hossein1387/BARVINN

Simulation project build not successful

schegde opened this issue ยท 9 comments

Hi! Thank you for maintaining this project. I am interested in exploring the bit-serial architecture of the BARVINN project. I am trying to compile the simulation flow ON WINDOWS PC to take a look at some example tests for convolution. However I am currently encountering some issues with compilation.

  1. Some documentation on the versions of python and fusesoc (and Vivado) used by you would be great to know! Looks like from your sourcing script you are using Vivado 2019.1 . On my windows PC, I created a conda environment with Python 3.10.5 ; fusesoc==1.12.0
    2 . I see that for a fresh clone of the project and submodule update I get this error:
    image
    I went in and looked around a bit and figured out from MVU repo README, that we need to run vivado -mode batch -nolog -nojournal -source gen_xilinx_ip.tcl first time to generate these needed IPs (This would a good thing to add into the main BARVINN readme)
  2. I see that you guys using a Kintex Ultrascale part for MVU synthesis : set xilinxpart xcku115-flva1517-2-e in MVU/.tclscripts/common.tcl . I am using a 2019.1 free Vivado Webpack installation . I changed it to xcku5p-ffvd900-3-e one of the devices supported in the free WebPack version. I am able to generate the MVU IPs for this different part . (This should be fine I assume?)
  3. Finally when I run fusesoc run --target=sim barvinn (after setting the mvu and pito risc v libraries in fusesoc) I get the following error:
    image.
    Please let me know if you have come across this issue, and I can provide more information if you need!

Hi! Thank you for your interest in BARVINN and submitting this issue!
What you did is right, you need to create blk_mem_gen_v8_4.v RAM IPs for MVU. We are planning to use generic RAMs for simulation for MVUs as well. You can follow this issue in MVU repository obilaniu/MVU#38.

I checked your log and it seems everything is going well right before static elaboration phase. It seems FuseSoc is causing an issue. I checked FuseSoc github page and this error has been reported for Windows machines before: olofk/fusesoc#543

Unfortunately, I do not have access to a Windows machine. Could you try on a linux machine? if not, maybe try to use the latest FuseSoc (not from pip). You can do the following:

python3 -m pip uninstall fusesoc
git clone https://github.com/olofk/fusesoc.git
cd fusesoc
python -m pip install -e .

This should install the latest FuseSoc in edit mode (you can also install in normal mode). Please let me know if this fixes the issue.

Thanks for the pointer! I am actually working with the latest version of fusesoc/edalize which already has the fix for the issue you linked. But something exactly similar to the issue you mentioned was happening here wherein, after the build, the --define XILINX=1 shown below in the build\barvinn_0\sim-xsim\config.mk file :
image

... was getting translated to --define XILINX 1 in the xsim commandline , leading to the error I posted in the previous comment. Looks like this is windows specific, and issue with fusesoc/edalize makefile build. I will follow up with them on how to fix this. For now I worked around by manually editing the config.mk line to just say VLOG_DEFINES = --define XILINX , and with this I am able to bringup the XSIM GUI! . Thanks for the assistance!,

Some more followup questions, please answer at your convenience:

  1. There is one warning in the xsim log: Loading decoder rom. WARNING: File /users/hemmat/MyRepos/pito_riscv/verification/common/decoderlut.mem referenced on C:/work/BARVINN/build/barvinn_0/src/barvinn_0/deps/pito_riscv/vsrc/rv32_decoder.sv at line 128 cannot be opened for reading. Please ensure that this file is available in the current working directory. ; I can see this file version-controlled, should I just drop this in the cwd of the xsim directory? (Or whats the fix needed to get rid of your local path being propagated here)
  2. [ERROR] 0 ns Expecting a command line argument $finish called at time : 0 fs : File "C:/work/BARVINN/build/barvinn_0/src/barvinn_0/verification/lib/testbench/testbench_config.sv" Line 19 . Couple more other errors like this, looks like xsim is not getting firmware/rodata arguments from the commandline? (Also I guess I will have to change these paths below in the barvin.core file to my localpaths...)
    image

Nice find! Thanks for following up and letting us know about the possible issues in Windows machine.

Regarding your questions:

1- The decoderlut.mem file should be loaded from pito's verification/common/ directory. I will check in a fix shortly.
2- Now that you have simulation working, you can start programming BARVINN. You need two hex files, one to program data memory rodata section and one for programming instruction memory firmware. You can use the Makefile provided in https://github.com/hossein1387/BARVINN/blob/master/csrc/conv/Makefile to generate these files. The path you pointed out here should match to ones that are produced by the Makefile.

We are in the process of attaching the MVU array memory and pito to a HOST machine through a memory subsystem. We are working with ALVEO U200 card and soon, these memories will be connected to a proper memory subsystem that can be programmed from a host machine.

thanks again for your questions and please let me know if you have more questions.

Understood. I will open a new issue encountered in the conv2d csrc compilation to generate the above firmware files. I will close this issue as the simulation related aspects are all clarified and reproduced as intended. Thanks for the support!

How long does it take usually on your end for the full sim to complete (for conv2d test)? ๐Ÿ˜…

it is pretty fast (less than 10min). you might be looping! I think there is a while(1) some where :D

maybe here?

while(1){};

yea just found that in the code , sounds good, I am able to see signals crunching (like start and done signals) in sim, I do see quite a few signals in sim at X too. I guess not everything is necessary to be initialized/configs written to by the code?

there are some configs that are not used right in the code above (like scaler, fixed point, bias etc). The MVU_code_gen generates the expected output as well. You might want to check the mvu outputs. You can do that using the code available here:

function int get_mvu_bank_val (mvu, bank_num, addr);

It is actually limited to mvu0 but it is the same procedure for other mvus. You just need to adjust the hdl path.