What is the difference between set_data_length() and set_streaming_width() in tlm_generic_payload

[Ramarao V]

Hii

[Eyck]

You may check section 14.12 Data length attribute and '14.15 Streaming width attribute' in the LRM.

The first says:

Quote

For a read command or a write command, the target shall interpret the data length attribute as the number of bytes to be copied to or from the data array, inclusive of any bytes disabled by the byte enable attribute.

while the second states in paragraph 😄

Quote

Streaming affects the way a component should interpret the data array. A stream consists of a sequence of data transfers occurring on successive notional beats, each beat having the same start address as given by the generic payload address attribute. The streaming width attribute shall determine the width of the stream, that is, the number of bytes transferred on each beat. In other words, streaming affects the local address associated with each byte in the data array. In all other respects, the organization of the data array is unaffected by streaming.

 

[David Black]

For ordinary memory transfers, you want the data length equal to the streaming width.

For FIFO-like transfers, you would set the streaming width to the width of the FIFO, which will be less than the data length.

Having a streaming length greater than the data length is somewhat pointless; however, it you don't want to think about it, using a value of UNINT_MAX (#include <climits>) is a great way of ensuring that streaming won't mess up the transaction.

The default constructed value of streaming width is zero and illegal.

[cnsujeer]

On 7/1/2020 at 1:26 PM, Eyck said:

You may check section 14.12 Data length attribute and '14.15 Streaming width attribute' in the LRM.

The first says:

while the second states in paragraph 😄

 

Hi Eyck, David, 
     Thanks for the details.. Just to make sure I have understood it in the correct way, I would like to put forward my understanding. 
     

################################################################

For a 256B read transaction with 32B beat would roughly look like below (ignoring byte enable stuff.. ) : 

::b_transport(payload, delay) {

   data_length = payload.get_data_length()

   streaming_width= payload.get_streaming_width()

   for(marker = <start_index_of_memory_for_the_burst> ; marker < data_length ; marker += streaming_width) {

        memcpy(&(target_memory[marker]), &(data[marker]), streaming_width);

        delay += <delay consumed for the beat>; 

   }  

}

Is this correct ?
########################################################################
 
2) Is there a relation between streaming width & BUSWIDTH from transaction perspective ?
3) What are the things to be considered when streaming_width > BUSWIDTH ?
     Is it that only time consumed for handling the beat need to be appropriately set ? i.e. delay_per_beat = streaming_width / BUSWIDTH + 1(cycles)

[Eyck]

1. No. In your memcpy you would not change the target address. So &(data[marker]) would become data. Basically the payload data contains N blocks of size streaming_width all to be written to the same address given by the payload address.
2. No. The bus has to transfer data_length/(BUSWIDTH/8) beats of data. streaming_width only tells the target how to interpret the data.
3. Since the answer to question 2 is no there is nothing to be considered in relation to streaming_width, only in relation to data_length.

In short streaming_with is an attribute telling the target how to interpret the transferred chunk of bytes. In that it can be seen as an abstraction of AHBs  HBURST setting WRAP*

[cnsujeer]

Hi Eyck,

     That clarifies my doubt. Really appreciate the quick response from your side.  🙂

 

Regards,

Chethan 

 

[niboaix]

On 7/1/2020 at 4:09 AM, David Black said:

For ordinary memory transfers, you want the data length equal to the streaming width.

For FIFO-like transfers, you would set the streaming width to the width of the FIFO, which will be less than the data length.

Having a streaming length greater than the data length is somewhat pointless; however, it you don't want to think about it, using a value of UNINT_MAX (#include <climits>) is a great way of ensuring that streaming won't mess up the transaction.

The default constructed value of streaming width is zero and illegal.

Hi David: if the  streaming width <  the data length, e,g.  data length =16, streaming width =8, then will the data in 2nd beat overwrite the data in the 1st beat because the target will put them at same starting address ?

[David Black]

Yes, that is what it is supposed to do.