- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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
?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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:
I have attached my .sdc file too. I must have something wrong in the .sdc file surely?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page