[Libre-soc-bugs] [Bug 336] ALU CompUnit needs to recognise that RA (src1) can be zero

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sat Jan 2 13:20:53 GMT 2021


https://bugs.libre-soc.org/show_bug.cgi?id=336

--- Comment #75 from Cesar Strauss <cestrauss at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #74)
> (In reply to Cesar Strauss from comment #73)
> > (In reply to Cesar Strauss from comment #71)
> > The next step is to actually invent some new operations for the test ALU,
> > that do not make use of some of the read ports,
> 
> the simplest one there is just bit-inversion (o = ~a).  or, perhaps, add 1?

Thanks, but I ended up going with sign extension, there was already a MicrOp
Enum allocated to it. I also added a NOP, which does not use any read or write
ports.

> > and maybe add some write ports to it as well.
> 
> hmm i can't think of anything that would be needed to be very difficult, it
> only needs to be different and detectable.  how about add 1 for port 1 and
> subtract 1 for port 2?

Thanks, but I ended up implementing a simple condition register output port,
for all existing instructions, conditioned on the rc bit which was already
available on CompALUOpSubset.

So, there are now test cases that include all combination of masked read and
write ports.

Some observations:

1) It seems that MultiCompUnit depends on the ALU *.ok output fields being held
valid long enough into the write phase. In the test ALU, I tried holding *.ok
valid just for the duration of the ALU valid_o, and it didn't work. I ended up
instead directly decoding the input operation, combinatorially, into the *.ok,
so they do stay valid during the entire instruction cycle.

2) I noticed that, for the CompUnit outputs, MultiCompUnit strips out the *.ok
ALU output fields by flattening the Data Record (*.data and *.ok) into a
Signal, truncating it. This works, but relies on the "ok" field being the last
field.

I'm now moving on to the final task, of testing shadown/go_die.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the libre-soc-bugs mailing list