Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
10 years ago

Source synchronous transmitter constraints

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.

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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.