Hi Jason, The longer run times might be explained by the tool struggling to meet timing. I can't say off the top of my head what's wrong without looking at the timing report. Do you have an updated post_route_timing_summary.rpt file yet? Buried in there it should say exactly what's not meeting timing, which should offer some clues. The source and destination clocks for the failing signal path should be checked to make sure that those are correct and properly constrained, since clock crossings are sometimes the cause of unexpected timing errors.
Wade On Thu, Nov 8, 2018 at 7:11 AM Jason Matusiak via USRP-users < usrp-users@lists.ettus.com> wrote: > OK, this has befuddled me for 3 days and I can't seem to get past it. I > have a prefix that seems to work fine. > > Here are my working steps for building a bitfile on an E310: > cd /opt/gnuradio/e300/src/uhd/fpga-src/usrp3/tools/scripts > > source ../../top/e300/setupenv.sh > > ./uhd_image_builder.py keepMinN ddc split_stream axi_fifo_loopback -d e310 > -t E310_RFNOC_sg3 -I /opt/gnuradio/e300/src/rfnoc-nocblocks > > This build and runs fine. keepMinN is a small custom block I made that > doesn't use much resources and has been working fine for weeks. > > Now, if I open a new terminal and run this: > > cd /opt/gnuradio/e300/src/uhd/fpga-src/usrp3/tools/scripts > source ../../top/x300/setupenv.sh > ./uhd_image_builder.py keepMinN ddc ddc split_stream axi_fifo_loopback -d > x310 -t X310_RFNOC_XG -I /opt/gnuradio/e300/src/rfnoc-nocblocks -m 5 > > it never seems to meet timing. Now, I have done this with and without the > "-m" directive, that doesn't seem to matter. The only real difference in > the command is the second ddc block. > > So what the heck could be causing these issues? If anything, I would have > expected the X310 build to be fine and the E310 to not meet timing. > Another odd thing (though I am chalking it up to the X310 doing more) is > that the X310 build is taking A LOT longer. I don't recall it taking this > long before, but I am not sure. > > It tell me to look at the report_timing_summary, but it hasn't updated yet > (it keeps running for a bit after throwing the timing warning). If I > remember though, I think that the issue it had was with the ce_clk for some > reason. > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
