unstable fpga design

Well, off my head I can't help you what specific problem you may face but in general, if you have access to more than one syntesize tool, try to compile to code with it too and see if you see a difference. If you code is OK, the both tools should give similar results (apart from timing) but if there is a small bug, sometimes usinge a second tool which may map the design differently, can help you to isolate the problem. I assume you use XST, so you can try Synplify just as an example. If you don't have access to it, you can ask for a 30 days evaluation version (which is full featured) and try your desing with it.

Regards Arash

What is your background is FPGA design? This might be teaching you to suck eggs, but....

Ideally you want your whole design to be written synchronously off one clock. The only constraints you will then need are

1 for the clock and for input/output timing.

If you have ripple/gated clocks the timing analysis tools can't do a proper analysis on what's actually going to happen and you're likely to have a lot of clock races etc.

Nial.

------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design Cyclone Based 'Easy PCI' proto board

In my experience, FSM's generally stop working when there are asynchronous inputs. Note that in XST you need to try REALLY hard to end up with FSM's synthesized any way other than one-hot. When an asynchronous input affects the next state decision in the FSM, you can go to "zero-hot" or "more-than-one-hot" on a state after the async input doesn't meet setup and hold requirements. This can also happen if the FSM comes out of reset asynchronously. There was a recent thread about this...

I am not sure what you mean about the clocks. A gated clock, as in "enabled", is still easy to analyze timing. This becomes multicycle which I do all the time. I am not sure what a ripple clock is, but when you use multiple clocks, you can specify the timing relationship between them and the tool will do all the work.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

I think "gated clock" in the ASIC world means a clock made by ANDing the enable with the clock signal. Just like we used to do in the old TTL days when only a few chips had enable pins. (Worked OK as long as you ran your normal/main clock through a dummy gate to keep the clock skew reasonably close.)

They have the advantage of saving the power on the rest of the clock distribution chain when the clock isn't enabled.

"Ripple clock" probably refers to ripple counters. You build a counter out of toggle FFs. The 0=>1 transition of bit N clocks bit N+1. I'd guess it is small but I don't know if it's used much.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

In no particular order:

1) Start with the synthesis log files. It can be easy to overlook the information presented there - particularly if it is listed as a "WARNING" as opposed to an "ERROR". Look carefully at all the WARNINGs, sometimes there is information about clock, latch and asynchronous inference that you may explain why you are getting behavior you did not intend.

2) Scan through your code and look for reset circuits in *all* of your registers. Did you intend to reset all flops? Did you actually do that? If you did not, sometimes the powerup state of a flop can change when re-building the design.

3) Simulate, simulate, simulate. Have you verified this design in logic simulation? Does your simulation "sky-wire" into the design to force internal nodes? If so, your lab bahavior will be different.

4) Give us more details about the design style you use. I think the suggestion to make the entire design synchronous is a very good one. Gating clocks and / or generating clocks from internal registers can cause mismatches between simulation and synthesized designs.

Good luck, Chris

You're probably on the edge with the timing. The reason it works differently when you re-synthesize with only minor changes is because the place and route software starts with a random seed. You could actually make no changes at all and it would work one time and not work the next (though even if it "works" it would probably break under hot/low power conditions).

You might want to try a couple things -- take a heat gun set on low (or a hair dryer) and heat up the chip a little bit. Does the problem get worse? Spray it with cold spray -- does it get better? Also, raise the internal power supply voltage SLIGHTLY (like 1.5 volts to 1.55). Does the problem get better? If you lower the PS a little bit (like 1.45 volts) does it crap out? The silicon will run a little faster when it's cold and also when its voltage is a little high, so if your timing is on the edge then either of these factors might affect your circuit. If you've got a race condition, however, things might actually get worse when you cool the chip down or increase voltage.

Ideally, you want your FPGA design to be stable even if it's got to suffer with both bad conditions -- hot AND low voltage.

Agreed - this is a likely problem. First thing to do is to perform a static timing analysis post-P&R on the entire design. Doing just some of the paths is not adequate.

Hopefully you are not using gated clocks (where the main clock goes through a gate before it hits the clock pin of some of the flip-flops), ripple clocks (where the output of one f/f is used as the clock on another flip-flop) or asynchronous logic (typically placing gates on the set or reset pins of flip-flops). If you are using any of these techniques, pay extremely close attention to the timing, and try to avoid these techniques if you can. It should be possible to avoid using these techniques, as they are typically used in an attempt to reduce the size of a design or to maximize the clock rate.

If you have multiple clocks in the design, you also have to take a close look at all of the signals that cross the boundary between clock domains. The issue is not so much metastability (unless you are, perhaps, really pushing the clock rates) but the handling of signals that must be processed as a coherent set. For example, if you have a binary counter that is incremented on one clock (clock A, say) but latched (registered) by another clock (call it clock B), it is very likely that the signals will be mis-read. Say the counter changes from 0111 to 1000 on a particular edge of clock A; clock B may sample some of the bits before they change, and some of the bits after they have changed (due to slightly different clock-to-output delays on the counter flops, to routing delays that vary from signal to signal, and to slightly different setup times on the sampling flops). In principle, the sampling register could contain any value at all. You have to be very careful in your design to prevent this type of problem when dealing with multiple clock domains, especially if the clocks are asynchronous with respect to each other.

This is useful for verifying the presence of further problems after checking the things mentioned above, but as a go-nogo test it is not particularly helpful in isolating and fixing the problem. These tests (as well as running with both a fast clock and a slow clock) are useful for determining if you have a problem(s), but provide little insight in fixing them.

to

--

Phil

Hi all, firstly I would like to thank all of you guys for answering..

here are some more facts, before posting my questions I've made the following.. (with no sucsess).

Multi clocks - my design is indeed using few clock sources but each of them is driving a speperate block (i.e. only one clock is driving the data in/out of a single FSM).

Async reset: before I've encountered the problem I used an async reset such as

process (resetn,clk) begin if resetn ='0' then ... elsif rising_edge(clk) then ...

but when the unstabilty problem has rised I immidiatly changed all my design to

work on a sync reset such as

process (resetn ,clk) begin if rising_edge(clk) then if resetn ='0' then .... else ...

but it did not helped me ..

undesired Latch inferences: I also searched my entire design for warnings about latch inferences or some other warning that might indicate regarding an un-intentioned logic implementation (I found one warning regarding a latch, fixed it but the problem didnt "died").

Gated clocks - I dont think that I'm using them but I would be very happy if someone will give me a VHDL code example that will cause a gated clock. so I can be sure what you guys ment by "gated clock".

Simulation - I'm not fimiliar with the term "sky-wire" (mentioned by chris) maybe someone can explain what's the meaning of it.

FSM encoding: I also changed my FSMs encoding to GRAY instead of "one hot" beacuse from ny past experinse in some cases it helps (but it didnt help).

synthesis - Chris mentioned that even the same code could be synthesized differntly on each synthesis. In my case it's no so! I use Source safe for version control and save a version of every "good" synthesis and I saw that whenever I synthesize a code that has worked before it's always continuing to work.

In the past when I encounterd such problems I used the ChipScope LA to find & debug them but now the problem is moving from block to block and the chipscope itself when used is also changing the logic (using the device LUTs and RAM resources) so I can't realy use it.

I didnt tried yet to run the entire design on a lower frequency rate, that was a good sugesstion and I will try it. I will also try to "play" a little with power supply and with the temperature..

I was wondering if something in my syntheis/MAP/P&R configuration is wrong maybe you can throw me few tips on this subject too (I'm using Xilinx project navigator 6.1 with XST).

again, lots of thanks. Regards, Moti.

Do not know if this was addressed before. Do you use a four layer PCB carefully decoupled with capacitors? Is your ground bounce ok? Do you have contentions on your board? Did you try to put the outputs into slow smooth switching mode?

It looks to me like you switch off a bank by switching and the result depends on what is fitted into this bank.

Regards Thomas

- I'm using a 10 layers PCB and I believe that I decoupled the voltage supply inputs as needed ( three levels of capcitors values).

- I dont have any contentions on the board (I tested it on several boards) - and the current consumption is o.k. + the chip does not warm up + the same pin assignment file is used in cases when the chip does works.

- I guess that by "smooth switching mode" you mean "Slow slew rate" so at the begining I did tried to set the outputs to slow slew rate but without any success.

I didnt checked for ground bounces - but my design does not contains many outputs that change on the same time and along with using slow slew rate outputs I hope that I should not worry about ground/VCC bouncing problems.

I'm not sure what you meant by "switching off a bank" I will be glad if you explain it..

Thanks again, Moti.

Looks like a very proper design. Another idea: Do you have floating inputs?

Chips have multiple VCC/GND inputs to parts of the chip. If you overload a section it is likely that because of the supply break down caused by this in the section flip flops might flip. Texas Instruments has a very good app note: scba004c.pdf

Another thing is tiying the design. I am not familia with the latest software and just figuring out some things either. But on Foundation there was a tie option to tie unused inputs to defined logic levels. I know from the past that you can test designs without tie to save time but they were not that reliable like tied design.

Regards Thomas

in the Xilinx's spartan IIE its possible to associate an internal pull-up/pull-down resistor to each of the logic inputs, hence tying them to either vcc or gnd in case that they are floating.

But still I would like to thank you for the reference to the TI article, I downloaded it and I attend to read it soon.

Thanks again.. Ragards, Moti.

I have experienced a similar problem with the XC2V6000. To get repeatable performance I had to resort to 2-phase clocking for local clocks. I used Global clock buffers every place that I could. I used one common master clock with a Global clock buffer. I had to use area_group placements for modular portions of the logic to ensure close placement for minimum routing delays. I staggered the delay of the 32 BIT output bus signals to minimize switching noise. I added maximum skew constraints on local clocks to 2 nsec. I still get a problem with a few signals each time that I re-compile and re-route any change.

Bill

What do you mean by that? Could you give more details?

Rgds André

HI, I faced similar problems.For FSM's one should be very careful in coding.Tool must infer it as FSM.Total design must be synchronous.System clock must be routed through GCLK.Do not ignore any warnings.Use gray or one-hot encoding for FSM.If you are implementing a combo logic using process block one must be extra careful,else one will end up in infering latches instead of combinational circuit.Also make sure after power on entire design is in known state.

Even after doing so ,if u still struggling then modify constraints and try synthesising...

Also you so POST P&R simulation for long duration....

Regards, Raghavendra.Sortur

Hi,

What do you mean ?

Could you give more details on that?

Thank you.

Rgds André

Hi all, firstlly, i would like to thank all of you for answering. your answers were very helpfull and informative. I mannaged to stabilze my design and now it is working very smoothly (Knock on wood..). I made some changes both in my code and in my constarints in order to acheive stability and repeatability. I will describes some of the simple steps that i've taken in order to get my design stable - for the use of fpga designers experiencing the same unstability problems as i did.

1. Check that are no unconnected (floating) inputs - in my case i forgot some floating inputs so I took care of it (internal pull-ups res.)

1. Check that the design is !!!realy!!! synchronous with no FFs driving the clock to other FFs - I found a hidden ripple clock in my design and took care of it.

2. When high rate output is not needed set the "SLOW SLEW RATE" option to LOW - it might help.

1. Synthesize the design in a different Synth. tool - I found some new warnings that way and they were very informative.

2. Look for latches inferences - I had one and I believe that it gave me some problems.

1. Ask the guys in this group - they can give you some pretty good tips..

All of the above tips are tips that I received from the guys here and I'm very gartefull for them - THANKS!! Ragards, Moti.

Two-phase clocking uses the clock rising edge to clock the FF and uses the clock falling edge to capture the FF Q output in a 2nd FF to avoid hold time violations when using local clocks. The local clocks can have a maximum skew of 9 nsec due to the poor router. The XC2V6000-4 FF gate delay is 0.57 nsec and the net delay for a fan-out of 1 is 0.52 nsec. The FF set-up time is 0.35 nsec. So, maximum skew on a local clock greater than 1.5 nsec will cause false results.

I have used a MAXSKEW constraint of 1 nsec for local clocks in the UCF file and the router meets the constraint for 90% of the signals.

The global clock buffer maximum skew is 0.57 nsec across the die. However , there is a limited number of global clock buffers (16).

Bill Hanna