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