Hi Randy, I'm a bit confused. Is it correct that both 400MHz and 800MHz 4k versions of GUPPi are non-functional, but only the 800MHz design reports timing errors?
Can you run your 800MHz 2k design successfully on the same bee2? With regards to the 400MHz design - when you say "all seems well," does that mean that indeed everything is working as you would expect? When the TinySH interface hangs, does it appear that the fpga fabric is still operating normally? Also, the Xilinx Timing Analyzer Tool can be very useful in exploring timing errors. This can usually be found in the xilinx installation directory (or nearby), or can be run by issuing the shell command 'timingan' directly from matlab (assuming paths are setup correctly.) Once you have the Timing Analyzer open, navigate to the implementation directory of your design and open the XML Timing Report file (.twx) file. Problematic paths should be indicated in red (if I remember correctly). Most can usually be corrected by inserting appropriately latency blocks. - Andrew On 10/20/08 8:12 AM, "Randy McCullough" <[email protected]> wrote: > All, > > First, the good news... > > Our 800MHz, 2K-channel version of GUPPi is now running reliably and has > already been > used successfully during several trial observations; yielding excellent > results! > > But now, the bad news... > > While attempting to implement an 800MHz, 4K-channel version of our GUPPi > instrument, > we've been experiencing lots of timing errors (150+) and horrible timing > scores (100,000+). > Even though these attempts "appear" to build successfully, they, of > course, don't run reliably. > > Our basic architecture is comprised of two DSP engines running in USER1 > and USER3 which > feed their respective spectral data streams via the IOBs to USER2; where > we calculate Stokes > Parameters, perform scaling and offsets, do Vacc, and packetize and > transmit 10Ge to our big > backend computer. > > As a sanity check, we decided to try a 400MHz, 4K-channel version, which > consistently yields > successful builds with NO timing errors and timing scores of 0; feeling > confident that this version > would work right out of the box. No such luck... > > Even though the two DSP engines are identical EXCEPT for the directions > of the IOBs used to > carry the spectral data streams to USER2, we've encountered a really > weird problem... > > When we load the .bof files for USER1, USER2, and USER3 into the bee2, > all seems well > until we attempt to interact with USER1 via its Tiny Shell; at which > point it hangs up, while > the other two continue to work properly; allowing us to interact through > their Tiny Shells to > read and write software registers, etc. > > We've tried interchanging the DSP Engines by swapping the appropriate > .bof files into their > respective FPGAs; but end up with the exact same result... The design > which was originally > intended to run in USER1 won't run in USER3; while the design which was > originally intended > to run in USER3 works just fine in USER1. > > As a last ditch effort, we deleted the model file intended for USER1, > cloned the model for > USER3 and re-named it for use in USER1 (changing the IOB directions), > built this version, > and experienced the exact same behavior... i.e., the Tiny Shell in > USER1 simply hangs up > while the other two work just fine. > > Remember that these 400MHz versions which exhibit such weird behavior, > built with NO > timing errors! > > And, as a final sanity check, we went back and built known working > versions which, of > course, still work perfectly; verifying that our development environment > is still in good > shape... > > Any suggestions? > > Randy > > > > > >
