Dan Halperin wrote: >> In terms of software radio, reprogramming an FPGA with a different >> bitfile is no different than changing a flowgraph, in my opinion. The >> only thing really hard in the chain is the RF front end for grabbing >> the signals. It's all "software" from that point on. > > Agreed!
Agree as well. While it is definitely (much) more work, hacking the USRP FPGA code provides access to much wider swaths of spectrum on RX and TX. >> In all honesty, I wouldn't mind if the FPGA were more flexible at >> compile time and less flexible at runtime. I feel this would trim >> away some of the "fat" associated with being so flexible at runtime, >> and allow for better use of the USRP's FPGA for more low latency >> processing. > > In order for SDRs that think of their FPGA code as software (which I > think has to be where this is going to realize its full power), it seems > likely that we will need completely automated and reasonably fast ways > to rebuild the FPGA on the fly. Do these exist? I've done a few commercial contracts for custom FPGA code for the USRP. One thing that's needed is a refactoring of the top-level code to allow drop-in replacement of the "standard" functionality with a custom module, while reusing all the peripheral logic, FIFOs, USB interface, etc. Right now, however, the top level is completely separated into transmit and receive paths which are independently configured, reset, etc. This is normally the case with host-based apps that can handle any transmit-receive interdependencies in host code. Without breaking this model, then, it would be easy to refactor into a 'receive_app.v' and 'transmit_app.v' that would have a port list for the "inside API" from the ADCs to the RX fifo and from the TX fifo to the DAC. Then, if you only had a receive_app.v, there could be a stub transmit_app.v that would ultimately result in all the transmit side logic being pruned out during synthesis. But some FPGA applications (like gr-radar) don't really separate RX and TX functionality. I suppose you could still join these together underneath your custom transmit and receive app modules with some glue between them. Re-synthesizing the FPGA code is pretty simple with the Altera tools. Unfortunately, these are Windows only. Someone had some luck with running these under Wine in Linux, but that's probably a pretty fragile hack. USRP2 uses a Xilinx part with their native Linux ISE port, and the development build uses a Makefile to invoke the CLI tools. So in that environment, automating rebuilds for custom changes wouldn't be too difficult. _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
