Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
15774 Discussions

Timing Analyzer: Top Failing Paths

SparkyNZ
New Contributor II
330 Views

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?

u0JIeiM

 

If I disable the SignalTap instance, this reduces to:

MmDseo7

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.

 

0 Kudos
1 Solution
SparkyNZ
New Contributor II
274 Views

@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?

View solution in original post

9 Replies
sstrell
Honored Contributor III
318 Views

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
New Contributor II
311 Views

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

HrlKlCC

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

?

VCO5JjU

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
New Contributor II
310 Views

@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
New Contributor II
298 Views

@sstrell In my efforts to get rid of the above 3 timing errors, I have completely stripped my design right down to nothing.

module SystemVerilogTest1( input logic  sw1, input  logic clk, output logic clkFast );
  
logic tck, tdi, tdo, cdr, eldr, e2dr, pdr; 
logic sdr, udr, uir, cir, e1dr, bypass_reg;
logic [3:0] ir_in;
logic [3:0] ir_in_copy;
logic ir_out;

vJTAG v(
 .tdo (tdo),
 .tck (tck),
 .tdi (tdi),
 .ir_in(ir_in),
 .ir_out(ir_out),
 .virtual_state_cdr (cdr),
 .virtual_state_e1dr(e1dr),
 .virtual_state_e2dr(e2dr),
 .virtual_state_pdr (pdr),
 .virtual_state_sdr (sdr),
 .virtual_state_udr (udr),
 .virtual_state_uir (uir),
 .virtual_state_cir (cir)
);

always_ff @ (posedge tck) begin
end

Clock100 clock100(
	.inclk0( clk ),
	.c0( clkFast ) );

always_ff @( posedge clkFast )
begin
end

endmodule

 

I still have the below problems:

SparkyNZ_0-1672190613759.png

 

I have attached my .sdc file too. I must have something wrong in the .sdc file surely?

sstrell
Honored Contributor III
282 Views

Sorry, I didn't see that you were using the virtual JTAG IP.  I've never used it before so I'm not familiar with how you need to constrain it, but clearly your issue has something to do with it.  The user guide makes no mention of anything to put in .sdc.

https://www.intel.com/content/www/us/en/docs/programmable/683705/20-3/instantiating-directly-in-hdl....

SparkyNZ
New Contributor II
275 Views

@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
Honored Contributor III
273 Views

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
Moderator
249 Views

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
Moderator
174 Views

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


Reply