Forum Discussion

USo00's avatar
USo00
Icon for New Contributor rankNew Contributor
5 years ago

Design works with Quartus Prime Lite v15.1.0, but not with Quartus Prime Lite v17.0.2

Hello,

I have a design with a custom QSPI communication link between a TI DSP processor and a MAX 10 FPGA. The design was tested to work consistently with valid data exchange when the FPGA code is compiled using Quartus Prime Lite v15.1.0.

We purchased the Intel Functional Safety Data Package and so we would like to migrate to Quartus Prime Lite v17.0.2, since it is the latest qualified version for the FSDP. We would eventually move to Quartus Prime Standard v17.0.2 once we need the extra logic lock and partition features for functional safety, but for now we are using the Lite edition.

But when we compile with v17.0.2, the QSPI data exchange no longer works and we get intermittent bad data. We also tried an earlier working commit of our code that used standard SPI instead of QSPI and the same thing happened where it worked with 15.1.0, but not 17.0.2.

Is there some Quartus default setting that I need to change to make the compilation results more similar to what I get with v15.1.0?

I've attached the project .qsf file which remains the same whether I compile with v15.1.0 or v17.0.2, as well as the project .qdf file which was generated when I compiled with v17.0.2.

When I compare the assignment_defaults.qdf file from the Quartus 17.0.2 installation directory with the one generated by 17.0.2 in the project, there are only a couple of lines that are different:

Default settings:
set_global_assignment -name OCP_HW_EVAL Enable
set_global_assignment -name EDA_EXTRA_ELAB_OPTION "\"\"" -section_id ?

Project .qdf setting:
set_global_assignment -name OCP_HW_EVAL -value OFF
(the EDA_EXTRA_ELAB_OPTION line from the default is missing in the project .qdf, so I'm assuming the default in the installation directory is being used?)

Are there any important settings that I would need to change to make the compilation more similar?

I'm a bit of a beginner, so any help would be appreciated.

Thanks,

Udell

13 Replies

  • ak6dn's avatar
    ak6dn
    Icon for Regular Contributor rankRegular Contributor

    Your project file references a timing constraint file (andromeda.sdc) but you don't include it.

    Do your designs compile AND MEET TIMING under both versions of Quartus?

    How much slack is there in the worst case timing path(s)?

    Are your clocks correctly constrained?

    • USo00's avatar
      USo00
      Icon for New Contributor rankNew Contributor

      Hi ak6dn,

      Thanks for your response.

      I can't provide the .sdc as it was written by a contracted 3rd party and there may be some intellectual property issues. The compilation reports said all timing constraints were met for both versions.

      I've attached the sta reports if you want to look at them, but here is a worst-case summary from the sta report:

      Slow 1200mv 100C model

      • setup slack:
        • v15.1.0: 0.273
        • v17.0.2: 0.250
      • hold slack:
        • v15.1.0: 0.256
        • v17.0.2: 0.282
      • recovery slack:
        • v15.1.0: 1.974
        • v17.0.2: 2.176
      • removal slack:
        • v15.1.0: 0.932
        • v17.0.2: 0.710
      • min. pulse width slack:
        • v15.1.0: 3.434
        • v17.0.2: 3.434

      Slow 1200mv -40C model

      • setup slack:
        • v15.1.0: 0.412
        • v17.0.2: 0.356
      • hold slack:
        • v15.1.0: 0.250
        • v17.0.2: 0.281
      • recovery slack:
        • v15.1.0: 2.123
        • v17.0.2: 2.276
      • removal slack:
        • v15.1.0: 0.833
        • v17.0.2: 0.624
      • min. pulse width slack:
        • v15.1.0: 3.434
        • v17.0.2: 3.434

      Fast 1200mv -40C model

      • setup slack:
        • v15.1.0: 0.454
        • v17.0.2: 0.585
      • hold slack:
        • v15.1.0: 0.097
        • v17.0.2: 0.110
      • recovery slack:
        • v15.1.0: 3.488
        • v17.0.2: 3.564
      • removal slack:
        • v15.1.0: 0.389
        • v17.0.2: 0.292
      • min. pulse width slack:
        • v15.1.0: 0
        • v17.0.2: 0

      I would have thought if timing constraints were met in both cases, it would work with either version of Quartus. Also, all inputs and outputs between the SPI/QSPI module and top level ports are registered.

      One thing I noticed, in the .sdc file, the QSPI ports all have set_false_path and there's a note from the 3rd party who wrote it, that this was done since all inputs are synchronized with 2x registers to the 100MHz clock (which I've confirmed in the source code).

      Some extra background is the original standard SPI version of the code was developed by 3rd party FPGA experts. Then I modified the SPI to have a QSPI read mode as well. Both versions work when compiled with v15.1.0, but don't work when compiled with v17.0.2.

      Thanks for your help.

      • ak6dn's avatar
        ak6dn
        Icon for Regular Contributor rankRegular Contributor

        Several comments:

        SET_FALSE_PATH is going to remove any timing constraints on those paths from the referenced clock. So you won't know of those paths are failing as they aren't checked. Be careful with using that directive.

        Do both SPI and QSPI modes fail in the v17 compiled version? Or just QSPI?

        The timing values in the reports for v15 vs v17 are pretty close, so it looks like nothing is wildly off.

        Which generated clock is the SPI logic working off?

  • KhaiChein_Y_Intel's avatar
    KhaiChein_Y_Intel
    Icon for Regular Contributor rankRegular Contributor

    Hi,


    Since there is no other questions, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.


    Best regards,

    KhaiY