FPGARelated.com
Forums

unstable fpga design

Started by Moti Cohen October 20, 2004
Moti Cohen wrote:

>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
> > > > > 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?
- 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.
> It looks to me like you switch off a bank by switching and the result > depends on what is fitted into this bank.
I'm not sure what you meant by "switching off a bank" I will be glad if you explain it.. Thanks again, Moti.
Moti Cohen wrote:

>>> >>> >>> >>> >>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? >> >> > > >- 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. > > > >
Looks like a very proper design. Another idea: Do you have floating inputs?
>>It looks to me like you switch off a bank by switching and the result >>depends on what is fitted into this bank. >> >> > >I'm not sure what you meant by "switching off a bank" I will be glad >if you explain it.. > > >
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
Thomas Rudloff <thomasREMOVE_rudloffREMOVE@gmx.net> wrote in message news:<417BA070.3030805@gmx.net>...
> Moti Cohen wrote: > > >>> > >>> > >>> > >>> > >>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? > >> > >> > > > > > >- 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. > > > > > > > > > Looks like a very proper design. Another idea: Do you have floating inputs? > > >>It looks to me like you switch off a bank by switching and the result > >>depends on what is fitted into this bank. > >> > >> > > > >I'm not sure what you meant by "switching off a bank" I will be glad > >if you explain it.. > > > > > > > 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.
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.
moti@terasync.net (Moti Cohen) wrote in message news:<c04bfe33.0410250326.74fff416@posting.google.com>...
> Thomas Rudloff <thomasREMOVE_rudloffREMOVE@gmx.net> wrote in message news:<417BA070.3030805@gmx.net>... > > Moti Cohen wrote: > > > > >>> > > >>> > > >>> > > >>> > > >>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? > > >> > > >> > > > > > > > > >- 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. > > > > > > > > > > > > > > Looks like a very proper design. Another idea: Do you have floating inputs? > > > > >>It looks to me like you switch off a bank by switching and the result > > >>depends on what is fitted into this bank. > > >> > > >> > > > > > >I'm not sure what you meant by "switching off a bank" I will be glad > > >if you explain it.. > > > > > > > > > > > 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. > > 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
Bill wrote:
> To get repeatable > performance I had to resort to 2-phase clocking for local clocks.
What do you mean by that? Could you give more details? Rgds Andr&#4294967295;
moti@terasync.net (Moti Cohen) wrote in message news:<c04bfe33.0410200517.391ab8d9@posting.google.com>...
> Hello all, > > first a little background .. > I'm currently working on a fpga design (using VHDL) and using > the Xilinx spartan IIE fpga (xc2s400e) chip. > my design size is about 1300 slices (about third of the chip > capacity). > My problem is as follow : > sometimes when I change my top design and then re-synthisizes it, some > "parts" of my code is not working properly i.e. - some of my fpga > blocks are working as usuall and some dont (e.g. FSMs). > this appens not only for large code changes, sometimes it happens when > I "just" change an output pin to be '0' instead of '1' (a very minor > change). > my static timing analisys looks o.k. (at least the paths that i've > constrained). and I realy dont know where to start looking. > I checked my design over and over for "bad code" parts but didnt found > anything that might explain this. > > I would realy like to know if some of you have expeienesd something > similar in the past and if not maybe someone can give me a tip to > start with.. > > thanks in advance, Moti.
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,

> To get repeatable > performance I had to resort to 2-phase clocking for local clocks.
What do you mean ? Could you give more details on that? Thank you. Rgds Andr&#4294967295;
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.)

2. 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.

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

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

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

6. 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.
ALuPin@web.de (ALuPin) wrote in message news:<b8a9a7b0.0410272244.2ee6e77@posting.google.com>...
> Hi, > > > To get repeatable > > performance I had to resort to 2-phase clocking for local clocks. > > > > What do you mean ? > > Could you give more details on that? > > Thank you. > > Rgds > Andr&#4294967295;
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