cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
noreeli79
Adventurer
Adventurer
162 Views
Registered: ‎11-04-2015

Constraints for iddr lead to hold violation

Jump to solution

Hi,

when implementing the following input ddr port VHDL code:  (Kintex 7, xc7k410tffv676-2)

 

library ieee;
use ieee.std_logic_1164.all;

library unisim;
use unisim.vcomponents.all;

entity ddr_in is
port(
    CK : in std_logic;
    D  : in std_logic;
    RESET : in std_logic;
    Q1 : out std_logic;
    Q2 : out std_logic
);
end;



architecture struct of ddr_in is

signal clk : std_logic;

begin

clk_b : BUFIO
port map(I => CK, O => clk);


ddr_i : IDDR
generic map (   
    DDR_CLK_EDGE => "SAME_EDGE",               -- "OPPOSITE_EDGE", "SAME_EDGE" or "SAME_EDGE_PIPELINED"   
    INIT_Q1      => '0',                    -- Initial value of Q1: '0' or '1'   
    INIT_Q2      => '0',                    -- Initial value of Q2: '0' or '1'   
    SRTYPE       => "ASYNC"                 -- Set/Reset type: "SYNC" or "ASYNC"
)     
port map (   
    Q1  => Q1,                      -- 1-bit output for positive edge of clock   
    Q2  => Q2,                      -- 1-bit output for negative edge of clock   
    C   => clk,                     -- 1-bit clock input   
    CE  => '1',                     -- 1-bit clock enable input   
    D   => D,                       -- 1-bit DDR data input   
    R   => RESET,                   -- 1-bit reset   
    S   => '0'                      -- 1-bit set   
);


end struct;

 

 

with the following constraint file:

 

create_clock -period 8.0 -name TheClk [get_ports {CK}]
set_property IOSTANDARD LVCMOS33 [get_ports "*"]
set_property PACKAGE_PIN U16 [get_ports "RESET"]
set_property PACKAGE_PIN R22 [get_ports "CK"]
set_property PACKAGE_PIN P24 [get_ports "D"]


# Center-Aligned Double Data Rate Source Synchronous Inputs 
#
# For a center-aligned Source Synchronous interface, the clock
# transition is aligned with the center of the data valid window.
# The same clock edge is used for launching and capturing the
# data. The constraints below rely on the default timing
# analysis (setup = 1/2 cycle, hold = 0 cycle).
#
# input                  ____________________
# clock    _____________|                    |_____________
#                       |                    |                 
#                dv_bre | dv_are      dv_bfe | dv_afe
#               <------>|<------>    <------>|<------>
#          _    ________|________    ________|________    _
# data     _XXXX____Rise_Data____XXXX____Fall_Data____XXXX_
#

set input_clock         TheClk;           # Name of input clock
set input_clock_period  8;                # Period of input clock (full-period)
set dv_bre              1.2;              # Data valid before the rising clock edge
set dv_are              1.2;              # Data valid after the rising clock edge
set dv_bfe              1.2;              # Data valid before the falling clock edge
set dv_afe              1.2;              # Data valid after the falling clock edge
set input_ports         "D"  ;            # List of input ports

# Input Delay Constraint
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 - $dv_bfe] [get_ports $input_ports];
set_input_delay -clock $input_clock -min $dv_are                                [get_ports $input_ports];
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 - $dv_bre] [get_ports $input_ports] -clock_fall -add_delay;
set_input_delay -clock $input_clock -min $dv_afe                                [get_ports $input_ports] -clock_fall -add_delay;

 

 

I get a hold time violation (Vivado 2019.2). As far as I can see in different posts regarding input ddr, the DDR timing template (from Vivado) should work. What exactly is the problem with my approach?

Thank you very much,

Noreeli

0 Kudos
Reply
1 Solution

Accepted Solutions
avrumw
Guide
Guide
145 Views
Registered: ‎01-23-2009

What exactly is the problem with my approach?

The problem with your approach is simply the expectation that this is going to pass!

You have a center aligned source synchronous interface with a centered window of 2.4ns - 1.2ns before the clock edge and 1.2 after. You have described this and you have implemented a DDR capture mechanism using the BUFIO. The tool is telling you that this fails the hold check. There is nothing inconsistent with this - the tool is telling you that the 1.2ns before the clock and 1.2ns after the clock isn't sufficient to meet the timing requirements of this capture mechanism.

The first thing to do is take a look at the slack on the setup check. If the positive slack on the setup check is larger than the magnitude of the negative slack on the hold check (ideally larger by a few hundred picoseconds) then this interface is "fixable" (and with a 2.4ns window I am certain that it is) - but you need to do something to fix it.

Take a look at this post on input capture mechanisms - particularly the part on clock/data phase relationships. There is nothing that says that the setup/hold requirement of the FPGA with a given capture mechanism is symmetrical - in fact it isn't - even using the datasheet (Tpscs/Tphcs) we see that the setup and hold requirements are not actually centered around the clock edge - in most devices the required window happens completely after the clock edge. So you need to adjust the timing - the way to do this is with the IDELAY. Add the IDELAY (I am pretty sure) to your data pins (and also add an IDELAYCTRL) - start with a tap value of 0. Perform timing analysis and look at the setup and hold margins, and determine exactly how much delay is required to make the interface pass both the setup and hold check - change the tap value on the IDELAY and time it again (and adjust if necessary - the tap delays are not all equal).

By the way, for capturing with the IDDR you can use a combination of BUFIO/BUFR (which I presume you are doing) the BUFIO for the IDDR and the BUFR for the logic working with the Q1/Q2 outputs of the IDDR. Or you can use the BUFR for both (and not use the BUFIO). In my experiments (at least with the 7 series) there seems to be a very minor advantage in timing from just using the BUFR.

Avrum

View solution in original post

1 Reply
avrumw
Guide
Guide
146 Views
Registered: ‎01-23-2009

What exactly is the problem with my approach?

The problem with your approach is simply the expectation that this is going to pass!

You have a center aligned source synchronous interface with a centered window of 2.4ns - 1.2ns before the clock edge and 1.2 after. You have described this and you have implemented a DDR capture mechanism using the BUFIO. The tool is telling you that this fails the hold check. There is nothing inconsistent with this - the tool is telling you that the 1.2ns before the clock and 1.2ns after the clock isn't sufficient to meet the timing requirements of this capture mechanism.

The first thing to do is take a look at the slack on the setup check. If the positive slack on the setup check is larger than the magnitude of the negative slack on the hold check (ideally larger by a few hundred picoseconds) then this interface is "fixable" (and with a 2.4ns window I am certain that it is) - but you need to do something to fix it.

Take a look at this post on input capture mechanisms - particularly the part on clock/data phase relationships. There is nothing that says that the setup/hold requirement of the FPGA with a given capture mechanism is symmetrical - in fact it isn't - even using the datasheet (Tpscs/Tphcs) we see that the setup and hold requirements are not actually centered around the clock edge - in most devices the required window happens completely after the clock edge. So you need to adjust the timing - the way to do this is with the IDELAY. Add the IDELAY (I am pretty sure) to your data pins (and also add an IDELAYCTRL) - start with a tap value of 0. Perform timing analysis and look at the setup and hold margins, and determine exactly how much delay is required to make the interface pass both the setup and hold check - change the tap value on the IDELAY and time it again (and adjust if necessary - the tap delays are not all equal).

By the way, for capturing with the IDDR you can use a combination of BUFIO/BUFR (which I presume you are doing) the BUFIO for the IDDR and the BUFR for the logic working with the Q1/Q2 outputs of the IDDR. Or you can use the BUFR for both (and not use the BUFIO). In my experiments (at least with the 7 series) there seems to be a very minor advantage in timing from just using the BUFR.

Avrum

View solution in original post