[USRP-users] VHDL and RFNoC
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
* 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...
More information about the USRP-users