Forum Discussion

SparkyNZ's avatar
SparkyNZ
Icon for Contributor rankContributor
3 years ago
Solved

Timing Analyzer: Top Failing Paths

Can somebody please help me. I am getting unpredictable behaviour with my design so I have been looking at the Top Failing Paths report.

This appears to be full of SignalTap timing issues?

What do I need to do to fix these problems?

If I disable the SignalTap instance, this reduces to:

Are the issues in the second screenshot the cause of the many SignalTap issues in the first screenshot?

And what exactly is the problem in the second screenshot? It all seems to relate to the Virtual JTAG IP Core. What am I doing wrong?

I have attached my project.

  • @sstrell I have a new theory!

    I copied the generated vJTAG module from my Cyclone IV project to the Cyclone V project.

    When creating a new vJTAG module, it asks for the device that it is intended for. Could it be that the one generated for the Cyclone IV is not truly compatible with the Cyclone V?

    I just created a brand new project, added a VJTag and 100Mhz PLL clock same as in the example above: No problems with the timings whatsoever in Top Failing Paths

    So I guess in future I should be regenerating any IP Core components when I move between different FPGA hardware platforms?

9 Replies

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor

    Did you add the altera_reserved_tck clock constraint to your .sdc file or maybe you used a derive_ command (like derive_clock_uncertainty) and they got added automatically? You don't normally need to do that. It's recommended (though I've never understood quite why because the JTAG hardware is fixed) to add JTAG constraints to the .sdc from a template available in the text editor. This gets rid of "unconstrained paths" in the JTAG hardware. You can do that and/or remove the altera_reserved_tck constraints from your file.

    • SparkyNZ's avatar
      SparkyNZ
      Icon for Contributor rankContributor

      @sstrell I just tried removing all tck references in my .sdc file. That is still giving me the same altera_reserved_tck complaints:

      I can't remember how the tck entries were put into the .sdc file. I was following some help on adding constraints and I either clicked on "Create Clock" or "Generate Clock" in the Timing Analyzer.

      Whereabouts would I find the JTAG constraints template that you refer to? Are you referring to the likes of this:

      https://www.intel.com/content/www/us/en/docs/programmable/683081/17-1-1/jtag-signals.html

      https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/manual/mnl_timequest_cookbook.pdf

      ?

      There's about 5 pages worth of .sdc "code" in that section. Would a straight copy and paste of this be enough? I wouldn't have a clue what needs changing in that template "code".

      I shouldn't need to add constraints for SignalTap at all should I? The whole reason I ended up here was because my design just stopped working when I added a SignalTap signal monitor.. then when I added another, it started to work again. Whenever I am close to resolving part of what I am working on, the whole thing just stops working - particular around the vJTAG interface.

      • SparkyNZ's avatar
        SparkyNZ
        Icon for Contributor rankContributor

        @sstrell By pasting in the JTAG template that I found, the tck errors seem to be less:

        ..but they are still present. I just left the "--customize here--" sections as the defaults.

        Is there something else I need to do to get rid of these?

        I also re-enabled the SignalTap instance and I now only have the same 3 lines above - so it does look better.

    • SparkyNZ's avatar
      SparkyNZ
      Icon for Contributor rankContributor

      @sstrell I have a new theory!

      I copied the generated vJTAG module from my Cyclone IV project to the Cyclone V project.

      When creating a new vJTAG module, it asks for the device that it is intended for. Could it be that the one generated for the Cyclone IV is not truly compatible with the Cyclone V?

      I just created a brand new project, added a VJTag and 100Mhz PLL clock same as in the example above: No problems with the timings whatsoever in Top Failing Paths

      So I guess in future I should be regenerating any IP Core components when I move between different FPGA hardware platforms?

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor

    IP needs to be regenerated when making this type of move and often when moving to a new version of Quartus. The tool does check if you have IP generated from an older version of Quartus but it doesn't check if IP was originally generated for a different device. Glad you figured it out!

  • SyafieqS's avatar
    SyafieqS
    Icon for Super Contributor rankSuper Contributor

    Paul,


    Glad you are able to resolve it. Yes, IP generation should be run every time there is changes in component, device and etc. To avoid any issue on timing and compatibility.

    Let me know if there is any other concern.


  • SyafieqS's avatar
    SyafieqS
    Icon for Super Contributor rankSuper Contributor

    I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, 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.


    p/s: If any answer from community or Intel support are helpful, please feel free to mark as solution, give Kudos and rate 10/10 survey