[Libre-soc-dev] first stage new grants "passed", planning needed for 2nd

Dmitry Selyutin ghostmansd at gmail.com
Sat Feb 24 18:05:01 GMT 2024


On Fri, Feb 23, 2024 at 9:45 PM lkcl <luke.leighton at gmail.com> wrote:
> i emailed michiel, he sent to my lkcl at lkcl.net address which
> is still having problems [that i cannot resolve]
> ...
> they're not. i am in touch with Michiel directly.

Ack, thank you! I'm looking forward to news regarding this issue.

> > I still have to think about the budget for each task. Meanwhile you
> > can think about administrative and conference budgets and probably can
> > add some tasks.
>
> yes.

I took a hard guess based on 939 that the administrative (this
includes discussions, cooperation, tracking the tasks, etc.) will take
somewhat similar percentage, and deliberately put 5K. I did the same
for conferences, but that's just a wild guess, feel free to adopt as
you see fit. I'll just note that if we allocate a lot it'd be an awful
if we can't participate in any conferences or write any articles due
to occupation with code or docs or whatever. So the budget here must
be chosen wisely. Probably the wording must be more flexible and less
conference-article bound.

> we can pick a simpler ISA if that helps?
> or one you are familiar with?
> x86 for example?

Having spent a lot of time with x86, I'd say choosing it would be a
real disaster. :-) No offence, but in terms of its assembly and
disassembly it's a real maintenance hell.
But that's just mumbling, RISC-V is OK per se as "yet another
architecture we may use as a basis", there's another, more important
thing below.

I've noticed we also have SVP32/48/64 mentioned. For PPC, things were
simpler: we have 32-bit instructions, add a 32-bit prefix, bang, we're
done. That's SVP64 for PPC.
Note that I intentionally omitted PO9 from the task: I consider
migration to that format, if this is going to happen, a standalone big
task (not perhaps for a separate grant, but certainly out of scope
here).
Do we have an established format for other encoding types (I assume
these come from RISC-V instruction types)?
If not, I'd say that at most we should raise a task "develop SVP32/48
prefix encoding schemes" and be happy with that only, and implement
only SVP64 for RISC-V.

I'm deeply worried about time constraints. Could you, please, remind
me of the overall timeline? That is, when (if?) it's accepted, how
much time do we have?
Even with these tasks, we have an awful lot to handle, and I suspect
we have to be careful here to ensure this is actually _doable_.

-- 
Best regards,
Dmitry Selyutin



More information about the Libre-soc-dev mailing list