UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
169 Views
Registered: ‎02-23-2019

Constraining Component Mode DDR interface

Jump to solution

Using Vivado 2019.1 and a xcku060-ffva1517-2-e device. It has a edge-aligned DDR interface to an ADC implemented as follows:

DDRschematic2.JPG

The IDELAY3 is set to TIME (fixed to 1/4 offset), EN_VCT=1 and an IDELAYCTRL is implemented; so I believe that BISC is run when the IDELAYE3 is released from reset.  This design fails static timing analysis; however, the IDELAYE3/IDELAYCTRL compensate for clock/data skew (BISC) and is temperature & process compensated... does static timing analysis apply?  Would Xilinx's recommendation be to implement this in Native Primitives?

0 Kudos
1 Solution

Accepted Solutions
124 Views
Registered: ‎02-23-2019

Re: Constraining Component Mode DDR interface

Jump to solution

I'm confused... in UG571 Component Primitives IDELAYCTRL under DELAY_FORMAT=TIME (p.175) it clearly cautions about BISC: 

CAUTION! During the built-in self-calibration (BISC) process, the input delay line (IDELAY) is used to
eliminate the clock-to-data skew at the input of the first flip-flops in the serial-to-parallel conversion
process.
This process consumes a number of taps of the input delay line, and is called Align_Delay. The
Align_Delay is reported as a value between 45 and 65 taps, when DELAY_VALUE is set as 0 ps and read
out through the CNTVALUEOUT or RIU_RD_DATA when using the RIU interface with the
BITSLICE_CONTROL.
Writing all zeros or an amount of taps smaller than the reported Align_Delay to an input delay line can
impact the Align_Delay inserted by the BISC and might cause issues when capturing data.

Isn't this directly stating that BISC is operational in this case?

0 Kudos
2 Replies
Historian
Historian
147 Views
Registered: ‎01-23-2009

Re: Constraining Component Mode DDR interface

Jump to solution

IDELAYE3/IDELAYCTRL compensate for clock/data skew (BISC) and is temperature & process compensated... does static timing analysis apply?

The mode you are describing isn't BISC - the EN_VTC is simply to calibrate the "TIME" value of the IDELAY - it is dynamically adjusting the number of delay taps used in order to implement the specified time delay. So, the delay of the IDELAY is the "TIME" value (1/4 of your period) plus or minus some variation. The static timing tools understand this, and will correctly time it (so static timing does apply).

I don't know as much about native mode - it has far more capability then component mode. Originally the native mode was used exclusively by the physical layer of IPs such as the MIG and was not recommended for direct use by the designer, but this has changed more recently. I suspect that the BISC is only available in native mode, as it involves more than just the IDELAY - it requires active feedback between the IDELAY and the capture flip-flops/timing strobes.

Be aware that the clocking in native mode is different than in component mode - the clocks need to be on the byte strobe pins, which are not the same as the clock capable pins (required for accessing global clock resources). Some strobe pins are also clock capable pins, but not all...

Avrum

 

0 Kudos
125 Views
Registered: ‎02-23-2019

Re: Constraining Component Mode DDR interface

Jump to solution

I'm confused... in UG571 Component Primitives IDELAYCTRL under DELAY_FORMAT=TIME (p.175) it clearly cautions about BISC: 

CAUTION! During the built-in self-calibration (BISC) process, the input delay line (IDELAY) is used to
eliminate the clock-to-data skew at the input of the first flip-flops in the serial-to-parallel conversion
process.
This process consumes a number of taps of the input delay line, and is called Align_Delay. The
Align_Delay is reported as a value between 45 and 65 taps, when DELAY_VALUE is set as 0 ps and read
out through the CNTVALUEOUT or RIU_RD_DATA when using the RIU interface with the
BITSLICE_CONTROL.
Writing all zeros or an amount of taps smaller than the reported Align_Delay to an input delay line can
impact the Align_Delay inserted by the BISC and might cause issues when capturing data.

Isn't this directly stating that BISC is operational in this case?

0 Kudos