Timing Analysis

[iamthemik3]

I am working on a design that uses multiple clock signals. Since they are sourced from the same MMCM, I know that they are phase locked and share every Nth rising edge. To cross clock domains, I am generating a synchronization pulse that is high whenever the rising edges are to be aligned. Unfortunately, timing analysys doesn't seem to recognize this and falsely reports timing errors. Below is a sketch of what is going on:

The first register is clocked by the faster CLK_A but the output only changes on the synchronous rising edge. This allows a full CLK_B period to propagate the signal (green arrow). Unfortunately, the timing analysis doesnt seem to recognize this synchronization and I get failed timing constraints between clock edges that I know can be ignored (red arrow)

How would I write a timing constraint to handle this?

[austin]

Use the TIG

Timing ignore constraint.

If you are sure you know what you are doing, and you check the timing in the simulation, then just ignore those paths.

The tools must error on the side of caution.  You are forced to acknowledge each case, and either resolve it, or accept that you can ignore it.

[iamthemik3]

I've been ignoring them in the past however doesnt the tool end up putting extra (and unnecessary) effort into those paths?

Thanks.

[avrumw]

Because of the functionality of the SYNC signal, the path from the first FF to the second FF is a multicycle path, and can be described using a FROM:TO constraint.

In order to actually create the constraint, we would need to know how the clocks were created (we would need the TIMESPEC name of the clock that created CLK_A), and we would need the instance names of the two FFs, but in general, you would do

INST <FF_on_clock_A> TNM = TNM_src;

INST <FF_on_clock_B> TNM = TNM_dst;

TIMESPEC TS_mcp = FROM TNM_src TO TNM_dst TS_<timespec_that_generated_CLK_A> * 3;

Of course, we need to be sure that the SYNC signal is generated properly, using proper synchronous design techniques.

Avrum

[iamthemik3]

I'm having trouble getting the design tools to recognize the timing constraints correctly since it seems that I am still getting timing errors for these false paths. Worse yet, PAR reports that the timing score is so bad that it stops attempting to meet timing. This is unacceptable.

I have two clocks named clk50 and clk250 in my top-level module. They are both sourced from the same MMCM a few submodules in. I want to write a constraint that describes the above case for every logic path starting from clk250 and ending at clk50. This is what I have currently:

NET "clk100" TNM_NET = FFS "GRP_CLK100";
NET "clk50"  TNM_NET = FFS "GRP_CLK50";

TIMESPEC "TS_250to50" = FROM "GRP_CLK250" TO "GRP_CLK50" 20 ns DATAPATHONLY;

Unfortunately, my timing report still shows that the clk250->clk50 path is being analyzed incorrectly:

Slack (setup path):     -12.737ns (requirement - (data path - clock path skew + uncertainty))
   Source:               Inst_In2Ch/skip_channel_set_1 (FF)
   Destination:          gen_channels_loop[0].gen_CH_ ... etc ... /SP.WIDE_PRIM18.ram (RAM)
   Requirement:          4.000ns <- Didn't I just constrain this to 20ns?
   Data Path Delay:      16.460ns (Levels of Logic = 12)
   Clock Path Skew:      -0.078ns (2.788 - 2.866)
   Source Clock:         clk250 rising at 16.000ns
   Destination Clock:    clk50 rising at 20.000ns
   Clock Uncertainty:    0.199ns

What am I doing wrong?

[avrumw · Accepted solution]

There are two things - one is probably just a typo in your message. In the constraints you define GRP_CLK100 and GRP_CLK50. I presume you meant to show GRP_CLK250 (which is what you use in the timespec).

The real problem is the "FFS" in your TNM_NET. By putting the FFS in, you are restricting the group to contain only FFs. The destination, in this case, is a block RAM, and hence isn't in the group. Remove the FFS (and make sure that GRP_CLK250 is defined) and it should work.

As for the TIMESPEC itself, you should specify it differently. By doing the  "DATAPATH_ONLY" you are disabling the clock skew analysis of the tool - since the two clocks come from the same MMCM, the tools should be able to correctly understand the skew between these two domains. The clock skew between these clocks can be a couple of hundred picoseconds, which could result in a timing failure that you will be masking with the DATAPATH_ONLY.

Finally, it is really preferable to use something other than a fixed number for the TIMESPEC value - you would be better using an existing timespec (normally the period timespec) - instead of "20" you should use the name of the timespec that is applied to the MMCM, scaled appropriately. You don't say what the input freqency of the MMCM is, but lets say its 100MHz - in this case you would have

NET clk TNM_NET = my_clk;

TIMESPEC TS_my_clk = PERIOD my_clk 10 ns;

Then you should use

TIMESPEC TS_250to50 = FROM GRP_CLK250 TO GRP_CLK50 TS_my_clk * 2;

Avrum

[iamthemik3]

- Yep that was a typo. I also have a clk100 signal that has similar requirements. I copy/pasted the wrong line.

- FFS: Yes! that was it. Now that I look at the report it seems quite obvious

- DATAPATHONLY: I added that since I was just guessing at possible solutions. It has been removed.

- I am aware that the fixed timespec number isn't the "correct" way of doing it. I plan to switch it to reference the existing timespec later.

Thank you very much for your help avrumw