[USRP-users] timing issues with RFNoC block

Jason Matusiak 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...


~Jason Matusiak
Computer Engineer
Gardetto Engineering LLC
443.848.7188 (c)
301.422.5214 (o)

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.
> --n
> 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
>     block
>     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
>     took
>     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
>     block
>     >> 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
>     'ready=0'
>     > 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>
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160302/8ff8a951/attachment-0002.html>

More information about the USRP-users mailing list