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: 
Scholar helmutforren
Scholar
3,445 Views
Registered: ‎06-23-2014

How can I fix this timing error, please?

Jump to solution

I'm using Vivado 2017.1 and I'm new at trying to get a project to meet timing.  I get the following timing error:

 

 

The germane code looks like this:

    
    reg rx_mmcm_lckd_clk,rx_mmcm_lckd_metastable;
    always @(posedge clk) begin rx_mmcm_lckd_clk = rx_mmcm_lckd_metastable; rx_mmcm_lckd_metastable = rx_mmcm_lckd; end

Constraints include this:

create_clock -period 5.000 -name SYSCLK -waveform {0.000 2.500} [get_ports SYSCLK_P]
create_clock -period 1.961 -name ROIC_bitclk -waveform {0.000 0.981} [get_ports FMC_HPC_LA07_P]

Where clk is connected to the instantiator's SYS_CLK, and SYS_CLK comes from SYSCLK_P like this:

    IBUFGDS #(.DIFF_TERM("FALSE"))   CL_iob (.I(SYSCLK_P),  .IB(SYSCLK_N),  .O(SYS_CLK));

 

As I read the error, the setup time for rx_mmcm_lckd_metastable is not met.  But the whole point of rx_mmcm_lckd_metastable was to get the MMCM Locked signal across the clock domain.  As you can see in the first code snippet.  I guess maybe there setup is indeed not met, but because I have two [flipflops] in a row, it should be ok.

 

Do I have a timing error here?  How would I fix it?  Is it not in fact an error?  Should I try to make the error not display?  (I read about being unable to do that last one, which is a shame.  That means I must remember a year or three from now which are acceptable and which are not.)  Or is my clock domain crossing incorrect?  Or are my constraints insufficient?

 

Thanks VERY MUCH again,

Helmut

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
5,837 Views
Registered: ‎01-23-2009

Re: How can I fix this timing error, please?

Jump to solution

So, first of all, the two flip-flops you describe here are inferred "incorrectly" - in an always @(posedge clk) you must use non-blocking assignments.

 

Also, these two flip-flops are metastability flip-flops, and hence then need the ASYNC_REG property set - this can be done in the XDC file, or can be embedded in the RTL, as shown below. Note: in previous versions, others have had problems with the ASYNC_REG being set in the RTL, but the problems appear to be more in VHDL than in Verilog, and I haven't seen people complaining in a while, so this is probably fixed - you should, however, verify that the ASYNC_REG property of these flip-flops are set after synthesis).

 

 

(* ASYNC_REG = "TRUE" *) reg rx_mmcm_lckd_clk;
(* ASYNC_REG = "TRUE" *) reg rx_mmcm_lckd_metastable;

always @(posedge clk)
begin rx_mmcm_lckd_clk <= rx_mmcm_lckd_metastable;
rx_mmcm_lckd_metastable <= rx_mmcm_lckd;
end

 

 

Second, what are you planning to do with ROIC_bitclk - this clock is running at 510MHz - there is very little you can do with a clock at this speed - internal paths will barely work at this speed (but can be done with very careful design) and interfaces are extremely difficult at this rate...

 

Next, I presume SYS_CLK drives the MMCM, which in turn drives a BUFG to become "clk"? Also rx_mmcm_lckd is the LOCKED pin of the MMCM.

 

Finally, since this is (now) a true synchronizer, the input to the synchronizer needs an exception. You can use either a false path (if you don't care about how long after the MMCM comes out of locked the synchronized signal arrives), or a set_max_delay -datapath_only if you want to limit the delay. For example using

 

set_max_delay -from [get_cells <mmcm_instance>] -to [get_cells rx_mmcm_lckd_metastable_reg] 5;

 

The delay from the MMCM asserting LOCKED to rx_mmcm_lckd_clk deassertind is 5ns plus 1-2 clock periods of "clk".

 

If you don't care about the latency, then you can do

 

set_false_path -to [get_cells rx_mmcm_lckd_metastable_reg];

 

Avrum

3 Replies
Highlighted
Historian
Historian
5,838 Views
Registered: ‎01-23-2009

Re: How can I fix this timing error, please?

Jump to solution

So, first of all, the two flip-flops you describe here are inferred "incorrectly" - in an always @(posedge clk) you must use non-blocking assignments.

 

Also, these two flip-flops are metastability flip-flops, and hence then need the ASYNC_REG property set - this can be done in the XDC file, or can be embedded in the RTL, as shown below. Note: in previous versions, others have had problems with the ASYNC_REG being set in the RTL, but the problems appear to be more in VHDL than in Verilog, and I haven't seen people complaining in a while, so this is probably fixed - you should, however, verify that the ASYNC_REG property of these flip-flops are set after synthesis).

 

 

(* ASYNC_REG = "TRUE" *) reg rx_mmcm_lckd_clk;
(* ASYNC_REG = "TRUE" *) reg rx_mmcm_lckd_metastable;

always @(posedge clk)
begin rx_mmcm_lckd_clk <= rx_mmcm_lckd_metastable;
rx_mmcm_lckd_metastable <= rx_mmcm_lckd;
end

 

 

Second, what are you planning to do with ROIC_bitclk - this clock is running at 510MHz - there is very little you can do with a clock at this speed - internal paths will barely work at this speed (but can be done with very careful design) and interfaces are extremely difficult at this rate...

 

Next, I presume SYS_CLK drives the MMCM, which in turn drives a BUFG to become "clk"? Also rx_mmcm_lckd is the LOCKED pin of the MMCM.

 

Finally, since this is (now) a true synchronizer, the input to the synchronizer needs an exception. You can use either a false path (if you don't care about how long after the MMCM comes out of locked the synchronized signal arrives), or a set_max_delay -datapath_only if you want to limit the delay. For example using

 

set_max_delay -from [get_cells <mmcm_instance>] -to [get_cells rx_mmcm_lckd_metastable_reg] 5;

 

The delay from the MMCM asserting LOCKED to rx_mmcm_lckd_clk deassertind is 5ns plus 1-2 clock periods of "clk".

 

If you don't care about the latency, then you can do

 

set_false_path -to [get_cells rx_mmcm_lckd_metastable_reg];

 

Avrum

Scholar helmutforren
Scholar
3,412 Views
Registered: ‎06-23-2014

Re: How can I fix this timing error, please?

Jump to solution

Avrum,

 

Your answers are always so well thought out, too the point, and helpful.  Thanks very much.

 

Point by point...

 

Oops.  I know about using non-blocking there.  I've done this in several other places, and only today did I forget the "<" character.  So I'm revising those to "<=" and will test again.

 

About max delay or false path, I'll go with false path.  I don't really care how long it takes.  FYI, that rx_mmcm_lckd signal is a register modified via NBA in an always loop based on ROIC_clkdiv7. If logic is from rst_iserdes0 that's driven by ISERDES.  Anyway, I use it to augment my reset signals to places that want active ISERDES data.  (This makes the rx_mmcm_lckd name a bit of a misnomer.)

 

About ROIC_bitclk.  (You've gone an extra mile there, because it's off subject.  But thanks for double checking.) That 510MHz comes in from outside, alongside some data.  This all goes into some ISERDES.  So for that portion of it, I think it's fine.  I'm double checking now...

 

So below you see bitclk_{p|n} to go BIT_CLK_IO to BIT_CLK to ROIC_clkdiv7.  That ILA may be a problem, but it's omitted from build right now.  BIT_CLK at 510Mhz feeds the ISERDES.  I'm not sure why I don't have the ISERDES driven directly from the pins.  This does seem to work in hardware.  I'm doing other funniness to get 13:1, but I'm basing it on 7:1 hardware.  That's the end of the road for 510MHz.  So the ILA is the only problem, but excluded from build at this time.  Otherwise, the ROIC_clkdiv7 (72.9MHz) goes out to other places to bring this data into my SYSCLK 200MHz.

 

// This code is cobbled together to put into a single place to see clock flow

wire bitclk_p = FMC_HPC_LA07_P;
wire bitclk_n = FMC_HPC_LA07_N;

IBUFGDS #(.DIFF_TERM("TRUE")) ROIC_iob (.I(bitclk_p), .IB(bitclk_n), .O(BIT_CLK_IO));

BUFIO BUF_bitclk (.I (BIT_CLK_IO), .O(BIT_CLK));
    BUFR #(.BUFR_DIVIDE("7"),.SIM_DEVICE("7SERIES"))    BUF_bitclkdiv7 (.I(BIT_CLK_IO),.CE(1'b1),.O(ROIC_clkdiv7),.CLR(1'b0));

ISERDESE2 #(
...
ISERDES_line (
...
.CLK (BIT_CLK),
.CLKB (~BIT_CLK),
.RST (rst_iserdes0),
...
.CLKDIV (ROIC_clkdiv7),
...
);

if (INCLUDE_ILA == "TRUExxx") begin // Currently forced to not be included ila_ROIC_Input ila_ROIC_Input ( // Perhaps this ILA is asking for trouble. Omitted in current build .clk(BIT_CLK_IO), ...
... );
end

 So, overall, I think my 510MHz usage is OK.

 

 

 

0 Kudos
Historian
Historian
3,387 Views
Registered: ‎01-23-2009

Re: How can I fix this timing error, please?

Jump to solution

Two things...

 

First, at 510MHz (I presume SDR) the unit interval (UI - the length of a bit period) is 1.961ns. The valid window for the bit is less than that, due to things like clock/data skew at the source, board delay skew, signal integrity, jitter... Depending on how much you lose to these things, it can be very challenging to capture a data eye this small. Furthermore, you need to find a way to adjust the clock/data relationship in the FPGA to get the "optimum" timing. In your case, you will almost certainly need to use an IDELAY either on the clock or on the data (or maybe on both) to adjust the timing.

 

Take a look at this forum thread which talks about capturing a window with small eyes using ChipSync capture (BUFIO and BUFR).

 

Second, about that ILA - you cannot use BITCLK_IO for anything at all (except connections to the BUFIO/BUFR) and you cannot use BITCLK for anything other than clocking the high speed clock of the ISERDES (or an IDDR). Even if these were structurally legal (which they are not) there is no way you would be able to clock an ILA at anything near this frequency.

 

Avrum

0 Kudos