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
