Andrew Siemion wrote:
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
Hi Andrew,
Sorry for the long discourse... and the confusion. Let me attempt to
clarify...
Our 800MHz, 2K-channel design(s) build with minimal timing errors (~50);
but they load and execute perfectly with no apparent hitches. In fact
this particular
design set has been used successfully to conduct several PULSAR
observations.
(The timing errors that ARE reported are "marginal"; typically missing
the 5nSEC
mark by a fraction of a nSEC.)
Our 800MHz, 4K-channel design(s) build with high numbers of timing
errors (150+);
and won't load properly... Their Tiny Shells don't respond and our
logic level indicator
LEDs don't light (which comes as no surprise).
Our 400MHz, 4K-channel design(s) build with NO timing errors, appear to load
normally, their Tiny Shells initially display their respective sign-on
messages, and our
logic level indicator LEDs display the correct states and blink
appropriately; indicating
that our logic is functioning properly. However, when we attempt to
access the design
loaded into FPGA1 through it's Tiny Shell, that particular design
crashes, it's Tiny
Shell quits responding, and our logic level LEDs all go blank in FPGA1
only (the
other two FPGAs' Tiny Shells continue to respond and their logic level LEDs
continue to display their proper states.
However, Oren Milgrome cautioned us in an earlier e-mail today that
dense designs
which result in "unrelated logic" being synthesized in slices can
sometimes cause OS
crashes, etc. Indeed, the designs in question DO result in "unrelated
logic" being
synthesized in slices, so he may be onto something there...
John Ford is in the process of trying to build our designs with the new
FFT blocks
which have the optimized re-order sections and his initial results look
quite promising.
They report significantly fewer slices being used, so this might turn
out to be the
ultimate solution to our problems...
Randy
