cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Adventurer
Adventurer
1,903 Views
Registered: ‎10-17-2016

Distribution of reset signal to replicated idelayctrl primitives

Jump to solution

I have a design that requires a large number of differential serial input and output ports. They are all on the same clock domain and reset domain. Therefore, they are all part of the same IODELAY_GROUP. The input and output ports are distributed over Banks 64, 65 and 66.

 

In VHDL, I only instantiate one single idelay_ctrl which then gets replicated automatically by Vivado. I am following the reset sequence described in ug571 for all SelectIO resources. This includes the reset of the MMCM that generates the clocks for the SelectIO resources. My 100 MHz input clock comes from a differential clock input on Bank 65 and is used to clock my reset controller and as input clock for the MMCM. The MMCM generates a 500 MHz clock for the serial inputs/outputs.

 

My problem is the distribution of the reset signal to the replicated idelay_ctrl instances. Since the reset signal originates from the 100 Mhz clock domain and goes to the idelay_ctrl clocked by 500 MHz, the timing is very tight. The flip-flop of the reset signal gets replicated too, but the placer puts the replicas in the clock region of Bank 65. This is too far for 500 Mhz. The replicated flip flops seem to be constrained to this clock region because the input clock is not fed through a BUFGCE.

I have tried to feed the 100 MHz clock through a BUFGCE to allow distribution of the 100 MHz to other clock regions. This would then allow to place the replicated reset flip flops closer to the idelay_ctrls in the other IO Banks. However, when I use a BUFGCE for the 100 MHz clock, the routing process terminates abnormally without any useful information.

 

Any idea how I could achieve the distribution of the reset would be most welcome.

0 Kudos
Reply
1 Solution

Accepted Solutions
Adventurer
Adventurer
1,940 Views
Registered: ‎10-17-2016

Hi @chrisz, @marcb,

 

I finally found a solution to this. The register driving the reset signal never got replicated. I suspect this is because there is only one instance of IDLYCTRL in the RTL.

 

So I put multiple instances of IDLYCTRL in the RTL and constrained them to IODELAY_GROUPs matching the I/O-Banks. I added the IDLY instances to the corresponding groups. With this design, Vivado 2017.2 crashed again during placement.

 

In Vivado 2018.1, the design with only one IDLYCTRL was just able to get positive timing, with WNS 0.000 ns. The reset register still was not getting replicated. The design with multiple IDLYCTRLs finally replicated the reset register once for each IODELAY_GROUP, and the timing has improved to 0.061 ns WNS, 0.000 ns TNS, 0.011 ns WHS, 0.000 ns THS.

 

As a suggestion to Xilinx, I would propose that either the placer should be allowed to replicate the register driving the IDLYCTRL reset, or you should at least provide some more detailed instructions on how to implement the reset in a multi-bank I/O design.

 

Thanks,

Tobias

View solution in original post

0 Kudos
Reply
11 Replies
Moderator
Moderator
1,890 Views
Registered: ‎05-08-2012

Hi @welo_zhaw. Can you try manually replicating the reset registers? This would allow you full control on where they are placed, and how many are used.

 

Is a DCP that reproduces the abnormal termination/crash available? This can be tested against known issues, and reported if not already fixed.

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

---------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------
0 Kudos
Reply
Adventurer
Adventurer
1,818 Views
Registered: ‎10-17-2016
Hi marcb, Thank you for the response. I have three DCP files, *_opt.dcp, *_placed.dcp and *_physopt.dcp. When I open *_physopt.dcp, vivado crashes with the message "Abnormal program temination (11)". Is there a way I can submit this DCP to Xilinx privately? To manually replicate/place the registers, I still require the 100 MHz clock to be globally available, which currently causes the crash of the routing. Regards, Tobias
0 Kudos
Reply
Xilinx Employee
Xilinx Employee
1,808 Views
Registered: ‎05-06-2008

Hello @welo_zhaw,

 

I will send you a PM so you can share the DCP files.

 

Thanks,
Chris

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
1,791 Views
Registered: ‎05-06-2008

Hello @welo_zhaw,

 

Thank you for the DCP files.

 

I ran report_timing_summary and have a WNS of -0.576ns, TNS of -5.477ns, WHS of -0.260ns, and THS of -35.954ns on the post-physopt DCP.

 

I ran report_methodology command and noticed that the clock definition was placed on the input of the MMCM, instead of the clock port.

  TIMING-#1: Invalid clock redefinition on a clock tree. The primary clock mmcm_ioserdes_US_PLUS_1/inst/clk_in100 is defined downstream of clock clk_llO_p_i and overrides its insertion delay and/or waveform definition

 

Then I noticed that you have a clocking definition on  the input clock port and the input pin of the MMCM, so I removed the clocking definition on the input pin of the MMCM and re-ran report_timing_summary.  The timing analysis looks much better with WNS of 0.050ns, TNS of 0.00ns, WHS of -0.260ns, and THS of -35.954ns.

 

I ran route_design with high confidence that the tools could fix the hold violations.  And the results from report_timing_summary is all positive values.  Once the constraints are corrected, then the run-time of the tools is more efficient and faster.

 

Thanks,
Chris

Adventurer
Adventurer
1,784 Views
Registered: ‎10-17-2016
Hi Chris, thank you for having a look into this. So the route step did not crash again? I don't know where the clock definition on the MMCM input pin came from, it is not in the constraint files that I created. I guess it will have been created by the IP. I'll fix the constraints and try again, but it will be tomorrow. Thanks again, Tobias
0 Kudos
Reply
Adventurer
Adventurer
1,769 Views
Registered: ‎10-17-2016
Hi @chrisz I found the source of the clocking definition on the MMCM input clock port. It was generated by the MMCM IP configurator because the clock source was set to 'clock capable pin', instead of 'global buffer'. The warning TIMING-#1 is now gone and the route_desing process currently does not terminate abnormally any more. However, I still don't get positive timing. Did you apply special directives? Thank you, Tobias
0 Kudos
Reply
Xilinx Employee
Xilinx Employee
1,751 Views
Registered: ‎05-06-2008

Hello @welo_zhaw,

 

I did not apply any special directives.  How much are you failing timing?

  You may try some of the directives to try to meet timing.

 

Good Luck,
Chris

0 Kudos
Reply
Adventurer
Adventurer
1,737 Views
Registered: ‎10-17-2016

Hello @marcb,

 

Could you give me a hint how to manually replicate a register? I've been looking at the user guides but can't find clear instructions how to do so.

 

Is it correct to use the MAX_FANOUT attribute? This somehow works in generating replicated registers, but I don't know how to add a replicated register to a pblock for instance to manually place it.

In some other threads I have read about using the KEEP attribute to prevent removal of registers. But since my reset is driving IDELAYCTRLs that must be automatically replicated, I do not see how I would connect a specific register that I have instantiated multiple times to a replicated IDELAYCTRL.

 

Thank you,

Tobias

0 Kudos
Reply
Adventurer
Adventurer
1,730 Views
Registered: ‎10-17-2016

Hello @chrisz,

 

My Timing Summary currently looks like this:

WNS of -0.276 ns, TNS of -1.800 ns, WHS of 0.030 ns, THS of 0.000 ns

13 failing endpoints, all of them are resets to the IDELAYCTRLs.

 

Applied directives are:

opt_design: enabled, Default directive

place_design: ExtraTimingOpt, -fanout_opt

phys_opt_design: AggressiveFanoutOpt

 

I have a MAX_FANOUT = 3 attribute on the register driving the reset signal, but the register is not being replicated.

 

Apparently, I'm not replicating the registers correctly. Any help will be appreciated.

 

Thanks, Tobias

 

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
1,314 Views
Registered: ‎05-06-2008

Hello @welo_zhaw,

 

I recommend running with some of the other strategies provided in Vivado and see if they will help meet timing.

 

Good Luck,
Chris

0 Kudos
Reply
Adventurer
Adventurer
1,941 Views
Registered: ‎10-17-2016

Hi @chrisz, @marcb,

 

I finally found a solution to this. The register driving the reset signal never got replicated. I suspect this is because there is only one instance of IDLYCTRL in the RTL.

 

So I put multiple instances of IDLYCTRL in the RTL and constrained them to IODELAY_GROUPs matching the I/O-Banks. I added the IDLY instances to the corresponding groups. With this design, Vivado 2017.2 crashed again during placement.

 

In Vivado 2018.1, the design with only one IDLYCTRL was just able to get positive timing, with WNS 0.000 ns. The reset register still was not getting replicated. The design with multiple IDLYCTRLs finally replicated the reset register once for each IODELAY_GROUP, and the timing has improved to 0.061 ns WNS, 0.000 ns TNS, 0.011 ns WHS, 0.000 ns THS.

 

As a suggestion to Xilinx, I would propose that either the placer should be allowed to replicate the register driving the IDLYCTRL reset, or you should at least provide some more detailed instructions on how to implement the reset in a multi-bank I/O design.

 

Thanks,

Tobias

View solution in original post

0 Kudos
Reply