Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
15387 Discussions

Simulation: override warnings during compilation, and Intel rebranding breaking generated scripts

SimonRichter
New Contributor I
965 Views

Hi,

I'm trying to get simulation for IP cores running from the command line.

My first approach was to generate a tcl script using

 

ip-setup-simulation --output-directory=simulation --quartus-project=test

 

which gave me a file "mentor/msim_setup.tcl" below the "simulation" directory.

Evaluating this with

 

vsim -batch <<EOF
source mentor/msim_setup.tcl
com
EOF

 

failed, as it couldn't find "altera_mf.altera_mf_components" and several others.

Investigating, I stumbled across

 

if ![ string match "*ModelSim ALTERA*" [ vsim -version ] ] {
  ensure_lib                       ./libraries/altera_ver/
  vmap       altera_ver            ./libraries/altera_ver/

 

in the generated script -- this seems to set up the libraries for the included components when not using the Altera version of ModelSim that includes precompiled libraries -- but the current version of ModelSim uses "INTEL" in place of "ALTERA", and a hyphen to separate it:

 

$ vsim -version
Model Technology ModelSim - INTEL FPGA STARTER EDITION vsim 2020.1 Simulator 2020.02 Feb 28 2020

 

Fixing this, I can compile the IP cores in the current project, with lots of warnings like

 

# ** Warning: (vlog-2070) Existing unprotected design unit "altera_xcvr_reset_control" is being recompiled as protected.

 

The reason for this is obvious: both the unprotected (in the ..._sim directory) and the protected (in the ..._sim/mentor directory) generated sources are compiled. This seems to have little adverse effect other than doubling compilation time and generating lots of warnings, though.

The top-level components of each IP core seem to be generated inside the "work" library, which is inconsistent with synthesis (where the QIP file uses the instantiation name as a library name), but consistent with the SPD files that don't use a library name, e.g.:

 

set_global_assignment -library "ddr3_bottom" -name VHDL_FILE [file join $::quartus(qip_path) "ddr3_bottom.vhd"]

 

in the QIP vs

 

 <file path="ddr3_bottom_sim/ddr3_bottom.vhd" type="VHDL" />

 

in the SPD.

Adjusting the SPD files and regenerating everything, I can then compile the IP cores that do not have simulation files (like ALTIOBUF) and my actual design, and run the simulation, either interactively

 

vsim -batch <<EOF
set TOP_LEVEL_NAME "tb_serdes"
source mentor/msim_setup.tcl
elab
EOF

 

or noninteractively

 

vsim -batch -t ps -L altera_mf_ver -L cyclonev_ver -L cyclonev_hssi_ver tb_serdes <<EOF
vcd file tb_serdes.vcd
vcd add -r *
run -a
EOF

 

All of this still involves manual processes, either because "elab" starts a new instance, so I cannot send a "run -a" as part of the batch, or because I need additional knowledge about which libraries need to be loaded.

My goal is to automate the entire process so I can run it as part of a Continuous Integration pipeline, starting from IP generation (so I don't have to include generated files in version control, and for open source projects, so I don't run into copyright issues).

I have a working pipeline that can synthesize a project with the IP blocks reduced to just their retrieval info by regenerating the IP blocks, and now I'd like to also get simulation to run reliably.

Questions:

  1. is there a more relevant guide to setting up a scripted simulation environment than chapter 1.9.3 of the User Guide to Megafunctions?
  2. Are there workarounds or fixes for the problems during generation (names inconsistent with synthesis, warnings generated by double definitions, wrong library path due to failing check for "ALTERA")?
  3. Is there a good way to extract the names of libraries used, so I can automatically generate an appropriate command line for noninteractive simulation?

   Simon

0 Kudos
11 Replies
Nurina
Employee
894 Views

Hi Simon,


To answer your questions:

  1. We have a quick-start tutorial if that's what you're looking for: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/archives/ug-20093-17-0.p...
  2. I see that you're using the Cyclone V. Because this device is rather old, Quartus will use the older IP that are still under "Altera" for your project. Another reason why you're seeing this issue is that you're using a ModelSim version that is incompatible to your Quartus software. I believe that Quartus will use the older IP because of these reasons. Can you attach your .qar file so I can investigate?
  3. As far as I know, there isn't a way to do this. Although, I think this is a counter-productive solution, seeing as the errors relating to the libraries you mentioned are pre-compiled libraries.


Nurina


SimonRichter
New Contributor I
873 Views

Hi Nurina,

I've made a quick demo project that shows the problem, with just a PLL and a DDIO as IP components. My simulation setup was really close to the quickstart tutorial already, and I've redone it in the test project to rule out errors here.

The `sim.tcl` script included in the archive follows the layout of the template generated from the quickstart tutorial, the `sim.sh` just wraps generation and ModelSim invocation:

 

ip-setup-simulation --output-directory=simulation --quartus-project=sim_test
cd simulation
vsim -batch -do ../sim.tcl

 

Inconsistent names

The name of the "doubler" component (the PLL in the test project) is doubler.doubler in synthesis, and requires a use clause, but work.doubler during simulation. I can work around that with pragmas, but that is far from ideal:

 

-- synthesis read_comments_as_HDL on
-- library doubler;
-- use doubler.doubler;
-- synthesis read_comments_as_HDL off

 

to make the library import conditional on synthesis, and

 

-- synthesis translate_off
	pll_inst : entity work.doubler
-- synthesis translate_on
-- synthesis read_comments_as_HDL on
--	pll_inst : entity doubler.doubler
-- synthesis read_comments_as_HDL off

 

to use the imported name during synthesis, and the name inside `work` during simulation. The DDIO component is not affected, as it uses an older format and is never loaded into a separate namespace (I also need to explicitly compile that in my sim.tcl script, as no SPD file exists for this component, so it is ignored by ip-setup-simulation).

Recompilation of shipped libraries

The generated ModelSim setup script (simulation/mentor/msim_setup.tcl) has a conditional section that isn't supposed to be executed when using the ModelSim included with Quartus, which recompiles the shipped libraries. For the simple project, that isn't much of an issue (just takes longer), but for the project that uses DDR3 memory and transceivers, these are less optimized models, which increases simulation time.

Removing the section between

 

if ![ string match "*ModelSim ALTERA*" [ vsim -version ] ] {

 

and the corresponding closing bracket from the generated msim_setup.tcl reduces both compilation time (dev_com becomes a no-op) and uses the shipped libraries.

With the sim.sh script in the QAR file, this can be tested by deleting the "simulation" folder (to start with a clean slate) and invoking the script as

 

rm -r simulation
./sim.sh f

 

This applies a (crude) fix that deletes the conditional sections.

My interpretation is that the ModelSim version included with Quartus is supposed to skip these sections always, but the branding update from "ALTERA" to "INTEL" broke this test.

Extracting the library names can be skipped when using the "elab" command as defined by the msim_setup.tcl script -- that includes all necessary -L options, and I can work with that, thanks for the pointer to the quickstart that shows how to actually make this usable.

   Simon

Nurina
Employee
858 Views

Hi Simon,


Glad your issue is solved.


However I would like to advise you, unless you compiled the libraries on Quartus Simulation Library Compiler tool, it isn't a good idea to edit the msim_setup.tcl script because everything in the script should be auto-generated by itself. You just need to make sure the script has QUARTUS_INSTALL_DIR correctly set, it should point to the directory of your Quartus installation.


I highly suspect your ModelSim version is not compatible to your Quartus software. This is often the reason why pre-compiled libraries have conflicts when trying to run simulation. Seeing as you are using ModelSim - INTEL FPGA Starter Edition 2020.1, you should use Quartus version 20.1 as it's the only Quartus version compatible with that version of ModelSim.


Table 2 of this page lists out the Quartus versions and their corresponding compatible ModelSim - INTEL FPGA version. You can also check the simulation tools support for your Quartus version in the Software and Device Support Release Notes: https://www.intel.com/content/www/us/en/programmable/support/support-resources/download/os-support.h...


Regards,

Nurina


SimonRichter
New Contributor I
850 Views

Hi Nurina,

I wouldn't call this "solved" though: I have workarounds that allow me to continue by editing autogenerated files -- as you say, that isn't a good idea, but at least it unblocks my progress.

I have ModelSim and Quartus installed from the same download archive (the 20.1.1.720 "full"), and no other versions of either are installed, so I can verify that this script has been generated with Quartus 20.1, and the libraries are also the ones included with Quartus 20.1 -- hence my assessment that the generated script is incorrect, as it checks for the wrong string in the version to assess whether the Quartus and ModelSim versions are compatible.

The mismatch between the QIP and SPD files seems to be a regression from earlier Quartus versions: I have an older project that uses Quartus 16.1, and generated IP blocks there are added to the "work" library for both synthesis and simulation, so at some point between 16.1 and 20.1 a decision was made to add a -library tag in the QIP file to move the main component of the IP block into a library, but the same change wasn't made for SIP files.

    Simon

Nurina
Employee
833 Views

Hi Simon,


Thank you for your feedback and clarification. I shall report this matter to engineering. Is your Quartus software the Pro, Standard or Lite edition?


Regards,

Nurina


SimonRichter
New Contributor I
822 Views

Hi Nurina,

thank you!

This is the Lite edition for now.

   Simon

Nurina
Employee
805 Views

Hi Simon,


Do you have a Quartus project that shows the error? Our internal team wants to reproduce the error. If so, please attach here.


Thanks,

Nurina


SimonRichter
New Contributor I
796 Views

Hi Nurina,

the one attached to my earlier post should work for that -- it compiles and simulates because I've used the workarounds I've described, and the scripts implementing those are included in the archive.

   Simon

Nurina
Employee
758 Views

Hi Simon,


While your project did show that the workarounds worked, we still don't have proof that the error/warning is showing up, so I cannot report this to our engineering team. Using Quartus Prime Lite 20.1.1, I tried deleting the simulation files from the project then have it go through the normal NativeLink flow, and there were no problems. I also tried this demo design just to make sure and there were no problems either: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/archives/ug_gs_msa_qii-1...


I think you might have gone through a bad installation, could you try to reinstall both Quartus and ModelSim? Maybe try Quartus version 20.1 instead.


Regards,

Nurina


Nurina
Employee
638 Views

Hi,

We did not receive any response to the previous question/reply/answer that I have provided, thus I will put this case to close pending. Please post a response in the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you with your follow-up questions.

Regards,
Nurina

P/S: If you like my comment, feel free to give Kudos. If my comment solved your problem, feel free to accept my comment as solution!

SimonRichter
New Contributor I
629 Views

Hi Nurina,

 

it will take a few days as I'm swamped with other work right now.

 

   Simon

Reply