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
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
