> 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
--
View this message in context:
http://old.nabble.com/building-carrier-sense-in-the-FPGA-and-UHD-tp33436450p33443808.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
