UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor hyphen
Visitor
454 Views
Registered: ‎07-03-2018

should tvalid de-assert after tlast is asserted?

Jump to solution

Hi everyone, 

Considering an 'axi stream fifo' is connecting to an s2mm of axi dma, should the tvalid de-assert after tlast is asserted? 

 

====================================

here is the reason caused the problem in my design and temporary solution.  

thanks, everyone's valuable discussion. 

I check the customized IP I used. the block design was like this:

 customer IP(data port) ->   (S)axi stream fifo(M)  -> (s2mm)axi_dma ....

However, the port of the 'customer IP(data port) ' is sort of a slave port, which is always detecting an input then put data on bus and assert tvalid.  

So, that why my dma read always halts somehow. As discussed in this thread, a slave to slave of axi_stream_fifo will never work. 

Now, my solution is to inserting another logic between two slaves and keep previous 'tvalid' and data bus. 

- check fifo occupation link:   customer IP(data port) <- [ extera logic (if not full)]  <- (S)axi stream fifo(M) 

- tvalid and data link:             customer IP(data port) -> (S)axi stream fifo(M) 

The [ extera logic] detect the fifo_occupation of the 'axi stream fifo' and assert a 'not full' to the  'customer IP(data port) '. 

Now, the dma reads smoothly.  

 

 

0 Kudos
1 Solution

Accepted Solutions
Scholar richardhead
Scholar
379 Views
Registered: ‎08-01-2012

Re: should tvalid de-assert after tlast is asserted?

Jump to solution

@drjohnsmith 

"is that correct or a typo ?"

Correct. You are allowed to reflect tvalid back via tready, but not the other way, to prevent deadlocks. Its in the AXI spec

AXI4-stream spec, 2.2.1:

"A master is not permitted to wait until TREADY is asserted before asserting TVALID. Once
TVALID is asserted it must remain asserted until the handshake occurs.
A slave is permitted to wait for TVALID to be asserted before asserting the corresponding
TREADY."

 

This is true of all ready/valid handshaking across AXI, not just streaming (each channel in AXI4 is effectively the same as an axi-stream interface)

10 Replies
Scholar drjohnsmith
Scholar
446 Views
Registered: ‎07-09-2009

Re: should tvalid de-assert after tlast is asserted?

Jump to solution
https://www.xilinx.com/support/documentation/ip_documentation/axis_interconnect/v1_1/pg035_axis_interconnect.pdf Tvalid from the master indicates that the master is driving valid data . Tlast from the master shows this is the last data of the 'block'. So I'd say that if data is valid, then Tvalid is true, no matter what the state of Tlast. But, look at the doc for the fifo your using.....
Visitor hyphen
Visitor
439 Views
Registered: ‎07-03-2018

Re: should tvalid de-assert after tlast is asserted?

Jump to solution

Thanks for the reply. 

The reason of my question is that I customized an axi-stream-master to feed data to s2mm, tlast desserts every N transfers but DMA reading in SDK still halt somehow. So, I am trying looking for the bugs. 

Now, the implementation is that tvalid desserts when tready from s2mm desserts then every 32 tlast assert. 

The ali waveform shows: tlast works and does assert every 32, but the tready from s2mm never de-asserts so that my tvalid never de-asserts either. Is this normal?

 

0 Kudos
Scholar richardhead
Scholar
425 Views
Registered: ‎08-01-2012

Re: should tvalid de-assert after tlast is asserted?

Jump to solution

tvalid indicates that there is valid data (which covers tdata, tid, tlast etc). There is no requirement for it to drop after tlast. Tlast indicates the end of one packet. To force back-pressure, you de-assert tready. It is actually illegal to de-assert tvalid once it has been asserted without tready being asserted.

Its also illegal to tie tvalid to tready, but tready is allowed to be tied to tvalid.

Why not post some code or a waveform?

Visitor hyphen
Visitor
417 Views
Registered: ‎07-03-2018

Re: should tvalid de-assert after tlast is asserted?

Jump to solution

thanks. will post the sch, codes and waveform once I get the board and run it again. 

0 Kudos
Scholar drjohnsmith
Scholar
398 Views
Registered: ‎07-09-2009

Re: should tvalid de-assert after tlast is asserted?

Jump to solution
"its also illegal to tie tvalid to tready, but tready is allowed to be tied to tvalid"

is that correct or a typo ?
0 Kudos
Scholar drjohnsmith
Scholar
398 Views
Registered: ‎07-09-2009

Re: should tvalid de-assert after tlast is asserted?

Jump to solution
whats the simulation say ?
0 Kudos
Scholar richardhead
Scholar
380 Views
Registered: ‎08-01-2012

Re: should tvalid de-assert after tlast is asserted?

Jump to solution

@drjohnsmith 

"is that correct or a typo ?"

Correct. You are allowed to reflect tvalid back via tready, but not the other way, to prevent deadlocks. Its in the AXI spec

AXI4-stream spec, 2.2.1:

"A master is not permitted to wait until TREADY is asserted before asserting TVALID. Once
TVALID is asserted it must remain asserted until the handshake occurs.
A slave is permitted to wait for TVALID to be asserted before asserting the corresponding
TREADY."

 

This is true of all ready/valid handshaking across AXI, not just streaming (each channel in AXI4 is effectively the same as an axi-stream interface)

Explorer
Explorer
370 Views
Registered: ‎03-31-2016

Re: should tvalid de-assert after tlast is asserted?

Jump to solution

You should also be aware that a combinatorial implementation of looping TVALID to TREADY is not allowed.

I only have version 1.0 of the streaming spec but it says 2.7.1 Clocks "...All output signal changes must occur after the rising edge of ACLK."

The normal AXI spec is a bit clearer "there must be no combinatorial paths between input and output signals."

 

Basically once you start driving a VALID, it and the associated data signals cannot change unless accepted as indicated by the associated READY being asserted.  If READY de-asserts you should leave everything as it is including the in block and total blocks counters.

Scholar drjohnsmith
Scholar
321 Views
Registered: ‎07-09-2009

Re: should tvalid de-assert after tlast is asserted?

Jump to solution
Ok, yes agree with that

it was just the words you typed, seem to say that the signlas were bi directional, which they are not..

""its also illegal to tie tvalid to tready, but tready is allowed to be tied to tvalid""
0 Kudos
Visitor hyphen
Visitor
306 Views
Registered: ‎07-03-2018

Re: should tvalid de-assert after tlast is asserted?

Jump to solution

thanks, everyone's valuable discussion. 

I check the customized IP I used. actually, the block design was like this:

 customer IP(data port) ->   (S)axi stream fifo(M)  -> (s2mm)axi_dma ....

However, the port of the 'customer IP(data port) ' is sort of a slave port, which is always detecting an input then put data on bus and assert tvalid.  

So, that why my dma read always halts somehow. As discussed in this thread, a slave to slave of axi_stream_fifo will never work. 

Now, my solution is to inserting another logic between two slaves and keep previous 'tvalid' and data bus. 

- check fifo occupation link:   customer IP(data port) <- [ extera logic (if not full)]  <- (S)axi stream fifo(M) 

- tvalid and data link:             customer IP(data port) -> (S)axi stream fifo(M) 

The [ extera logic] detect the fifo_occupation of the 'axi stream fifo' and assert a 'not full' to the  'customer IP(data port) '. 

Now, the dma reads smoothly.  

 

0 Kudos