discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Encoder Integration


From: Johnathan Corgan
Subject: Re: [Discuss-gnuradio] Encoder Integration
Date: Mon, 29 Oct 2007 11:15:44 -0700
User-agent: Thunderbird 2.0.0.6 (X11/20071022)

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
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]