cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
22,523 Views
Registered: ‎04-07-2014

Vivado and BUFGMUX timing

Jump to solution

Hi all,

 

I observe a strange behavior with Vivado and a BUFGMUX. As I understand, the purpose of the BUFGMUX is seamless switching between two different clocks. In the code example below, a timing error is given for the path from input_buf to output. I do not want to declare the two clocks asynchronous because there are in fact other interactions between the clocks I would like to check and/or constrain.

 

Comments are welcome.

 

 

XDC file:

 

create_clock -name clk1 -period 20 [get_ports clk1]
create_clock -name clk2 -period 21 [get_ports clk2]

 

VHDL file:

 

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
library UNISIM;
use UNISIM.VComponents.all;

entity test123 is
    Port ( clk1 : in STD_LOGIC;
           clk2 : in STD_LOGIC;
           sele : in STD_LOGIC;
           input : in STD_LOGIC;
           output : out STD_LOGIC);
end test123;

architecture Behavioral of test123 is

signal clk_muxed,input_buf : std_logic;

begin
    BUFGMUX_inst : BUFGMUX port map (O => clk_muxed,I0 => clk1,I1 => clk2,S => sele);
    
    process(clk_muxed)
    begin
        if rising_edge(clk_muxed) then
            input_buf <= input;
            output <= input_buf;
        end if;
    end process;
end Behavioral;

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
35,326 Views
Registered: ‎09-20-2012

Re: Vivado and BUFGMUX timing

Jump to solution

Hi,

 

Check set_case_analysis constraint. This is used to choose one clock among BUFGMUX inputs in the timing analysis

 

Refer to page-110 of http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_4/ug903-vivado-using-constraints.pdf

 

 

 

Thanks,

Deepika.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)

View solution in original post

0 Kudos
17 Replies
Highlighted
Xilinx Employee
Xilinx Employee
35,327 Views
Registered: ‎09-20-2012

Re: Vivado and BUFGMUX timing

Jump to solution

Hi,

 

Check set_case_analysis constraint. This is used to choose one clock among BUFGMUX inputs in the timing analysis

 

Refer to page-110 of http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_4/ug903-vivado-using-constraints.pdf

 

 

 

Thanks,

Deepika.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)

View solution in original post

0 Kudos
Highlighted
Guide
Guide
22,516 Views
Registered: ‎01-23-2009

Re: Vivado and BUFGMUX timing

Jump to solution

It would be better if you gave us all your XDC constraints...


When you use the BUFGMUX, the output of the BUFGMUX and everything downstream of it carries both clocks. Therefore, every static timing path that starts/ends at clocked elements that use this clock will be timed FOUR times

 

clk1 -> clk1

clk2 -> clk2

clk1 -> clk2 (which is pretty much guaranteed to fail, since it results in a 1ns requirement)

clk2 -> clk1 (so is this)

 

This is the way Vivado works...

 

This will be true of paths that start at your inputs. When you do the set_input_delay, you choose which clock you reference the input to. Lets say you do

 

set_input_delay -clock clk1 1 [get_ports input]

 

You are defining the startpoint relative to clk1, so it will get timed

 

clk1 -> clk1

clk1 -> clk2

 

 

If you don't want the cross clock analyses , then you will need to modify the behavior with some timing exceptions - for example

 

set_false_path -from [get_ports input] -to [get_clocks clk2]

 

By the way, (and this is an interesting aside) you can reference an input to both clocks...

 

set_input_delay -clock clk1 1 [get_ports input]

set_input_delay -clock clk2 1 [get_ports input] -add_delay

 

With this you now get all four checks defined above...

 

Avrum

Highlighted
Xilinx Employee
Xilinx Employee
22,486 Views
Registered: ‎08-02-2007

Re: Vivado and BUFGMUX timing

Jump to solution

Hi,

 

I have tested it out and it works.

 

--Hem

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Explorer
Explorer
22,472 Views
Registered: ‎04-07-2014

Re: Vivado and BUFGMUX timing

Jump to solution

Hi all,

 

thank you all for your quick replies. The set_case_analysis constraint definitely works. I have to get used to the fact, that Vivado, in contrast to ISE, considers all clocks synchronous to each other.

 

Thanks again.

 

Yours,

Sebastian

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
22,314 Views
Registered: ‎11-28-2007

Re: Vivado and BUFGMUX timing

Jump to solution

Hi Sebastian,

 

I do not agree with the proposed solution.

Using set_case_analysis is nice for what-if analysis or static configurations where only 1 of 2 configurations is used.

 

In this case - correct me if I'm wrong - you want make sure timing is verified against both clocks:


@sgeorgi_sen wrote:
I do not want to declare the two clocks asynchronous because there are in fact other interactions between the clocks I would like to check and/or constrain.

There is a section in UG903 - Using constraints that mentions this case. As Avrum already explained, the problem is that Vivado doesn't understand how BUFGMUX'es work and just propagates both clocks through the BUFGMUX.

As a result the 2 clocks exist at the other end at the same time.

To prevent simultaneous co-existence, you need to make them exclusive:

 

screenshot_005.jpg

This will make sure that both configurations are verified for timing: case where clk1 is selected and case where clk2 is selected.

 

Do these clocks also clock logic outside the BUFGMUX domain?

 

 

Best regards

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
0 Kudos
Highlighted
Explorer
Explorer
21,501 Views
Registered: ‎04-07-2014

Re: Vivado and BUFGMUX timing

Jump to solution

Hi Dries,

 

excuse me for replying after such a long time. I agree with your post: Both clocks are used and both clocks should be checked. I switched the case_analysis to the faster clock as a first step but I have a bad feeling about this.

 

Your last question must be answered with YES, therefore the clocks are not exclusive. There is interaction between flip flops driven by the BUFGMUX and flip flops driven by one of the BUFGMUX's input clocks.

 

What would be the appropriate timing constraint? signal transitions between the clocks are protected (SYNC/GUARD) and constrained with set_max_delay.

 

Best regards and thanks for the patience,

Sebastian

 

0 Kudos
Highlighted
Guide
Guide
21,491 Views
Registered: ‎01-23-2009

Re: Vivado and BUFGMUX timing

Jump to solution

OK - so it gets complicated now. We want to declare the clocks after the BUFGMUX as asynchronous but any interaction between clocks other than through the BUFGMUX not asynchronous...

 

So, what we want to do is to separate the clocks on the far side of the MUX from the clocks on the near side of the MUX. This is done by generated clocks.

 

We will create two new clocks on the output of the BUFGMUX that are generated clocks based on their inputs

 

create_generated_clock -name clk1_post -source [get_pins BUFGMUX_inst/I0] -combinational [get_pins BUFGMUX_inst/O]

 

create_generated_clock -name clk2_post -source [get_pins BUFGMUX_inst/I1] -combinational [get_pins BUFGMUX_inst/O] -add; # Don't forget the -add on this one, but it must not be on the first one

 

[Edit: Corrected the -combinational flag. Note: You can, and maybe even should use -divide_by 1 instead]

 

With these two new clocks, we can set them as physically exclusive (since they are - they can't exist at the same time). From the timing point of view this is identical to -asynchronous, but is more descriptive.

 

set_clock_groups -physically_exclusive -group clk1_post -group clk2_post

 

Now the two generated clocks are false paths from eachother, but they are not false to any other clock in the design.

 

Avrum

Highlighted
Moderator
Moderator
21,489 Views
Registered: ‎01-16-2013

Re: Vivado and BUFGMUX timing

Jump to solution

Hello,

 

"There is interaction between flip flops driven by the BUFGMUX and flip flops driven by one of the BUFGMUX's input clocks"

 

If clkA and clkB are input clocks of bufgmux and clk_out (that can be any one of input clock) is output of bufgmux. Then suppose clkB drives some interactive FF whose input driven by FF clocked by bufgmux output, in this case when clkA is at output it will be async with clkB. {Refer below snapshot}.

 

forum.PNG

 

So you want to analyze this {ASYNC} path or you want to ignore this path?


If you want analysis the you can specify set_max_delay with -datapath_only option as it is async path.

If you want to ignore then you can specify timing exceptions.

 

Thanks,

Yash

0 Kudos
Highlighted
Explorer
Explorer
21,463 Views
Registered: ‎04-07-2014

Re: Vivado and BUFGMUX timing

Jump to solution

Hi Avrum,

 

thanks for your very reasonable explanation. I tried your constraints with the following modifications:

 

-combinatorial is -combinational

 

with the -add option I had to provide the master_clock option which is to my understanding the previously defined clock network connected to I1 of the BUFGMUX.

 

Now timing check works and I have a much better feeling about this.

 

Thank you again!

Sebastian

0 Kudos
Highlighted
Guide
Guide
14,976 Views
Registered: ‎01-23-2009

Re: Vivado and BUFGMUX timing

Jump to solution

I am puzzled by the need for the -master_clock option. That should only be needed if the pin specified in the -source carries more than one clock. In this case the source (BUFGMUX_inst/I1) shouldn't be carrying more than one clock (although the destination will be) - at least not from what you have told us.

 

Is it possible that the I1 input of this BUFGMUX itself comes from a BUFGMUX so already has 2 clocks on it (in which case it would need the -master_clock option not because it is used in the constraint with the -add, but due to the nature of this clock pin in your particular design)?

 

Avrum

0 Kudos
Highlighted
Explorer
Explorer
14,960 Views
Registered: ‎04-07-2014

Re: Vivado and BUFGMUX timing

Jump to solution

Hi Avrum,

 

in the help for create_generated_clock the -master_clock is mandatory - at least in 2014.2:

 

"Note: -master_clock and -name options must be specified with -add"

 

although the -source option already provides the one and only clock source.

 

The constraint works and the timing checks of the design make sense. But you are right, I neither understand the need for the -master_clock option.

 

Regards,
Sebastian

0 Kudos
Highlighted
Explorer
Explorer
14,956 Views
Registered: ‎04-07-2014

Re: Vivado and BUFGMUX timing

Jump to solution

Even in the provided sample design Vivado 2014.2 gives a warning, when -master_clock is left out:

 

[Vivado 12-670] Cannot specify -add without specifying -master_clock.

 

Sebastian

0 Kudos
Highlighted
Observer
Observer
7,334 Views
Registered: ‎06-14-2017

Re: Vivado and BUFGMUX timing

Jump to solution

Hi @avrumw,

 

I see that you have mentioned following :

 

create_generated_clock -name clk1_post -source [get_pins BUFGMUX_inst/I0] -combinatorial [get_pins BUFGMUX_inst/O]

 

create_generated_clock -name clk2_post -source [get_pins BUFGMUX_inst/I1] -combinatorial [get_pins BUFGMUX_inst/O] -add.

 

Quick clarification needed :

 

1) I believe we need to use -master_clock option too, otherwise Vivado (v2017.2) tool throws warning that no _master_clock is defined.

2) You are using -combinational flag because generated clock (out of BUFGMUX) is travelling through combinational logic of mux, right? And that input to this logic (of MUX) is a clock.

Something like :

clockA-->Combo_logic-->clock_out.

 

In this case combo logic is mux.

a) But if we have simple AND gate of clock gating logic, then also same principle will hold true and we will need -combinational flag to create_generate_clock at output of AND gate w.r.t. the clock coming to inputs of AND gate, right?

b) What if, if the input to mux is another generated_clock based on some source clock. There also can we use -combinational flag? Circuit is something like :

source_clock-->Genereted_clock-->combo_1-->clock_out.

 

But there is an AR to put constraints :

https://www.xilinx.com/support/answers/59484.html

And there i don't see any -combinational flag in constraints. Can you please let me know what am i missing here?

 

Best Regards,

RB

 

0 Kudos
Highlighted
Guide
Guide
7,308 Views
Registered: ‎01-23-2009

Re: Vivado and BUFGMUX timing

Jump to solution

1) I believe we need to use -master_clock option too, otherwise Vivado (v2017.2) tool throws warning that no _master_clock is defined.

 

This shouldn't be necessary. The -master_clock should only be necessary if there is more than one clock on the -source port.

 

The "no_master_clock" warning may mean something else - it may be indicating that there is no clock propagating to the -source pin specified in the command - as in "I cannot find the master clock here".

 

2) You are using -combinational flag because generated clock (out of BUFGMUX) is travelling through combinational logic of mux, right? And that input to this logic (of MUX) is a clock.

 

In a create_generated_clock command you must define the relationship between the generated clock and the master clock (the clock found on the -source pin). The relationship can be defined using the -divide_by, the -multuply_by, the -edges or the -combinational flag. I used to think the -combinational is a synonym for -divide_by 1, but it isn't. It specifically excludes propagation through a clocked element. In this case, I believe it is acceptable, but in most other cases, I now avoid using it, and use -divide_by 1 or -multiply_by 1.

 

For all your other questions, I have mostly answered it. The -combinational is merely defining a relationship between the master clock and the generated clock. If the master clock can be any clock - a primitive clock or another generated clock that has propagated to the -source pin. It doesn't matter if the propagation is through a MUX or a logic gate or even a sequential element (like an ODDR) - as long as the relationsip is properly defined.

 

Note: It is not necessary to use  create_generated_clock at all places that a clock propagates through a cell. Clocks propagate through buffers all the time, and need no additional constraints. Clocks will propagate through AND and OR gates and even MUXes with no problem. The only reason we need to do what I described above is so that we have separate clocks before and after the MUX (rather than the same clock), so that we can manipulate the behavior of the clocks before and after the MUX differently.

 

Finally, one should (generally) not propagate a clock through general logic. While SDC/XDC allows for this and times it properly, it is bad architecture, and introduces significant clock skew...

 

Avrum

Highlighted
Observer
Observer
7,224 Views
Registered: ‎06-14-2017

Re: Vivado and BUFGMUX timing

Jump to solution

@avrumw,

 

Thanks for you clear explanation.

I now understand when we need -combinational flag (when generated clock path may have sequential element in it's path and we want tool to consider on LUT path only and not path through sequential element).

Well FYI, this was the case when i was using ICG cell in my design.

 

Thanks and Regards,

Rakesh

0 Kudos
Highlighted
Explorer
Explorer
6,972 Views
Registered: ‎11-24-2016

Re: Vivado and BUFGMUX timing

Jump to solution

in https://www.xilinx.com/support/answers/59484.html

create_generated_clock -name clk1mux -divide_by 1 -add -master_clock clk1 -source [get_pins BUFGMUX_inst1/I0] [get_pins BUFGMUX_inst1/O]
create_generated_clock -name clk2mux -divide_by 1 -add -master_clock clk2 -source [get_pins BUFGMUX_inst1/I1] [get_pins BUFGMUX_inst1/O]
set_clock_groups -physically_exclusive -group clk1mux -group clk2mux
 -----------------------------

It use get_pins in create_generated_clock, but use -physicall_exclusive in set_clock_groups. Is it OK?

As I know, get_ports matches -physically_exclusive, get_pins matches -logically_exclusive. Is this a right undersand?

0 Kudos
Highlighted
Moderator
Moderator
6,966 Views
Registered: ‎11-04-2010

Re: Vivado and BUFGMUX timing

Jump to solution
Hi, @luoyanghero ,
Actually there is no difference in result no matter you use -physically_exclusive or -logically_exclusive.
In general, we use -physically_exclusive when the path analyzed doesn't exist in the real design. Like the output of BUFGMUX, only one clock take affect in the same time.
We use "-logically_exclusive" when the path exist in the design but we have taken the other method to promise the logical correctness, such as FIFO, hand shaking signal. The paths don't need to be analyzed from logic perspective.
Get_pins/ get_ports is not the reason to use -physically_exclusive or
-logically_exclusive.
-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------