Please help, Xilinx FIFO problem!
in [FPGA]
|
From: John McCaskill on 22 Dec 2009 10:57 On Dec 22, 9:24 am, Antti <antti.luk...(a)googlemail.com> wrote: > On Dec 22, 3:55 pm, John_H <newsgr...(a)johnhandwork.com> wrote: > <snip> > > Hi John, > > I have only spare minute, please do not shoote me - when I reported > all 4 FIFOs not working it was wrong, the non-xilinx fifo is not > tested > i replaced the un-unused FIFO > > I will retest and report results. > what does look like valid result is that replacing one of 2 similar > FIFOs the unused one, made the other one have 10 times less error > > have to give kids e-lectronics class this instant! > Antti Since your change did not change the functionality of what you tested, but changed the timing due to going through place and route again, this sure sounds like it could be a timing problem to me. I am sure that you have already checked that static path analysis stated that all of your constraints were met, so generate a custom timing report and have it list the unconstrained paths. If something that matters is unconstrained, you are susceptible to strange behavior from the design. Since the symptoms are appearing at a FIFO, I would pay special attention to signals crossing between the clock domains. You mention that the FPGA is about 80% full. If you meant 80% of LUTs and FFs, you are getting into the region that the place and route tools are having to work hard to meet timing constraints. If something is unconstrained, it could be getting really poor placement and timing with respect to what it really needs. Regards, John McCaskill www.FasterTechnology.com
From: Antti on 22 Dec 2009 12:32 snip > > Antti > > Since your change did not change the functionality of what you tested, > but changed the timing due to going through place and route again, > this sure sounds like it could be a timing problem to me. > > I am sure that you have already checked that static path analysis > stated that all of your constraints were met, so generate a custom > timing report and have it list the unconstrained paths. > > If something that matters is unconstrained, you are susceptible to > strange behavior from the design. Since the symptoms are appearing at > a FIFO, I would pay special attention to signals crossing between the > clock domains. You mention that the FPGA is about 80% full. If you > meant 80% of LUTs and FFs, you are getting into the region that the > place and route tools are having to work hard to meet timing > constraints. If something is unconstrained, it could be getting > really poor placement and timing with respect to what it really needs. > > Regards, > > John McCaskillwww.FasterTechnology.com not very encouranging, I have had really hard times with Actel devices where i have witnessed a simple shift register at low as dirt clean clock to stop shifting if FPGA utilization did go above say 93% of versatales. There was no violations, nothing did show up in post place and route simulation, just chip was dead. Later i did read about MANUAL insertion of "inverting" clock tree to adjust the timings. This was scary! current design utilization is Slices 14K 73% brams 116 80% DSP 39 80% GT11 6 50% the device is slowest speed grade FX40 and there is not a single assembled with higher speed grade, so that testing is not possible. i just did clean some snow outside, hm actually there is no other explanation except XILINX TOOL messup, that is, the FIFO clocks are constrained, no violation reported, but tools generate non-working design. i will still test the non-xilinx fifo properly for good luck test, but then its time to redesign to 8b-32b DPRAM it would have much less logic in 125mhz domain, so there could be more hope. Actually first version of that module is ready, but it needs change of other HDL code, and change of firmware, so working fifo would be less work to, well if fifo would work thanks for all suggestion, i will continue with testing, and focusing on timing-hunt or then remove all fifo from that place Antti
From: John McCaskill on 22 Dec 2009 13:22 On Dec 22, 11:32 am, Antti <antti.luk...(a)googlemail.com> wrote: > snip > > > > > > Antti > > > Since your change did not change the functionality of what you tested, > > but changed the timing due to going through place and route again, > > this sure sounds like it could be a timing problem to me. > > > I am sure that you have already checked that static path analysis > > stated that all of your constraints were met, so generate a custom > > timing report and have it list the unconstrained paths. > > > If something that matters is unconstrained, you are susceptible to > > strange behavior from the design. Since the symptoms are appearing at > > a FIFO, I would pay special attention to signals crossing between the > > clock domains. You mention that the FPGA is about 80% full. If you > > meant 80% of LUTs and FFs, you are getting into the region that the > > place and route tools are having to work hard to meet timing > > constraints. If something is unconstrained, it could be getting > > really poor placement and timing with respect to what it really needs. > > > Regards, > > > John McCaskillwww.FasterTechnology.com > > not very encouranging, I have had really hard times with Actel devices Not trying to be discouraging Antti, I think you can find and fix this problem. > where i have witnessed a simple shift register at low as dirt clean > clock > to stop shifting if FPGA utilization did go above say 93% of > versatales. > There was no violations, nothing did show up in post place and route > simulation, just chip was dead. Later i did read about MANUAL > insertion of "inverting" clock tree to adjust the timings. This was > scary! > If you are using synchronous design techniques, and are treating the clocks properly by keeping them on the clock networks and only using the dedicated clocking resources to manipulate them, static path analysis should make sure that there are either no problems with the constraints being met no matter how full the chip is, or finding that there are timing problems. Where some of the hard to find problems creep in is unconstrained paths that should be constrained, improperly constrained paths, such as improper use of multi-cycle and false path constraints, and improper handling of asynchronous signals and clock domain crossing. Sometimes the tools can work against you if you are not careful. If you have two or three FFs in a series to synchronize a signal, you don't want to let the tools replicate those registers. > current design utilization is > Slices 14K 73% > brams 116 80% > DSP 39 80% > GT11 6 50% > Ok, I thought you meant that LUT or FF utilization was at 80%, if it is not LUTs and FFs that are at 80%, but the BRAMS and DSP blocks that should not be a problem. Since slices are only at 73%, you have plenty of LUTs and FFs left and the tools have lots of flexibility to work with. By default, the mapper will not put unrelated logic into the same slice, so it tends to spread it out to give place and route flexibility. I have many designs that are at 99% slice utilization well before I am finished adding stuff to them that place and route just fine. > the device is slowest speed grade FX40 > and there is not a single assembled with higher speed grade, so that > testing is not possible. If you are having clock domain crossing problems, a faster speed grade may move the problem around, but is not the real solution. > > i just did clean some snow outside, hm > actually there is no other explanation except XILINX TOOL messup, that > is, the FIFO clocks > are constrained, no violation reported, but tools generate non-working > design. Hope it is not the tools, that is hard to fix on your own! I think there are plenty of other possibilities. This sounds like a timing issue to me from what you have described. You can find it with the tools you have, it is just one of the more frustrating problems to deal with. Look at the unconstrained paths? What do you see? I don't think the FIFO is the cause of the problem, but it is where it shows up so put multiple ChipScope ILAs on it to cover the different clock domains. While not perfect, you can run the ILAs off of a clock that is a multiple of the clock domain it is sampling to get some timing info if you want. Something is going to look wrong here, follow the trail. Using the ILA tool in the FPGA editor you should be able to change which signals the ILA is monitoring and get a new bitstream to download in a matter of a few minutes since that does not require you to go through place and route again. I was doing this the last few days to see why something that was working in simulation was not working on the hardware, it is a powerful technique. > > i will still test the non-xilinx fifo properly for good luck test, but > then its time to redesign > to 8b-32b DPRAM it would have much less logic in 125mhz domain, so > there could be > more hope. Actually first version of that module is ready, but it > needs change of other > HDL code, and change of firmware, so working fifo would be less work > to, well if > fifo would work > > thanks for all suggestion, i will continue with testing, and focusing > on timing-hunt > or then remove all fifo from that place > > Antti Good luck, John McCaskill www.FasterTechnology.com
From: GLOW on 23 Dec 2009 06:28
Antti, Based on all the symptoms you have described, namely the read side of the fifo going crazy and getting stale or duplicated data strongly suggests that the problem is in the recovered clock. I once worked on a chip where the duty cycle of the recovered clock can vary widely and that the recovered clock even occasionally have a stretched cycle where the clock looked like it was missing a cycle. This was on an actual asic as opposed to an fpga. But the bottom line was that we had unintentionally assumed that the recovered clock would always be 50/50 duty cycle and that the recovered clock would never do strange things like skip a clock. If at all possible, I suggest you try the following. 1) I assume that you are using the recovered clock directly. If you are, try running the clock thru an onboard PLL and use the pll generated clock instead. If this helps your problem then do #2 below. 2) Route the recovered clock back out to a pin and observe it on a 1GHz scope. Configure the scope to trigger on anything less than 40/60 duty cycle. Good Luck.... |