cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Observer
Observer
2,376 Views
Registered: ‎12-29-2016

Timing analysis and clock synchronization

I have an MMCM which produces two outputs:

 

f1 - at frequency f

f2 - at frequency f/2

 

I connected:

 

BUFR (along with BUFIO)  is connected to f1. BUFR is configured to divide by 2.

BUFG connected to f2.

 

BUFR collects data from ISERDES and then the data are passed to other clock regions where the processing is clocked by BUFG.

 

In theory the clocks generated by BUFR and BUFG may have rising edges coincide to the same rising edge of the f1 clock. In this case they are roughly in phase. Or they may have their rising edges coincide to different rising edges of the f1 clock. In this case they are shifted by 90 degrees.

 

I do not do anything to make sure BUFG and BUFR clocks are in phase. I cannot find any documentation which discusses phase relationship between such clocks.

 

Vivado timing analysis assumes that BUFG and BUFR are in phase. Therefore the design passes timing as if both were the same clock except for a small clock skew. It works in hardware, but this doesn't prove anything.

 

My question is:

 

Is the Vivado assumption that BUFG and BUFR are always in phase correct?

 

0 Kudos
Reply
13 Replies
2,334 Views
Registered: ‎01-22-2015

Hi @new_user,

 

Thanks for the clear explanation of what you are doing and for the clear question.

 

   Is the Vivado assumption that BUFG and BUFR are always in phase correct?

Vivado does not assume this. From your description of things, it appears that you have properly routed all clocks in your design. Further, the MMCM and BUFR are among the devices that automatically derive clocks (see pg 89, UG903) and automatically generate the necessary clock constraints. Since you have properly routed and constrained the clocks, Vivado is able to precisely characterize your entire clock network and to perform accurate timing analysis.  Having the clock outputs of the BUFG and BUFR be in-phase is not a requirement for accurate timing analysis.

 

Said another way, even a single clock travels to different destinations (eg. registers) inside the FPGA and arrives at these different destinations at slight different times (ie. the clock becomes skewed). So, for a particular timing path, the clock at the launch-register may be slightly skewed with respect to the same clock at the destination-register. Vivado understands all this and factors it into timing analysis.

 

However, you are correct in thinking that it is sometimes advantageous to control the phase relationship between different clocks. This is called Clock Network Deskew. It is done by the MMCM and is described for 7-Series FPGAs in chapter 3 of Xilinx document UG472.

 

Mark

Guide
Guide
2,323 Views
Registered: ‎01-23-2009

As markg@prosensing.com, the tools completely understand the phase relationship between the BUFR and BUFG clock. If they say that they can meet timing with the skew between these clocks, then your design will work. 

 

These two clocks (the BUFR and BUFG clocks) will be "mesochronous" - exactly the same bit rate, but with a somewhat unknown and varying phase between them.

 

However, even if the tools can meet timing, this is still a relatively poor solution. The skew between the BUFR and BUFG clocks will be significant, and the tools will have to fix the hold time violations that result from this skew. This will result in significant extra routing to meet hold times, which will make timing in the rest of your design harder to meet. This will also make your place and run time longer (as the tools have to work to fix the hold time).

 

As a general rule, you want to use a clock crossing FIFO between these two domains. The FIFO need not be deep (a couple of entries deep is sufficient), and you can use some "special tricks" to ensure that you don't get any data gaps on the far side of the FIFO. A distributed RAM based FIFO is ideal for this task... Take a look at this post for a description of this clock crosser for mesochronous clocks.

 

Avrum 

Tags (1)
0 Kudos
Reply
2,300 Views
Registered: ‎01-22-2015

Thank you, Avrum!

 

@new_user and Avrum,

 

Can things be improved if current plan to:

    1) route f1 to BUFR that is configured to divide by 2

 

is replaced by:

     2) route f2 to BUFR that is configured to divide by 1?

0 Kudos
Reply
Guide
Guide
2,286 Views
Registered: ‎01-23-2009

Can things be improved if current plan to:

    1) route f1 to BUFR that is configured to divide by 2

 

is replaced by:

     2) route f2 to BUFR that is configured to divide by 1?

 

I suppose, but I am not sure what you are trying to acheive...

 

The only problem with using using the output of the f1 BUFR (/2) is that it can only be used in the clock region of the BUFR. If all the operations you need to do with this data can be done in one clock region, then there is no need for a second buffer.

 

Conversely, if you do need the data outside one clock region then you need to put it on a BUFG - and the best way to do that is to use a clock crossing FIFO.

 

Your new proposal will end up with two in-phase (or potentially 180 degree out of phase - which is a problem) clocks at f/2, both on BUFRs, so both of which can reach exactly the same resources within one clock region. I don't see the point...

 

The reason that they could be 180 degrees out of phase is that the two dividers (the one in the MMCM and the one in the BUFR) aren't guaranteed to come up in the same state (in fact, its 50/50). If they come up in the opposite state, then your two clocks will be 180 degrees out of phase.

 

Avrum

Tags (1)
2,272 Views
Registered: ‎01-22-2015

Thank you, Avrum!

 

The reason that they could be 180 degrees out of phase is that the two dividers (the one in the MMCM and the one in the BUFR) aren't guaranteed to come up in the same state (in fact, its 50/50). If they come up in the opposite state, then your two clocks will be 180 degrees out of phase.

 

This sounds very scary!  -and is perhaps what @new_user was referring to when he said:

 

In this case they are roughly in phase. Or they may have their rising edges coincide to different rising edges of the f1 clock. In this case they are shifted by 90 degrees.

 

How is it possible for timing analysis to know about these random(?) power-up phase relationships between the clock buffers?

 

Thanks,

Mark

Guide
Guide
2,268 Views
Registered: ‎01-23-2009

markg@prosensing.com

 

How is it possible for timing analysis to know about these random(?) power-up phase relationships between the clock buffers?

 

That's a good question...

 

My first guess is that they can't/don't.

 

When a generated clock is created, we (or the tool) implicitly choose the phase. If we do

 

create_generated_clock -divide_by 2

 

it is effectively the same as saying

 

create_generated_clock -edges {1 3 5}

 

(the rising edge of the generated clock occurs at the time of edge "1" of the source clock, the falling edge at edge "3" and the next rising edge at edge "5"). These result in the "postive" phase clock with respect to time 0 (the first rising edge is at time 0)

 

But it is equally correct to say

 

create_generated_clock -edges {3 5 7}

or

create_generated_clock -divide_by 2 -invert

 

Both of the above describe the "other" phase relationship, where the falling edge is at time 0.

 

I highly suspect that the automatically generated clocks created by the BUFR and the MMCM both use one of the non-inverted formats. So, in this case, the tool will always understand that the two divided clocks are "in phase".

 

We can, of course, override these create_generated_clocks so that one of them uses the inverted version, but, the reality is, that we don't...

 

But, are these static timing failures or design failures? I guess I would argue that they are the latter.

 

And, by the way, this comes up in more common situations. Take a look at the 7 series Clocking User Guide on the section on the Multi-Region Clock Buffer (BUFMR). In figure 2-25 we have a BUFMR driving multiple BUFR that are independently doing clock division (UG 472, version 1.14, p. 56). If we don't manage the CE of the BUFMR and the CLR of the BUFRs according to the description given in that section, we can end up with the BUFRs coming up in different phases. Failure to follow these recommendations is an incorrect design - not something that can/should be caught by static timing analysis...

 

Avrum

Observer
Observer
2,259 Views
Registered: ‎12-29-2016


@avrumw wrote:

As markg@prosensing.com, the tools completely understand the phase relationship between the BUFR and BUFG clock. If they say that they can meet timing with the skew between these clocks, then your design will work. 


I don't use any create_clock or create_generated_clock except for the create_clock for the external clock feeding MMCM.

 

When I use f = 400 MHz (f/2 = 200 MHz) and look at the timing analysis, Vivado displays the goal for setup analysis 5.0 ns. Which means that Vivado thinks that both BUFG and BUFR are roughly in phase.

 

If the relationship between BUFR and BUFG was unknown, then the worst case would be when the clocks are shifted roughly by 180 degrees. In this case to meet the setup requirements the timing must assume 2.5 ns between edges.

 

Vivado uses 5.0 ns, but the design would meet 2.5 ns because it is just register to register. The design works either way. If I had more logic on the clock transition, it is possible that the design would meet 5.0 ns goal but would not meet 2.5 ns goal. In such case, Vivado would pass the timing, but the design would only work if the clocks were roughly in phase, as opposed to clocks roughly shifted by 180.

 

Since Vivado uses 5.0 ns, then there are two possibilities:

 

1. There is a mechanism which aligns the phases of the clocks, making them roughly in phase and not shifted by 180 degrees.

 

2. The Vivado analysis is incorrect and 2.5 ns must be used instead of 5.0 ns.

 

Either one looks improbable.

 

Here's the Vivado timing report:

 

  Source:                 source_reg/C
                            (rising edge-triggered cell FDRE clocked by clk_bufr  {rise@0.000ns fall@2.500ns period=5.000ns})
  Destination:            destination_reg/D
                            (rising edge-triggered cell FDRE clocked by in_bufg  {rise@0.000ns fall@2.500ns period=5.000ns})
  Path Group:             in_bufg
  Path Type:              Setup (Max at Slow Process Corner)
  Requirement:            5.000ns  (in_bufg rise@5.000ns - clk_bufr rise@0.000ns)
  Data Path Delay:        2.026ns  (logic 0.379ns (18.707%)  route 1.647ns (81.293%))
  Logic Levels:           0 
  Clock Path Skew:        0.438ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    5.188ns = ( 10.188 - 5.000 )
    Source Clock Delay      (SCD):    4.882ns
    Clock Pessimism Removal (CPR):    0.132ns
  Clock Uncertainty:      0.192ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Discrete Jitter          (DJ):    0.125ns
    Phase Error              (PE):    0.120ns
    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock clk_bufr rise edge)
                                                      0.000     0.000 r 
    H3                                                0.000     0.000 r  clk (IN)
                         net (fo=0)                   0.000     0.000    clk
    H3                                                                r  clk_IBUF_inst/I
    H3                   IBUF (Prop_ibuf_I_O)         1.435     1.435 r  clk_IBUF_inst/O
                         net (fo=1, routed)           1.065     2.500    clk_IBUF
    MMCME2_ADV_X1Y1                                                   r  MMCME2_BASE_inst/CLKIN1
    MMCME2_ADV_X1Y1      MMCME2_ADV (Prop_mmcme2_adv_CLKIN1_CLKOUT1)
                                                      0.077     2.577 r  MMCME2_BASE_inst/CLKOUT1
                         net (fo=1, routed)           0.883     3.460    in_bufr
    BUFR_X1Y5                                                         r  BUFR_inst/I
    BUFR_X1Y5            BUFR (Prop_bufr_I_O)         0.756     4.216 r  BUFR_inst/O
                         net (fo=1, routed)           0.666     4.882    clk_bufr
    SLICE_X65Y89         FDRE                                         r  source_reg/C
  -------------------------------------------------------------------    -------------------
    SLICE_X65Y89         FDRE (Prop_fdre_C_Q)         0.379     5.261 r  source_reg/Q
                         net (fo=1, routed)           1.647     6.908    source
    SLICE_X64Y89         FDRE                                         r  destination_reg/D
  -------------------------------------------------------------------    -------------------
                         (clock in_bufg rise edge)    5.000     5.000 r 
    H3                                                0.000     5.000 r  clk (IN)
                         net (fo=0)                   0.000     5.000    clk
    H3                                                                r  clk_IBUF_inst/I
    H3                   IBUF (Prop_ibuf_I_O)         1.369     6.369 r  clk_IBUF_inst/O
                         net (fo=1, routed)           1.004     7.373    clk_IBUF
    MMCME2_ADV_X1Y1                                                   r  MMCME2_BASE_inst/CLKIN1
    MMCME2_ADV_X1Y1      MMCME2_ADV (Prop_mmcme2_adv_CLKIN1_CLKOUT2)
                                                      0.073     7.446 r  MMCME2_BASE_inst/CLKOUT2
                         net (fo=1, routed)           1.352     8.798    in_bufg
    BUFGCTRL_X0Y16                                                    r  BUFG_inst/I
    BUFGCTRL_X0Y16       BUFG (Prop_bufg_I_O)         0.077     8.875 r  BUFG_inst/O
                         net (fo=1, routed)           1.313    10.188    clk_bufg
    SLICE_X64Y89         FDRE                                         r  destination_reg/C
                         clock pessimism              0.132    10.320   
                         clock uncertainty           -0.192    10.128   
    SLICE_X64Y89         FDRE (Setup_fdre_C_D)       -0.015    10.113    destination_reg
  -------------------------------------------------------------------
                         required time                         10.113   
                         arrival time                          -6.908   
  -------------------------------------------------------------------
                         slack                                  3.205   
0 Kudos
Reply
Observer
Observer
2,252 Views
Registered: ‎12-29-2016


markg@prosensing.com wrote:

 

This sounds very scary!  -and is perhaps what @new_user was referring to when he said:

 

In this case they are roughly in phase. Or they may have their rising edges coincide to different rising edges of the f1 clock. In this case they are shifted by 90 degrees.


I made a mistake. It should be 180 degrees.

 

0 Kudos
Reply
Guide
Guide
2,243 Views
Registered: ‎01-23-2009

1. There is a mechanism which aligns the phases of the clocks, making them roughly in phase and not shifted by 180 degrees.

 

There isn't...

 

2. The Vivado analysis is incorrect and 2.5 ns must be used instead of 5.0 ns.

 

It appears that this is so.

 

It would be interesting to see the Clock Interaction Report in this case - does the tool consider these as "related (safe)" or "unrelated (unsafe)" paths. The same for the "report_cdc" command - it may flag this as a potential problem...

 

Vivado uses 5.0 ns, but the design would meet 2.5 ns because it is just register to register.

 

It isn't safe to assume this...

 

While it is register to register, it is IOB register (ISERDES) to fabric register. These can be potentially pretty far apart on the die. With them constrained to 5.0ns, there is nothing preventing the tool from placing the cell "far" and using slower routing to get between these cells; as long as the total route delay (and setup and skew) isn't more than 5ns, the tool will think its OK - it can easily add more than 2.5ns in routing delay... But if it does this and the counters come up in opposite polarity, then this system will fail.

 

Again, the safest thing to do is to use a clock crossing FIFO; this is foolproof  - this will work with any phase relationship between the two clocks.

 

Alternatively, you can also consider

  - have the MMCM generate only the high speed clock

  - route that to the BUFIO/BUFR (as you are doing now)

     - be sure that this clock comes from CLKOUT0 - CLKOUT3 of the MMCM - the "High Performance Clock Path" can only come from these outputs (and only from the MMCM, not the PLL)

  - route the output of the BUFR back to a BUFG

 

This has the advantage that the BUFR and BUFG are now guaranteed to be "in phase" (since one is derived from the other). It has the disadvantage that there is a larger skew between the BUFR clock and the BUFG clock - this can potentially create timing problems.

 

Again, the best solution is the clock crossing FIFO.

 

Avrum

0 Kudos
Reply
Observer
Observer
1,971 Views
Registered: ‎12-29-2016


@avrumw wrote:

It would be interesting to see the Clock Interaction Report in this case - does the tool consider these as "related (safe)" or "unrelated (unsafe)" paths. The same for the "report_cdc" command - it may flag this as a potential problem...


  Here are the reports. I have createad a small project with just MMCM/BUFR/BUFG to demonstrate the effect. I'm attaching the VHDL as well.

 

report_cdc
------------------------------------------------------------------------------------
| Tool Version : Vivado v.2018.1 (win64) Build 2188600 Wed Apr  4 18:40:38 MDT 2018
| Date         : Mon Aug 20 16:06:49 2018
| Host         : --- running 64-bit Service Pack 1  (build 7601)
| Command      : report_cdc
| Design       : top
| Device       : 7a50t-fgg484
| Speed File   : -2  PRODUCTION 1.21 2018-02-08
------------------------------------------------------------------------------------
 
CDC Report
 
Severity  Source Clock  Destination Clock  CDC Type      Exceptions  Endpoints  Safe  Unsafe  Unknown  No ASYNC_REG 
--------  ------------  -----------------  ------------  ----------  ---------  ----  ------  -------  ------------ 
Info      clk_bufr      in_bufg            Safely Timed  None                1     1       0        0             0 
 
report_clock_interaction
INFO: [Timing 38-91] UpdateTimingParams: Speed grade: -2, Delay Type: max.
INFO: [Timing 38-191] Multithreading enabled for timing update using a maximum of 2 CPUs
Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.
------------------------------------------------------------------------------------
| Tool Version : Vivado v.2018.1 (win64) Build 2188600 Wed Apr  4 18:40:38 MDT 2018
| Date         : Mon Aug 20 16:08:03 2018
| Host         : --- running 64-bit Service Pack 1  (build 7601)
| Command      : report_clock_interaction
| Design       : top
| Device       : 7a50t-fgg484
| Speed File   : -2  PRODUCTION 1.21 2018-02-08
------------------------------------------------------------------------------------
 
Clock Interaction Report
 
Clock Interaction Table
-----------------------
 
                            WNS                            TNS Failing  TNS Total    WNS Path         Clock-Pair           Inter-Clock 
From Clock    To Clock      Clock Edges  WNS(ns)  TNS(ns)    Endpoints    Endpoints  Requirement(ns)  Classification       Constraints 
------------  ------------  -----------  -------  -------  -----------  -----------  ---------------  -------------------  ----------- 
clk_bufr      in_bufg       rise - rise     3.20     0.00            0            1             5.00  Clean                Timed       

 

  The VHDL code:

 

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
 
library UNISIM;
use UNISIM.VComponents.all;
 
entity top is
  port (
    clk: in std_logic;
    ia: in std_logic;
    oa: out std_logic
  ); 
end top;
 
architecture Behavioural of top is
 
signal feedback: std_logic;
signal in_bufg: std_logic;
signal in_bufr: std_logic;
signal clk_bufg: std_logic;
signal clk_bufr: std_logic;
signal source: std_logic;
signal destination: std_logic;
    
begin
 
   MMCME2_BASE_inst : MMCME2_BASE
   generic map (
      BANDWIDTH => "OPTIMIZED",  -- Jitter programming (OPTIMIZED, HIGH, LOW)
      CLKFBOUT_MULT_F => 8.0,    -- Multiply value for all CLKOUT (2.000-64.000).
      CLKFBOUT_PHASE => 0.0,     -- Phase offset in degrees of CLKFB (-360.000-360.000).
      CLKIN1_PERIOD => 0.0,      -- Input clock period in ns to ps resolution (i.e. 33.333 is 30 MHz).
      -- CLKOUT0_DIVIDE - CLKOUT6_DIVIDE: Divide amount for each CLKOUT (1-128)
      CLKOUT1_DIVIDE => 2, -- f = 400 MHZ
      CLKOUT2_DIVIDE => 4, -- f/2 = 200 MHz
      CLKOUT3_DIVIDE => 1,
      CLKOUT4_DIVIDE => 1,
      CLKOUT5_DIVIDE => 1,
      CLKOUT6_DIVIDE => 1,
      CLKOUT0_DIVIDE_F => 1.0,   -- Divide amount for CLKOUT0 (1.000-128.000).
      -- CLKOUT0_DUTY_CYCLE - CLKOUT6_DUTY_CYCLE: Duty cycle for each CLKOUT (0.01-0.99).
      CLKOUT0_DUTY_CYCLE => 0.5,
      CLKOUT1_DUTY_CYCLE => 0.5,
      CLKOUT2_DUTY_CYCLE => 0.5,
      CLKOUT3_DUTY_CYCLE => 0.5,
      CLKOUT4_DUTY_CYCLE => 0.5,
      CLKOUT5_DUTY_CYCLE => 0.5,
      CLKOUT6_DUTY_CYCLE => 0.5,
      -- CLKOUT0_PHASE - CLKOUT6_PHASE: Phase offset for each CLKOUT (-360.000-360.000).
      CLKOUT0_PHASE => 0.0,
      CLKOUT1_PHASE => 0.0,
      CLKOUT2_PHASE => 0.0,
      CLKOUT3_PHASE => 0.0,
      CLKOUT4_PHASE => 0.0,
      CLKOUT5_PHASE => 0.0,
      CLKOUT6_PHASE => 0.0,
      CLKOUT4_CASCADE => FALSE,  -- Cascade CLKOUT4 counter with CLKOUT6 (FALSE, TRUE)
      DIVCLK_DIVIDE => 1,        -- Master division value (1-106)
      REF_JITTER1 => 0.0,        -- Reference input jitter in UI (0.000-0.999).
      STARTUP_WAIT => FALSE      -- Delays DONE until MMCM is locked (FALSE, TRUE)
   )
   port map (
      -- Clock Outputs: 1-bit (each) output: User configurable clock outputs
      CLKOUT0 => open,     -- 1-bit output: CLKOUT0
      CLKOUT0B => open,   -- 1-bit output: Inverted CLKOUT0
      CLKOUT1 => in_bufr,     -- 1-bit output: CLKOUT1
      CLKOUT1B => open,   -- 1-bit output: Inverted CLKOUT1
      CLKOUT2 => in_bufg,     -- 1-bit output: CLKOUT2
      CLKOUT2B => open,   -- 1-bit output: Inverted CLKOUT2
      CLKOUT3 => open,     -- 1-bit output: CLKOUT3
      CLKOUT3B => open,   -- 1-bit output: Inverted CLKOUT3
      CLKOUT4 => open,     -- 1-bit output: CLKOUT4
      CLKOUT5 => open,     -- 1-bit output: CLKOUT5
      CLKOUT6 => open,     -- 1-bit output: CLKOUT6
      -- Feedback Clocks: 1-bit (each) output: Clock feedback ports
      CLKFBOUT => feedback,   -- 1-bit output: Feedback clock
      CLKFBOUTB => open, -- 1-bit output: Inverted CLKFBOUT
      -- Status Ports: 1-bit (each) output: MMCM status ports
      LOCKED => open,       -- 1-bit output: LOCK
      -- Clock Inputs: 1-bit (each) input: Clock input
      CLKIN1 => clk,       -- 1-bit input: Clock
      -- Control Ports: 1-bit (each) input: MMCM control ports
      PWRDWN => '0',       -- 1-bit input: Power-down
      RST => '0',             -- 1-bit input: Reset
      -- Feedback Clocks: 1-bit (each) input: Clock feedback ports
      CLKFBIN => feedback      -- 1-bit input: Feedback clock
   );
 
   BUFG_inst : BUFG
   port map (
      O => clk_bufg, -- 1-bit output: Clock output
      I => in_bufg  -- 1-bit input: Clock input
   );
   
   BUFR_inst : BUFR
   generic map (
      BUFR_DIVIDE => "2",   -- Values: "BYPASS, 1, 2, 3, 4, 5, 6, 7, 8"
      SIM_DEVICE => "7SERIES"  -- Must be set to "7SERIES"
   )
   port map (
      O => clk_bufr,     -- 1-bit output: Clock output port
      CE => '1',   -- 1-bit input: Active high, clock enable (Divided modes only)
      CLR => '0', -- 1-bit input: Active high, asynchronous clear (Divided modes only)
      I => in_bufr      -- 1-bit input: Clock buffer input driven by an IBUF, MMCM or local interconnect
   );
  
process(clk_bufr)
begin
  if rising_edge(clk_bufr) then
    source <= ia;
  end if;
end process;
  
process(clk_bufg)
begin
  if rising_edge(clk_bufg) then
    destination <= source;
  end if;
end process;
 
oa <= destination;
    
end Behavioural; 

 


  - route the output of the BUFR back to a BUFG


Thank you. I think it's a good idea.

0 Kudos
Reply
1,962 Views
Registered: ‎01-22-2015

@new_user – Avrum and I have MWS (many word syndrome) 😊.  Thanks for your patient listening and thoughtful responses.

 

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

 

Avrum – Thanks again!

    

     …. the best solution is the clock crossing FIFO.

Got it! This solves all problems.

 

   - route the output of the BUFR back to a BUFG

Got it! This solves the skew problem.

 

Please again consider the suggestion in my second response to this post.

 

If the clock-divider feature of BUFR is not used (ie. we use divide by 1), have we avoided the scary power-up phase problem of this clock buffer?

0 Kudos
Reply
Observer
Observer
1,946 Views
Registered: ‎12-29-2016


markg@prosensing.com wrote:

 

If the clock-divider feature of BUFR is not used (ie. we use divide by 1), have we avoided the scary power-up phase problem of this clock buffer?


 

That's a good idea too. Thank you.

 

I'm more interested in figuring out the problem with Vivado timing analysis. Bad design may pass timing and I don't even get a warning.

 

0 Kudos
Reply
1,915 Views
Registered: ‎01-22-2015

@new_user

 

     If the clock-divider feature of BUFR is not used (ie. we use divide by 1), have we avoided the scary power-up phase

     problem of this clock buffer?

I am pretty sure that the answer to this(my) question is YES. –since, the BUFR with “divide by 1” looks like a BUFG, for which we never worry about power-up phase.

 

So, if you can change your design to use the BUFR with “divide by 1” (instead of “divide by 2”) then (I think) you needn’t worry about “breaking” timing analysis.

 

However, if you must use the BUFR with “divide by 2” then (as described by Avrum and UG472) you might need to manually reset the BUFR at power-up to prevent “breaking” timing analysis.

0 Kudos
Reply