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

[bugzilla-daemon at libre-soc.org]

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

--- Comment #76 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cesar Strauss from comment #75)

> > 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.

both great, it sounds like this was easier.  fantastic.

> 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. 

yes, very important.  they are the "data is valid and needs to be written"
signals.

they are needed because some ALUs will decide *themselves* if the data is to be
written (XER.so for example is done this way.  you don't know if it will be
modified)

i.e. if the "ok" flag is False then the write.req must definitely not be raised


> 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.


ah, right: if you find any of those... yyyees, strictly speaking this should
not happen: there is supposed to be detection of the data/ok and to create a
suitable Record, matching it.  i may have missed some of those and used Signal
instead.

at least however nmigen will cope fine by flattening and correctly transferring
the data.


> This works, but relies on the "ok" field being the
> last field.

that definitely needs documenting.


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

star.  this one is important for the predication, and when we get to SIMD.

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