Unit tests and ISACaller Simulator implementation exists for the various Draft ISA instructions to be proposed under bug #952 (NLnet 2022-08-051) but HDL for inclusion in Libre-SOC Core does not yet exist. There are approximately 50 new IEEE754 Transcendental instructions to be added, several bitmanip instructions, and the BigInt 3-in 2-out (64-bit carry) instructions. ---------------------------------------------------------------- (TODO: link to the appropriate OPF ISA WG bugs: #NNNN #NNNN) (overlaps with https://bugs.libre-soc.org/show_bug.cgi?id=1025#c0, we need to resolve what goes where) general instruction groups, the priority needs to be on instructions used in cryptographic primitives: * TODO: bigint mul ops * TODO: bigint div op (should merge task with fremainder and other div/rem/sqrt ops, probably as another top-level task rather than as part of this bug or #1025) * TODO: bigint shift ops * TODO: post-update load/stores * TODO: shift load/stores lower priority: * TODO: fptrans as a 1-in 1-out pipeline (see mtspr/mfspr and mtmsr/mfmsr for guidance on the register-profiles) * TODO: [f]minmax* * TODO: bitmanip insns (both Libre-SOC & PowerISA v3.1B ops missing in soc.git) * TODO: sadd* shift-add ops * TODO: PowerISA v3.1 byte-rev ops & grev* * TODO: quadword atomic load/store: lq/stq/lqarx/stqcx. * TODO: gpr<->fp moves/conversions (just integration of computation pipeline(s) into rest of cpu, actual computation pipelines are part of #1025) * TODO: maddrs/msubrs/maddsubrs * TODO: pcdec. * TODO: set[n]bc[r] * TODO: FFT fp add/sub/mul ops * TODO: others that aren't in the openpower-isa.git markdown files yet...
as mentioned on irc: i think the budget on https://bugs.libre-soc.org/show_bug.cgi?id=1026 needs to be bigger, eur 8000 could be justified for fptrans by itself...
(In reply to Jacob Lifshay from comment #1) > as mentioned on irc: (please always provide the link) > i think the budget on https://bugs.libre-soc.org/show_bug.cgi?id=1026 needs > to be bigger, eur 8000 could be justified for fptrans by itself... if you go back through the history you'll find i had to crush this budget several times, allocating its budget to other tasks. can you "TODO-list" comment #0 so that each group can be assessed? (fptrans would be under bug #1025, you need to read all of these milestones as a "set") if there really isn't enough budget we allocate it to something else and skip the HDL entirely, put in another Grant request.
(In reply to Luke Kenneth Casson Leighton from comment #2) > (In reply to Jacob Lifshay from comment #1) > > as mentioned on irc: > > (please always provide the link) https://libre-soc.org/irclog/%23libre-soc.2023-07-30.log.html#t2023-07-30T17:37:40 > > > i think the budget on https://bugs.libre-soc.org/show_bug.cgi?id=1026 needs > > to be bigger, eur 8000 could be justified for fptrans by itself... > > if you go back through the history you'll find i had to crush this > budget several times, allocating its budget to other tasks. can you > "TODO-list" comment #0 so that each group can be assessed? this bug? sure, i can do that later. > > (fptrans would be under bug #1025, you need to read all of > these milestones as a "set") i understood this bug to include fptrans since that's explicitly mentioned, whereas #1025 seems to exclude implementing new ieee754fpu.git hw which is needed for some fptrans ops such as fremainder (that should probably go in the fp/int divide pipeline) > > if there really isn't enough budget we allocate it to something > else and skip the HDL entirely, put in another Grant request.
(In reply to Jacob Lifshay from comment #3) > i understood this bug to include fptrans since that's explicitly mentioned, > whereas #1025 seems to exclude implementing new ieee754fpu.git hw which is > needed for some fptrans ops such as fremainder (that should probably go in > the fp/int divide pipeline) since that's not the case, the task descriptions need to be edited to make that clear
(In reply to Jacob Lifshay from comment #3) > > if you go back through the history you'll find i had to crush this > > budget several times, allocating its budget to other tasks. can you > > "TODO-list" comment #0 so that each group can be assessed? > > this bug? sure, i can do that later. added to https://bugs.libre-soc.org/show_bug.cgi?id=1026#c0 if insns shouldn't be part of this bug, please copy them to the correct bug and don't just delete them.
one task that imho deserves special mention since I think it should be split out from both this task and #1025 is fremainder, divmod2du, and other div/rem/sqrt ops since they'd probably all go in the same fp/int div pipeline and need to be merged together.
(In reply to Jacob Lifshay from comment #6) > one task that imho (gentle reminder could you please use "in my HUMBLE opinion" less? it gets quite irritating as this project is goal-oriented not ego-oriented.9) > deserves special mention since I think it should be split > out from both this task and #1025 is fremainder, divmod2du, and other > div/rem/sqrt ops since they'd probably all go in the same fp/int div > pipeline and need to be merged together. yes - register profiles again. there's a page on them on the wiki. plus shared functions (micro-coded ops) aka FSMs (like microwatt's FPU). needs careful design though, they can get out of hand very quickly (MW's FP FSM is 4,500 lines). hmmm we need an HDL "design strategy task". can go under this one as a subtask.
(In reply to Jacob Lifshay from comment #5) > (In reply to Jacob Lifshay from comment #3) > > this bug? sure, i can do that later. ta. > added to https://bugs.libre-soc.org/show_bug.cgi?id=1026#c0 that's big enough to justify an entire new grant. drat. ok can i suggest changing this to a documenting "planning HDL strategy" task, decreasing it slightly and allocating to other areas?
(In reply to Luke Kenneth Casson Leighton from comment #7) > (In reply to Jacob Lifshay from comment #6) > > deserves special mention since I think it should be split > > out from both this task and #1025 is fremainder, divmod2du, and other > > div/rem/sqrt ops since they'd probably all go in the same fp/int div > > pipeline and need to be merged together. > > yes - register profiles again. there's a page on them on the wiki. ah, yeah, that too. I was thinking of sharing pipelines because all of the div/mod/sqrt stuff has similar hardware that can be shared. (In reply to Luke Kenneth Casson Leighton from comment #8) > (In reply to Jacob Lifshay from comment #5) > > added to https://bugs.libre-soc.org/show_bug.cgi?id=1026#c0 > > that's big enough to justify an entire new grant. drat. > ok can i suggest changing this to a documenting "planning HDL strategy" > task, decreasing it slightly and allocating to other areas? sounds good to me, though I think we could squeeze a few insns under this budget: * post-update load/stores * set[n]bc[r] * [f]minmax* * fp/int moves * bigint shift ops all of those should be pretty simple new hw or simple extensions of existing hw
(In reply to Jacob Lifshay from comment #9) > ah, yeah, that too. I was thinking of sharing pipelines because all of the > div/mod/sqrt stuff has similar hardware that can be shared. yes. needs planning. and diagrams. shriya has offered last week to do some, this would be perfect. > (In reply to Luke Kenneth Casson Leighton from comment #8) > sounds good to me, though I think we could squeeze a few insns under this > budget: > > * post-update load/stores > * set[n]bc[r] > * [f]minmax* > * fp/int moves > * bigint shift ops > > all of those should be pretty simple new hw or simple extensions of existing > hw agreed, and no need to adjust this budget - fit within available. ok i think we're probably done on this one?
(In reply to Luke Kenneth Casson Leighton from comment #10) > (In reply to Jacob Lifshay from comment #9) > > > ah, yeah, that too. I was thinking of sharing pipelines because all of the > > div/mod/sqrt stuff has similar hardware that can be shared. > > yes. needs planning. and diagrams. shriya has offered last week to do some, > this would be perfect. yeah, i'm thinking we use goldschmidt div/sqrt with a final step to do fixup and/or mod/rem, which gives us all of div, rem, mod, sqrt, and rsqrt plus fp versions of those. it would need a wide (a bit >64 bit) mul-add unit or two and the rom tables (pretty small, on the order of a few hundred bits). alternatively, if we want a much smaller unit, we'd just need a few add/sub, but it would be 20-60 cycles instead of ~15. > > > (In reply to Luke Kenneth Casson Leighton from comment #8) > > > sounds good to me, though I think we could squeeze a few insns under this > > budget: > > > > * post-update load/stores > > * set[n]bc[r] > > * [f]minmax* > > * fp/int moves > > * bigint shift ops we can adjust the list somewhat as we go, since those may be simpler or more complex than fits in the eur 8000 budget. > > > > all of those should be pretty simple new hw or simple extensions of existing > > hw > > agreed, and no need to adjust this budget - fit within available. > ok i think we're probably done on this one? sounds good!