[Libre-soc-bugs] [Bug 1073] Microwatt verilator sim - setting up chroot and documentation

[bugzilla-daemon at libre-soc.org]

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

--- Comment #2 from Andrey Miroshnikov <andrey at technepisteme.xyz> ---
After our conversation on IRC:
https://libre-soc.org/irclog/latest.log.html#t2023-04-27T16:38:23

(In reply to Luke Kenneth Casson Leighton from comment #1)
> don't do that arbitrarily.  you need to enable the FST compile option
> which outputs gtkwave traces then go look at them.
> 
> > What would really help is some way to measure the progress of the simulation
> > (and that it's not just sitting, running NOPs).
> 
> gtkwave trace, as i mentioned on the last call.

I was able to convert using vcd2fst and open the .fst file in gtkwave. The
problem seems to be with the core being idle.

Looking at the bram.dump in the hex editor, I see these:
pc         ff000000 insn ffffffff msr 8000000000000001
pc         ff000004 insn ffffffff msr 8000000000000001
pc         ff000008 insn ffffffff msr 8000000000000001
                          rd @ 00000100 di                0 sel ff ........
                          rd @ 00000101 di                0 sel ff ........
And so on...
Looks like PC is starting at 0xff00_0000, which follows the soc.vhdl and
microwatt.h definitions for DRAM init.


I found the arguments you added for using the BRAM dump or verilator.save
files:
-s FILENAME
Example: ./microwatt-verilator bram.dump
Loads a previous dump of the BRAM (which allows you to resume from where you
left off)

+[TICKNUMBER]
Example: ./microwatt-verilator +1999990
Loads from save called "verilator.save.1999990".

However it took me a while to finally understand how arguments are passed to
verilator itself (using the +verilator prefix).

Found the list of runtime verilator args that can be passed:
https://verilator.org/guide/latest/exe_sim.html

None of those seem relevant. Do I need point the sim to a starting address, or
do I need to supply a binary instead?

I would've thought that if the microwatt reset address is set to where the code
is located, it should begin executing.

One more thing I tried looking before finishing for today is looking at the
ghdl synthesis in the Makefile.
On line #233 and #235 of the Makefile, the (generic?) options -gRAM_INIT_FILE
as well as -gRESET_ADDRESS specify the RAM init file to be passed to ghdl,
however I haven't found any documention on these options at all.

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