[libre-riscv-dev] [Bug 325] create POWER9 TRAP pipeline

[bugzilla-daemon at libre-soc.org]

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

--- Comment #78 from Cole Poirier <colepoirier at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #74)
> (In reply to Cole Poirier from comment #72)
> 
> > I'm having a difficult time understanding how to write the first test for
> > class TrapTestCase looking both at cr/test/test_pipe_caller and
> > logical/test/test_pipe_caller... Do I have to translate all the code that
> > was set up for CR into setting up for TRAP? Trying to think through it I
> > can't figure it out, and I suspect it is related to my previous comment
> > about not understanding how the test_pipe_caller, XXXInput/OutputData,
> > CompALUOpSubset, and CompTrapOpSubset, and the decoder, relate to and
> > interact with each other... I have a little idea of each but I'm doing the
> > 'freeze cause I don't understand' right now.
> 
> ok.  suggestion.  take alu test_pipe_caller.py and cut out absolutely every
> test_* except for one, make sure to pick one with only one assembly
> instruction.
> 
> (or take copy of tpc.py, call it tpc2.py)
> 
> then run it and load the generated alu_simulator.gtk in gtkwave.
> 
> at the top level you will see an instruction.
> 
> add that to the window.
> 
> then just go through the hierarchy adding signals.
> 
> look especially for these
> 
> fn_unit
> dest1
> dest2
> src1_i
> src2_i
> issue_i
> busy_o
> rd_go_i
> rd_rel_o
> wr go req as well
> 
> then go *back* to the source code (remember have SEVERAL files open at once)
> 
> note that "hey anywhere i have m.submodules those show up in the hierarchy!"
> 
> note that the Record contents also show up in the gtkwave output.
> 
> look at the debug output and note the instruction assembly code 0xNnnnff1234
> etc got outputted and that it also matches that toplevel signal in gtkwave.
> 
> the tree hierarchy in gtkwave will start to give you an idea of the
> interrelationships of the modules, in ways that staring at the static code
> simply cannot give you, and the  "time" dimension will show you valuable
> insights too.
> 
> once you have got used to this, add *one* more unit test back in, rerun
> tpc2.py, and hit ctrl-shift-r in gtkwave.
> 
> you should be able to track the change in outputs, the result from the
> operation, with what the debug output shows.

Thank you, this is the process for MUCH greater understanding I mentioned
above. I plan on working on this today after doing a more polished draft of the
b-deck, and fixing the trap() convenience function. Probably will work on this
for a few days until I feel like I'm starting to get a handle on things. Will
also work on translating psuedo code to nmigen for SPR tomorrow.

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