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: 
Visitor drinu8
Visitor
11,218 Views
Registered: ‎10-21-2015

Is the BUFGCTRL output automatically constrained?

Jump to solution

Hi All,

 

I have 4 clocks, for which I need to be able to disable. Obviously I thought of using a BUFGCE first, but this requires that the CE signal must meet the setup time requirement, and as the CE signal is being fed by another asynchronous clock source, this is not possible. So instead I am using a BUFGCTRL as this offers glitchless operation if only the S inputs are used. My setup is as follows;

bufgctrl.png

I verified correct operation of the Buffer through a simulation, but when I come to timing analysis, it seems that no clock constraint is being generated for the output of the BUFGCTRL, and thus Setup and hold time values are listed as NA. Should I do this myself? and if so how?

Some other details;

The input of the BUFGCTRL is the output of a PLL.

Vivado_schematic.png

report_clocks.png

 

Some other details;

The device is the XC7A200, speed grade is -2.

CLK details;

- 625MHz

- 625MHz shifted by 90 degrees

- 312.5MHz

- 312.5MHz shifted by 90 degrees

625MHz drives OSERDES.

312.5MHz drives Logic, and low frequency side of OSERDES.

 

Thanks in advance, and regards,

drinu8

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
20,854 Views
Registered: ‎01-23-2009

Re: Is the BUFGCTRL output automatically constrained?

Jump to solution

So, I am not sure what problem you have. The timing report you showed us doesn't really give us information - it's not clear where in the timing summary it comes from. Show us an actual timing path - that would give more information.

 

I don't see anything obviously wrong with what you are doing. As long as you constrain the input to the PLL (at the DCLK_out input pins), the clocks should be (and apparently are) properly generated at the outputs of the PLL (as seen by the clock report) and should propagate through the BUFGCTRL cells.

 

The only other possibility is that you have misconfigured your BUFGCTRLs so that they are permanenty (and statically) disabled - if that is the case (I think) Vivado will not allow the clock to propagate through the BUFGCTRLs. Try changing them (at least temporarily) to regular BUFGs and see if that makes a difference (and re-check your control inputs to the BUFGCTRL if it does).

 

But, again, we need to see a static timing path to really understand if the clocks are not propagating through the BUFGCTL.

 

Another thing you can do is check the clocks propagating on each net or pin. This can be easily done with the command

 

get_clocks -of_objects [get_selected_objects]

 

Type this command into the Tcl console after selecting a net or pin in the schematic view. You will be able to verify that the clock exists on the nets (or pins) going into the BUFGCTRL, and then see if they are still present on the nets going out.

 

And by the way, I notice that you have two BUFGs before the PLL input. Ideally the PLL input should come directly from the clock capable input pins. Particularly at these frequencies (625), you don't want to go through any unecessary clock networks, as this will just increase the induced jitter on these clocks. This isn't the cause of your timing analysis problems, but will degrade performance of your design.

 

Avrum

4 Replies
Highlighted
Historian
Historian
20,855 Views
Registered: ‎01-23-2009

Re: Is the BUFGCTRL output automatically constrained?

Jump to solution

So, I am not sure what problem you have. The timing report you showed us doesn't really give us information - it's not clear where in the timing summary it comes from. Show us an actual timing path - that would give more information.

 

I don't see anything obviously wrong with what you are doing. As long as you constrain the input to the PLL (at the DCLK_out input pins), the clocks should be (and apparently are) properly generated at the outputs of the PLL (as seen by the clock report) and should propagate through the BUFGCTRL cells.

 

The only other possibility is that you have misconfigured your BUFGCTRLs so that they are permanenty (and statically) disabled - if that is the case (I think) Vivado will not allow the clock to propagate through the BUFGCTRLs. Try changing them (at least temporarily) to regular BUFGs and see if that makes a difference (and re-check your control inputs to the BUFGCTRL if it does).

 

But, again, we need to see a static timing path to really understand if the clocks are not propagating through the BUFGCTL.

 

Another thing you can do is check the clocks propagating on each net or pin. This can be easily done with the command

 

get_clocks -of_objects [get_selected_objects]

 

Type this command into the Tcl console after selecting a net or pin in the schematic view. You will be able to verify that the clock exists on the nets (or pins) going into the BUFGCTRL, and then see if they are still present on the nets going out.

 

And by the way, I notice that you have two BUFGs before the PLL input. Ideally the PLL input should come directly from the clock capable input pins. Particularly at these frequencies (625), you don't want to go through any unecessary clock networks, as this will just increase the induced jitter on these clocks. This isn't the cause of your timing analysis problems, but will degrade performance of your design.

 

Avrum

Visitor drinu8
Visitor
10,814 Views
Registered: ‎10-21-2015

Re: Is the BUFGCTRL output automatically constrained?

Jump to solution

Hi Avrum,

 

Thanks for your reply.

I used the command;  -  get_clocks -of_objects [get_selected_objects]  and I got the following output: - PLL_clks_n_3 I0 PLL_clks_n_2 PLL_clks_n_1. So the clocks are being propagated properly through the BUFGCTRL buffers. I was not sure whether the clocks were being propagated.

Furthermore, I opened a static timing path as shown below, showing that the clock is being propagated as well.

failed timing.png

As you can see, the timing is not being met. I will be adding a pipeline register in the path above. In the static timing, how does the tool determine the timing of the PLL? Furthermore, shouldn't the timing for the PLL be equal for both source and destination paths [for source path, timing is -5.846, for destination path, timing is -5.215]?

 

With regards to the BUFGs, yes you are right - I removed them :)

 

Thanks and regards,

drinu8

0 Kudos
Historian
Historian
10,802 Views
Registered: ‎01-23-2009

Re: Is the BUFGCTRL output automatically constrained?

Jump to solution

This is going to be a tough path to meet. The clock to output time of the block RAM is a very significant portion of your clock period (2.125ns). If you are going to add a pipeline stage to this path, consider turning on the output registers on the block RAM (see "Optional Output Registers" in the Memory Resources User Guide - UG473). If you use RTL to infer your RAMs, putting pipeline registers in your code should move these registers into the block RAM.

 

At these speeds, you have to recognize the limitations of the physical layout of the device. The Block RAMs are in their own column on the die, and that means that there will often need to be significant routing delays both to and from the BRAMs. Generally, at higher frequencies, I budget for the address and control signals to come directly from flip-flops and the outputs of the RAM going directly to flip-flops, and sometimes with the optional output registers. This makes the BRAM reads effectively have 3-4 clocks of latency (one through the address FFs, one through the RAM, one through the output registers of the RAM, and one for the extra FFs in the fabric) - this is a lot, but if you can afford it architecturally, it is the best way to ensure that you won't have timing problems around the RAMs at high frequencies.

 

As for the timing of the PLL, it is correct. The way that Vivado deals with Source Clock Delay and Destination Clock Delay (and the fact that they are done at slightly different process corners) is a bit complicated, but is correct. The "pessimism" of counting common components in these two paths with different timing is added back in the "clock pessimism" line of the timing report.

 

Avrum

0 Kudos
Visitor drinu8
Visitor
10,698 Views
Registered: ‎10-21-2015

Re: Is the BUFGCTRL output automatically constrained?

Jump to solution

I'm using the IP core, so I'll just tick the option available whilst configuring the core.

 

Ok thanks ... I think I will start by 1 pipeline register, and keep increasing until it meets timing ... design should be ok, even if it adds a little bit of latency, but should be fine.

 

Ok thanks for the brief explanation!

 

Thanks for the help :)

 

drinu8

0 Kudos