cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
10,808 Views
Registered: ‎12-18-2014

Setup violation for input from external device

Jump to solution

Hello,

i have specified an input delay for interfacing to an external device. I adopted the Xilinx Timing Template for Rising Edge System Synchronous Inputs. The register for the dedicated input is placed in an IOB.

But i have a setup violation!

 

set input_clock_period 10.000; # Period of input clock
set dv_bre 2.000; # Data valid before the rising clock edge(from external device)
set dv_are 8.000; # Data valid after the rising clock edge(from external device)

 

set_input_delay -clock [get_clocks clk_gen] -max [expr $input_clock_period - $dv_bre] [get_ports FLAGA];
set_input_delay -clock [get_clocks clk_gen] -min $dv_are [get_ports FLAGA];

 

The dedicted output of the external device has the following timing parameter:

t(clock to out)=8ns

t(hold)=0.5ns

t(setup)=2ns

t(period)=10ns

 

How to solve the setup violation.

 

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
17,519 Views
Registered: ‎01-23-2009

First, let me start by saying that this kind of interface is very hard to get to meet timing. It is sort of both source synchronous and system synchronous; the data from the FPGA to external device is source synchronous (which is easy), but the return data is "worse than system synchronous". You can take a look at  this thread, which describes a similar system (RMII) that uses this kind of clocking; it is the worst of both worlds since the larger uncertainties (the clock-to-output time of both the FPGA and the external device) both show up on the read path.

Second, you need to be careful how you constrain this - I see your constraints using create_clock - that isn't the correct thing to use for this interface...

Referencing the picture you attached (assuming that Clkif on the board is generated through an ODDR as you and @nagabhar have been discussing), then this clock is a generated clock, and all timing for these interfaces need to be constrained against this generated clock, not a primary clock. Looking at your ODDR_inst example, I will assume your output is called CLK_OUT_pin (CLK_OUT from the ODDR, but driven through an OBUF).

So, you need to constrain your 200MHz input clock

create_clock -name input_clock -period 5 [get_ports <input_clock_pin>]

This will automatically constrain the internal 100MHz clock generated by the clock wizard.

Now you need to define the generated clock on the board

create_generated_clock -name CLK_OUT -combinational -source [get_pins .../ODDR_inst/C] [get_ports CLK_OUT_pin]

Now you have a clock named CLK_OUT that represents the clock on the board. Your set_input_delay and set_output_delay commands need to be done with respect to this clock. As was pointed out, these should take into account not only the characteristics of the external device, but also propagation times on the board.

With that properly constrained, you can now start figuring out how to make the interface work (or even if it is possible). Yes, you can consider clocking on other edges than the "default" ones (this will involve the set_multicycle_path command to change the capture edge relationships), but in the end it will all boil down to uncertainties - and you are missing the biggest piece of information required here...

You have the t(clock_to_out) = 8ns - presumably this is MAX, but what is the MIN? And this is critical! No device can change its output precisely at 8ns after the clock, it will change sometime between (something) and 8ns. Any "well documented" device will tell you the min as well as the max. If the min is something like 4ns, then you have a chance (maybe), if the min is 0ns (which is what you have to assume if it is unspecified), then you are done - this interface has NO chance of working.

Lets say its 3ns, this means that you have 5ns of uncertainty from the output device (the outputs change sometime between 3ns and 8ns after the clock, resulting in 5ns of uncertainty). The FPGA clock coming through the ODDR and OBUF will also have some uncertainty - at least in the order of 2ns (maybe more depending on I/O standard). To capture the return data, you need stable inputs for some amount of time - around 2ns - for reliable capture. So you start with 10ns, you lose 2ns for the clock to output uncertainty for the clock coming from the FPGA, 5ns for the clock to output of the external device. This leaves you with 3ns of stable window (somewhere) - you need at least 2ns (for FPGA setup and hold), so this MIGHT work. But you also need to factor in the board uncertainties (often only a few hundred picoseconds each way), and other factors... Its pretty tight.

Assuming this analysis says there is enough stable window, now you have to design a clocking mechanism to capture it - this may need an ODELAY or IDELAY or a negative edge of the clock or a clock with a different phase - there are lots of ways of doing this - but only if the window is large enough...

Avrum

View solution in original post

9 Replies
Xilinx Employee
Xilinx Employee
10,798 Views
Registered: ‎05-07-2015

HI @sevenclock

 

Clearly,  out of 10 ns  period. 8 ns is Tco(clk to Out) of the external device.   leaving only 2 ns for the FPGA to capture data properly which is difficult to achive without a good amount clock insertion delay.

Keeping the register in IOB  might restrict the freedom of the tool to place the capture reg in way to try and meet the input setup timing.

 

Does keeping the IOB=FALSE attribute improve the setup slack in any way? (as you mentioned in the previous post).

Please share timing reports with and without IOB.

 

Thanks
Bharath
--------------------------------------------------​--------------------------------------------
Please mark the Answer as "Accept as solution" if information provided addresses your query/concern.
Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
Highlighted
Moderator
Moderator
10,737 Views
Registered: ‎01-16-2013

Hi,

 

Also you can use the below interface changes to achieve the alignement.

Use IODELAY in both clock and data path in FPGA input side. Keep the data path IODELAY with 0 tap value and control/ adjust the tap value for IODELAY in clock path. 

 

Note: I am asking to use IODELAY in both path to nullify the primitive level delay differnaces.

 

Thanks,
Yash

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
10,505 Views
Registered: ‎05-07-2015

HI @sevenclock

 

Hope our replies helped. Please let us know.

Thanks
Bharath
--------------------------------------------------​--------------------------------------------
Please mark the Answer as "Accept as solution" if information provided addresses your query/concern.
Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
Highlighted
Explorer
Explorer
9,938 Views
Registered: ‎12-18-2014

Hi,

keeping IOB=true results in an addtional hold time violation...

Basically i have to delay/shift the rising edge of my clock to the center of the rx data valid window. 

Similar to one of the post from avrumw i have to encounter the following:

 

 

  - from the Rising edge of the internal clock in FPGA 

  - through pad of FPGA

  - on board to external device

  - CLK-Q of external device (which is 8ns!)

  - on board back to FPGA

  - through input pad

  - meeting setup/hold requirement of some internal clock resource

 

So is it possible to only insert delay for the clock path? And how to calculate the number of required taps?

Attached is my source synchronous block design.

 

source synchronous design.JPG
0 Kudos
Highlighted
Explorer
Explorer
9,918 Views
Registered: ‎12-18-2014

I'm sorry the design is source synchronous not system synchronous :)

 

Please correct me if i am wrong: I can not use IODelay for the clock as suggested  since they are in the IO Cells.

I tried another approach by capturing the data coming from the external device on the falling edge and modifying the set_input_delay for "Center-Aligned Falling Edge Source Synchronous Inputs"

 

set input_clock_period    10.000; # Period of input clock
set dv_bfe                       6.000; # Data valid before the falling clock edge
set dv_afe                       4.000; # Data valid after the falling clock edge

set_input_delay -clock clk_gen -max [expr $input_clock_period - $dv_bfe] [get_ports FLAGA] -clock_fall;
set_input_delay -clock clk_gen -min $dv_afe [get_ports FLAGA] -clock_fall;

 

 

Thereby i have no setup violation but is this correct?

 

0 Kudos
Highlighted
Explorer
Explorer
9,867 Views
Registered: ‎12-18-2014

No suggestions?

Here is a drawing for the launch and capture edges. 

20160309_085711.jpg
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
9,863 Views
Registered: ‎05-07-2015

HI @sevenclock

 

From what you explained, the external device on your FMC card is lauching data using the forwarded clock from FPGA and the data received is captured with the same FPGA internal clock(which sourced the forwarded clock through ODDR).

 

In this scenario, ideally, you also need take into account the board trace delays exprienced by the generated clock (from FPGA to Ext device) and the  board trace delay exprienced by the data being received(from extdevice to FPGA).

 

yes, capturing with an inverted or a phase shifted version of internal clock is always an option,

I wonder how you arrived at dv_bfe, dv_afe  being  6 ,4 ns respectively (should be 7 and 3 right?). if the Tclk(rising)->Out of the external device is 8 ns. and clk period being 10 ns.

Thanks
Bharath
--------------------------------------------------​--------------------------------------------
Please mark the Answer as "Accept as solution" if information provided addresses your query/concern.
Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
Highlighted
Explorer
Explorer
9,855 Views
Registered: ‎12-18-2014

Hi @nagabhar,

thank you for the reply.

You are absolutely right.

I saw in some implementation forwarding the clock with setting the D1=0 and D2=1 for negative edge:

 

	ODDR_inst : ODDR
	generic map(
		DDR_CLK_EDGE => "OPPOSITE_EDGE", -- "OPPOSITE_EDGE" or "SAME_EDGE" 
		INIT => '0',   -- Initial value for Q port ('1' or '0')
		SRTYPE => "SYNC") -- Reset Type ("ASYNC" or "SYNC")
	port map (
		Q  => CLK_OUT,   -- 1-bit DDR output
		C  => clk_100,    -- 1-bit clock input
		CE => '1',    -- 1-bit clock enable input
		D1 => '0',    -- 1-bit data input (positive edge)
		D2 => '1',    -- 1-bit data input (negative edge)
		R  => '0',    -- 1-bit reset input
		S  => '0'     -- 1-bit set input
   );

Does this mean the clock comes basically shifted by 180* at the external device flop. And how does this effect the data/ clock alignment for the external device? And since the clock is shifted and the data valid window moved - does this relax my setup time when i am going to receive data back from the external device?

 

Here is block diagram(from another thread) which applies to my system as well:

 

source synchronous2.JPG
0 Kudos
Highlighted
Guide
Guide
17,520 Views
Registered: ‎01-23-2009

First, let me start by saying that this kind of interface is very hard to get to meet timing. It is sort of both source synchronous and system synchronous; the data from the FPGA to external device is source synchronous (which is easy), but the return data is "worse than system synchronous". You can take a look at  this thread, which describes a similar system (RMII) that uses this kind of clocking; it is the worst of both worlds since the larger uncertainties (the clock-to-output time of both the FPGA and the external device) both show up on the read path.

Second, you need to be careful how you constrain this - I see your constraints using create_clock - that isn't the correct thing to use for this interface...

Referencing the picture you attached (assuming that Clkif on the board is generated through an ODDR as you and @nagabhar have been discussing), then this clock is a generated clock, and all timing for these interfaces need to be constrained against this generated clock, not a primary clock. Looking at your ODDR_inst example, I will assume your output is called CLK_OUT_pin (CLK_OUT from the ODDR, but driven through an OBUF).

So, you need to constrain your 200MHz input clock

create_clock -name input_clock -period 5 [get_ports <input_clock_pin>]

This will automatically constrain the internal 100MHz clock generated by the clock wizard.

Now you need to define the generated clock on the board

create_generated_clock -name CLK_OUT -combinational -source [get_pins .../ODDR_inst/C] [get_ports CLK_OUT_pin]

Now you have a clock named CLK_OUT that represents the clock on the board. Your set_input_delay and set_output_delay commands need to be done with respect to this clock. As was pointed out, these should take into account not only the characteristics of the external device, but also propagation times on the board.

With that properly constrained, you can now start figuring out how to make the interface work (or even if it is possible). Yes, you can consider clocking on other edges than the "default" ones (this will involve the set_multicycle_path command to change the capture edge relationships), but in the end it will all boil down to uncertainties - and you are missing the biggest piece of information required here...

You have the t(clock_to_out) = 8ns - presumably this is MAX, but what is the MIN? And this is critical! No device can change its output precisely at 8ns after the clock, it will change sometime between (something) and 8ns. Any "well documented" device will tell you the min as well as the max. If the min is something like 4ns, then you have a chance (maybe), if the min is 0ns (which is what you have to assume if it is unspecified), then you are done - this interface has NO chance of working.

Lets say its 3ns, this means that you have 5ns of uncertainty from the output device (the outputs change sometime between 3ns and 8ns after the clock, resulting in 5ns of uncertainty). The FPGA clock coming through the ODDR and OBUF will also have some uncertainty - at least in the order of 2ns (maybe more depending on I/O standard). To capture the return data, you need stable inputs for some amount of time - around 2ns - for reliable capture. So you start with 10ns, you lose 2ns for the clock to output uncertainty for the clock coming from the FPGA, 5ns for the clock to output of the external device. This leaves you with 3ns of stable window (somewhere) - you need at least 2ns (for FPGA setup and hold), so this MIGHT work. But you also need to factor in the board uncertainties (often only a few hundred picoseconds each way), and other factors... Its pretty tight.

Assuming this analysis says there is enough stable window, now you have to design a clocking mechanism to capture it - this may need an ODELAY or IDELAY or a negative edge of the clock or a clock with a different phase - there are lots of ways of doing this - but only if the window is large enough...

Avrum

View solution in original post