[USRP-users] timing issues with RFNoC block
jason at gardettoengineering.com
Wed Mar 2 13:23:53 EST 2016
Nice, I don't seem to have that file. I have post_route_timings.rpt in
the build-X310_RFNOC_HGS directory, but not the file you mentioned...
Gardetto Engineering LLC
On 03/02/2016 12:42 PM, Nick Foster wrote:
> There's a very useful (and very verbose) timing report, called
> "x300_timing_summary_routed.rpt", generated during the build. It
> should give you a place to start looking for your timing problem.
> On Wed, Mar 2, 2016 at 7:46 AM Jason Matusiak via USRP-users
> <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>> wrote:
> Thank you for the quick response Sylvain. That is an interesting
> thought that I hadn't really considered. My build takes forever to
> build, so I know it is struggling with timing, but it does run (my
> experience in the past is that if it doesn't meet timing, the NoC
> won't run), so it must be OK (I am waiting on another build to see if
> that is correct). Do you happen to have an example of the random
> scenario somewhere in the project (wasn't sure if you had one for
> fosphor that I haven't found yet)? Thanks!
> EDIT: A correction to my above post. My build just finished, so I
> a look at the build.log and see this at the bottom:
> CRITICAL WARNING: [Timing 38-282] The design failed to meet the timing
> requirements. Please see the timing summary report for details on the
> timing violations.
> So I definitely have some timing issues to work through....
> On 03/02/2016 10:35 AM, Sylvain Munaut wrote:
> > Hi,
> >> I seem to be having some timing issues with an RFNoC block. My
> >> worked, I made some significant changes, it stopped working,
> and then I
> >> rolled back and the block continued to not work. I played with
> things for
> >> about a week until I got it to work again. I made one minor
> change and
> >> suddenly things didn't work again. This makes me think that I
> am right up
> >> against some sort of threshold somewhere (most probably timing)
> and it
> >> sometimes works, and other times doesn't (though the block
> always "runs").
> >> So my question is, is there a good methodology for working on
> the timing of
> >> a particular block within your larger RFNoC VIvado project?
> > If the design met the timing when building (as reported by xilinx
> > static timing analyzer) and it still exhibits random behaviour, then
> > there is probably a bug in your logic and it doesn't entirely comply
> > with the AXI stream specs. (like not handling 'busy' output or holes
> > in the 'valid' at the input or things like that).
> > I usually test my logic in simulation against 'random' input/output
> > patterns (forcing valid=0 at the input randomly and forcing
> > at the output randomly). and check the output is still the expected
> > one.
> > Cheers,
> > Sylvain
> USRP-users mailing list
> USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users