Michael,

some comments:

On 08/25/2016 11:19 AM, Michael Wentz via USRP-users wrote:

Did you update NUM_CE? That's what typically causes this.

That's also a possibility. The current workaround that we provide is
that you use a different NOC_ID (DDC0000000000001). There's no
auto-detection of number of ports (yet).

Between old RFNoC and current rfnoc-devel (i.e. after the radio-redo
merge) there was indeed an increase in resource utilization. Jonathon is
currently working on reducing that. However, note that there are a
couple of differences:

• We now include a DRAM FIFO block (always) on top of the radio blocks.
• By default, we now have 2 radios per radio block (so 4 radios total)
  to work with TwinRX. You can reduce utilization further by scaling that
  back to 1 radio per block.
• Having DDCs and DUCs in separate blocks is more resource intensive
  than having them in the radio. So, the sum of new radio + new DSP blocks
  is >> than the old radio.

Cheers,
M

Hi Martin,

I did have NUM_CE set correctly, it ended up being NUM_CHAINS = 1 that was
the problem. Good to know that I can update the NOC ID to get around that
too.

Totally understand that by making things more modular they'll have a larger
footprint - I'll try building with fewer radios and a single DDC/DUC.

I also had a question regarding the axi_rate_change module that is in the
new DDC and DUC. When should someone include that in their design? If I am
dealing with a sample stream (no sensitivities to packetization, EOB,
timing, etc.) is it necessary?

Thanks,
Michael

On Fri, Aug 26, 2016 at 12:45 PM, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:

On 08/26/2016 12:44 PM, Michael Wentz wrote:

No, this module is to facilitate writing blocks that actually change
rates. There is never a requirement to use it, but if you have a block
that takes N input packets for every 1 output packet, this module will
take care of handling the headers etc.

Cheers,
M

Regarding rate changes, are there issues I could have trying to manage that
in my component? For example, if I decimate by 10, the valid out is asserted
once for every 10 valid inputs, and I keep the input/output packet sizes
identical by counting the number of valid outputs and asserting tlast when
the counter reaches 364 (assuming samples from the radio). I've tested
blocks that do this in sim and hardware and they appear to work but now I'm
wondering if there's more to a rate change than I thought?

Thanks,
Michael

On Friday, August 26, 2016, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:

Hi Michael,

Rating changes in RFNoC can be very easy or fairly difficult depending on
what you want.

If you don't care about VITA time or EOB, rate changes are pretty simple.
You need to generate the header s_axis_data_tuser (since you cannot use
SIMPLE_MODE), but generating it is not difficult to do. You can use
cvita_hdr_encoder.v or cvita_hdr_modify.v along with m_axis_data_tuser.

However, most people care about VITA time and others care about EOB. When
you have those fields in a rate change block, there are several corner
cases that make things difficult (for example, what should happen when
decimating by 10 but you receive a packet with only 9 samples?) To make it
easier on the user, I wrote axi_rate_change.v. AXI rate change handles both
the header and the packet sizing for the user. All you have to do is
process the sample data with your algorithm.

Jonathon

On Fri, Aug 26, 2016 at 5:21 PM, Michael Wentz via USRP-users <
usrp-users@lists.ettus.com> wrote:

Jonathon,

Thanks for the feedback, it's clear to me what axi_rate_change.v provides
now. In my components so far I haven't done anything that cares about time
or EOB so I just did something like what's in the old version of the
keep_one_in_n block:

// Output CHDR packet header data, same as input except SRC / DST SID
fields.
assign s_axis_data_tuser =
{m_axis_data_tuser[127:96],m_axis_data_tuser[79:64],next_dst,m_axis_data_tuser[63:0]};

That seems to be working. Interestingly, I had gone without that and used
SIMPLE_MODE in the AXI wrapper, and that also worked, but only in the
receive path (transmit had problems).

-Michael

On Thu, Sep 15, 2016 at 2:10 PM, Jonathon Pendlum <
jonathon.pendlum@ettus.com> wrote:

Hey Michael,

SIMPLE_MODE instantiates a header FIFO in AXI Wrapper to store the headers
for you and it is assumed you produce a packet for every packet consumed in
a 1:1 ratio. If your block does a rate change, then either the header FIFO
will underflow (interpolating block) or overflow (decimating block) because
the FIFO is not being filled / emptied in a 1:1 ratio.

Jonathon

On Thu, Sep 15, 2016 at 8:00 PM, Michael Wentz mchlwntz@gmail.com wrote: