Xilinx / ISE multi-cycle path constraint pitfall

The "en" signal is a synchronous input to the second block. It is not a clock and does not need any constraint other than the Fmax for "clk".

Here's a related example using a single block:

-- Mike Treseler

[1] There are lots of ways to define a Time group, and yours is too inclusive.

Here are some multipath constraints I use for similar problem :

INST "u_tcg_sys_timers/tcg_year_*" TNM="SYSTIMER_1_PER_SEC"; INST "u_tcg_sys_timers/tcg_doy_*" TNM="SYSTIMER_1_PER_SEC"; INST "u_tcg_sys_timers/tcg_hrs_*" TNM="SYSTIMER_1_PER_SEC"; INST "u_tcg_sys_timers/tcg_min_*" TNM="SYSTIMER_1_PER_SEC"; INST "u_tcg_sys_timers/tcg_sec_*" TNM="SYSTIMER_1_PER_SEC";

TIMESPEC "TS_IGNORE_1_PER_SEC" = FROM "SYSTIMER_1_PER_SEC" TO "SYSTIMER_1_PER_SEC" 18.0;

[2] In future, if you have a prefix on signal names that you know will be a multipath source/destination, it will be easier, in large designs to use wildcards for inclusion in group. [3] Take a look at xilinx/doc/usenglish/docs/cgd/cgd.pdf for good reference on constraint usage. Or open the constraint editor, and experiment with applying constraints ... check the results in .ucf file for syntax. I personally don't use constraint editor for final changes, because I don't like the tools mucking with my .ucf file.

-- Regards, John Retta Owner and Designer Retta Technical Consulting Inc.

Colorado Based Xilinx Consultant

email : snipped-for-privacy@rtc-inc.com web :

I think you need to change the way you're setting up the MCP constraint. What you want is for every flop which is controlled by EN, the REG.Q to REG.D path is 4 cycles. EN.Q to CNT.D is actually a single cycle path. It's easier to see if you draw the waveform; EN controls a MUX one end of which is connected CNT.Q and the other is connected to the output of the incrementer logic (including the CNT!=16'hFFFF check) (only logically not what the synthesizer necessarily implements) EN is high only a single clock so the path of the MUX which is short has to work in a single cycle. The other path which has the conditional incrementer can take 4 cycles to settle.

First, thanks all for responding.

Now to bus> [1] There are lots of ways to define a Time group, and yours is too

Of course it is. Otherwise there wouldn't be a problem. ;)

(...)

That won't solve the problem, I'm afraid. What I showed in my example above, is that some paths between registers which change only every 4 clocks still can't be allowed for multipath constraint relaxation. So hand-picking those registers according to their expected BEHAVIOUR won't do the job. I mean, wouldn't you (manually) pick "cnt" as a candidate for a multi-cycle path from itself to itself? (which would be correct, if there wasn't any extra "if" to mess up the real CE path)

Identifying groups by connectivity allows you to group elements by specifying nets that eventually drive synchronous elements and pads. This method is a good way to identify multi-cycle paths elements that are controlled by a clock enable. This method uses TNM_NET on a net.

The TNM_NET syntax for identifying groups by connectivity is:

NET "net_name" TNM_NET = qualifier "tnm_name";

... and then they go on more or less like I did. (I chose TNM instead of TNM_NET but that's not relevant here).

So the problem remains. Any ideas?

Eli

[1] Try this. NET "clk" TNM_NET = "clk"; TIMESPEC "ts_clk" = PERIOD "clk" 10 ns HIGH 50 %;

INST "cnt*" TNM="JUST_CNT_FF";

TIMESPEC "TS_JUST_CNT_FF" = FROM "JUST_CNT_FF TO "JUST_CNT_FF" "TS_clk" *

4; [2] My only point was that there were more specific techniques for identifying paths. The level of specificity though is limited. For instance, suppose FF1 had two paths to FF2, one a multicycle path, the second a single clk path. It is not clear how to distinguish the two paths. This might seem like an arcane example, but I suspect your "simple" example might be more illustrative of a common problem

-- Regards, John Retta Owner and Designer Retta Technical Consulting Inc.

email : snipped-for-privacy@rtc-inc.com web :

It is certainly a common problem in this newsgroup. A multi-cycle constraint is a last resort in my book. It is a fussy monkey on the back of the design that must be tinkered with any time the circuit is modified, branched or retargeted.

It would take me much more time to repeatedly verify, that I had this vendor-specific constraint described correctly than it would to fix the design to meet single-cycle timing in the first place.

And like you said, this is a very simple example.

-- Mike Treseler

Hi Eli, Synplify has an attribute called 'direct_enable'. Use it on your enable net to make sure you don't get the problem you describe. HTH., Syms.

I avoid multi-cycle constraints like the plague as well. They bring in too many opportunities to make a mistake that will bite you later.

Seems like a couple of years ago, there were some startups that were trying to create tools that would automatically/formally identify and/ or verify multi-cycle and false paths/constraints. Seemed like a really great idea. Anyone know or try one of these?

I'm with Mike and Ray, I avoid such constraints if at all possible. It is just too hard to verify that you have them specified correctly, and you are not accidentally relaxing a single clock path. They are an absolute last resort for me. With enabled clock buffers, many circuits can be converted to slower clocks and automatically verified in STA with no special constraints (other than clock rates/relations).

Andy

I think the FishTail product does this.

---Matthew Hicks

It uses formal analysis techniques to locate multi-cycle paths and check the validity of your multi-cycle constraints. BluePearl's tool does somewhat similar things.

I suspect that both are likely to be priced out of reach of typical FPGA users, though.

-- Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK snipped-for-privacy@MYCOMPANY.com

The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.

Most likely.

These tools might provide rehab for a critical design that is already hooked on multi-cycle constraints.

However, for a new design, I would rather keep the monkey off my back in the first place.

-- Mike Treseler

So I don't want to appear to be the advocate of designs that rely on multicycle constraints, and therefore sprinke around like salt and pepper.

However, there are occasions, mostly in core usage which do not run at full data rate clocks, where a designer runs into this problem.

The point is that multicycle constraints are as powerful as a shotgun .... and possibly just as dangerous

-- Regards, John Retta Owner and Designer Retta Technical Consulting Inc.

email : snipped-for-privacy@rtc-inc.com web :

I commend you for actually answering Eli's question rather than just recoiling in horror as I did.

Yes, if I didn't have source code for the core or if I didn't know how to rewrite it or pipeline the problem sections, I might be in the same boat.

And quite unnecessary for new fpga designs where registers are free.

-- Mike Treseler

Hello again,

After giving some thought about this issue, I'd like to show my own solution (i.e. answer my own question).

But before that, my opinion about multicycles: I'm generally in favor of using clock enables instead of multiple clocks whenever possible. The worst thing about being generous with clocks is that each core has its own set of clocks, and before you know it, you're out of clock resources.

Personally, I try to keep my HDL reusable, which generally means to use device-dependent resources as little as possible. For example, I don't know of a portable way to make a pipelined multiplier (I know, of course, how to do that with Coregen).

So to summarize my opinion, I do prefer a single clock, with clock enables within the core, in order to make it easier to reuse. And this brings up the need for a reliable way to define multi-cycle paths.

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

Now to my suggestion: The problem is that paths which end up in the flip-flops' CE pin are taken for multi-cycle paths. After all, the CE is sampled by the flip-flop on every clock. So let's exclude exactly those paths.

With the example I gave in the beginning, let's change the UCF to:

NET "clk" TNM_NET = "clk"; TIMESPEC "TS_clk" = PERIOD "clk" 10 ns HIGH 50 %; NET "en" TNM = FFS "tgrp_en"; TIMESPEC "ts_multipath" = FROM "tgrp_en" TO "tgrp_en" "TS_clk" * 4;

PIN "*.CE" TPSYNC="tgrp_ces"; TIMESPEC "ts_no_multipath" = FROM "tgrp_en" TO "tgrp_ces" "TS_clk";

The first four lines are like before (except I've corrected "tgrp_en" to include flip-flops only).

And then comes the fix: The two rows next pick all paths which start at multi-cycled flip-flops, but end at CE pins. These paths are returned to their original, single-cycle timing.

So what we have now is this: If a path begins at a flip-flop which changes value every 4 clocks, and ends at a flip-flop which samples at the same clock enable, that path can take longer. This statement is now true, because we've excluded paths that end on the CE pin, which is sampled on every clock.

Note that if the relevant paths are crossing clock domains or are used against flip-flops which sample on reverse edge of the clock, we might mess things up. So I would suggest using a more specific definition for "tgrp_ces" ("*.CE" is just for the example).

Does anyone see a problem with this?

By the way, I *was* somewhat worried that the timing calculation would change. It wasn't clear to me if referring to the flip-flop's CE pin in the TPSYNC constraint rather than using the INST/TNM pair for the entire flip-flop, would change the timing endpoint, resulting in a different timing calculation. But it turns out that the tools include Tceck (CE to clock) in both cases, which results in identical calculations (at least where I managed to compare them).

So what do you say about this?

Eli

I don't follow this. A clock enable is just a synchronous input. Which tool automatically constrains timing for these?

-- Mike Treseler

Hi Mike, He's trying to ensure the enable signal gets to all the FFs in time. This should happen anyway as long as he keeps the instance 'en' out of his timegroup 'tgrp_en' which he may or may not have done. I think there's a flaw in his logic, in that the enable doesn't necessarily attach to the .CE pins. It can go to regular logic depending on the synthesisers 'day_of_week' input. :-) Also, CE pins get used for other things the synthesiser decides on. Cheers, Syms.

The example which I began with shows exactly why this isn't true.

... which is exactly what my recent suggestion should solve.

Eli

Hi Eli, I think you've misinterpreted what's happening. In your original example, the 'cnt' signals don't need to get back to the clock enable input in one cycle. Only the signal 'en' does. As long as 'en' gets to the FFs in time, whatever the CNT signals are doing does not matter a jot.

This is your mistake :- "This is all nice, but now we have a path from cnt[15:0] (a.k.a. "tgrp_en") to itself, which has to be finished in one single clock:

=16'hffff, and back to the flip-flops' CE. After all, the CE must meet timing for every clock. On the other hand, the multi-path constraint allows 4 clocks for this path."

HTH., Syms.