SDC set_input_delay and set_output_delay constraints

--- Quote Start ---

Hello,

I'm new to TimeQuest / SDC commands. In my design I've got an external Ethernet switch device that is sourcing a dedicated clock signal to drive data into an FPGA. The switch device also sources a dedicated clock to read data from the FPGA. I'm trying to apply constrains for both the tx and rx data paths. I've read through the a document referenced here (TimeQuest User Guide by Ryan Scoville) along with other Altera documentation and it's not clear to me how to do this.

Maybe the first question is, can I consider this to be a source synchronous interface? The descriptions I've read on this seem to indicate that a source synchronous interface is when a clock input to the FPGA a) drives logic associated with an external device, and b) the input clock is also driven back out of the FPGA to clock the external device.

In my design, the clock is coming from the external device and the FPGA is not driving the clock back out.

Details of the clocks and setup/hold times are as follows. FPGA input rx and tx clock from switch device is 25 mhz. Switch device specs for its receive data lines a min setup time of 10 ns and min hold time of 0 secs on the rising clock edge. The switch specs for its transmit data lines that the output data will be valid a min of 18 ns and max of 28 ns after the rising clock edge.

Can anyone provide any insight into how I can constrain this?

Thanks in advance

--- Quote End ---

Your inputs to fpga(data and clock from switch) is a typical source synchronous case.

since the valid window is 18~28 ns then you need to inform timequest about the data/clock offset using set input delay as follows:

set_input_delay -max 18

set_input_delay -min -(period - 28) i.e. -12

Your outputs from fpga(data) to switch is close to source synchronous case but your clock is opposite data direction.

if it was same direction then you set max output delay to tSU i.e. 10 and min output delay to -tH i.e. 0

as your clock is not you can either estimate the effect and adjust above or use virtual clock offset(advanced) from actual clock by estimated delay.

edit: for simplicity assume data and clock have same delay across board(if input to fpga) or equal but opposite delay for outputs.

kaz,

I think you got it wrong.

18~28 ns the window is NOT the valid window. The valid window is up to 18 ns (for hold) and from 28 ns (for setup)

So, the basic constrains are something like this

create_clock -name rx_clock -period 40 [get_ports rx_clock]

create_clock -name rx_clock_virtual -period 40

create_clock -name tx_clock -period 40 [get_ports rx_clock]

create_clock -name tx_clock_virtual -period 40

set_input_delay -min $tCO_min -clock rx_clock_virtual ...

set_input_delay -max $tCO_max -clock rx_clock_virtual ...

set_output_delay -min -$tH -clock tx_clock_virtual ...

set_output_delay -max $tSU -clock tx_clock_virtual ...

You may want to account for PCB delays on a) your clock lines and b) your data lines.

For a), you can use set_clock_latency, set_clock_uncertainty or just mix it into the input/output delay values

For b), better mix it into the input/output delay values

--- Quote Start ---

kaz,

I think you got it wrong.

18~28 ns the window is NOT the valid window. The valid window is up to 18 ns (for hold) and from 28 ns (for setup)

So, the basic constrains are something like this

create_clock -name rx_clock -period 40 [get_ports rx_clock]

create_clock -name rx_clock_virtual -period 40

create_clock -name tx_clock -period 40 [get_ports rx_clock]

create_clock -name tx_clock_virtual -period 40

set_input_delay -min $tCO_min -clock rx_clock_virtual ...

set_input_delay -max $tCO_max -clock rx_clock_virtual ...

set_output_delay -min -$tH -clock tx_clock_virtual ...

set_output_delay -max $tSU -clock tx_clock_virtual ...

You may want to account for PCB delays on a) your clock lines and b) your data lines.

For a), you can use set_clock_latency, set_clock_uncertainty or just mix it into the input/output delay values

For b), better mix it into the input/output delay values

--- Quote End ---

Thanks Rbugalho:the OP has worded it as:

--- Quote Start ---

output data will be valid a min of 18 ns and max of 28 ns after the rising clock edge

--- Quote End ---

Do you interpret that as valid after 10ns(min) and up to after 28 ns(max)?

then min tCO is 18 and max tCO is 28 ns. Fair enough if you know about their device. Thus they should set input delay to 18 min and 28 max

Fair enough.

I did read the OPs as tCO min = 18, tCO max = 28, which may not have been what he means.

Thanks kaz and rbugalho for your responses.

The device is a KSZ8995MAI ethernet switch. I have attached a snapshot of the timing info from the datasheet. The datasheet provides an "output valid" parameter for the data lines that the switch sends data to the fpga on; this is spec'd as a min of 18 ns and max of 28 ns.

Below is what I have in my SDC file so far (updated based on your feedback). Based on the attached info, does this seem correct?

I have not factored in board delay yet, but I would expect no more than 2 ns based on my board design. Since the clock and data originate from the switch, if we assume trace lines are the same length, I wouldn't need to constrain anything on the FPGA's receive data lines, correct?

Note that mii_mrxd and mii_mtxd are data signals defined in my design.

create_clock -name {mii_txclk_25mhz_in} -period 40.000 -waveform { 0.000 20.000 } [get_ports {mii_mtxclk}]

create_clock -name {mii_rxclk_25mhz_in} -period 40.000 -waveform { 0.000 20.000 } [get_ports {mii_mrxclk}]

set_input_delay -max -clock [get_clocks {mii_rxclk_25mhz}] 28 [get_ports {mii_mrxd

[*]}]

set_input_delay -min -clock [get_clocks {mii_rxclk_25mhz}] -12 [get_ports {mii_mrxd

[*]}]

set_output_delay -max -clock [get_clocks {mii_txclk_25mhz}] 10 [get_ports {mii_mtxd

[*]}]

set_output_delay -min -clock [get_clocks {mii_txclk_25mhz}] 0 [get_ports {mii_mtxd

[*]}]

Thanks in advance

inputs to fpga:

your interpretation of 18/28 ns is not right and you need to follow tCO min as 18 ns, tCO max as 28 ns (as Rbugalho first thought).

set_input_delay -max 28

set_input_delay -min 18

since clock and data arrive with same delay then you can ignore board effect for above.

outputs:

Your output assignments are correct if clock and data arrive at same time but since your clock is opposite that of data then clock arrives late by say 2ns and data arrives after 2 ns at target switch thus you got 4 ns net delay of data relative to clock at switch. treat this as board delay so advance data by 4 ns.

set_output_delay -max 6

set_output_delay -min -(-4) i.e. 4

alternatively use virtual clock and keep your figures.

--- Quote Start ---

inputs to fpga:

your interpretation of 18/28 ns is not right and you need to follow tCO min as 18 ns, tCO max as 28 ns (as Rbugalho first thought).

set_input_delay -max 28

set_input_delay -min 18

since clock and data arrive with same delay then you can ignore board effect for above.

outputs:

Your output assignments are correct if clock and data arrive at same time but since your clock is opposite that of data then clock arrives late by say 2ns and data arrives after 2 ns at target switch thus you got 4 ns net delay of data relative to clock at switch. treat this as board delay so advance data by 4 ns.

set_output_delay -max 6

set_output_delay -min -(-4) i.e. 4

alternatively use virtual clock and keep your figures.

--- Quote End ---

You are sure that the delay_min should be 4?

And not -4??

That's quite the the thread resurrection...

From what I can now gather, kaz was describing the following situation:

clk source (Ethernet chip) -> 2 ns -> FPGA -> 2 ns -> register (Ethernet chip)

From the point of view of the Ethernet chip, this is see as if the data arrives 2+2 ns later relative to the clock edge, as seen by the Ethernet chip itself.

Thus, the constraints should be:

set_output_delay -max 14

set_output_delay -min 4

But min e max delays are from the point of

view of the external chip or of the fpga chip??