[USRP-users] VHDL and RFNoC

Marcus Müller marcus.mueller at ettus.com
Tue Dec 30 06:29:42 EST 2014


Hello Eddie,
On 12/30/2014 01:17 AM, Eddie Carle via USRP-users wrote:
> I guess my question is, since GNU radio will now start representing
> data steams not just on the host but also on the FPGA is there a
> method (or plans) to allow for types that are more suitable for the
> FPGA side of things (like bit arrays of an arbitrary length)?
jumping in here: GNU Radio (classical host-side GNU Radio) doesn't care
about what's inside the items you produce or consume in a block's out-
or input, respectively.
Due to GNU Radio running on General Purpose Computers, these items can
only have sizes of multiples of bytes. This means that you can, for
example, pack four of your two-bit symbols into a byte and exchange that
between GNU Radio blocks. However, you will have to find or write blocks
that deal with this kind of items; the usual data type for things like
symbol "numbers" is unsigned chars in GNU Radio. Luckily, there are the
flexible "Packed to Unpacked" and "Unpacked to Packed" blocks that do
exactly the conversion that you'll need.

> Should I wish to communicate a symbol stream back and forth between
> the host and the FPGA I could represent said symbols as 8 bit integers
> but that would be quite a waste of throughput.
That kind of depends. Usually I'd say: As long as the symbol rate easily
passes through the link between host and X3x0 as a unpacked string of
bytes, do that.
I say that because arithmetics with these symbols will -in the general
case- require the symbols to be in individual CPU registers, thus
implying a unpacking overhead for the host CPU, which might not be much
smaller than the IO overhead due to the higher bandwidth, and also the
ease of handling might well be worth the CPU load. However, if your
intent is to primarily store the samples, or process the items simply as
"data", sending them over packed will be a nice choice.

Best regards,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141230/6f441368/attachment-0002.html>


More information about the USRP-users mailing list