Simulating Ariane BRAM tests

[Mohamed Hamad]

Hello,

I have been trying to simulate Ariane BRAM tests; let us say "rv64um-p-mul.S" as an example

To do that, I thought of running protosyn and simply copy the resulting Vivado setup to a Modelsim setup. With that idea in mind, I ran the following protosyn command:
protosyn -b vc707 -d system -c ariane --x_tiles 1 --y_tiles 1 --no-ddr --bram-test rv64um-p-mul.S

In addition to all defined directives, all RTL files being sourced in Vivado's script were added to my Modelsim "-f verilog.fl", those that were Python processed were replaced with the *tmp* suffix.

With that setup, there were only two Xilinx IPs, bram_256x512 and uart16550. I used the blackbox stub for the latter as its functionality did not seem to interfere with my goal and for the bram, I used "write_verilog" on Vivado's compiled DCP of the bram.
As an alternative, I used a simple dual port memory to which I had initilized with readmemh's input being the data of the ".coe" file generated by Vivado.

Later, it seemed to be possible to quickly change the test by running a sims run and python make_mem_map.py on its output,
sims -sys=manycore -msm_run -x_tiles=1 -y_tiles=1 -ariane -precompiled rv64um-p-addi.S
python $DV_ROOT/tools/src/proto/make_mem_map.py -b vc707 -s bram -t rv64um-p-addi

At that point, I had a compiled RTL that can run any test by readmemh'ing the bram_map.log of make_mem_map.py
Unfortunately, the simulation did not seem to read the bram correctly and the test did not seem to really execute.

I would kindly like to ask for your help in getting this simulation setup to work.

Guess the key is somewhere in these files
PITON_BRAM_TEST_DEPTH macro directive in $DV_ROOT/design/chipset/include/chipset_define.vh
$DV_ROOT/design/chipset/io_ctrl/rtl/fake_boot.v
$DV_ROOT/design/chipset/rtl/storage_addr_trans.tmp.v
$DV_ROOT/design/xilinx/vc707/devices_ariane.xml

Probable related changes in openpiton-dev branch

grigoriy-chirkov committed: fix bram tests

Side questions,
Is it a must to use assembly tests with protosyn's --bram-test?
In a similar setup to mine, will the resulting bram_map.log from make_mem_map work with any sims run even non-assemly tests?
Say
sims -sys=manycore -msm_run -x_tiles=1 -y_tiles=1 -ariane hello_world_many.c -rtl_timeout=1000000 -log_all

Keep Pitoning,
Mohamed

[Mohamed Hamad]

Update:
Post Vivado synthesis simulation works so we can establish that my setup messed something up. Will give it a thorough look before reporting the result here.

[Mohamed Hamad]

Another update:

Seems like the UART module's functionality is important and that is why my local setup was all dead although the post synthesis simulation could boot the core.

Now to isolate the test simulation problem, let us ignore my faulty local setup.

I have tried to run the behavioral simulation of the protosyn's xpr project and the test does not seem to execute correctly.

Having a look at the trace_hart_0.log clarified that issue_commit_instruction is always prefixed with "000000fff1010..." which I presume to be incorrect.

[Jonathan Balkind]

Hi Mohamed,

 

This isn't a setup that we'd usually support simulation for and we haven't done any simulations in the Vivado simulator for some time so I'm not certain if I'll be a lot of help. However, based on when I recently ran a similar setup on the Nexys 4 DDR, I think this might be a bootrom issue.

 

Just to make sure: you said you're using the build files from after running the protosyn command you mentioned, right?

 

The simulation setup and pitonstream both use a bootrom which assumes the test has already been placed at 0x80000000 (the base of memory for Ariane). The OS-booting FPGA version assumes it can copy a boot sector from SD card into main memory and then jump to the DRAM base. I think that your defines may be setting the latter bootrom which tries to do things like print to the UART (which, if blocked, will block the core) and copy from the SD. If this is the case, then you want to use the other bootrom which is normally used by simulation/pitonstream, but you don't want to use the whole pitonstream setup. Try tying the following wire to use the baremetal bootrom: https://github.com/PrincetonUniversity/openpiton/blob/openpiton-dev/piton/design/chipset/rtl/chipset_impl.v.pyv#L992

 

As for running non-assembly test, you should be able to just run hello_world.c or hello_world_many.c with the make_mem_map stuff, provided you modify it to actually pass the ariane core arguments inside the script. I'm not sure that it's fully configurable at the moment as a standalone script.

 

Please let me know if any of this helps!

 

Thanks,

Jon

--
You received this message because you are subscribed to the Google Groups "OpenPiton Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpiton+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiton/fd3a1930-eb8f-494f-ab42-ec27333db621%40googlegroups.com.

[Mohamed Hamad]

Hi Jonathan,

Forcing the boot address to 0x80000000 did the trick. (Is this absolutely correct?)

This line to be precise caused it to be forced to 0xfff1010000. Guess commenting out the "ariane_bootrom" XML element from here would have also worked.

Doing the above worked correctly for the first memory word only and fortunately, the fake_boot_ctrl.v from the dev branch fixed it all.

In regards to using make_mem_map as a standalone script, running it after setting the MODEL_DIR environment variable to a directory that holds the mem.image file created by any sims run creates a readmemh ready bram_map.log and that suits my local setup best.

Kind regards,

Mohamed