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

Source synchronous transmitter constraints

Altera_Forum
Honored Contributor II
1,397 Views

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.
0 Kudos
2 Replies
Altera_Forum
Honored Contributor II
699 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
699 Views

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.
0 Kudos
Reply