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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sun Jun 7 04:23:45 BST 2020


--- Comment #74 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(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

(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

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.

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

More information about the libre-riscv-dev mailing list