- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
before I start, I have read the Altera doc on this many times and often seem to end up confused one way or another though I have successfully constrained such interfaces before now. This one is slightly different. I have an internal PLL clock driving some logic which generates a source synchronous transmit interface at a decimated rate. Both the clock and data output are fed by registers. The internal clock ("pll1|clk[0]") drives a counter to produce a decimated version "tx_clk" (divide by 4) and the data output "tx_data" is arranged by logic to transition on the falling edge of tx_clock (so that the remote receiver can use the rising edge of the clock to capture the data). The following lines are what I have used previously, where tx_clk was at the same frequency as the internal clk (through use of a DDR output). You can see that TX_CLK has a -phase 180 option to indicate that it is inverted wrt clk. This seems to work fine. create_generated_clock -name TX_CLK -source {pll1|clk[0]} {tx_clk} -phase 180 set_output_delay -clock {TX_CLK} -max $OUTPUT_DELAY_MAX tx_data set_output_delay -clock {TX_CLK} -min $OUTPUT_DELAY_MIN tx_data -add_delay The question is how should I modify this to use a TX_CLK driven by a register and decimated down? I have tried the following but the fitter complains: "Warning (332088): No paths exist between clock target "tx_clk" of clock "TX_CLK" and its clock source. Assuming zero source clock latency." And timing fails, though my constraints don't seem to paint the correct picture for Timequest to do a proper analysis. create_generated_clock -name TX_CLK -source {surface_card_0|pll_tx_clk|altpll_component|auto_generated|pll1|clk[0]} {tx_clk} -divide_by 4 set_output_delay -clock {TX_CLK} -max $OUTPUT_DELAY_MAX tx_data -clock_fall set_output_delay -clock {TX_CLK} -min $OUTPUT_DELAY_MIN tx_data -clock_fall -add_delay Any help gratefully received. Thanks for reading.Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Should not you be using create_generated_clock in following way? create_generated_clock -name TX_CLK -source {surface_card_0|pll_tx_clk|altpll_component|auto_g enerated|pll1|clk[0]} [get_pins {div|q}] -divide_by 4 where instead of DIV you should mention your register name. Reference : https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/manual/mnl_timequest_cookbook.pdf ( Figure 3, Example 3 ) Please share your view as I am also facing problem in giving constraints. Regards, Bhaumik- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I thought perhaps that I would be better off concentrating on the skew across the tx_data and tx_clk outputs since they are both register outputs (tx_clk is really no different to tx_data in this regard). So by constraining maximum skew, I would be able to constrain my source synchronous output. So I used the following:
set_max_skew -to [get_ports {tx_clk tx_data}] 0.050 This has a skew which I know is impossible to meet, but the timing analysis run as part of the compile process does not fail as a result. The failure only shows up when TimeQuest is run using the GUI and a maximum skew report is run. So this is pretty useless. Also I have seen a comment that the set_max_skew constraint does not influence the fitter.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page