cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mohsin_ch
Adventurer
Adventurer
3,078 Views
Registered: ‎05-25-2018

How to change the clock region of IDELAYE2 Clock region

Jump to solution

Please anybody guide me how can i change the clock region of IDELAYE2 I/O Bank.

 

Right now, i have following allocation of Banks:

 

1. GROUP: mb_subsystem_cascaded_Post_delay PRIMITIVE: IDELAYCTRL BANK: 13 NAME: mb_subsystem_i/Post_iDelay/inst/delayctrl
GROUP: mb_subsystem_cascaded_Post_delay PRIMITIVE: IDELAYE2 BANK: 12 NAME: mb_subsystem_i/Post_iDelay/inst/pins[0].idelaye2_bus

2. GROUP: mb_subsystem_cascaded_Post_delay PRIMITIVE: IDELAYCTRL BANK: 12 NAME: mb_subsystem_i/Slave_Post_iDelay/inst/delayctrl
GROUP: mb_subsystem_cascaded_Post_delay PRIMITIVE: IDELAYE2 BANK: 34 NAME: mb_subsystem_i/Slave_Post_iDelay/inst/pins[0].idelaye2_bus

 

I want that for:

1. Both IDELAYCTRL and IDELAYE2 in same bank #12.

2. Both IDELAYCTRL and IDELAYE2 in same bank #13.

 

Please guide me for this command.

 

Regards,

Mohsin

0 Kudos
1 Solution

Accepted Solutions
mohsin_ch
Adventurer
Adventurer
3,103 Views
Registered: ‎05-25-2018

The DRC Problem is resolved by Fixing the LOC of MIG Group and assigning the Post_iDelay and Slave_Post_iDelay Modules to their respective IO banks.

View solution in original post

0 Kudos
11 Replies
syedz
Moderator
Moderator
3,067 Views
Registered: ‎01-16-2013

@mohsin_ch

 

From the device view check the available cells in the required clock region and use LOC constraint to lock the cells: 

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug912-vivado-properties.pdf#page=256

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos
mohsin_ch
Adventurer
Adventurer
3,048 Views
Registered: ‎05-25-2018

@syedz, thanks for the reply.

 

Yes i exactly follow these commands, but once i applied these commands and run the implementation, the tool again reset them to previous values.

 

I am using following commands in tcl console:

 

set_property LOC IDELAY_X0Y0 [get_cells mb_subsystem_i/Slave_Post_iDelay/inst/pins[0].idelaye2_bus]          #Bank33
set_property LOC IDELAYCTRL_X0Y0 [get_cells mb_subsystem_i/Slave_Post_iDelay/inst/delayctrl]                #Bank33

 

But they work once, and again reset to previous LOC values.

 

Am i doing mistake in flow? Please guide me.

 

Regards,

Mohsin

0 Kudos
avrumw
Guide
Guide
3,041 Views
Registered: ‎01-23-2009

IDELAYCTRL are funny things.

 

Regardless of how the tool views them, there is one (and exactly one) IDELAYCTRL per I/O bank. Each IO in that bank that uses the IDELAY must and can only use the IDELAYCTRL in that bank. Period.

 

The tools have done this fairly complex abstraction mechanism, where you instantiate a proxy for the IDELAYCTRL. This instantiation is purely to tell the tools which clock drives the IDELAYCTRL and what to do with the outputs. It uses this information to know how to connect the "real" IDELAYCTRL in the bank that needs it.

 

The IDELAY groups are merely to tell the tool the association; these IDELAYs are associated with this proxy, these here are associated with that one over there. So, if you instantiate an IDELAY in a bank with IDELAY group A, the IDELAYCTRL in that bank has its input and outputs connected according to the proxy in group A. It is for this reason that you can have only one group in a bank.

 

So, it sounds like what you are doing is illegal - if you have IDELAYs in bank 34, an IDELAYCTRL for those IDELAYs must be in bank 34. Any attempt to move them with a LOC constraint will not work...

 

Avrum

0 Kudos
mohsin_ch
Adventurer
Adventurer
3,036 Views
Registered: ‎05-25-2018

Yes, i agreed and understand that there os one and only one IDELAYCTRL per bank. If they are mixed, as in my case, then what we do?

 

I use the following command to see IDELAYCTRL used in my design:

show_objects -name find_1 [get_sites -filter { SITE_TYPE == "IDELAYCTRL" } ]

 

List of IDELAYCTRLs is attached in the picture.

 

Please guide me how can i find the IDELAYS associated with these IDELAYCTRL?

IDELAYCTRL_Used_CASCADED.PNG
0 Kudos
mohsin_ch
Adventurer
Adventurer
3,031 Views
Registered: ‎05-25-2018

@avrumw... Please find the attached file after implementation.

0 Kudos
avrumw
Guide
Guide
3,024 Views
Registered: ‎01-23-2009

If they are mixed, as in my case, then what we do?

 

I don't understand this question... Mixed what? If you have IDELAYs in the same bank that have different IODELAY_GROUP attributes, then (simply) you can't.

 

So, assuming the pins cannot move (i.e. the board is done and the PACKAGE_PIN properties can't be changed), then you have to find a way to get all the IODELAYs in one bank into the same IODELAY_GROUP. 

 

Remember, the IODELAY_GROUP is only there so that the tool knows how to connect the REFCLK, RST and RDY if the IDELAYCTRL. There is rarely a lot of subtlety to these ports

  - REFCLK is either 200MHz, 300MHz, or 400MHz

  - RST can be pretty much any reset

  - RDY is often simply ignored

 

 

So the IDELAYCTRL in one IODELAY_GROUP is often identical to the IDELAYCTRL in another group. If so, then you just need to put them all in the same IODELAY_GROUP. This means

  - you need to ensure that they can use the same REFCLK, RST and RDY

  - you need to change the IODELAY_GROUP attribute to be the same

 

However, this can be very difficult when the IODELAY_GROUP property is set in an IP module (as it is, for example, with the MIG and the SelectIO Wizard). 

 

From your file, you have contention in bank 34. One is clearly the MIG - you probably can't/don't want to mess with that.

 

The other is from mb_subsystem_cascaded_Pre_Delay - I don't know what that is... If this is hand written RTL code (and you can confirm that this code will be "ok" with the REFCLK, RST and RDY from the MIG) then simply remove the instantiation of the IDELAYCTRL in this module, and set the IODELAY_GROUP of the IDELAYs in this module to use the MIG's group (MB_SUBSYSTEM_MIG_7SERIES_0_0_IODELAY_MIG0 PRIMITIVE). If this is not possible, then you may be in trouble...

 

Avrum

0 Kudos
mohsin_ch
Adventurer
Adventurer
3,016 Views
Registered: ‎05-25-2018

@avrumwThank you so much for detail answer. Its help me to resolve my problems.

A. In the first phase, I have cascaded two IDELAYE2 modules on the Positive Side of DIFF BUFF to increase the Tap delay values. They were work perfect. The instance names were:

 

Sr.No.IDELAYCTRLIODELAY_GROUP
1mb_subsystem_i/axi_ethernet_0/inst/mac/inst/tri_mode_ethernet_mac_idelayctrl_common_itri_mode_ethernet_mac_iodelay_grp
2mb_subsystem_i/mig_7series_0/u_mb_subsystem_mig_7series_0_0_mig/u_iodelay_ctrl/u_idelayctrl_200MB_SUBSYSTEM_MIG_7SERIES_0_0_IODELAY_MIG0
3mb_subsystem_i/Post_iDelay/inst/delayctrlmb_subsystem_cascaded_Post_delay
4mb_subsystem_i/pre_idelay/inst/delayctrlmb_subsystem_cascaded_Pre_Delay

 

B. In the second phase, I have cascaded two more IDELAYE2 modules on the Negative Side of DIFF BUFF. The instance names are:

5mb_subsystem_i/Slave_Post_iDelay/inst/delayctrlmb_subsystem_cascaded_Post_delay
6mb_subsystem_i/Slave_Pre_iDelay/inst/delayctrlmb_subsystem_cascaded_Pre_Delay

 

Pictures are attached for clarity. This information was only for your understanding.

 

Now i move to your Solutions.

1. All the cascaded IDELAYCTRL runs with same REF_CLK (150MHz) and RESET Signal.

2. So the IDELAYCTRL in one IODELAY_GROUP is often identical to the IDELAYCTRL in another group. If so, then you just need to put them all in the same IODELAY_GROUP. This means

  - you need to ensure that they can use the same REFCLK, RST and RDY.

  - you need to change the IODELAY_GROUP attribute to be the same.??

 

Please elaborate these points. Its mean that i assigned to all my cascaded four modules be same IODELAY GROUP?

 

3. Theres no hand written RTL Code, i have instainted from the Xilinx Library by using the Selectio Wizard.

 

 

IDELAY_CASCADED_Modules.PNG
IDELAY_CASCADED_Modules_N_SIDE.PNG
0 Kudos
avrumw
Guide
Guide
3,008 Views
Registered: ‎01-23-2009

1. All the cascaded IDELAYCTRL runs with same REF_CLK (150MHz) and RESET Signal.

 

So, first, this is illegal. The IDELAYCTRL frequency must be either 200MHz, 300MHz, or 400MHz (all +/-10MHz) - nothing else is legal. So 150MHz is illegal. I don't know what stage you are at, but eventually the tools will complain, unless you "lie" to it and tell it the frequency is 200MHz when it is really 150MHz. And if that is the case, then there is no guarantee that the actual IDELAY on the FPGA will behave properly.

 

The next comment is about IP integrator. IP Integrator can be a very powerful tool for putting together complex systems quickly. However, it comes at a cost - control. When using IPI, you are somewhat at the mercy of the IP and the integrator platform. In this case, the SelectIO wizard is creating a module that has both the IDELAYs and the IDELAYCTRL. It binds these two together using an IODELAY_GROUP - each SelectIO IP uses a different IODELAY_GROUP. This is a limitation of the SelectIO wizard - there is no mechanism (or at least in the past there wasn't any) of getting it to "share" an IODELAY_GROUP with another component. To do this, the SelectIO wizard would

  a) have to allow you to assign an IODELAY_GROUP that is the same as an existing one

      - this isn't actually a problem - you can name the IODELAY_GROUP when you run the wizard

  b) generate a IP that uses IDELAYs, but does NOT instantiate an IDELAYCTRL

     - at least in the past, this wasn't possible

 

So, using the SelectIO wizard, you probably cannot fix this. The only solution would be to write your own RTL in place of the SelectIO wizard - in your own RTL, you have more control over managing the IDELAYCTRL and groups.

 

But the next question is "why?". Why are you doing this? Since you are cascading two IDELAYs using a REFCLK of 150MHz, this means you need more than 3.33ns of delay (as much as 6.66ns) - although you really can only get 2.5x2 for a total of 5ns using 200MHz.

 

Why do you need so much delay? Any interface that needs that much delay is (probably) by definition "pretty slow". If the interface is "pretty slow" then there are lots of solutions for capturing the interface that don't require the IDELAY at all.

 

Avrum

0 Kudos
mohsin_ch
Adventurer
Adventurer
2,996 Views
Registered: ‎05-25-2018

@avrumwWe are using cascaded modules because we have master clock of 320MHz. For 320MHz, we have 48ps Delay/Tap. To traverse the complete clock cycle, we require 41 Tap values. Please see the picture for the clarity. Since, one module gives 32 taps, so cascaded will give 64 tap values. With this taps, we can read data at both the near and far edge.

 

 

With cascaded version with signals on Positive side, the module was working perfect. With the addition of N Side, i got the errors.

Otherwise, there is no issue with this scheme. Tap values are changed for 64 values. 

 

For the rest, i didn't get any solution yet.

IDELAYCTRL_Timing.PNG
0 Kudos
avrumw
Guide
Guide
2,692 Views
Registered: ‎01-23-2009

For 320MHz, we have 48ps Delay/Tap.

 

So, no.

 

There is no reason to (and in this case it is illegal to) use the bitrate clock to drive the IDELAYCTRL. As I have now said several times, there are only a handful of legal values for the REFCLK of the IDELAYCTRL, 200MHz, 300MHz, and in some cases 400MHz (fastest speedgrades only). This means that the tap values are 78ps, 56ps or 39ps respectively. You cannot use 320MHz and you cannot use 150MHz. Refer to DS182 (I am assuming Kintex-7 since you haven't told us what part you are using) table 29  for the IDELAYCTRL REFCLK requirements.

 

Next, from your context, you appear to be doing some kind of dynamic calibration. At 3.125ns per bit-period this shouldn't be necessary unless the timing from your external device is really terrible. In most cases, a stable data eye of around 1.75ns is enough for static capture.

 

Next, I find no reference to the ability to "cascade" IDELAYs - there is no dedicated path from one IDELAY to another. That being said, the IDELAY can take an input from the fabric routing, so presumably what is happening is the output of the first IDELAY is going into the fabric routing and from there to the 2nd IDELAY (I may be wrong on this - I simply have never heard of IDELAY cascading). If this is the case, then the delay on this route is 

  a) significant

  b) highly PVT variable

  c) subject to variation from implementation run to implementation run

 

For these reasons you should expect unpredictability (and probably unreliability) of an interface done this way. This is not a recommended way of implementing dynamic capture.

 

There are other ways of doing dynamic capture. If you really do need to scan the entire data eye, the dynamic fine phase shift on an MMCM is much more precise and has an infinite range. But you shouldn't really need to scan the entire eye for dynamic capture...

 

Avrum

Tags (1)
0 Kudos
mohsin_ch
Adventurer
Adventurer
3,104 Views
Registered: ‎05-25-2018

The DRC Problem is resolved by Fixing the LOC of MIG Group and assigning the Post_iDelay and Slave_Post_iDelay Modules to their respective IO banks.

View solution in original post

0 Kudos