Hi Jason, That actually makes sense to me... Bus clk on the e310 is usually 50 MHz if I remember correctly (and if it didn't change), and the max radio_clk is something like 64ish MHz.
Max clock rates on the x310 are, I believe, more like 200-215 MHz. So logic in the x310 nominally needs to settle within 5 ns while logic on the e310 can have a luxurious 15-20 ns. Xilinx will try very hard to optimize timing and the build for x310 could take a LONG time. If you can access the timing report, it will often show critical paths, but the text report is often unintelligible to me. I have also built in GUI mode before (like setting up a ILA core) because the Vivado interface for organizing and understanding timing failures are actually pretty helpful. I'd also suggest, if you'd like some verilog input, to send the relevant code you think might continue to the timing errors, and we can take a look for ideas? It could potentially lead to a quick solution if you're up for it. A MaxNinM block sounds like it could easily contribute to poor timing depending on the implementation. EJ On Thu, Nov 8, 2018, 8: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
