[libre-riscv-dev] IEEE754 FPU

[Luke Kenneth Casson Leighton]

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

On Thu, Feb 14, 2019 at 2:08 PM Aleksandar Kostovic
<alexandar.kostovic at gmail.com> wrote:
>
> I have done the unpack but I have no idea about that TODO stuff.

 i created a class called FPNum.  so z_e is now z.e, z is now z.v, z_m
is now z.m and z_s is now z.s.  etc.

> Have a
> look at the last few lines I added what would be print Verilog but it
> doesnt work.

 just use the python command "python3 blahblah.py generate -t v" for now.

> Also see the condition in unpack case. I didnt know what to
> use so i put x. i dont know what a 24'h0 in verilog would translate into
> something useful by nmigen.

nmigen Signals contain their width as a member variable, and when you
do an assignment, the width of what is being assigned is taken into
account.

so if you try to assign to a Cat that is too wide, nmigen will
*automatically* truncate it to the width of the variable it's being
assigned to.

likewise, straight python "numbers" (0b000101100, 53, 0x95) are
automatically assigned to the full width.  if you want to assign
*partial* widths, you do it via m.d.sync += signal[3:6] = 0b100

so... x in this case equals... zero :)  or 0x0.  or just... 0.


so i did a *partial* conversion to using FPNum... replaced all
z_{s/m/e} with z.{s/m/e}

also after talking on #m-labs irc channel i learned that it's not
possible to use verilog "&&" or "||" operators.  you have to use "&"
and "|" which is the bit-wise and/or operators.  it turns out that a
comparison (x == 5) will return a *single bit*, so doing (a & b) where
a and b are comparisons is perfectly fine.

the only thing: python's & and | operators take PRECEDENCE over ==, >,
<, >=, <= and so on.  so you *must* put brackets round the
comparisons, like this:

with m.If((z.e == -126) & (z.m[23] == 0)):

l.