[USRP-users] timing issues with RFNoC block

Jason Matusiak jason at gardettoengineering.com
Wed Mar 2 10:43:37 EST 2016


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





More information about the USRP-users mailing list