Inactive Axi Stream in hardware Zmod 1410, EclypseZ7

[Xband]

Greetings, 

I have a hardware design using the Zmod ADC that runs but the axi streams are "Inactive".  I tried changing the clock source from the Zynq processor, as some previous error suggested an issue but the design seems to work as I get tdata out of the ADC and am able to use DSP on the data but the AXI stream isn't working. 

Any basic Ideas?  I'm using the old 1410 IP, pre scope, no level triggers, just enable acquisition with a digital.  Attached are the block design and the ILA scope screen capture. 

I've searched some Xilinx forums but nothing jumps out, something about "instantiating" that I don't understand.  Perhaps somebody here can help. 

Thanks, 

 

 

design_1.pdf

Edited May 24 by Xband
update

[artvvb]

Hey XBand,

How are you starting the ILA, using Run Trigger Immediate? Setting up a trigger should let you narrow in on only when interesting events are happening, by doing something like triggering on a read address channel tvalid signal being high at the same time as the corresponding tready signal. Pairing ILAs with the Vitis debugger can also be helpful, so that you can manually step through code and precisely control what state the hardware and software are in when you run the ILA. If a trigger set up to trigger on valid and ready for some channel never fires, it means that that stream isn't being used at all.

The screenshot below shows a trigger setup. It's not a meaningful one in this case, just a project I happened to have open, but hopefully helps for seeing the UI. In the trigger setup pane, the plus button adds signals to the trigger. The "And gate" icon shows that everything in the list below must be true for a trigger to occur. In this case, a trigger occurs when the pLockLostRst signal is high, and the dbg_pBitslip bus matches "3" (3'b011). The Settings pane gives a little bit more info - the trigger position in window field specifies where in the chart the trigger condition will be displayed; changing it lets you see more data in front of or behind the trigger condition. The window data depth shows how many clock cycles the ILA is capturing.

4 hours ago, Xband said:

I tried changing the clock source from the Zynq processor, as some previous error suggested an issue but the design seems to work as I get tdata out of the ADC and am able to use DSP on the data but the AXI stream isn't working. 

The ILA should always be driven by the clock associated with the AXI stream interface, and I'd expect to see build errors when that isn't the case.

Thanks,

Arthur

[Xband]

@artvvb, 

I'm triggering omn the data coming from the ADC, perhaps the AXI doesn't have time to get started?

 

[artvvb]

I think "X" for a value in a bus means "don't care", so it will trigger on anything, meaning that run trigger and run trigger immediate are effectively doing the same thing - which is a long way of saying that yes, the channel might not have time to start before data is captured from it. Try something like this, valid and ready are only both high when data is moving:

[Xband]

I'm also running different Vitis Software dShow Replyebugger projects, sometimes to get the ILA to trigger. 

 

[Xband]

@artvvb

I'm still not able to get the AXI stream active.  Have triggers set up as you suggest, and trigger through the software side in Vitis sometimes, it is not consistent to get the tdata output from the ADC that way though.  Also FYI, I'm using the older ADC IP (pre production) version.  I do not want the triggering as set up in the Zmod Scope IP. 

The sawtooth wave form is data accumulator DSP, so data is coming out of the 1410-105, just that the AXI does not initialize. 

Thanks for anything, 

[artvvb]

From what I can see in your block design, the axis_data_fifo_0 IP's S_AXIS interface's handshake signals aren't connected. If valid is tied off to zero, data would not be pushed into the IP. At a minimum, its valid signal should be tied off to 1 (data will always be pushed into the IP), or potentially driven by a delayed (to account for however long it takes to get data into and out of the accumulators) and inverted version of the ZmodADC1410_Controll_0 IP's sInitDone_n signal. If you tie it off to one, and the axis_combiner's S00_AXIS interface's ready bit is high, you should at least see data moving into the combiner...

I'm not familiar with the combiner, but I'd be concerned that it will wait until data is valid on both the input interfaces before it allows data to move through. This would mean it would wait until the AXI controller's trigger has fired to forward data from both it and the accumulators through to the DMA.

There's a checkbox to be able to see pin tie-offs for unconnected pins through the settings gear, the 1, 0, 1 for each of the pins in the screenshot below:

[Xband]

@artvvb,

Thanks, that pdf was a bit stale, I have the fifo S axi going to the axi_dma in the design now, not sure if it makes any difference in what you're suggesting.  

Also have a constant (1) tied to tvalid on the fifo.  

Perhaps the axi_combiner wouldn't be necessary if I were to concat the data stream together before sending it into the fifo, I could eliminate the combiner and its issues. 

Let me know if you think that might help. 

Thanks

[thinkthinkthink]

You manually connected signals from the Stream interface to the combiner and to an ILA which actually makes it so that the connections only go to the ILA instead of both the combiner and the ILA. Check the Critical Warning and normal Warning messages in Vivado. Also check the synthesized design schematic to see how Vivado actually made the connections in your design. 

You can right click on an interface and select DEBUG and then let Vivado manage the instantiation of an ILA ip. The connection should look something like this: 

 

If you really want to manually route signals from an interface you should do it like this:

[Xband]

@thinkthinkthink, 

Thanks for chiming in, with my current level of understanding of Axi stream and such I don't want to do anything "manually" necessarily and am hoping Vivado does things correctly when letting wizards work.  

I'm reading this as I should delete the current ILA setup and try the debug path to let Vivado correctly make the connections?  That is what I'll do next. 

I've already punted the stream combiner so will do a similar process with the stream fifo related signals. 

My interpretation is that by running the tdata signals into the AXI4-Stream Data FIFO that I'm relying on the this IP to properly configure the AXI stream and that these packaged tready, tvalid,tlast will be taken care of within this box.  Let me know how I'm wrong about this philosophy if its bad. 

The below screenshot shows the new ILA generated with debug and connection automation.  I''ll follow up later, hope it works!  I'm happy to learn this option today.

Thanks!!,