IP Simulation

The "walkthrough" is built around this simple example project running a simulation on a floating point adder from Lab 08. File here

There have been a couple requests about how to simulate IP within our framework.  It gets really tricky and annoying since you've got to write some extra scripts for globbing among other things, so I'm putting together a much "simpler" way to do it that uses Vivado's project mode.

While we could make this work with our lab-bc thing, that needs its own updated scripts to handle this so this would be best done having an actual copy of Vivado.  Luckily you can get this by logging into one of the lab machines that has Ubuntu on it (eecs-digital-33.mit.edu and above!)

Log in with your name over ssh (same one from lab 8).

Set up a new project like you would normally, but don't worry about the lab-bc remote stuff. It can be there if you want, but you don't need to use it since we have access to Vivado directly.. Note git is installed on lab machines so you're welcome to clone your project repo and whatever.

Anyways, make a new script called sim.tcl. Into it you can place the following (though you'll likely need to change it for your custom use case).

create_project -force -part  xc7s50csga324-1 ip_tb ip_tb


read_verilog -sv [ glob ./hdl/*.sv ]
read_verilog  [ glob ./hdl/*.v ]
#read_mem [ glob ./data/*.mem ]
read_verilog -sv [ glob ./sim/*.sv ]

read_ip ./ip/adder/adder.xci
generate_target all [get_ips]
synth_ip [get_ips]

set_property top core_tb [get_fileset sim_1]
synth_design -top core_tb
launch_simulation
restart
open_vcd
log_vcd *
run all
flush_vcd
close_vcd

The script, in general is good, but you can change the following things about it:

create_project -force -part  xc7s50csga324-1 ip_tb ip_tb

This line is making Vivado build an entire "project" from your source material. Note a "project" is a very specific structured thing in Vivado. We've been using Vivado in non-project mode so far. Project-mode compiles and builds slower, though one nice thing about it is it lets us manage a lot of non-verilog files and source material in a light-weight manner. I called my "project" ip_tb in this particular file, but you can call it whatever. Note it will influence what folders get created. You can technically use different names for those two arguments, but it is probably better to just make them both the same which is why ip_tb is listed twice there.

read_verilog -sv [ glob ./hdl/*.sv ]
read_verilog  [ glob ./hdl/*.v ]
#read_mem [ glob ./data/*.mem ]
read_verilog -sv [ glob ./sim/*.sv ]

The lines above are basic tcl lines used to bring in all your RTL files (as well as show how to bring in mem or mem.h files in case you need to). In this particular I could probably comment out the two read_verilog lines targeting the hdl directory since I'm just running a single sim file on a single IP module, but I'll leave them here for reference.

read_ip ./ip/adder/adder.xci
generate_target all [get_ips]
synth_ip [get_ips]

The lines above are how you include your IP files into your project. Really only the first one needs to be customized for each file. Since we recommend keeping the IP's in separate named folders, I think it is not possible to have a one-liner bring in all IP...so bring them in specifically by name here. Here I'm just including a copy of the float adder IP from lab 08.

set_property top core_tb [get_fileset sim_1]

This line above sets a testbench of interest (in this case core_tb from the core_tb.sv module that was in the project) as the "top" of the project. This is important because when we launch the simulation this will be used as the entry point! It also says the results of this simulation will be in a sim_1 directory. That can be named anything to be honest.

Finally:

launch_simulation
restart
open_vcd
log_vcd *
run all
flush_vcd
close_vcd

These lines basically just tell Vivado to launch a simulation and then dump the contents to a VCD. You'll get that same "ERROR something something dump.vcd". Like before ignore that.

Now if everything ran fine, the dump.vcd file will be buried deep down into the file structure that Vivado created.

In the case of the starter files included here it ends up in:

core2/ip_tb/ip_tb.sim/sim_1/behav/xsim/dump.vcd

That can be transferred out or whatever and then viewed. In this particular simulation I put the number: 'h3fa9999a into both sides of the adder (which is 1.32500004768 in IEEE floating point). I add them and you'll see (or should see) your resulting dump.vcd shows that the result of adding that is 'h4029999a which is 2.65000009537. The only way that would happen (other than lottery-winning-levels of chance) would be if the floating point adder IP is actually being simulated properly. So good!

Note if you are using version control, try not to version control the actual "project" tree that Vivado creates (ip_tb in this instance). There are tons of temp files in it and you'll just make your version control history needlessly complicated. It is like people who version control a powerpoint file or something...like really and then poor git tries to do a merge on that mess. Version control your source files, but derived ones should not be. If you stick with FPGAs and do more complicated builds there are things like checkpoints and stuff which you'll start to use, but for most of you I don't think that will be needed.