DRAM problem when simulating with VCS

[saber cheng]

Hello, this time i met another problem

in order to simplify this problem, i use the official Adder apps to do simulation with VCS

but here are some problems with the DRAMSim2 file

here are the problem descriptions:

1. first i run "spatial Adder --synth --fpga=VCS"

2. cd gen/Adder && make

3. errors occurred: displayed in the following picture

 

but i do find these function in the responding file, for example, the getMemorySystemInstance. i find it is defined in the MultiChannelMemorySystem.cpp

but the "MultiChannelMemorySystem.h" isn't included by the "Dram.h"

by the way which edition of VCS can support the VCS Simulation

[Matt F]

Hi Saber,

We have tested with vcs 2017.03 and 2015.09.

I've never seen this error before.   In your other message, you mentioned that one of the Makefiles tries to include a directory that doesn't exist but that seems to be a mistake (that I will fix) that happens to not affect anything.

Can you paste the full output before these errors so I can see if I can poke around and recreate this?  When I run make, I see this command which include the dirs "-I../dramShim -I../DRAMSim2" in the command, and DRAM.h is including DRAMSim2/DRAMSim.h which has the "MultiChannelMemorySystem" class.

vcs -full64 -quiet -timescale=1ns/1ps -sverilog -debug_pp -Mdir=Top.csrc +v2k +vcs+lic+wait +vcs+initreg+random +define+CLOCK_PERIOD=1 +lint=TFIPC-L +libext++.v -y /cad/synopsys/dc_shell/J-2014.09-SP3/dw/sim_ver +incdir+/cad/synopsys/dc_shell/J-2014.09-SP3/dw/dw02/src_ver -cpp g++ -LDFLAGS "-no-pie -L../ -ldramsim -lstdc++ -Wl,-rpath=../" -CFLAGS "-O0 -g -I/cad/synopsys/vcs/K-2015.09-SP2-7/include -I../../cpp/SW -I../../vcs.sw-resources -I../dramShim -I../DRAMSim2 -I../ -fPIC -std=c++11 -L../ -ldramsim -lstdc++ -Wl,-rpath=../" -o accel.bit.bin *.v *.sv sim.cpp

[saber cheng]

ok, this time i will attach all of my output info after i ran make.

And you see the command you paste. 

when you run this comman, you are under the "verilog-vcs" folder.

The paths "../../cpp/SW" and "../../vcs.sw-resources" are wrong, they should be "../cpp/SW" and "../vcs.sw-resources"

But it seems that we cannot change this command directly because i found that the Makefile in TOP.csrc will be generated according  the parameter you defined before.

my problem seems strange,  i will continue to work on it.

By the way, do i need the synopsys DW to run VCS simulation because i have seen that the default path "/cad/synopsys..." has been defined

[saber cheng]

Hi Matt

it seems that this problem is generated because of my gcc version

so i want to know the exact  gcc version which spatial-quick start support

[Matt F]

Hi Saber,

We have tried with gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) and gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04).  Which version are you using?  I can try poking around with that and seeing if I can recreate this.

If you want to edit the Makefiles, they are all getting copied from vcs.hw-resources to verilog-vcs/.  If you run make clean between runs, it will clear target/ and verilog/ and should copy the files from the resources directory fresh.  We do have DW_HOME hardcoded to this path /cad/synopsys/dc_shell/J-2014.09-SP3/dw., but I don't think you actually need it for vcs simulation flow.

[saber cheng]

Hi Matt,

this seems really strange. i have tested several gcc version from 4.4, 4.7, 4.8. (My VCS is 2016.06, Ubuntu 16.04 LTS)

if i use 4.4 the c++11 will be an error

if i use 4.7/4.8, there will be some errors about the undefined reference in some *.so(you can see my attach file). So when use the 4.7/4.8, i have add the option when run vcs "-Wl,--no-as-needed"

But still get the undefined functions in Dram.h(the functions defined in MultiChannelMemorySystem.h just like what i posted). And if i include this, there will be some errors about the macro READ and Write have multiple definitions 

[Matt F]

Hi Saber,

This is very strange.  I would expect these functions to be part of verilog/libdramsim.so and it should be able to see this when it compiles from verilog/Top.csrc/ because it has the flag -L../  . Can you check if that file exists after it crashes and if it has all of the correct functions in it (strings libdramsim.so | grep setCPUClockSpeed)?   I see your log tries to compile to this file with "g++ -g -shared -Wl,-soname,libdramsim.so -o libdramsim.so AddressMapping.po PrintMacros.po Transaction.po BusPacket.po BankState.po CommandQueue.po MemorySystem.po SimulatorObject.po MemoryController.po Bank.po MultiChannelMemorySystem.po Rank.po ClockDomain.po IniReader.po" and it says it completed successfully.

[Matt F]

I think I found the cause of this.  I don't have access to vcs 2016, but I see that this issue happens with 2014 (undefined functions in Dram.h and a bunch of undefined references in *.so in the vcs lib).  It looks like it is because vcs 2014/2016 injects the provided LDFLAGS in a different order than 2015/2017 and happens to include --no-as-needed in a convenient location.  If you run the vcs command without -quiet, it crashes at:

g++  -o ../accel.bit.bin  -no-pie -L../ -ldramsim -lstdc++ -Wl,-rpath=../   -Wl,-rpath-link=./ -Wl,-rpath='$ORIGIN'/accel.bit.bin.daidir/ -Wl,-rpath='$ORIGIN'/accel.bit.bin.daidir//scsim.db.dir  sim.o  _csrc0.so  pre_vcsobj_1_1.so  rmapats_mop.o rmapats.o rmar.o           /cad/synopsys/vcs/I-2014.03-2/amd64/lib/libzerosoft_rt_stubs.so /cad/synopsys/vcs/I-2014.03-2/amd64/lib/libvirsim.so /cad/synopsys/vcs/I-2014.03-2/amd64/lib/liberrorinf.so /cad/synopsys/vcs/I-2014.03-2/amd64/lib/libsnpsmalloc.so    /cad/synopsys/vcs/I-2014.03-2/amd64/lib/libvcsnew.so /cad/synopsys/vcs/I-2014.03-2/amd64/lib/libuclinative.so   -Wl,-whole-archive /cad/synopsys/vcs/I-2014.03-2/amd64/lib/libvcsucli.so -Wl,-no-whole-archive       ./../accel.bit.bin.daidir/vc_hdrs.o    /cad/synopsys/vcs/I-2014.03-2/amd64/lib/vcs_save_restore_new.o -ldl -lm  -lc -lpthread -ldl

In 2015, the equivalent command it runs is this, which happens to have :

g++  -o ../accel.bit.bin   -Wl,-rpath-link=./ -Wl,-rpath='$ORIGIN'/accel.bit.bin.daidir/ -Wl,-rpath=./accel.bit.bin.daidir/ -Wl,-rpath='$ORIGIN'/accel.bit.bin.daidir//scsim.db.dir  -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu -Wl,--no-as-needed -no-pie -L../ -ldramsim -lstdc++ -Wl,-rpath=../ -rdynamic  sim.o   objs/amcQw_d.o   _48507_archive_1.so  SIM_l.o    uM9F1_0x2aB.o   rmapats_mop.o rmapats.o rmar.o  rmar_llvm_0_1.o rmar_llvm_0_0.o          /cad/synopsys/vcs/K-2015.09-SP2-7/linux64/lib/libzerosoft_rt_stubs.so /cad/synopsys/vcs/K-2015.09-SP2-7/linux64/lib/libvirsim.so /cad/synopsys/vcs/K-2015.09-SP2-7/linux64/lib/liberrorinf.so /cad/synopsys/vcs/K-2015.09-SP2-7/linux64/lib/libsnpsmalloc.so    /cad/synopsys/vcs/K-2015.09-SP2-7/linux64/lib/libvcsnew.so /cad/synopsys/vcs/K-2015.09-SP2-7/linux64/lib/libsimprofile.so /cad/synopsys/vcs/K-2015.09-SP2-7/linux64/lib/libuclinative.so   -Wl,-whole-archive /cad/synopsys/vcs/K-2015.09-SP2-7/linux64/lib/libvcsucli.so -Wl,-no-whole-archive       ./../accel.bit.bin.daidir/vc_hdrs.o    /cad/synopsys/vcs/K-2015.09-SP2-7/linux64/lib/vcs_save_restore_new.o -ldl -lm  -lc -lpthread -ldl

I was able to fix the Dram.h and *.so errors using vcs 2014 by adding "-Wl,--no-as-needed" as the first arg in vcs.hw-resources/Makefile CC_OPTS LDFLAGS "CC_OPTS=-LDFLAGS "-Wl,--no-as-needed -no-pie -L../ -ldramsim -lstdc++ -Wl,-rpath=../" -CFLAGS "-O0 -g -I${VCS_HOME}/include -I../../cpp/SW -I../../vcs.sw-resources -I../dramShim -I../DRAMSim2 -I../ -fPIC -std=c++11 -L../ -ldramsim -lstdc++ -Wl,-rpath=../""  Is this where you tried adding -Wl,--no-as-needed?  I was able to get your combination of errors by adding this flag at the end of LDFLAGS, but adding it to the beginning should fix all of them.   I'll republish the java jars with this change in a bit.

[saber cheng]

Hi Matt

It works as what you said. Before i add this "-Wl, --no-as-needed" like CC_OPTS=-LDFLAGS "-no-pie -L../ -ldramsim -lstdc++ -Wl,-rpath=../ -Wl,--no-as-needed" ..., this helped to solve the undefined reference, but can help to solve the DRAM.h. I think this must be due to the version of VCS. Thanks a lot.

And I found another problem(I'm not sure whether this is still a problem for you). In the file "FringeContextVCS.h" and at the line 369, there is code "EPRINTF("Design ran for %lu cycles, status = %u/n", numCycles, status)"

It reports that the usigned int doesnt match with status where status is typed of status_t

So i think this code should be like this

"EPRINTF("Design ran for %lu cycles, status = %lu/n", numCycles, status.bits)"

Hope my understanding is right, and this can help

[saber cheng]

Hi Matt.

I'm Very sorry to disturb you again because i received another problem when run VCS backend flow.

After i do "make" in the generated file, and i do "bash run.sh "args" ", i received this problem like:

[WARNING]: DELITE_NUM_THREADS undefined, defaulting to 1

Executing with 1 thread(s)

Note-[RT_BS] Larger stack needed

  Note: Bumping stack limit from 8192 to 8194 Kbytes.

Command line: ./verilog/accel.bit.bin

--- Stack trace follows:

Dumping VCS Annotated Stack:

No context available

Error: Received ID does not match sent ID

Assertion (cmd->id == id) failed in ../vcs.sw-resources/FringeContextVCS.h, 279

Top: ../vcs.sw-resources/FringeContextVCS.h:279: void FringeContextVCS::connect(): Assertion `0' failed.

Realistic DRAM Simulation

it seems very strange, because the first time i run this, it passed well. But when i want to do more simulation to verify my code, i got this and cannot pass any more.

so i want to ask for help.

[Matt F]

Hi Saber,

Thanks for pointing those out.  I made that change to status.bits and a few other changes so it hopefully gives fewer gcc warnings/errors. I will publish later today.

For the received/sent id error, this error usually happens because something went wrong when it tried to run verilog/accel.bit.bin.  Your log shows that something messed up, but its not clear what.  I've seen this error myself if I do things like transfer a compiled dir to another machine or switch around the .so files or other libraries it needs between when I compile and when I run, but there could be other things that cause this to happen.  Can you try these things and let me know if anything works?

1)  rm -rf the gen/<app> directory and recompile the spatial app to see if this fixes it

2)  Check if anything is obviously wrong with verilog/accel.bit.bin.  In gen/<app>, try running "export LD_LIBRARY_PATH=./verilog/DRAMSim2:${LD_LIBRARY_PATH} && ./verilog/accel.bit.bin" and see if it can start the process ([SIM] Sim process started!).  It should crash about Command 0 not supported shortly after.

3) Use gdb to see if anything looks wrong.  Edit gen/<app>/scripts/vcs.mk and put "-g" in LDFLAGS and recompile.  Then add "gdb --args" before "./Top $@ 2>&1 | tee sim.log" in run.sh.  Run the app and set a breakpoint just after the line "FringeContext *c1 = new FringeContext("./verilog/accel.bit.bin");" in cpp/TopHost.cpp, probably something like "b TopHost.cpp:36".  This line should spawn the process which hosts the verilog simulation and should report a PID for that process.  If it does, you can attach to that process with another gdb session with "gdb -p <PID>" and continue poking around.  Otherwise hopefully this explains exactly what is wrong with spawning the accel.bit.bin process.

I just found that vcs 2017 and 2018 crash due to something in Top-harness.sv but vcs 2014 and 2015 are fine, so maybe this is the problem you are seeing.  It complains about importing a dpi function and you can fix it by adding context to whatever line it complains about in Top-harness.sv (import "DPI" context function int tick();).  I also fixed this and will publish in a bit but you can try locally if you want

[saber cheng]

Hi Matt, i have tried as what you said

1) the first one, can not ensure it can work every time, sometimes it works, sometimes it not

2) i tried only once and it still not work

3) i didnt get what you said, i think this is because i'm not familiar with GDB, i'm sorry

i found some answers from the internet, they said this problem may be caused by the version of VCS i use. most of them said that the VCS 2016 is unstable

so i will try some other version.

by the way, this problem will occurs sometimes. And sometimes, it can works well even i dont change any thing. So i think the version of VCS should be responsible for this.

i will let u know, if it works with another version

thanks