Xilinx / ISE multi-cycle path constraint pitfall

Hi Eli, Of course, I think I DO understand why you're making a fuss, but think you don't need to worry! :-)

Please, instead of following your suggestion, let me spend the five minutes to allow me to try again to persuade you of the error of your ways!

You correctly state that the CNT signals have a logical path to the CE pin of the counter which generates them. Let's call the signal at this CE pin CNT_CE. This fact alone causes you to believe that these CNT signals must get through the logic which generates CNT_CE in one cycle.

However, this is _NOT_ true in this case. The signal EN, which is high for one in every four cycles of the clock, is gated into this logic that makes CNT_EN. Whenever EN is low, the signal CNT_CE is low, no matter what the CNT signals are. So, as long as the signal EN gets from the FF it's generated in to CNT_EN and the CE pins of the CNT counter, all will be well, provided the CNT signals get through the logic by the time the EN signal next goes high. Your original constraints are fine for your situation.

If this weren't the case, multi-cycle paths wouldn't work. Also, and I'm sure you realise this, there is nothing magical about the CE pin, it's just another logic input that controls a mux.

It's easy(ish) for you to try this out. I suggest that you (the person asking the group for input ;-)) get your simulator out, write your HDL to add suitable simulated long delays to the CNT pins, and see what happens. I only wish I'd pointed this out to you 2 weeks ago, I may have saved you some effort. My excuse is I didn't read the OP thoroughly as it seems to have Hebrew characters in it that my viewer complains about.

Finally, it is a pain in the arse when the synthesiser uses gated logic (that admittedly can save LUT usage) on the CE input if you have a very fast clock that needs clock enables. As I said in another post, Synplify has a switch called syn_direct_enable. This is great for fixing this problem.

In VHDL:-

attribute syn_direct_enable: boolean; attribute syn_direct_enable of EN : signal is true;

HTH., Syms.

Let's now assume that the CNT_CE is made by a single 4-input LUT. One of those inputs is the EN itself, so when EN=0 the output, according to the LUT's logic mapping, is indeed 0. But the other three input can go crazy during these four cycles.

Now, can this cause glitches or not? As far as I know, the LUT's spec guarantees a propagation delay after all inputs are stable. Does it say anything about transactions between two 4-input sets, which give the same output value anyhow? After all, a LUT is a 16x1 bit RAM. Is there any guarantee that its output stays steady at 0 when EN=0. An AND port would, but what do we know about the LUT?

The simulation won't show this, of course, because the simulation model for a LUT merely shows the propagation delay.

Now, you need some bad luck to sample the CE exactly when it's glitching, so the fact that multi-cycle paths commonly work as is, doesn't mean that we have our bottoms covered.

If someone can turn me to where Xilinx guarantees a stable output from a LUT, when three inputs change, and one remains stable, so that there is no reason to change the output -- I'll be relieved to see it.

Thanks, Eli

Hi Eli, OK, great you've sussed it! And no, the LUTs don't glitch. The LUTs are made of a tree of MUXes which select one of sixteen configuration bits. If the input EN signal is '0', all the thrashing in the world on the other inputs should have no effect, because the EN input guarantees the LUT to be selecting a '0' configuration bit.

See

for XC3000 series, not exactly up to date, but backs up what I'm saying about muxes.

Peter Alfke at Xilinx is a good guy to confirm this with, and I'd be grateful if you could let me know if he contradicts what I say, or the syn_direct_enable will become a necessity. You can find his email by searching this newsgroup.

Oh, I found it! Search google groups CAF for a thread called " Xilinx LUT behavior question" where Peter confirms this mode of operation. He says "I have answered this particular question many times over the past 15 years."

Cheers, Syms.

p.s. At least I bet you learnt a whole lot of useful stuff about constraints in the last fortnight! This'll certainly serve you well in the future. :-)

I wish I hadn't suggested that thread. My 'clever dick' response to Eric is not relevant in the case brought up in this thread. Live and learn! Syms.

I will use quartus only because it makes nicer graphics. ISE would give me equivalent results:

Here's the code I used

The RTL viewer sees the code like this:

Quartus synthesis ; Total registers ; 19 ; ; Total logic cells ; Type ; Actual Time

+----------------------+--------------------------------- Clock Setup: 'clk' ; 249.81 MHz ( period = 4.003 ns )

Here's how synthesis did the fit:

I see no reason to tinker with timing constraints in this case.

-- Mike Treseler

Hmmm... I gave the LUT as an example of what could go wrong, and now we have a Xilinx engineer claiming that the LUT doesn't glitch, and neither of us can find an official confirmation for that in Xilinx' docs. Which means that nothing stops Xilinx from shipping devices with a new LUT design, which doesn't have this quality.

Regardless, the next stage is to check whether any possible logic path combination could glitch, but I have to admit that this sounds a bit paranoid even in my own terms.

So I suppose I'll leave my extra constraint just to be safe, and in case it bugs me too much, I could always remember that there are good excuses to let go...

Thanks for the clarifications. This discussion shed light on issues which have bothered me for quite some time.

Eli