[USRP-users] VHDL and RFNoC

Matt Ettus matt at ettus.com
Mon Dec 29 13:41:39 EST 2014

On Sun, Dec 28, 2014 at 12:21 PM, Eddie Carle via USRP-users <
usrp-users at lists.ettus.com> wrote:

> So after feedback from both Ian and Martin and some further reading I've
> decided that my best course of action for a project I'm involved in is
> the new RFNoC system. To recap, I've got a QPSK encoder written in VHDL
> that takes a clocked sequence of symbols (std_ulogic_vector(1 downto 0))
> and outputs a sequence of symbols clocked at a a slightly higher rate
> (redundant data has been added).
> From what I can tell, I need to use the the NoC shell to wrap up my
> encoder VHDL module. I've been looking through the Verilog examples in
> the Git repository but am unfortunately not as familiar with Verilog as
> I am with VHDL. I supposed my questions are simply the following:
>       * Are there any working examples of a computational engine written
>         in VHDL? Along with it's use of the NoC shell?

We don't have any VHDL examples in there right now, but will likely have
one or two coming.  One of the [few] nice things about the Xilinx tools is
that they let you mix the languages very easily, so you just need to get
the port connections right.  I would look at one of the noc_block_xxx.v
files and connect in a similar way.

>       * Any examples of simply taking a serial sequence (of say samples)
>         and converting to/from these packets that are required? Or is
>         this what the NoC shell accomplishes.

The noc_shell block handles the interaction with the rest of the system, so
mostly it takes care of buffering and flow control.  The chdr_framer and
chdr_deframer (which are usually inside the axi_wrapper) are the blocks
which convert from/to encapsulated packets to/from streams of data items.
This way you usually don't need to have your code even understand the
packet framing.

      * Or is the end result of the (de)packetization simply a hunk of
>         data that I can do with as I please?

Yes.  You basically get a stream of data items which end of packet
markings.  All of the examples we've provided so far use 32-bit data types
(usually 16-bit I and 16-bit Q pairs), but there is no reason you can't use
something else.  32-bits is very convenient, though.

>       * Can I get the gnuradio build to send symbols instead of samples?
>         In this case it would ultimately just be a two bit integer.

I'm not sure what you mean here.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141229/c36c9c3a/attachment-0002.html>

More information about the USRP-users mailing list