- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 advanceLink Copied
12 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Fair enough.
I did read the OPs as tCO min = 18, tCO max = 28, which may not have been what he means.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Appreciate the help. Thanks much
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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??
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But min e max delays are from the point of
view of the external chip or of the fpga chip??- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- You are sure that the delay_min should be 4? And not -4?? --- Quote End --- I looked again into this thread and say “No I am not sure now that I have put the figures right but Rbugalho in his very last post corrected me, thanks“ The original info for FPGA outputs to the Switch is given as --- Quote Start --- 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. --- Quote End --- If clock and data are both from FPGA and assuming they arrive together then: set_output_delay -max +tSU (i.e. 10) set_output_delay-min –tH (i.e. -0) That model (model 1) is based on TimeQuest docs directly. If clock is opposite data then the beloved TimeQuest doesn’t say anything about how to constrain this destination synchronous model (model 2) but surely above equations wouldn’t apply anymore. So I posted my initial thoughts but I could be wrong and it will help us discussing this model 2. Let me convert model 2 to model 1 equivalent (by imagining board delay difference of data/clock). let clock arrive (x) ns from switch and let data travel (y) ns to arrive at Switch together with our virtual clock. What this means at FPGA (as imaginary model 1) clock delay is (–x) ns, then it launches data from FPGA, after that clock delays further (x) ns to reach Switch So clock delay = -x+x = zero if it was model 1 Data delay = y ns Applying model 1 equations now: max = required tSU + data board delay – clock board delay = 10 + y - 0 min = -reqiured tH + data board delay – clock board delay = -0 + y – 0 If y = 2 ns then obviously max becomes 12, min becomes +2 So my new model gave me some difference with max value which Rbugalho corrected. I am always on the learning curve and is not always upwards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ohh. I am crazy..
But I agree with Rbugalho. Outputmax=14 Outputmin=4 If clk is going out from eth chip to fpga with 2ns board trace, and if data is going out from fpga to eth chip with 2 ns board trace.. Tnx to all!
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