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: 
Voyager
Voyager
703 Views
Registered: ‎05-30-2018

Timing constraints for multiplexed clocks

Jump to solution

Hello

Thre are two ports clockA and clockB with same frequency (but different standards ... 1.8 and 3.3), that are multipexed by port SELECT_CLOCK.

How correctly describe this case in .sdc ?

Create two clocks for clockA and clockB , then create some kind of generated clock at the output of multiplexer ?

Thanks.

 

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
686 Views
Registered: ‎01-23-2009

Re: Timing constraints for multiplexed clocks

Jump to solution

When two clocks meet at a MUX, both clocks are propagated on the output of the MUX - you don't need any extra constraints for this.

But, there are a couple of issues.

The first is (or may be) structural. To MUX two clocks together you should be using the BUFGMUX - using anything else will result in the clock going through the fabric. This is bad from at least two reasons - the output clock

  • will pick up extra jitter
  • will have unknown phase with respect to the input clocks, and will vary from implementation run to run
    • Hence doing any interface timing with this MUXed clock will be a problem

Assuming you use the BUFGMUX, you have to be careful of where the two clock sources come from. A BUFGMUX has limited input connectivity. In 7 Series and earlier technologies, the BUFGMUX inputs can only be driven directly from the clock capable pins in the same half of the FPGA (top/bottom) - if your two clocks are in different halves, then one of the clocks will have to go through the fabric. In UltraScale/UltraScale+ the BUFGCTRL can only be driven from the one bank that is adjacent to it - so you will not be able to drive inputs from two different banks into the same BUFGCTRL without going through fabric logic...

Once you have the BUFGMUX instantiated, if you constrain both CLKA and CLKB, then the output of the BUFGMUX will have both clocks on its ouptuts. Therefore any FF that is clocked by this net will see both clocks. This means that if you have a path that is clocked on both ends (startpoint and endpoint) wth this net, then you will get FOUR paths

  • startpoint @ CLKA to endpoint @ CLKA
  • startpoint @ CLKB to endpoint @ CLKB
  • startpoint @ CLKA to endpoint @ CLKB
  • startpoint @ CLKB to endpoint @ CLKA

Clearly the last two of these are false. If these two clocks go nowhere else other than the inputs of the BUFGMUX then you can declare these clocks as physically exclusive

set_clock_groups -physically_exclusive -group [get_clocks CLKA] -group [get_clocks CLKB]

If either of these clocks go anywhere other than the inputs of the BUFGMUX then this creates the risk of underconstraining any clock domain crossing path between CLKA and CLKB (or either one and the MUXed clock), and hence the above command shouldn't be used. If this is the case, a more complex set of constraints is required...

Avrum

Tags (1)
14 Replies
Historian
Historian
687 Views
Registered: ‎01-23-2009

Re: Timing constraints for multiplexed clocks

Jump to solution

When two clocks meet at a MUX, both clocks are propagated on the output of the MUX - you don't need any extra constraints for this.

But, there are a couple of issues.

The first is (or may be) structural. To MUX two clocks together you should be using the BUFGMUX - using anything else will result in the clock going through the fabric. This is bad from at least two reasons - the output clock

  • will pick up extra jitter
  • will have unknown phase with respect to the input clocks, and will vary from implementation run to run
    • Hence doing any interface timing with this MUXed clock will be a problem

Assuming you use the BUFGMUX, you have to be careful of where the two clock sources come from. A BUFGMUX has limited input connectivity. In 7 Series and earlier technologies, the BUFGMUX inputs can only be driven directly from the clock capable pins in the same half of the FPGA (top/bottom) - if your two clocks are in different halves, then one of the clocks will have to go through the fabric. In UltraScale/UltraScale+ the BUFGCTRL can only be driven from the one bank that is adjacent to it - so you will not be able to drive inputs from two different banks into the same BUFGCTRL without going through fabric logic...

Once you have the BUFGMUX instantiated, if you constrain both CLKA and CLKB, then the output of the BUFGMUX will have both clocks on its ouptuts. Therefore any FF that is clocked by this net will see both clocks. This means that if you have a path that is clocked on both ends (startpoint and endpoint) wth this net, then you will get FOUR paths

  • startpoint @ CLKA to endpoint @ CLKA
  • startpoint @ CLKB to endpoint @ CLKB
  • startpoint @ CLKA to endpoint @ CLKB
  • startpoint @ CLKB to endpoint @ CLKA

Clearly the last two of these are false. If these two clocks go nowhere else other than the inputs of the BUFGMUX then you can declare these clocks as physically exclusive

set_clock_groups -physically_exclusive -group [get_clocks CLKA] -group [get_clocks CLKB]

If either of these clocks go anywhere other than the inputs of the BUFGMUX then this creates the risk of underconstraining any clock domain crossing path between CLKA and CLKB (or either one and the MUXed clock), and hence the above command shouldn't be used. If this is the case, a more complex set of constraints is required...

Avrum

Tags (1)
Voyager
Voyager
630 Views
Registered: ‎05-30-2018

Re: Timing constraints for multiplexed clocks

Jump to solution

Thanks.

I did as you suggested.

Implementation error occured:

[Place 30-574] Poor placement for routing between an IO pin and BUFG. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule.
< set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets spis_sck_18_IBUF] >

spis_sck_18_IBUF_inst (IBUF.O) is locked to IOB_X0Y76
design_1_i/logic_v_0/U0/BUFGMUX_inst (BUFGCTRL.I1) is provisionally placed by clockplacer on BUFGCTRL_X0Y15

The above error could possibly be related to other connected instances. Following is a list of
all the related clock rules and their respective instances.

Clock Rule: rule_gclkio_bufg
Status: PASS
Rule Description: An IOB driving a BUFG must use a CCIO in the same half side (top/bottom) of chip
as the BUFG
spis_sck_33_IBUF_inst (IBUF.O) is locked to IOB_X0Y24
and design_1_i/logic_v_0/U0/BUFGMUX_inst (BUFGCTRL.I0) is provisionally placed by clockplacer on BUFGCTRL_X0Y15

where spis_sck_18 - clockA and spis_sck_33 - clockB from my previous notation.

Should I apply proposed workaround, i.e. set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets spis_sck_18_IBUF] ..or there is another solution ?

Thanks.

0 Kudos
Scholar dpaul24
Scholar
625 Views
Registered: ‎08-07-2014

Re: Timing constraints for multiplexed clocks

Jump to solution

@pavel_47,

set_property CLOCK_DEDICATED_ROUTE FALSE

Yes this solution is widely used. But it strongly depends on your design. If you can route the signal to a clock capable pin and accept the routing delay, then you need not use the set_property CLOCK_DEDICATED_ROUTE FALSE .

--------------------------------------------------------------------------------------------------------
FPGA enthusiast!
All PMs will be ignored
--------------------------------------------------------------------------------------------------------
0 Kudos
Voyager
Voyager
620 Views
Registered: ‎05-30-2018

Re: Timing constraints for multiplexed clocks

Jump to solution

I'm afraid I didn't proprerly understand the last frase in your message.

First of all, both pins ClockA and ClockB are clock capable.

Concerning routing delay I have no any idea of its value.

... then you need not use the set_property CLOCK_DEDICATED_ROUTE FALSE.

Well ... because of error actually design isn't implemented, so I can generate bistream.

If not apply this constraint, how to proceed to get the design generated ?

0 Kudos
Voyager
Voyager
612 Views
Registered: ‎05-30-2018

Re: Timing constraints for multiplexed clocks

Jump to solution

Well ... because of error actually design isn't implemented, so I can generate bistream.

must be

Well ... because of error, actually design isn't implemented, so I can not generate bistream.

0 Kudos
Scholar dpaul24
Scholar
597 Views
Registered: ‎08-07-2014

Re: Timing constraints for multiplexed clocks

Jump to solution

@pavel_47,

spis_sck_18_IBUF_inst (IBUF.O) is locked to IOB_X0Y76
design_1_i/logic_v_0/U0/BUFGMUX_inst (BUFGCTRL.I1) is provisionally placed by clockplacer on BUFGCTRL_X0Y15

I accept that you are currently using clock capable pins.

Your problem is the separate location of IBUF and BUFGMUX. Keeping the loc of BUFGMUX constant, move the location of IBUF, such that IBUF and BUFGMUX are in the same region. That means you have to change your clock input pin. You have to move from a clock capable pin (your existing pin in the design) to a non-clock capable pin (some free pin which is in the same region as IBUF and BUFGMUX). Vivado will complain regarding the location of the clock pin, but use CLOCK_DEDICATED_ROUTE FALSE in the constrain file to demote the error to a warning.

Hope I was able to explain.

--------------------------------------------------------------------------------------------------------
FPGA enthusiast!
All PMs will be ignored
--------------------------------------------------------------------------------------------------------
0 Kudos
Voyager
Voyager
592 Views
Registered: ‎05-30-2018

Re: Timing constraints for multiplexed clocks

Jump to solution

Problems while applying clock_dedicated_route constraint: vivado can't find clock net:

clock_dedicated_route_false_1.png

but net does exist:

clock_dedicated_route_false_2.png

0 Kudos
Voyager
Voyager
588 Views
Registered: ‎05-30-2018

Re: Timing constraints for multiplexed clocks

Jump to solution

Your problem is the separate location of IBUF and BUFGMUX.

Yes, I'm aware of the problem

Keeping the loc of BUFGMUX constant ...

I beleive it's Vivado that place BUFGMUX

... move the location of IBUF, such that IBUF and BUFGMUX are in the same region. That means you have to change your clock input pin. You have to move from a clock capable pin (your existing pin in the design) to a non-clock capable pin (some free pin which is in the same region as IBUF and BUFGMUX).

I can't move spis_sck_18 because it's wired on the board.

With spis_sck_33 it's slightly different: I can choose between 14 different pins (some of them are non-clcok capable).

Anyway it's spis_sck_18 that poses a problem, not spis_sck_33

 

0 Kudos
Scholar dpaul24
Scholar
578 Views
Registered: ‎08-07-2014

Re: Timing constraints for multiplexed clocks

Jump to solution

@pavel_47,

I beleive it's Vivado that place BUFGMUX

Yes it is always Vivado.

I can't move spis_sck_18 because it's wired on the board.

1. In such cases custom placement of the components in question needs to be done. It can be done via TCL scripts. But I am not sure in your design if the IBUF and BUFGMUX can be placed in the same region. It needs a deep analysis of the region (IOB_X0Y76) and looking if a BUFGMUX is available there to be used or not. If yes, then you are lucky. You just have to instruct Vivado for custom placement.

2. If not, a board re-design shifting your clock capable pin.

--------------------------------------------------------------------------------------------------------
FPGA enthusiast!
All PMs will be ignored
--------------------------------------------------------------------------------------------------------
0 Kudos
Voyager
Voyager
573 Views
Registered: ‎05-30-2018

Re: Timing constraints for multiplexed clocks

Jump to solution

Does exist a way to locate a particula object on the "Device" map ?

For example, if I want to locate BUFCTRL_X0Y15 (higlight, zoom or both), how to proceed ?

custom placement of the components in question needs to be done. It can be done via TCL scripts.

1. What is criteria for custom placement ?

2. What is the syntax of such Tcl command ?

If not, a board re-design shifting your clock capable pin.

It's impossible

0 Kudos
Scholar dpaul24
Scholar
551 Views
Registered: ‎08-07-2014

Re: Timing constraints for multiplexed clocks

Jump to solution

@pavel_47,

Note: Do this for everytime you seek help from anybody in this forum.

1. If you don't tag me, I will loose this thread and may never get back to it...and today is Friday! I will log off early. :-)

2. You have drifted from the original question. Creating new threads makes problem segregation and answering to the point easier.

----------------------------------------------------------------------------------------

For example, if I want to locate BUFCTRL_X0Y15 (higlight, zoom or both), how to proceed ?

Open the Implemented design and zoom into the region X0Y15. Play around with the implemented design graphics....explore more!

 

1. What is criteria for custom placement ?

2. What is the syntax of such Tcl command ?

Please understand that step-by-step guide is impossible in such forums. So start with reading the relevant documentation for custom placement. After you have some knowledge you can ask *SPECIFIC questions* in the relevant sub-forum.

 

 

--------------------------------------------------------------------------------------------------------
FPGA enthusiast!
All PMs will be ignored
--------------------------------------------------------------------------------------------------------
0 Kudos
Voyager
Voyager
542 Views
Registered: ‎05-30-2018

Re: Timing constraints for multiplexed clocks

Jump to solution

If you don't tag me ...

Sorry, I don't understand what do you mean exactly.

I succeded to apply constraint from Tcl shell, then implement design and generate bistream. Whan I try to do the same in .xdc, constraint fails: the net,  that is actually exists, isn't recognized.

So start with reading the relevant documentation for custom placement.

You mean ug904 or some other document ?

0 Kudos
Moderator
Moderator
526 Views
Registered: ‎11-04-2010

Re: Timing constraints for multiplexed clocks

Jump to solution

Hi, @pavel_47 ,

For the new derived question, please create a new thread as @dpaul24 suggested. It will be helpful to catalog the question and get right person to help you. 

If the question in original thread is resolved, please close the thread. At same time, don't forget to kudo the posts which are helpful for you.

Thank you for your understanding and cooperation. 

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Historian
Historian
516 Views
Registered: ‎01-23-2009

Re: Timing constraints for multiplexed clocks

Jump to solution

[Place 30-574] Poor placement for routing between an IO pin and BUFG.

This is exactly what I was describing before.

The error message is pretty clear - your two clock sources may be on clock capable pins, but they are in different halves of the FPGA - one is in the top half of the FPGA and the other is in the bottom half of the FPGA. The BUFGs are also split - with half in the top half and half in the bottom half. A single BUFG (or BUFGCTRL) can only be reached by clock capable pins in the same half.

So the tool has to choose where to place the BUFG. If it puts it in the top half, it has a legal connection to the clock in the top half, but no dedicated connection to the clock in the bottom half. If it places it in the bottom half, then the opposite occurs. So it just chose one.

The CLOCK_DEDICATED_ROUTE property is a way of saying "I know there is no 'dedicated route' possible, but I am telling you it's OK to route this clock through the FPGA fabric to get from the clock input to the BUFG". This should be avoided for the reasons I described earlier (jitter and unknown and variable input delay).

To fix this, you should move both clock sources in to the same half of the FPGA. If this is not possible then you will have to set the CLOCK_DEDICATED_ROUTE=FALSE on one of them and live with the consequences of that (and maybe LOC the BUFG so that you can tell which clock gets the dedicated route and which one goes through the fabric)...

Avrum

0 Kudos