[libre-riscv-dev] Libre RISC-V Requirements Specification document

[Luke Kenneth Casson Leighton]

Yes, Daniel, feel free to go for it on an FPU (in nmigen, you good with
that?). Want to write a draft  spec first so we all are happy with it, or
shall I do one? Also it will be a really good standalone project, useful
for other CPUs. More later.

On Thursday, January 10, 2019, Jacob Lifshay <programmerjake at gmail.com>
wrote:

>
> it that way, saving both power and area. We may want to include
> partitioning all the way to 8 8x8 fma to support low-precision neural
> networks.


I have a friend who would be extremely interested in that.


>
>  Each of the multipliers would need to support signed*signed,
> signed*unsigned, and unsigned*unsigned.
> I think it's a good idea to build in the extra shifters to support denormal
> numbers without slowing down, also allowing us to avoid data-dependent
> timing allowing the fma units to be useful for cryptography and mitigating
> spectre-class bugs as well.
> Notably, avoiding data-dependent timing means we can't short-circuit things
> like Infinity/NaN or division. It also means that we don't need to have as
> many pipeline stages that can write to the register file allowing us to not
> need as many write ports.


 It's complicated... I came up with a way to do full "nameless" operand
forwarding. It bypasses the regfile entirely and cleanly, without needing
total state destruction and rollback if an exception occurs.

As a result we should be able to get away with 4 32 bit banks of 2R1W, even
for repeated FMAC, the proviso being there that the src accumulator must be
the dest of the previous FMAC. This case is the one I worked out how to
detect.

Btw Daniel, Jacob, the scoreboard OoO system absolutely does not care what
the pipeline length is, or even if there isn't one. FSQRT and FDIV can
therefore be done as blocking units, without detrimental consequences.

L.


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68