cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
787 Views
Registered: ‎06-21-2018

Multi-Region Clocking BUFR Alignment

Jump to solution

Hello!

I need to implement Multi-Region Clocking to capture incoming data using a high-speed and a divided clock. I'm planning to use the following setup from UG472:

 

grafik.png

The user guide further says in the BUFR Alignment Circuit description: "All BUFRs must be released in the same clock cycle to ensure phase alignment of all the BUFR output clocks."

I'm assuming the description means the BUFR's input clock by "same clock cycle", but this part stumps me. How can I ensure this? It seems to me that if I connect a clock enable signal coming from the FPGA fabric clocked by an unrelated clock, the routing of the signal can lead to the BUFRs being released at different times. But clocking the BUFR Alignment circuit with the BUFR clock is not possible because if the CLR is asserted, the clock stops.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
705 Views
Registered: ‎01-22-2015

@pf_arc 

Good question!

The following schematic of components can be used to implement the BUFR alignment procedure described on page 110 of UG472(v1.14). 
BUFR_ALIGN.jpg

Note that clock coming from the MRCC pin/port, CLK1_IN, has been routed to both a BUFMRCE and a BUFG.  When you disable the clock output of the BUFMRCE, the clock output of the BUFG stays “alive” (something you wanted).  Further, the tools understand that the clock outputs of the BUFMRCE and the BUFG are related (something you worried about). 

The RST_BRIDGE component is a reset bridge that brings the asynchronous reset, RST_IN, into the CLK1_IN clock domain.  When RST_IN=1 then the BUFMRCE output is disabled and the component called COUNTER1 (a simple counter) sets CLR=1 on each of the BUFR.  When RST_IN is toggled from 1 to 0 then the output of BUFMRCE is enabled and COUNTER1 begins a short countdown (eg. 4 cycles of CLK1_IN) and then sets CLR=0 on each of the BUFR.

You might be tempted to simplify the design by omitting the BUFG and letting the output of the BUFMRCE clock COUNTER1.  However, this won’t work because the BUFMRCE output cannot reach/clock fabric components.

Cheers,
Mark

View solution in original post

9 Replies
Highlighted
706 Views
Registered: ‎01-22-2015

@pf_arc 

Good question!

The following schematic of components can be used to implement the BUFR alignment procedure described on page 110 of UG472(v1.14). 
BUFR_ALIGN.jpg

Note that clock coming from the MRCC pin/port, CLK1_IN, has been routed to both a BUFMRCE and a BUFG.  When you disable the clock output of the BUFMRCE, the clock output of the BUFG stays “alive” (something you wanted).  Further, the tools understand that the clock outputs of the BUFMRCE and the BUFG are related (something you worried about). 

The RST_BRIDGE component is a reset bridge that brings the asynchronous reset, RST_IN, into the CLK1_IN clock domain.  When RST_IN=1 then the BUFMRCE output is disabled and the component called COUNTER1 (a simple counter) sets CLR=1 on each of the BUFR.  When RST_IN is toggled from 1 to 0 then the output of BUFMRCE is enabled and COUNTER1 begins a short countdown (eg. 4 cycles of CLK1_IN) and then sets CLR=0 on each of the BUFR.

You might be tempted to simplify the design by omitting the BUFG and letting the output of the BUFMRCE clock COUNTER1.  However, this won’t work because the BUFMRCE output cannot reach/clock fabric components.

Cheers,
Mark

View solution in original post

Highlighted
643 Views
Registered: ‎01-22-2015

UG472 says that the CLR pins of all BUFRs must be released in the same clock cycle. 

However, for the design I have shown, Vivado indicates that paths to the CLR pins of the BUFRs are unconstrained.  Using the following constraint does not help because Vivado says that [get_cells {BUFR*}] does not give valid endpoints for a timing path.

set_max_delay -datapath_only -from [get_cells {CNT1/OUT_CLR_reg}] -to [get_cells {BUFR*}] x.xx


So, after opening the implemented design, you should use Tcl commands like the following to check that paths to the CLR pins have delay less than the period of CLK1_IN.

report_timing -to [get_pins {BUFR1/CLR}]


If paths to the CLR pins have the necessary delay, then use LOC constraints (UG912(v2019.1), page 268) to fix the location of the register that feeds the CLR pins and to fix the location of the BUFRs. 

Highlighted
Visitor
Visitor
604 Views
Registered: ‎06-21-2018

Hello Mark,

Thank you very much for your reply. At first I was thinking of using another BUFR with no divider, but for one it doesn't reach as high a frequency and the clock would only be available in one region, I didn't think of using a BUFG. That solves both of these problems!

Since I will be controlling the reset by software, I think I'll have RST_BRIDGE running off an unrelated clock and synchronize its RST output in the COUNTER1 block. I think controlling the BUFMRCE's CE pin from a different clock should be fine, as per this post: Re: BUFMRCE.CE question

The unrelated clock is a lot slower, which has the added benefit of ensuring that the CE pin is asserted for at least an entire clock cycle.

0 Kudos
Highlighted
472 Views
Registered: ‎01-22-2015

@pf_arc 

@avrumw and I believe that the BUFR Alignment procedure described on pg110 of UG472(v1.14) is incorrect.  Further, Vivado simulation shows that the stated procedure sometimes fails to align the BUFRs.

So, if you are having trouble, then try the following BUFR Alignment procedure, which Vivado simulation shows to be working.

  • Deassert the CE pin of the BUFMRCE
  • Assert CLR pin on all the BUFR
  • Deassert CLR pin on all the BUFR
  • Assert CE pin of the BUFMRCE

As Avrum pointed out to me, this new BUFR Alignment procedure is implied by wording below Figure A-5 in UG472 and by wording on pg282 of UG953(v2019.1).

If you do any hardware testing of BUFR alignment, I hope that you will share the results with us.

Mark

Tags (1)
0 Kudos
Highlighted
Visitor
Visitor
437 Views
Registered: ‎06-21-2018

Hi Mark,

Thank you for getting back to me on this.

UG953 seems to provide conflicting information: the second sentence on pg282 is "Asserting CE stops the output clock to a user specified value". In the middle of the paragraph however, it says that "When using BUFR dividers (not in bypass), the BUFMRCE must be disabled by deasserting the CE pin, ..."

Just to make sure, when you write "assert", you mean the VHDL equivalent of std_logic '1', correct?

We're still a long way off from hardware testing, but I'm hoping to start simulations soon.

In your simulation, is the clock output of the BUFMRCE inactive when the CE pin is deasserted? To me, what the wording in the user guides have in common is that the clock output of the BUFMRCE needs to be inactive while the BUFR are being cleared.

Greetings, Cyril

0 Kudos
Highlighted
422 Views
Registered: ‎01-22-2015

Hi Cyril,

Yes, the Xilinx documentation seems to have many unclear statements on this topic.

 "Asserting CE stops the output clock to a user specified value".
Good catch!  This sentence should say "Deasserting CE stops the...."

Just to make sure, when you write "assert", you mean the VHDL equivalent of std_logic '1', correct?
Assert CE means to send a std_logic '1' to the CE pin.  For BUFMRCE, the UG953 documentation says that the Clock Enable (CE) pin is "active high".  So, when you apply a '1' to the CE pin then the Clock (output) is Enabled.

In your simulation, is the clock output of the BUFMRCE inactive when the CE pin is deasserted?
Yes.  When CE='0' then the clock output of BUFMRCE is inactive/disabled.

To me, what the wording in the user guides have in common is that the clock output of the BUFMRCE needs to be inactive while the BUFR are being cleared.
Yes, but wording in the guides is contradictory when it comes to deasserting the CLR pin on the BUFRs.  Avrum and I are saying that you should assert and deassert the CLR on BUFRs while the BUFMRCE clock output is inactive.

Mark

0 Kudos
Highlighted
Visitor
Visitor
411 Views
Registered: ‎06-21-2018

Oh, now I see the difference between your explanation and UG472. At first I thought it had to do with the logic level at which I need to drive the CE/CLR pins. I will keep yours and Avrum's procedure in mind.

I've noticed yet another oddity with UG472. Below the BUFR Alignment description, the guide says that "To turn off clocks during circuit operations, that is after the reset/CLR signal to the BUFRs is deasserted, disable the BUFMRCE using its CE pin."

However, in the description of the BUFR blocks themselves there is a note (pg54): "For proper operation, if the clock to the BUFR is stopped, then a reset (CLR) must be applied after the clock returns."

These again directly contradict each other. Having a reference design for Multi-Region Clocking would be really helpful.

0 Kudos
Highlighted
Visitor
Visitor
369 Views
Registered: ‎06-21-2018

markg@prosensing.com 

It just occurred to me that if your procedure is correct, the BUFG from your original reply should not be necessary anymore. Since the BUFMRCE would be disabled while the BUFR are being cleared, the BUFR are not clocked, hence the timing of the individual CLR signals should not matter because they have nothing to relate to.

Cyril

0 Kudos
Highlighted
365 Views
Registered: ‎01-22-2015

Cyril,

It just occurred to me that if your procedure is correct, the BUFG from your original reply should not be necessary anymore. Since the BUFMRCE would be disabled while the BUFR are being cleared, the BUFR are not clocked, hence the timing of the individual CLR signals should not matter because they have nothing to relate to.

I agree with you.

Mark

0 Kudos