Brian,
FYI, soft versions of the Viterbi decoder (named soft-input/soft-output
blocks) are already implemented in gr-trellis.
In addition a serially concatenated code, and corresponding turbo
decoder is implemented using these blocks in the corresponding
examples directory.
Achilleas
PS: I have mixed feelings about all this being implemented on the FPGA:
is this a software or a hardware radio?
On 10/29/07, Achilleas A. [email protected] wrote:
Brian,
FYI, soft versions of the Viterbi decoder (named soft-input/soft-output
blocks) are already implemented in gr-trellis.
In addition a serially concatenated code, and corresponding turbo
decoder is implemented using these blocks in the corresponding
examples directory.
Very nice. Thanks for pointing that out!
Achilleas
PS: I have mixed feelings about all this being implemented on the FPGA:
is this a software or a hardware radio?
In terms of GNURadio, I can agree with the mixed feelings. I feel
that GNURadio is a good framework to explore the spectrum and radio
communications systems.
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.
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.
Brian
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian P. wrote:
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!
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?
iD8DBQFHJhu2y9GYuuMoUJ4RApLhAKC2gVlZYHQeANpbQKTPyr9HfzE6bgCfa7Qd
Zc1C/VJSOgL08B4r/VIrW1Q=
=dQRO
-----END PGP SIGNATURE-----
Dan H. 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 C.
Corgan Enterprises LLC
http://corganenterprises.com
Brian P. wrote:
put into a state of lockdown while being reprogrammed, and a reset can
be applied to the guts once reprogrammed.
Not sure if USRP2 FPGA supports this or not. Not a bad idea to floor
plan, get timing right, and lock down the non-DSP parts, and let the
user create an inner application with abstract ports. But I’d be happy
with a compile-time logically equivalent code organization. I think
Matt’s already planning for it.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com
On 10/29/07, Dan H. [email protected] wrote:
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?
Rebuilding an entire FPGA image on the fly isn’t in the cards just
yet, though some high end Xilinx FPGAs do support “partial
reconfigurability” which will allow a design to have a standardized IO
interface and all the “guts” are reprogrammed without powering down
the device.
This could allow, in theory, one “IO ring” to be made for the USRP and
the user would fill in the “guts” with their signal processing
application (eg: wideband TDMA, CDMA, narrowband FSK, etc). As long
as each of the guts had the same hooks to the outside, the FPGA can be
put into a state of lockdown while being reprogrammed, and a reset can
be applied to the guts once reprogrammed.
The reprogramming time is on the order of milliseconds to hundreds of
milliseconds I believe, but I could be mistaken.
More information with regards to the Xilinx specific implementation
can be found here:
http://www.xilinx.com/products/design_tools/logic_design/advanced/partialreconfig.htm
Brian
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs