> I just don't want to loose all the flexibility of software by moving the
> critical but interesting things to hardware.
> (* But of course, it all depends upon your goals. *)
George (and others),
I think that the above statement is the basic issue here and seems to summarize the issues with offering a 'solution for everyone'; although, offering to do this is still noble sentiment from you, George. I have been using the USRP1 for a few years now, using code based on the old deprecated mblock code (and your code too!) and there have been a few times when I have wondered about whether I needed to crack open the FPGA code or not... and suffer through the re-fitting and then the required timing verification that this would require above and beyond verifying any functional changes I was considering in Verilog.
How about a middle ground to provide the ultimate programmable state machine? Would it be feasible, in terms of gate count and IP/GnuPL licensing terms, to include a small processor core in the FPGA and to define a messaging interface to GnuRadio_proper? This could be 8051-like or maybe a GPL 32-bit LEON3 or....
If this processing core code had parallel access to sampled I/Q baseband data in both directions and could be 'programmed' dynamically (maybe supporting two loads in RAM) from the main code and IF (big if) it could 'keep up' well enough with the baseband data to do things like calculate power and/or frame on specific baseband data symbols, make other decisions e.t.c. ....and then buffer to/insert sequences from data in FPGA 'RAM' without substantial further processor involvement, the flexibility required by different people could be managed (and managed by them) as different micro software loads in FPGA RAM.
A real-time messaging mechanism between the two software domains would allow PC-based Gnuradio software to steer the lower-level code at a higher level, if required, and also to read status information from it too. Ideally, this would be a streamed communication mechanism, which piggy-backed on the I/Q samples, allowing samples to be tagged anywhere along the signal processing chain in either direction. This is not required, however. The discussion of applications so far in this thread would seem to be well-served by a pair of registers on the FPGA containing one or two shared-memory boolean flags in each direction.
Probably more than my two cent allotment. / David Knox