Cyclone 10 GX Simulation Files

[MKwiec]

Certain ports and attributes are missing in the simulation outputs.  On our current project we use Onespin to verify that the output does things consistently. 

We have differential IOs in the project however, the output from the simulation file in Quartus doesn't have the attribute differential_mode.  So Onespin is telling us that the output of Quartus's simulation file isn't equivalent the input file because of the differential_mode.  We use a two step verification process we validate the original against the simulation output, then we validate the previous simulation output versus the current simulation output.

On the cyclone10gx_vsd, the port muxsel doesn't show up unless if it is used, Quartus has never done this previously.  

[RichardTanSY_Intel]

In 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

[MKwiec]

I 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.

[RichardTanSY_Intel]

Thank you for understanding. I will wait for your example project.

It would be helpful if you could provide any screenshots that might show the results.

Regards,

Richard Tan

[MKwiec]

Sample files that show this

[RichardTanSY_Intel · Accepted solution]

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

[MKwiec]

Sorry I went on vacation last week and have been side tracked.  I am glad to see there is a solution to this that seems to solve this.  I do have a question about this though.

Inside the verification directory it produced an IO with the differential_mode attribute.

The only issue is that the component is a twentynm_io_ibuf.  Should this be expected, because the input was a cyclone10gx_io_ibuf? 

If this is the solution, we can adapt to it, but I just wanted to get a little verification here first.

Thanks for the information thus far.

[RichardTanSY_Intel]

Is this behaviour can be duplicated using the previous design provided (iostandards_compare.v)?
I am unable to compile those files. Could you shares a simplified Quartus project .qar ?
Thank you.

Regards,

Richard Tan

[MKwiec]

Using the files that I gave you should produce the same thing with the setting of:

set_global_assignment -name ENABLE_FORMAL_VERIFICATION ON

This produced a verification directory.  Inside of this verification directory, inside of the verification directory it produced a .sv.  I believe this is what you wanted me to look at.  This sv contains the Verilog with the differential_mode set correctly.  This model is a twentynm_ component.  This is fine if this is the method that we need to go from here, from examining the differences between the two components in the atoms files, it is mostly just the names of them.   

Getting you a .qar could take quite a bit, but I would think the engineer you talked to previously could answer this very easily.  If I can produce a cyclone10gx by using twentynm models, this shouldn't be too much of an issue.  

[RichardTanSY_Intel]

Yes, you are right. They are the same, you can either use the twentynm_io_ibuf or the cyclone10gx_io_ibuf.

Regards,
Richard Tan

[RichardTanSY_Intel]

Hi.

From the engineering standpoints regarding the missing differential_mode attribute:

-----

From the description above, I understand there to be two issues:

 1. The differential_mode parameter is not written out.

 2. The muxsel port is not shown unless it's connected.

If you can't provide the customer's RTL, can you attach or point me to a design that contains an atom with a muxsel port and an IO in differential mode?

If needed, please provide the IO standard assignment that should be used to generate the type of IO buffer that displays the problems above.

If I have a design containing an atom with a muxsel port and an IO with differential_mode=true, I can figure out why they may not be shown.

I was unable to re-synthesize the iostandards.v or iostandards_compare.v files you provided.

The iostandards_compare.v file shows the use of the differential_mode parameter. It looks like the new parameter format that has been introduced in 24.3.

Did you generate that on a recent Quartus build? If so, do you have access to the customer's source code?

-----

Is it possible to provide the design with the above information?

Regards,

Richard Tan

[RichardTanSY_Intel]

Hi.

From the engineering standpoints regarding the missing differential_mode attribute:

-----

From the description above, I understand there to be two issues:

 1. The differential_mode parameter is not written out.

 2. The muxsel port is not shown unless it's connected.

If you can't provide the customer's RTL, can you attach or point me to a design that contains an atom with a muxsel port and an IO in differential mode?

If needed, please provide the IO standard assignment that should be used to generate the type of IO buffer that displays the problems above.

If I have a design containing an atom with a muxsel port and an IO with differential_mode=true, I can figure out why they may not be shown. 

I was unable to re-synthesize the iostandards.v or iostandards_compare.v files you provided.

The iostandards_compare.v file shows the use of the differential_mode parameter. It looks like the new parameter format that has been introduced in 24.3.

Did you generate that on a recent Quartus build? If so, do you have access to the customer's source code?

----- 

Is it possible to provide the design with the above information?

Regards,

Richard Tan

[MKwiec]

Richard Tan,

I do not have a full project using these parameters as you have asked.  But your previous steps of using the attribute:

set_global_assignment -name ENABLE_FORMAL_VERIFICATION ON

and grabbing the twentynm verilog files has been working for us.  So we have switched to using that output now.

One of my engineers informed me that the vsd can be ignored at the moment, because the module that is doing the voltage detection has been verified and separated.  

In other words your solution has allowed us to move forward.

Thank you,

MKwiec

[RichardTanSY_Intel]

I am glad to hear that you are able to move forward!

Now, I will transitioning this thread to community support. If you have any further questions or concerns, please don't hesitate to reach out. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within 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 on your follow-up questions.

Thank you and have a great day!

Best Regards,

Richard Tan