cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
helmutforren
Scholar
Scholar
2,378 Views
Registered: ‎06-23-2014

Totally confused about IDELAYCTRL

Jump to solution

I'm using Vivado 2018.1 and System Verilog.

I've researched and things have gone from unclear to clear as mud.  That is, I totally do not understand.

To begin with, I'm getting this error when I try to build a bitstream:

IDELAYCTRL error message.jpg

I had one "camera wrapper" working.  Then I expanded to four of themand got this error.  When I look in detail, I find that it's actually my own code (the cam_1_input_link_X module) that's instantiating an IDELAYCTRL, as follows:

    IDELAYCTRL icontrol (              			// Instantiate input delay control block
        .REFCLK			(clk_sys/*refclkintbufg*/),
        .RST			(rst_sys),
        .RDY			(delay_ready)
    );

I did this by following the Xilinx example ISERDES that called module n_x_serdes_1_to_7_mmcm_idelay_ddr.  

My difficulty is this.  I read that one could omit the .RDY connection, and if I did that I might be able to follow a different strategy of making this work.  (That would be the strategy of instantiating only one per the last sentence of the error message.)  However, the .RDY is currently used, and that delay_ready signal is used deep within n_x_serdes_1_to_7_mmcm_idelay_ddr to set a different ready signal.  I would rather not break this, and I *believe* that omitting .RDY and replacing uses of delay_ready with 1'b1 would break this.  So I'm stuck with having four instantiations of IDELAYCTRL.

My *belief* is that if I should use "(* IODELAY_GROUP = PARM_IODELAY_GROUP *)" at the two IDELAYE2's deep inside n_x_serdes_1_to_7_mmcm_idelay_ddr.  (Actually there are four IDELAYE2's, but through parameters, only two are instantiated at a time.)  I provide PARM_IODELAY_GROUP ="X0Y0" to two of my top level camera wrappers, and PARM_IODELAY_GROUP ="X0Y1" for the other two.  (Note that the "X0Y0" is just a string.  I'm not believing this in itself to place anything, even though that's indeed where I want it placed.)  My *hope* is that the Vivado tools will magically cause two of my camera wrappers with the same PARM_IODELAY_GROUP to use the same IDELAYCTRL.  Then the other two would share a second IDELAYCTRL.  I realize that the .RDY output would then be "shorted" together or made the same for each pair, which may be a problem here.

I guess I should ask the following question.  Two of my camera wrappers deal with pins in the X0Y0 clock region, and the other two deal with pins in the X0Y1 clock region.  I would like those two camera_wrappers in the X0Y0 clock region to SHARE a single IDELAYCTRL.  Likewise for the X0Y1 clock region.  While doing this, I would like to keep using the .RDY signal, which as I mentioned gets passed lower down to be combined to make a composite ready signal within each n_x_serdes_1_to_7_mmcm_idelay_ddr.  How can I do this? 

What I have tried hasn't worked.  It continues to get this error.  Do note that when I specifically LOC'd the four wrappers to four different IDELAYCTRLs, the build worked and the bitstream was built.  However, I did this by causing the second wrapper in each clock region to use a separate IDELAYCTRL from a neighboring clock region.  I figure the long distance and clock region crossing are not good things.

Help!!!

0 Kudos
1 Solution

Accepted Solutions
helmutforren
Scholar
Scholar
2,269 Views
Registered: ‎06-23-2014

I'm starting to understand the EXPLICIT method, but less so the IMPLICIT method.

EXPLICIT: I made my submodules have a parameter, to either instantiate the IDELAYCTRL or use a RDY input that came from a brother submodule that *did* instantiate the IDELAYCTRL.  In this way, two submodules using pins in the same I/O bank are given opposite parameter values.  This way, only one IDELAYCTRL block is instantiated, yet both submodules get the same RDY signal coming from that one IDELAYCTRL block.  Since I have four submodules in two I/O banks, I've done this twice.

IMPLICIT: I'm not using the implicit method because I don't meet @avrumw 's criteria "if the two camera interfaces do NOT have pins in the same bank [emphasis added]."  Nevertheless, I want to understand it.  For Option 1, I understand to instantiate only once (first bullet).  That's the same as the EXPLICIT method.  The difference here is to omit IODELAY_GROUPS (second bullet), which will then let the tool automagically do it's job (third bullet).  I think I understnad this much.  What I do NOT understand is "which will be replicated into the banks where it is needed".  Well, by definition you said this case is for where the pins are NOT in the same bank.  So TWO instantiations of IDELAYCTRL are required.  But we only instantiate one.  Then the tool "replicates" it.  OK.  Maybe I'm beginning to understand.  In order for that replication to meet needs, however, all three I/O to the IDELAYCTRL must be the same.  The same input clock, reference clock, and ready out signal usage.  If we want anything different, then the replication won't be what we want.  Instead we must go to the EXPLICIT method.  Maybe I've got this. 

IMPLICIT: Let's move on to Option 2.  Since each submodule deals with pins in a different block, it's OK to have one IDELAYCTRL per submodule (first bullet).  Regarding the second bullet, I think this may not be necessary.  I think one might leave out the groups, and just like Option 1, the tool will figure it out.  If not, if the tool can't figure this out, then I understand the second bullet. Add the groups to explicitly associate IDELAYCTRL's with IDELAY/ODELAY instantiations.  Maybe this is actually an "EXPLICIT" example, in this case.  But the tool ***ought*** to be able to figure out this association simply by the given rules.  Whatever!

 

[EDIT: Note that following through and adding the IDELAYCTRL itself to the group has built succesfully.  I confirmed who used which IDELAYCTRL by highlighting on the netlist/device.  So that solves the question.  I am going to mark MY post here as the solution, with big thank you to @avrumw for confirming the path I had failed to follow through on.  I mark this one because I like my colloquial answer above, and think it might be a helpful starting point for others to read.  Then they can go deeper and read @avrumw and his references.  Thanks!]

View solution in original post

0 Kudos
4 Replies
avrumw
Guide
Guide
2,334 Views
Registered: ‎01-23-2009

Take a look at this post on the IDELAYCTRL.

Avrum

0 Kudos
helmutforren
Scholar
Scholar
2,283 Views
Registered: ‎06-23-2014

Thanks, @avrumw , but I still can't see the solution.  Please note that I have tried grouping, but couldn't get to a successful build.

Specifically, I wrote in my original post:

    "My *belief* is that if I should use "(* IODELAY_GROUP = PARM_IODELAY_GROUP *)" at the two IDELAYE2's deep inside n_x_serdes_1_to_7_mmcm_idelay_ddr.  (Actually there are four IDELAYE2's, but through parameters, only two are instantiated at a time.)  I provide PARM_IODELAY_GROUP ="X0Y0" to two of my top level camera wrappers, and PARM_IODELAY_GROUP ="X0Y1" for the other two.  (Note that the "X0Y0" is just a string.  I'm not believing this in itself to place anything, even though that's indeed where I want it placed.)  My *hope* is that the Vivado tools will magically cause two of my camera wrappers with the same PARM_IODELAY_GROUP to use the same IDELAYCTRL.  Then the other two would share a second IDELAYCTRL.  I realize that the .RDY output would then be "shorted" together or made the same for each pair, which may be a problem here.

    "I guess I should ask the following question.  Two of my camera wrappers deal with pins in the X0Y0 clock region, and the other two deal with pins in the X0Y1 clock region.  I would like those two camera_wrappers in the X0Y0 clock region to SHARE a single IDELAYCTRL.  Likewise for the X0Y1 clock region.  While doing this, I would like to keep using the .RDY signal, which as I mentioned gets passed lower down to be combined to make a composite ready signal within each n_x_serdes_1_to_7_mmcm_idelay_ddr.  How can I do this? 

Well, that didn't build.  I recall it made me ALSO add to the group, the IDELAYCTRL itself, not just the IDELAYE2's.  

Then, worrying about the output merging the .RDY signals, I modified things via parameters so that only two of the four wrappers actually instantiates the IDELAYCTRL, and this should be one per clock region / bank.  Then, the other two wrappers receive a RDY signal from the two that have the IDELAYCTRL.  This still didn't work.  (I realize at this point it may be complicated enough that I simply have a minor snafu in organization or text typing that is my problem.  Seeing a simplified EXAMPLE of this might help guide me.)

[

EDIT: It appears I didn't continue following through with my last paragraph above.  I got the error below and I'll try adding the IDELAYCTRL to the group.

image.png

]

0 Kudos
avrumw
Guide
Guide
2,274 Views
Registered: ‎01-23-2009

I am not following completely, but...

There is one IDELAYCTRL in each I/O bank. So if both of your camera interfaces have pins in the same I/O bank you are only allowed to instantiate one IDELAYCTRL. If your IDELAYCTRL is in the camera interface module and the two modules have pins in the same I/O bank then there is no solution for this - you must move the IDELAYCTRL out of the multiply instantiated module.

If the two camera interfaces do not have pins in the same bank, then you have two choices:

Option 1:

  • Move the IDELAYCTRL out of the sub-module and instantiate only one at the top level
  • Don't use any IODELAY_GROUPs anywhere
  • All IDELAY/ODELAYs in the design will use the one and only IDELAYCTRL in the design, which will be replicated into the banks where it is needed

Option 2:

  • Have one IDELAYCTRL in each sub-module
  • Have all the IDELAY/ODELAY and IDELAYCTRL in one sub-module have the same IODELAY_GROUP, which is different than the IODELAY_GROUP in the sother sub-module.

Avrum

helmutforren
Scholar
Scholar
2,270 Views
Registered: ‎06-23-2014

I'm starting to understand the EXPLICIT method, but less so the IMPLICIT method.

EXPLICIT: I made my submodules have a parameter, to either instantiate the IDELAYCTRL or use a RDY input that came from a brother submodule that *did* instantiate the IDELAYCTRL.  In this way, two submodules using pins in the same I/O bank are given opposite parameter values.  This way, only one IDELAYCTRL block is instantiated, yet both submodules get the same RDY signal coming from that one IDELAYCTRL block.  Since I have four submodules in two I/O banks, I've done this twice.

IMPLICIT: I'm not using the implicit method because I don't meet @avrumw 's criteria "if the two camera interfaces do NOT have pins in the same bank [emphasis added]."  Nevertheless, I want to understand it.  For Option 1, I understand to instantiate only once (first bullet).  That's the same as the EXPLICIT method.  The difference here is to omit IODELAY_GROUPS (second bullet), which will then let the tool automagically do it's job (third bullet).  I think I understnad this much.  What I do NOT understand is "which will be replicated into the banks where it is needed".  Well, by definition you said this case is for where the pins are NOT in the same bank.  So TWO instantiations of IDELAYCTRL are required.  But we only instantiate one.  Then the tool "replicates" it.  OK.  Maybe I'm beginning to understand.  In order for that replication to meet needs, however, all three I/O to the IDELAYCTRL must be the same.  The same input clock, reference clock, and ready out signal usage.  If we want anything different, then the replication won't be what we want.  Instead we must go to the EXPLICIT method.  Maybe I've got this. 

IMPLICIT: Let's move on to Option 2.  Since each submodule deals with pins in a different block, it's OK to have one IDELAYCTRL per submodule (first bullet).  Regarding the second bullet, I think this may not be necessary.  I think one might leave out the groups, and just like Option 1, the tool will figure it out.  If not, if the tool can't figure this out, then I understand the second bullet. Add the groups to explicitly associate IDELAYCTRL's with IDELAY/ODELAY instantiations.  Maybe this is actually an "EXPLICIT" example, in this case.  But the tool ***ought*** to be able to figure out this association simply by the given rules.  Whatever!

 

[EDIT: Note that following through and adding the IDELAYCTRL itself to the group has built succesfully.  I confirmed who used which IDELAYCTRL by highlighting on the netlist/device.  So that solves the question.  I am going to mark MY post here as the solution, with big thank you to @avrumw for confirming the path I had failed to follow through on.  I mark this one because I like my colloquial answer above, and think it might be a helpful starting point for others to read.  Then they can go deeper and read @avrumw and his references.  Thanks!]

View solution in original post

0 Kudos