Hi, I have seen this kind of unusual behavior with dense designs that
employ "logic slices with unrelated logic" reported in the system.log.
The logic fits, but does not actually meet timing in reality, and often
has intermittent failures with the CPU OS. Check your mapping report for
the unrelated logic packing. An example of an ok design report is:
Logic Distribution:
Number of occupied Slices: 30,684 out of 33,088 92%
Number of Slices containing only related logic: 30,684 out of 30,684
100%
Number of Slices containing unrelated logic: 0 out of 30,684
0%
*See NOTES below for an explanation of the effects of unrelated logic
In my experience "Slices containing unrelated logic" must be avoided.
-Oren
> 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
>
>
>
>
>
>
>
--
Oren Milgrome
University of California - Berkeley
Radio Astronomy Lab 601 Campbell Hall
Berkeley, CA 94720-3411
mobile: 510 368 6857 office: 510 642 5509
lab: 510 642 0381 fax: 510 642 3411
email: [email protected]
