[Libre-soc-bugs] [Bug 523] demo program needed showing register dependencies

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Thu Oct 29 09:09:00 GMT 2020


--- Comment #6 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---

cycle-accurate simulator is defined by convention initially i believe by the
academic community as that the state is full up-to-date even when there is a
single clock cycle, one-for-one with the instruction that was executed in that
clock cycle.

if the simulator takes 6 cycles to complete an instruction such that after
issue and one cycle the state is checked and it has *not* been updated to
reflect the changes anticipated by that just-issued instruction then this is
NOT a cycle-accurate simulator, it is a HARDWARE (microarchitecturally
specific) accurate simulator.

running nmigen pyrtl is such a hardware accurate simulator, and speedups are
possible by using cxxsim (eventually) or verilator (most conveniently via
litex) right now.

to create a cycle accurate simulator (running linux kernels like spike does) we
will need a full software simulation of both a XICS interrupt controller *and*
the simulation of PTEs, TLBs and a full RADIX MMU (if we don't have the MMU we
have to make heavily significant patches to the ppc64 linux kernel.  that
paul's 25+ years experienced team avoided doing that and added an MMU to
microwatt instead should give you an indicator there)

again, note that even with an MMU the state needs to be updated immediately in
the cycle that the instruction is issued, *not* 5 cycles later.  main memory
reads, normally taking 100 cycles again, are *not* simulated, they are, again,
assumed to complete immediately.  L1 and L2 caches are *not* simulated in a
cycle accurate simulator because these are fully transparent as far as any
given individual instruction is concerned.

for this exercise we have a very simple and immediate-focus set of requirements

what we need here is a very quick way to be able to continue the conversation
we started about Write-after-Write hazards in an on-the-fly iterative fashion.

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

More information about the libre-soc-bugs mailing list