One more thought. If the FPGA version that you built with dynamic linking,
you should be able to create an RFNoC Graph as follows:
tx_streamer => multiDDC => rx_streamer(s)
This way you can eliminate the radio from the equation and test in a very
similar fashion to the way it is tested in a testbench.
Rob
On Mon, Sep 12, 2022 at 6:33 PM Rob Kossler <rkoss...@nd.edu> wrote:
> Oops. Ignore what I said. I now realize you stated you were getting an
> Overflow which of course you would never get if streaming hadn't started.
> Rob
>
> On Mon, Sep 12, 2022 at 6:32 PM Rob Kossler <rkoss...@nd.edu> wrote:
>
>> Are you sure that the radio is even streaming? The typical method for
>> starting streaming is to tell the rx_streamer to start streaming. Then, in
>> UHD-land, the rx_streamer ctrl tells the next upstring block to start
>> streaming such that this streaming command propagates up the chain until
>> the radio receives it and starts streaming. So, if your custom block does
>> not forward the streaming command from the rx_streamer to the radio, then
>> the radio never even starts streaming. You can verify by simply monitoring
>> the LEDs.
>>
>> If this is the problem, you can go-around the intended use by simply
>> telling the radio to start streaming rather than the rx_streamer. Or, of
>> course, you can modify your custom block controller to propagate the
>> streaming command.
>> Rob
>>
>> On Mon, Sep 12, 2022 at 4:18 PM Kevin Williams <zs1...@gmail.com> wrote:
>>
>>> Yes, of course. But I don't get 1 sample from the ddc's, even with just
>>> one channel of a 2:1 decimated channel connected to the rx streamer.
>>>
>>> On Mon, 12 Sept 2022 at 22:13, Jonathon Pendlum <
>>> jonathon.pend...@ettus.com> wrote:
>>>
>>>> The aggregate output rate of the 5 streams could require more bandwidth
>>>> than the 10 GigE interface can sustain. What are the exact output rates?
>>>>
>>>> On Mon, Sep 12, 2022 at 3:53 PM Kevin Williams <zs1...@gmail.com>
>>>> wrote:
>>>>
>>>>> Those rates vary from a 2:1 decimation down to other rates.
>>>>>
>>>>> The host has 10 Gbe interfaces to the USRP.
>>>>>
>>>>> I get samples if i connect the radio to the rx streamer, just nothing
>>>>> from the ddc's.
>>>>>
>>>>> On Mon, 12 Sept 2022 at 21:48, Jonathon Pendlum <
>>>>> jonathon.pend...@ettus.com> wrote:
>>>>>
>>>>>> Hi Kevin,
>>>>>>
>>>>>> What are the sample rates for the 5 outputs? What connection are you
>>>>>> using to your host PC, 1 GigE or 10 GigE?
>>>>>>
>>>>>> Jonathon
>>>>>>
>>>>>> On Mon, Sep 12, 2022 at 3:38 PM Kevin Williams <zs1...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Jonathon,
>>>>>>>
>>>>>>> I've got an x310. The flowgraph is a simple radio->multiddc->(to 5x
>>>>>>> outputs). I've tried both static and dynamic routing from the radio
>>>>>>> block.
>>>>>>> I.e. the static route version:
>>>>>>>
>>>>>>> | /
>>>>>>> | | Static connections on this device:
>>>>>>> | |
>>>>>>> | | * 0/Radio#0:0==>0/multiddc#0:0
>>>>>>> | | * 0/multiddc#0:0==>0/SEP#2:0
>>>>>>> | | * 0/multiddc#0:1==>0/SEP#3:0
>>>>>>> | | * 0/multiddc#0:2==>0/SEP#4:0
>>>>>>> | | * 0/multiddc#0:3==>0/SEP#5:0
>>>>>>> | | * 0/multiddc#0:4==>0/SEP#6:0
>>>>>>>
>>>>>>>
>>>>>>> On the input side it is all at the radio rate, but I hope my core is
>>>>>>> being clocked at 214 MHz.
>>>>>>>
>>>>>>> When I simulate my IP core (which includes the AXI streaming
>>>>>>> interfaces) it looks ok.
>>>>>>>
>>>>>>> Regards, Kevin
>>>>>>>
>>>>>>> On Mon, 12 Sept 2022 at 21:29, Jonathon Pendlum <
>>>>>>> jonathon.pend...@ettus.com> wrote:
>>>>>>>
>>>>>>>> Hello Kevin,
>>>>>>>>
>>>>>>>> What device are you using and what does your flowgraph look like?
>>>>>>>> What sample rate are you running at? If your block is running at the
>>>>>>>> radio
>>>>>>>> sample rate (e.g. 200 MSPS on a X310), your block will need to process
>>>>>>>> one
>>>>>>>> input sample every clock cycle on average.
>>>>>>>>
>>>>>>>> Jonathon
>>>>>>>>
>>>>>>>> On Mon, Sep 12, 2022 at 9:09 AM Kevin Williams <zs1...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> I've got an IP core that is causing an "ERROR_CODE_OVERFLOW" when
>>>>>>>>> used in an RFNoC project.
>>>>>>>>>
>>>>>>>>> The core responds correctly when simulated outside the RFNoC
>>>>>>>>> environment. (I can see correct output, the AXI streaming signalling,
>>>>>>>>> back-pressure when required, etc.)
>>>>>>>>>
>>>>>>>>> I'm not sure how to go about debugging this, and am not yet
>>>>>>>>> familiar enough with RFNoC to know what to ask.
>>>>>>>>>
>>>>>>>>> I have been thinking it was the core not being reset or clocked
>>>>>>>>> correctly, but this is how it gets instantiated:
>>>>>>>>>
>>>>>>>>> multiddc multiddc_i (
>>>>>>>>> // - Using different clocks for the IP core and the AXI
>>>>>>>>> interface. The IPCore_Clk and AXILite_ACLK must be
>>>>>>>>> // synchronous and connected to the same clock source. The
>>>>>>>>> IPCore_RESETN and AXILite_ARESETN must be
>>>>>>>>> // connected to the same reset source. See Synchronization
>>>>>>>>> of Global Reset Signal to IP Core Clock Domain.
>>>>>>>>> .IPCORE_CLK (axis_data_clk),
>>>>>>>>> .IPCORE_RESETN (~axis_data_rst),
>>>>>>>>>
>>>>>>>>> .AXI4_Lite_ACLK (axis_data_clk),
>>>>>>>>> .AXI4_Lite_ARESETN (~axis_data_rst),
>>>>>>>>>
>>>>>>>>> The core YAML file describes the clock as:
>>>>>>>>>
>>>>>>>>> data:
>>>>>>>>> fpga_iface: axis_chdr
>>>>>>>>> clk_domain: ce
>>>>>>>>>
>>>>>>>>> In the project YAML file:
>>>>>>>>>
>>>>>>>>> clk_domains:
>>>>>>>>> - { srcblk: _device_, srcport: radio, dstblk: radio0,
>>>>>>>>> dstport: radio }
>>>>>>>>> - { srcblk: _device_, srcport: ce, dstblk: multiddc0,
>>>>>>>>> dstport: ce }
>>>>>>>>>
>>>>>>>>> Is there something that might be an obvious first place to check?
>>>>>>>>>
>>>>>>>>> Many thanks, Kevin
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Kevin Williams
>>>>>>>>> _______________________________________________
>>>>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>>>>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Kevin Williams
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Kevin Williams
>>>>>
>>>>
>>>
>>> --
>>> Kevin Williams
>>> _______________________________________________
>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>
>>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
