cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mofana
Visitor
Visitor
8,351 Views
Registered: ‎05-02-2016

How to define maximum allowed skew between different ports?

Jump to solution

Hey folks,

 

I am working with a DAC  that requires to have dac_data (a 16-bit vector) available 8ns before the conversion signal (dac_clk) goes high. My clock frequency is 100MHZ, and hence I raise the dac_clk output 1 cycle after I write to dac_data (conversion is run on 1MHZ):

 

@posedge(clk)
begin
   if (cnt == 0)
      dac_data <= my_data;
   if(cnt == 1)
      dac_clk <= 1;
   cnt <= cnt + 1;
   if (cnt == 99) begin
      cnt <= 0;
dac_clk <= 0;
end; end;

I'd like to ensure that there will not be any timing violation on DAC inputs by telling Vivado synthesis/implementation that the maximum allowed skew between dac_clk and any bits of dac_data has to be less than 2ns.

 

How could this be achieved by constraints?

0 Kudos
1 Solution

Accepted Solutions
avrumw
Expert
Expert
13,588 Views
Registered: ‎01-23-2009

In general, one ensures that there is little skew between output signals by having the signals be driven directly from flip-flops, and ensuring that the flip-flops are placed in the IOBs (the dedicated flip-flops in the input/output blocks right adjacent to the output pad). To make this possible, you have to be sure to have the outputs driven directly from a flip-flop, and ensure that the flip-flop is also not used internally; so, for example, you can't use something like

 

always @(clk_100)

begin

  if (time_to_toggle)

     dac_clk <= !dac_clk;

end

 

In this code, the output of dac_clk is needed to feed the input of the same FF, which prevents it from being packed into the IOB. Make sure to check your IO Report from implementation to ensure that all the outputs come from IOB flip-flops.

 

Forcing the flip-flops into the IOBs and driving the flip-flops with the same clock ensures skews that are very small - in the order of 200ps or so - well less than the 2ns you need. You don't really need constraints for this...

 

If you really want to define constraints for this path, then you can define dac_clk as a generated clock, and use set_output_delay commands to specify the timing requirements of dac_data wrt. dac_clk (but it really isn't necessary).

 

Avrum

View solution in original post

7 Replies
venkata
Moderator
Moderator
8,333 Views
Registered: ‎02-16-2010
can you check set_output_delay constraint?
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
yashp
Moderator
Moderator
8,307 Views
Registered: ‎01-16-2013

Hi,

 

You can use the set_bus_skew command with value of 2ns.

Refer UG 903: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_3/ug903-vivado-using-constraints.pdf (Page#135).

 

This will only ensure the skew between different paths, but for timing violation checks you need proper INPUT/OUTPUT constraints at FPGA interface to check whether data is capture or launched properly.

 

Thanks,
Yash

0 Kudos
avrumw
Expert
Expert
13,589 Views
Registered: ‎01-23-2009

In general, one ensures that there is little skew between output signals by having the signals be driven directly from flip-flops, and ensuring that the flip-flops are placed in the IOBs (the dedicated flip-flops in the input/output blocks right adjacent to the output pad). To make this possible, you have to be sure to have the outputs driven directly from a flip-flop, and ensure that the flip-flop is also not used internally; so, for example, you can't use something like

 

always @(clk_100)

begin

  if (time_to_toggle)

     dac_clk <= !dac_clk;

end

 

In this code, the output of dac_clk is needed to feed the input of the same FF, which prevents it from being packed into the IOB. Make sure to check your IO Report from implementation to ensure that all the outputs come from IOB flip-flops.

 

Forcing the flip-flops into the IOBs and driving the flip-flops with the same clock ensures skews that are very small - in the order of 200ps or so - well less than the 2ns you need. You don't really need constraints for this...

 

If you really want to define constraints for this path, then you can define dac_clk as a generated clock, and use set_output_delay commands to specify the timing requirements of dac_data wrt. dac_clk (but it really isn't necessary).

 

Avrum

View solution in original post

avrumw
Expert
Expert
8,278 Views
Registered: ‎01-23-2009

And, by the way, as coded - ignoring the syntax error in the first line, which should be "always @(posedge clk)", your output dac_clk will have a very unbalanced (and probably illegal) duty cycle, being high for 98 clocks and low for 2 clocks.

 

Avrum

0 Kudos
mofana
Visitor
Visitor
8,262 Views
Registered: ‎05-02-2016

Thank you @avrumw,

 

Your comments are so useful. I am going to check the use of IOB flip-flops.

Though, I have two questions:

 

1- I am really unclear with set_output(input)_delay. For instance in this particular example, what should I put as the output_delay to ensure less than 2ns skew? should I set_output_delay 8.0 or 2.0 (clk period is 10.0)?

 

2- What are the consequences of having an unbalanced duty cycle? I am using a fast DAC (up to 50MSPS) as I need small delay in the system. However, the sampling rate is not high (1MSPS).

 

Thanks,

 

 

P.S. about the syntax, I actually code VHDL, just used pseudo-verilog as it is easier/faster to covey. :D

0 Kudos
avrumw
Expert
Expert
8,231 Views
Registered: ‎01-23-2009

Set output delays are done with respect to the receiving device - the set_output_delay -max is the setup requirement of the external device, and the -min is the negative of the hold requirement of the device.

 

If you want to limit the skew to 2ns, then you are saying the data needs to be valid 2ns after the clock and remain valid until 2ns before the next clock. This corresponds to an 8ns setup requirement and a -2ns hold requirement. So that would mean

 

set_output_delay -clock <forwarded_clock> 8 [get_ports <port>]

set_output_delay -clock <forwarded_clock> 2 [get_ports <port>]; # The negative of -2

 

As for duty cycle, it depends on whether you are using single data rate (SDR) or double data rate (DDR). If you are using SDR, then the duty cycle is irrelevant as long as the clock itself is legal (doesn't violate the minimum high or low time of the reciever). If you are using DDR, then the variability on the location of the falling edge of the clock will eat into your data windows, reducing the margin of the interface.

 

Avrum

avrumw
Expert
Expert
8,223 Views
Registered: ‎01-23-2009

You can take a look at this post on constraining a similar interface.

 

Avrum

0 Kudos