Hi Rob, thanks for that testbench advice.
My core will not provide output if it does not see TREADY on its master
interfaces. (Which I have verified by simulating the core on its own.)
I have used the rfnoc-example testbench for reference, and issue a
"blk_ctrl.send_items(0, send_samples)".
Monitoring the rfnoc signal "m_rfnoc_chdr_tready" in the testbench shows
that it never transitions from zero's at the beginning of the simulation.
Should I see the BFM slave asserting these signals? (I cannot drive them
from my testbench - I get a warning about multiple drivers.)
On Tue, 13 Sept 2022 at 15:49, Rob Kossler <rkoss...@nd.edu> wrote:
> Have you tried to run an rfnoc-style testbench such as in the
> rfnoc-example? If not, this may be useful. If you try this, it may be
> easier to follow the example if you change your output number of ports to
> be 1 so that it is a simple 1-to-1 block.
> Rob
>
> On Tue, Sep 13, 2022 at 6:36 AM Kevin Williams <zs1...@gmail.com> wrote:
>
>> Hi Rob,
>>
>> I can confirm the radio streams correctly.
>>
>> I have also tried tx_streamer => multiDDC => rx_streamer which
>> successfully sends a number of samples, but none are received. (The script
>> is below.)
>>
>> Just to summarize, the IP core seems to be behaving correctly when
>> simulated in Vivado where I apply AXI handshaking, reset the core, and
>> clock it.
>>
>> I have set all endpoints in the design as follows:
>>
>> ep0: # Stream endpoint name
>> ctrl: True # Endpoint passes control traffic
>> data: True # Endpoint passes data traffic
>> buff_size: 32768 # Ingress buffer size for data
>>
>> Regards, Kevin
>>
>>
>> graph = uhd.rfnoc.RfnocGraph("type=x300,addr=192.168.30.2")
>>
>> tx_streamer = graph.create_tx_streamer(1, uhd.usrp.StreamArgs("sc16",
>> "sc16"))
>> rx_streamer = graph.create_rx_streamer(1, uhd.usrp.StreamArgs("sc16",
>> "sc16"))
>>
>> gb = graph.get_block("0/multiddc#0")
>> graph.connect(tx_streamer, 0, gb.get_unique_id(), 0)
>> graph.connect(gb.get_unique_id(), 0, rx_streamer, 0)
>> graph.commit()
>>
>> num_samps = 4 * tx_streamer.get_max_num_samps()
>> send_samps = np.array([[0x40004000] * num_samps], dtype="int32")
>>
>> tx_md = uhd.types.TXMetadata()
>> tx_md.start_of_burst = True
>> tx_md.end_of_burst = True
>>
>> recv_samps = np.zeros((1, num_samps), dtype="int32")
>>
>> rx_md = uhd.types.RXMetadata()
>>
>> num_sent = tx_streamer.send(send_samps, uhd.types.TXMetadata())
>> num_recv = rx_streamer.recv(recv_samps, rx_md, 0.1)
>>
>>
>> On Tue, 13 Sept 2022 at 00:36, Rob Kossler <rkoss...@nd.edu> wrote:
>>
>>> 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
>>>>>>
>>>>>
>>
>> --
>> 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
