- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi:
there are a lot of timing violations after synthesizing the SDRAM controller,the constrained clock is 150M. I noticed that the latch clock is about half period faster than the launch clock , but the launch clock and latch clock are in the same clock domain,which lead to a lot of timing violations. I just want to know how to constraint the clock skew between launch flip-flop and latch flip-flop.is there anyone can help me? thank you in advance!Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The info messages don't have enough detail. Run TimeQuest and do a report_timing -setup -detail full_path -npaths 2 -pairs_only -panel_name "2 worst paths" -file "worst_paths.txt"
Feel free to attach the text file. I doubt the source and destination are on the same clock. You're using a PLL(hence negative delays) and they always drive a global clock tree, so the skew would be minimal. Anyway, the TimeQuest report will help analyze it better.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes ,the source and destination are on the same clock , and the clock of SDRAM controller comes from the PLL.
thank you!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you attach the report? They both originate at pll_clk, but something is causing huge skew. Either they're not on a global, or one of them goes through a gated clock(that's my guess without seeing the report).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ahh, I missed the oExt delay. This isn't an internal transfer, where clock skew is bad, but an external transfer to an output port. That being said, you're latch clock delay is usually 0(unless a source synchronous output), but in your case it's negative. The problem is that you're using the PLL clock as the external clock. The PLL clock name should never be used in a set_input/output_delay constraint. The -clock option of this constraint is saying what clock drives the external register off chip. The analysis you're getting will look at the clock tree up to the PLL output and then have it magically jump off chip. I talk about this in the Getting Started section of the user guide:
http://www.alterawiki.com/wiki/timequest_user_guide Anyway, create a virtual clock: create_clock -name clk_ext -period 6.666 Then have your I/O constraints based on this, e.g.: set_output_delay -max 2.5 -clock clk_ext [all_outputs] The Clock Network Delay on your latch clock will go to 0, which will help setup timing and it should meet timing. (Note that your setup time is 6.666ns and your external delay is 2.5ns, so you're basically asking the FPGA to get its data out in 6.666-2.5 ns, or 4.166ns. Also, be sure to do your timing analysis in TimeQuest, not just that info message you're posting. There is a more detailed breakdown there.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This problem has been solved after creating the virtual clock.
Thank you !
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page