Hi Everyone,
I've got the i/o to registers in my core working - so the various layers of
logic from testbench through the rfnoc wrapper, control channel, my core,
and back, appear fine.
However, moving back to the chdr channel ("client interface" as per the
module created by rfnocmodtool) I see t
Hi Guys,
No solution yet, so to summarize:
My IP core generates TVALID's after a reset.
These TVALID's are seen in the "client interface" of the RFNoC wrapper.
They are not propagated to the master interface of the "framework
interface"?
The IP core gets the correct input data after a "send_it
Hi Kevin,
To expand on Brian's and Rob's comments, one issue that often comes up is
user logic bugs related to AXI stream's tvalid / tready signaling. The
user's logic will pass their test bench but behave strangely or lock up
when running on hardware. I've found that before running on hardware, y
Hi Kevin,
If you run the rfnoc-example gain testbench, it should demonstrate that the
testbench is providing a suitable environment for testing your custom logic
or core. Maybe see what is different between that and your testbench.
If the problem turns out to be related to the "waiting for TREADY
On Wed, Sep 14, 2022 at 1:55 PM Kevin Williams wrote:
> Thanks Brian. I think the core gets generated in a way which respects
> back-pressure, so unless a TREADY is seen the core does not generate output
> samples. I have observed this by simulating the core in isolation.
>
On 14 Sep 2022, 17:49
Thanks Brian. I think the core gets generated in a way which respects
back-pressure, so unless a TREADY is seen the core does not generate output
samples. I have observed this by simulating the core in isolation.
On 14 Sep 2022, 17:49 +0200, Brian Padalino , wrote:
> I believe the AXI spec says t
I believe the AXI spec says that data should be presented when valid, and
the tready signal just accepts that data. You can't rely on tready to be
asserted before asserting tvalid.
With that being said, I have no idea if this is the source of any of your
issues.
Brian
On Wed, Sep 14, 2022 at 11
Hi, I don't seem to be able to get TREADY's asserted for my core in a
testbench. (See the "X's" in the testbench below. The symptom is that
the "recv_items" blocks until the test times out.)
Without that check the "send_items" call is fine, and I can see the
transaction progressing on that int
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)".
Moni
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 Willia
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 a
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 testb
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 wrote:
> Are you sure that the radio is even streaming? The typical method for
> starting streaming is
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
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
wrote:
> The aggregate output rate of the 5 streams could require more bandwidth
> than the 10 GigE interfa
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 wrote:
> Those rates vary from a 2:1 decimation down to other rates.
>
> The host has 10 Gbe interfaces
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
wrote:
> Hi Kevin,
>
> What are the sample rates for the
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 wrote:
> Hi Jonathon,
>
> I've got an x310. The flowgraph is a simple radio->multiddc->(to 5x
> outputs). I've tried
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
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,
20 matches
Mail list logo
