Hi John, I think timing errors of 100ps or so are probably not too much of a concern, but I'd be a little worried about the ~1ns errors you're seeing. Some suggestions to try and improve timing: on software registers and brams, I've found that adding delays with register retiming enabled to the addr, data_in, we signals (same delay on each) or on the input/output of the software register can help a lot. The idea is that since you don't care about a few cycles of latency when the software accesses these resources, you can allow for more latency in the connections which should free up fast routing resources for areas where they are actually needed. The same is true of the rx_valid and out of band outputs from the XAUI, since these represent 72 lines that have to be routed around the chip, and the links have huge latency anyway. I think the compiler should be smart enough to optimize out the higher bits of your 32 bit counter driving the blinking LED, but large counters can use up fast counter resources that you might need elsewhere. Same goes for the counters in the pulse extenders because there they definitely won't be optimized down to fewer bits. You also have a relational with zero latency in that thing that is 32 bits wide, so that's going to eat up fast resources. Add a unit or two of latency. This will make the extended pulse a few counts longer than you set the register for, but in this particular case that's not an issue. Have you tried running this design? Hope this helps, these are just anecdotal things that I've found to help, but not sure if my reasoning is actually sound. Glenn
On Thu, Apr 24, 2008 at 7:45 AM, John Ford <[email protected]> wrote: > > > Hi all. We're closing in on a release of our pulsar machine. We have > > been ignoring the timing errors in the builds, but I want to clean them up > > before we release the system for use. I have attached the model and a > > timing report from the latest model, an 8K point pfb/fft, with 2 xaui > > ports inputting data samples, some shared bram for debugging, some > > software registers, and output of the specral information over bee2 pipes > > to another fpga chip. These timing errors seem to be coming from inside > > the system, in the first instance from some fifo's internal to the system, > > and in the second case from the PFB coefficient generator. > > > > Can you suggest ways to fix these errors? Or should I just ignore them? > > (Seems like a *bad* idea...) > > Well, it would be helpful if I had sent the attachments... > > Here they are! > > > > > Thanks! > > > > John > > > > > > >
