Forum Discussion
New ContributorCyclone 10 GX Simulation Files
Below is engineering's feedback:
---
Simulation netlist (which customer is using) is not meant for formal verification.
having said that we should be including all parameters in the ATOM instances in simulation netlist.
---
From engineering feedback, it seems that the simulation netlist generated is not meant for OneSpin formal verification.
When formal verification is enabled(set_global_assignment -name ENABLE_FORMAL_VERIFICATION ON), I checked that these are the verilog netlist generated under the project directory:
verification/
rtl/ (This directory contains all rtl files)
elaborated/ (Directory contains files used in RTL vs Elaborated Verification)
synthesized/ (Directory contains files used in Elaborated vs Synthesized Verification)
planned/ (Directory contains files used in Synthesized vs Planned Verification)
placed/ (Directory contains files used in Planned vs Placed Verification)
routed/ (Directory contains files used in Placed vs Routed Verification)
retimed/ (Directory contains files used in Routed vs Retimed Verification)
final/ (Directory contains files used in Routed/Retimed vs Finalized Verification)
You could perform Formal Verification at each stage
elaborated : To verify RTL vs elaborated netlist
synthesized : To compare elaborated vs synthesized netlist
planned: To compare synthesized vs planned netlist
placed: To compare planned vs placed netlist
routed: To compare placed vs routed netlist
retimed: To compare routed vs retimed netlist
final: To compare routed/retimed vs finalized netlist
Will inform if there is further update from the engineering.
Regards,
Richard Tan
Super ContributorIn order to aid your issue effectively, could you provide a test case and detailed steps to duplicate the issue?
Can you provide a step-by-step description of the actions you took leading up to the error? This will help in understanding the context and reproducing the issue.
Are you using the latest Quartus Pro version v24.1?
What is the expected result, and what is the actual result you are seeing from your side?
Kindly provide as much detail as possible. Please note that usually only the engineering team has access to using OneSpin tool.
This will requires the engineering team to investigate on this and please keep in mind that any work involving our engineering team may take some time, ranging from a few days to a few weeks, depending on the complexity of the issue.
Thank you.
Regards,
Richard Tan
New ContributorI will attempt to create an example project that shows this, but it will probably take a bit due to the fact that this project does not touch the internet.
We compile the design using the GUI and then we have tried two different simulators, but both give the same result afterwards. Afterwards we click on the play button next to EDA Netlist Writer and export a Verilog HDL simulation file. We have done this using both Questa Intel and ModelSim with Verilog HDL.
When we combine (multiple teams handling different aspects of the FPGA) and compile the designs, we use the ModelSim output to verify things. We then run Onespin against the previous version simulation output to make sure that nothing drastically changed unexpectedly there. This has not been giving us errors because both simulation files are missing the same things. But then we run Onespin on it against our original design as an effort to verify that nothing unusual has been changed by us or Quartus, this is where we are seeing the issue. In our original design we are using differential IO and we have the attribute differential_mode = true on it. In the simulation designs that are output from QuartusPro, this attribute is not present (it defaults to false). Therefore Onespin believes this IO is not differential and declares the designs to not be equivalent. In previous designs where we have done this (like Quartus 17) we have never had this issue before.
Thus far we have locked in on Quartus Pro 22.4 as our standard for the files. But we have attempted this in Quartus Pro 24.1 and we have seen the same result. So at the moment we are keeping 22.4, unless if this issue gets corrected, then we will probably switch because we will have to. Normally we lock in one version of Quartus and keep it throughout, because of the way we lock specific groups of components to different teams and we have seen designs change previously when we have switched versions of Quartus in the middle of a project.
