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: 
Highlighted
Explorer
Explorer
5,478 Views
Registered: ‎07-29-2009

report methodology

Jump to solution

I have a somewhat cryptic message of :
"TIMING-9#1 Warning
Unknown CDC Logic 
One or more asynchronous Clock Domain Crossing has been detected between 2 clock domains through a set_false_path or a set_clock_groups or set_max_delay -datapath_only constraint but no double-registers logic synchronizer has been found on the side of the capture clock. It is recommended to run report_cdc for a complete and detailed CDC coverage
Related violations: <none>

TIMING-10#1 Warning
Missing property on synchronizer 
One or more logic synchronizer has been detected between 2 clock domains but the synchronizer does not have the property ASYNC_REG defined on one or both registers. It is recommended to run report_cdc for a complete and detailed CDC coverage
Related violations: <none>"

 

 

Is there a way to tell what nets and clocks these are associated with?

 

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
8,660 Views
Registered: ‎01-23-2009

Re: report methodology

Jump to solution

I'm looking at Page 80-81 of UG906 (v2017.2) and I think my Verilog does a similar circuit

 

These circuits are specifically "reset bridges", which are performing a different role - synchronizing an asynchronous reset input. They should pretty much only be used for reset bridges. For anything else, these use what would otherwise be considered "non-synchronous" design practices and should be avoided.

 

without "FF1,"

 

And that is key. The FF1 is essential. The two back to back flip-flops (with the ASYNC_REG property on them) is what turns this into a (in this case) reset synchronizer, as opposed to just logic clocking an asynchronous signal (which creates system failures due to metastability).

 

I just have a little combinatorial logic to make sure it is only 1 pulse.

 

 

From your description - you have an asynchronous pulse that is guaranteed to be (singificantly) longer than one period of the capture clock, and you want a pulse from this that is one clock wide on the capture clock whenever the rising edge happens. This is a very standard problem with a very standard solution. You double synchronize the input (with two back to back flip-flops with the ASYNC_REG property) and then you use one more (regular) flip-flop to implement a rising edge detector.

 

The circuit below is what you use for this:

SlowEventSync.png

 

As is shown in the waveform to the right, the latency of this detector is 1-2 destination clock periods. It cannot be faster, and it cannot be "more precise" - this is the nature of sampling an asynchronous signal.

 

Any thoughts on how they constrain it?

 

The first two flip-flops need the ASYNC_REG property set on them, and the path ending at the first flip-flop (signal_meta_reg) needs an exception - either a set_false_path or a set_max_delay -datapath_only. From the point of view of the tools and the synchronizer, either is acceptable, but if you are concerned with keeping the detection latency of the synchronizer low, then you should use a set_max_delay -datapath_only with a relatively small value (say 5ns or so). The set_max_delay -datapath_only value adds to the detection latency of this circuit - thus it becomes 1-2 destination clock periods plus the value of the set_max_delay -datapath_only.

 

Avrum

0 Kudos
16 Replies
Scholar austin
Scholar
5,475 Views
Registered: ‎02-27-2008

Re: report methodology

Jump to solution

p,

 

ISE or Vivado?

 

In either, the (verbose in ISE, complete in Vivado log) timing report should tell you which paths.

 

The tool recognizes the data crosses clock domains, yet no CDC optimized structure is used.  This potentially will have a high rate of metastability, which might, or might not, be a problem in your system.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Explorer
Explorer
5,470 Views
Registered: ‎07-29-2009

Re: report methodology

Jump to solution

Yes, I had to use the GUI in vivado under Tools: timing: report CDC to be able to burrow down.  It turns out they're both related to circuitry that attempts to synchronize an asynchronous input that is written like this:

 

    always @(posedge S_AXI_ACLK) begin
        state <= onepps;
        reloadReg     <= state != onepps && onepps;
    end

    always @(posedge highspeedclk) begin
        stateh         <= onepps;
        reloadRegh     <= stateh != onepps && onepps;
    end

 

I need to use the signal "reloadReg" as close to when it was captured as possible, so I cannot add more flip-flops.  How would I tell the CDC that my intention is to capture an asynch signal?  In other words, I have a one pulse per second input that I need to capture with a single clock pulse to take action on.
Regards,

Kurt

Tags (1)
0 Kudos
Scholar austin
Scholar
5,465 Views
Registered: ‎02-27-2008

Re: report methodology

Jump to solution

read through the answers:

 

https://forums.xilinx.com/t5/Timing-Analysis/how-to-constrain-a-CDC/td-p/748174

Austin Lesea
Principal Engineer
Xilinx San Jose
Historian
Historian
5,455 Views
Registered: ‎01-23-2009

Re: report methodology

Jump to solution

need to use the signal "reloadReg" as close to when it was captured as possible, so I cannot add more flip-flops.  How would I tell the CDC that my intention is to capture an asynch signal?

 

Your problem isn't the fact that the tool is complaining. The problem is that the tool is (correctly) telling you that what you are doing is "illegal" (really just dangerous).

 

Synchronizing circuits are used for a reason. If you don't use a proper synchronizing circuit, then you run the risk of crashing your system when a metastable event occurs. The whole point of the back-to-back flip-flop is to prevent (really reduce the likelihood) of a metastable signal reaching your real logic. Using a metastable signal in the main part of your design (especially a state machine) can cause the system to crash in unpredictable ways.

 

You pretty much have to use (at least) two back-to-back flip-flops with the ASYNC_REG property to synchronize this asynchronous signal.

 

Avrum

Tags (2)
Explorer
Explorer
5,447 Views
Registered: ‎07-29-2009

Re: report methodology

Jump to solution

Avrunw,

    Is there recommended code in Verilog for capturing an asynchronous input signal that lasts >>>Tp where Tp is the capture clock period?  Note: I'm not actually crossing a clock boundary in this application.  I am just capturing the rising edge of the asynchronous input as close as possible to the rising edge and ensuring the now-synchronous captured signal is only 1 Tp long.

 

 

0 Kudos
Scholar hbucher
Scholar
5,445 Views
Registered: ‎03-22-2016

Re: report methodology

Jump to solution

@avrumw  

A friend of mine just posted something on the topic

https://asicsolutions.com/i-want-you-to-get-this-job-part-1-simple-synchronization/

 

vitorian.com --- We do this for fun. Always give kudos. Accept as solution if your question was answered.
I will not answer to personal messages - use the forums instead.
0 Kudos
Explorer
Explorer
5,446 Views
Registered: ‎07-29-2009

Re: report methodology

Jump to solution

I'm not crossing a clock boundary... just capturing an synchronous signal and registering it.

0 Kudos
Explorer
Explorer
5,432 Views
Registered: ‎07-29-2009

Re: report methodology

Jump to solution

I'm looking at Page 80-81 of UG906 (v2017.2) and I think my Verilog does a similar circuit to that without "FF1," which really is used later.  How do people write the correct clock constraints for either of those circuits?

 

Here's mine:

synchronizer.PNG

Here's from Page 81:

synchronizeras.PNG

 

I just have a little combinatorial logic to make sure it is only 1 pulse.

Any thoughts on how they constrain it?

Tags (1)
0 Kudos
Historian
Historian
5,384 Views
Registered: ‎01-23-2009

Re: report methodology

Jump to solution

I'm not crossing a clock boundary... just capturing an synchronous signal and registering it.

 

Really, you are crossing a clock boundary - just not necessarily one that exists in your FPGA. In this case your "onepps" is (presumably) coming from some timer in some other chip, and hence is synchronous to some other clock.

 

But it is irrelevant. Whether a signal is coming from some identifiable asynchronous clock domain or an unidentifiable asynchronous source, the problem is the same and the solutions are pretty much the same.

 

Avrum

0 Kudos
Historian
Historian
8,661 Views
Registered: ‎01-23-2009

Re: report methodology

Jump to solution

I'm looking at Page 80-81 of UG906 (v2017.2) and I think my Verilog does a similar circuit

 

These circuits are specifically "reset bridges", which are performing a different role - synchronizing an asynchronous reset input. They should pretty much only be used for reset bridges. For anything else, these use what would otherwise be considered "non-synchronous" design practices and should be avoided.

 

without "FF1,"

 

And that is key. The FF1 is essential. The two back to back flip-flops (with the ASYNC_REG property on them) is what turns this into a (in this case) reset synchronizer, as opposed to just logic clocking an asynchronous signal (which creates system failures due to metastability).

 

I just have a little combinatorial logic to make sure it is only 1 pulse.

 

 

From your description - you have an asynchronous pulse that is guaranteed to be (singificantly) longer than one period of the capture clock, and you want a pulse from this that is one clock wide on the capture clock whenever the rising edge happens. This is a very standard problem with a very standard solution. You double synchronize the input (with two back to back flip-flops with the ASYNC_REG property) and then you use one more (regular) flip-flop to implement a rising edge detector.

 

The circuit below is what you use for this:

SlowEventSync.png

 

As is shown in the waveform to the right, the latency of this detector is 1-2 destination clock periods. It cannot be faster, and it cannot be "more precise" - this is the nature of sampling an asynchronous signal.

 

Any thoughts on how they constrain it?

 

The first two flip-flops need the ASYNC_REG property set on them, and the path ending at the first flip-flop (signal_meta_reg) needs an exception - either a set_false_path or a set_max_delay -datapath_only. From the point of view of the tools and the synchronizer, either is acceptable, but if you are concerned with keeping the detection latency of the synchronizer low, then you should use a set_max_delay -datapath_only with a relatively small value (say 5ns or so). The set_max_delay -datapath_only value adds to the detection latency of this circuit - thus it becomes 1-2 destination clock periods plus the value of the set_max_delay -datapath_only.

 

Avrum

0 Kudos
Explorer
Explorer
4,755 Views
Registered: ‎07-29-2009

Re: report methodology

Jump to solution

Thanks, I changed my stuff over to your method, and it simulated right.  Can you give a tcl example of the setmaxdelay command?

Kurt

0 Kudos
Historian
Historian
4,748 Views
Registered: ‎01-23-2009

Re: report methodology

Jump to solution

Can you give a tcl example of the setmaxdelay command?

 

I can't give you a full example since the set_max_delay -datapath_only must have a -from value, and I don't know where your signal is starting from. If it comes directly from a port then

 

set_max_delay -datapath_only -from [get_ports <port_name>] -to [get_cells signal_meta_reg] <value>

 

The <value> should be as small as is reasonable - say around 3

 

If it comes from a flip-flop on another domain then

 

set_max_delay -datapath_only -from [get_cells <flip_flop_on_other_domain>] -to [get_cells signal_meta_reg] <value>

 

Avrum

0 Kudos
Explorer
Explorer
4,743 Views
Registered: ‎07-29-2009

Re: report methodology

Jump to solution

Thanks, that helps.  Weirdly I have two parts of the design doing the same thing; which I recoded for the method you suggested. Using one clock, the tool seems to recognize it; the other, it didn't. (which you can see in above in a previous message).

In the Verilog, there is literally no difference in the two instances, except one is using a highspeed clock and the other another clock.

Severity  Source Clock      Destination Clock  CDC Type                 Exceptions           Endpoints  Safe  Unsafe  Unknown  No ASYNC_REG 
--------  ----------------  -----------------  -----------------------  -------------------  ---------  ----  ------  -------  ------------ 
Critical  onepps            refclk_p           No Common Primary Clock  Asynch Clock Groups          5     0       5        0             0 
Info      onepps            clk_fpga_0         No Common Primary Clock  Asynch Clock Groups          1     1       0        0             0     <--- one instance

 

I have a constraint:

set_clock_groups -name async_onepps -asynchronous -group onepps -group spi_clk -group {clk_fpga_0 m00_axis_aclk} -group {refclk_p s00_axi_aclk} -group SYSREF_IN_D

 

Why isn't the tool behaving the same way for both clocks?

 

Tags (1)
0 Kudos
Historian
Historian
4,735 Views
Registered: ‎01-23-2009

Re: report methodology

Jump to solution

Why isn't the tool behaving the same way for both clocks?

 

I don't know.

 

However, I see that you are using the set_clock_groups command. Doing so overrides all other constraints (so the set_max_delay -datapath_only I gave you before is useless).

 

In general, I highly recommend not using set_clock_groups (or clock to clock set_false_path commands). They are dangerous.

 

Take a look at this post (and the posts referenced within it) as to why you shouldn't use set_clock_groups.

 

Avrum

Tags (1)
Explorer
Explorer
4,712 Views
Registered: ‎07-29-2009

Re: report methodology

Jump to solution

The difference is that CDC-11 is called out: "Fan-out from launch flop to destination clock." I suppose this is because I do have five of them doing the same thing in my design.  If I eliminate 4 of them and bring it out to a more top-level; maybe that will suppress this warning?  That's kind of a major design change, so I'll have to wait on that.

0 Kudos
Historian
Historian
4,708 Views
Registered: ‎01-23-2009

Re: report methodology

Jump to solution

I suppose this is because I do have five of them doing the same thing in my design. 

 

You are sampling the same asynchronous input onto the same clock (refclk_p) in 5 different locations? If so, you need to be aware that the 5 different output pulses may not occur on the same refclk_p edge; if the signal changes "near" the edge of the clock, the signal may end on a given clock edge or on the next clock edge. If you circuit is designed to assume that they will all be sampled on the same clock, then you can have system failures. It is certainly possible that this is what the message is warning you of.

 

Avrum

Tags (1)