I just want to be clear that if you define FPGA_FULL it has to be
defined in addition to FPGA, not instead of. The main difference of this
mode is that it uses a much more accurate model of the memory and runs
rather slowly. Another difference is that it puts more reliance on
Xilinx supplied IP than the normal version, so there is a potential for
a version incompatibility there. Unfortunately the member of the team
that worked on this release has left us now and I don't know if he is
still in a position to comment on your specific problem if it's not the
ambiguity that I mentioned above.
Regarding the possibility of a bug in VCS, it certainly can happen,
especially if you ignore warnings produced during compilation. As
academic users we are not entitled to support so any bugs just have to
be worked around by changing the syntax of the Verilog and/or the
version of the tool that is used. Sometimes a bug can crop by using a
newer version that incorporates optimisations that are not valid for all
circumstances. This may seem strange but the semantics of system Verilog
are not fully defined in every circumstance. The best that can be said
is that if a program works in several different simulators from
different vendors it is probably OK.
On 31/03/18 02:30, golirev wrote:
Hi, LowRISC team:
When I do FPGA_FULL mode simulation of your Untethered lowRISC version 0.2 got
from Git, I meet a strange simulation scenario showed below.
I found the "mem_nasti.r_ready[0:0]" always be 0, but driver of this wire is
1. The driver is "io_nasti_r_ready" of Rocket. So the Hellworld test will be
But if I use FPGA mode to do the simulation for same Helloworld test, it is successful
finished. I have checked the difference of this two simulation modes,
the difference are forcus on DRAM(xilinx mig) ,clock and reset generation which is not
the interface the Helloworld test need to access.
I am not sure it is VCS simulator's problem, or I missed something?
Waiting your feedback. Thank you!