Forum Discussion

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

Timequest: Q about interconnect delay effect on clock duty cycle

Hello all,

Being new to FPGA design, I created a simple design for analyzing the effects on routing a signal across an FPGA. For a Stratix V, I set a clock input pin to traverse the interconnect to an output pin at the opposite side of the FPGA using the Pin Planner. The verilog module had this:

module set_test (

input clk,

output clk_inv

);

assign clk_inv = ~clk;

endmodule

The SDC constraint was as follows:

# 15.0 - 66.666... MHz

set PERIOD 15.0

create_clock -name {clk}

-period ${PERIOD}

-waveform

[list 0 [expr ${PERIOD} / 2.0]]

[get_ports {clk}]

After fitting, I opened TimeQuest, entering these commands:

create_timing_netlist -model fast -temperature 0 -voltage 850

read_sdc

update_timing_netlist

report_path -from clk -to clk_inv -panel_name max

report_path -from clk -to clk_inv -panel_name min -min_path

The attachment has the output from Timequest, and my interpretation of what is happening to the clock at the output pin.

These questions probably are trivial, but I wanted to make sure of them before proceeding:

1) Is my interpretation of the clock waveform at the output pin correct? At the 0 C, 850mv fast timing corner, the effect of the interconnect alone causes ~1 ns difference in the arrival of a positive clock edge and a negative clock edge?

2) If so, what is the technical reason for this?

Thanks.

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Rise/fall variation and on-die variation(PVT variation within the die, as well as other effects like crosstalk...)

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Thanks for the reply. The undesirable result wasn't completely unexpected, I'm reading more documentation to try to get a better understanding of the effects that you had brought up (mainly the 'Guarenteeing Silicon Performance with FPGA Timing Models' paper). Since I'm working with one wire (eliminating crosstalk considerations?) and looking at the fast 850 mV/0 C corner (eliminating supply voltage/temperature variations/silicon speed differences?) I am trying to narrow down what I am looking at in the example (looking at the bullet points in page 3 of the Altera paper as well as the TimeQuest timing reports). The 1 ns difference between the arrival of the clock's rising edge and the arrival of the clock's falling edge along the interconnect is due to rise/fall asymmetry in the switching circuitry across the interconnect? Pessimistic assumptions from process variations?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    In static timing analysis, you're always analyzing the Data Arrival Path versus the Data Required Path. (99% of the time the Data Arrival is your source clock + data path and Data Required is your latch clock path). So you've got two signals racing against each other. Let's pretend we're sending clock and data off chip, so Data Arrival is the data path going off chip and Data Required is the clock path going off chip. Now let's say they're using identically laid out paths in silicon, down to the ps. The rise-fall variation is one component that will make them vary, but on-die variation is usually a bigger component. Let's say we're looking at the slow timing model and say the very worst the data output path could be is 10ns. Just because that path is at the very worst possible part of the PVT corner, another output(say the clock) might be better. TimeQuest has two "sub-models" within a corner, what I call a fast and slow sub-model. So when doing setup analysis, the data would be 10ns but the clock might only be at 9.5ns. That then flips for hold analysis, and the data might be at 9.5ns and hold at 10ns. The fact that it cuts both ways is a killer, as the amount of on-die variation is doubled when it cuts into your margin. (In this example the difference is 500ps, but we lose 1ns).

    Now, when you look at a single path, you're not analyzing it in reference to anything else, but TimeQuest is basically acting as if you did, i.e. it gives you the fast and slow sub-models within a corner. That all being said, 1ns of variation seems really high. Maybe it's because you're using local routing and not a global?