Open mole99 opened 3 years ago
I have limited knowledge of what I am doing, but was trying this out on VCS (which I am not really used to). Anyway, for what it is worth, this is as far as I got (full traceback hidden below, but I think this is the relevant part):
Warning-[VPI-CT-NS] VPI function is not supported
The VPI function 'vpi_get_vlog_info' is not supported in the compiler.
Please fix the code being referred to by the '-load' compile option.
Command line: vcs -sverilog -full64 +vpi testbench/div_int.sv testbench/div_int_tb.sv -load fstdumper.so
Thanks for giving fstdumper a try!
It seems that VCS does not support vpi_get_vlog_info
. Fortunately for us, this function is not really necessary for fstdumper to work, as it is only used to get command line args to decide whether to optimize for space or speed.
I have updated the main branch to exclude this feature when EXTENDED_ARGS
is not defined.
Could you pull the changes and give it another try?
Thanks! I got it to work, but no signal changes were saved, so similar behavior as with ModelSim(?).
I added a PR with the Makefile rule (and updated the vsim one as it used a deprecated switch).
Unfortunate to hear that no signal changes were saved. But maybe this gives us a chance to debug this problem.
I might find some time during next week to add debug statements to the VPI callbacks so we can see which ones are being called. Currently I don't have access to VCS, so if you could rerun fstdumper after the debug statements are added, that would be very helpful!
I have now added the debug output. Just pull the changes and run as normal. Maybe then we will see what is wrong.
This is the output for iverilog, yours should look similar - or not ;)
Not sure how relevant it is, but for the record:
I got a segmentation fault during the build process (when running cfs_ident_exec
). However, it still produces a simv
that appears as if it is running OK (except for fst not dumping).
I also tried using -debug_acc+all
to enable all debug features (maybe better than the current option, which I just found by googling a bit). However, behaves the same (core dump and identical output).
The debug output is different than I would have expected. It does not even seem to call the first value change callbacks, which is strange.
Honestly, I am not sure if it makes sense to continue down this path. This version of the fstdumper was more of a proof of concept. The bulk of the code comes from Icarus Verilog and therefore honers its quirks. It does not help that almost every simulator seems to have differences in how VPI is handled. There ought to be one interface that provides safe methods that have been tested for most simulators...
Luckily, there is! Maybe you have heard of cocotb. It supports a number of open and proprietary simulators. It does this through an interface called GPI: Generic Procedural Interface. In the background, VPI, VHPI or FLI is used to communicate with the simulators. More importantly, they have figured out the quirks of the various simulators.
By targeting GPI, fstdumper could run on most simulators (or at least on most Verilog simulators if we want to register our system tasks like $fstDumpvars
).
One drawback could be that fstdumper would support less features under GPI, but the most important objects are supported: GPI Library Reference.
I have created a small test to build GPI together with some code that queries some signals in the design and prints their changes: gpi-test. If this is working for you I will look into attaching fstapi
to it.
Have you had a chance to try it out? :)
Ahh, sorry, I missed the final sentence of that post...
I hope to be able to try it out next week once back to the office.
Blame is on me, I should have started on a positive note ^^
Thanks! By the way, there is no hurry, because I am currently occupied with other work.
Try out the
fstdumper
on Synopsys VCS.