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
