Ramarao V Posted July 1, 2020 Report Share Posted July 1, 2020 Hii Quote Link to comment Share on other sites More sharing options...
Eyck Posted July 1, 2020 Report Share Posted July 1, 2020 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. Quote Link to comment Share on other sites More sharing options...
David Black Posted July 1, 2020 Report Share Posted July 1, 2020 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. Quote Link to comment Share on other sites More sharing options...
cnsujeer Posted December 31, 2021 Report Share Posted December 31, 2021 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) Quote Link to comment Share on other sites More sharing options...
Eyck Posted December 31, 2021 Report Share Posted December 31, 2021 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. No. The bus has to transfer data_length/(BUSWIDTH/8) beats of data. streaming_width only tells the target how to interpret the data. 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* David Black 1 Quote Link to comment Share on other sites More sharing options...
cnsujeer Posted December 31, 2021 Report Share Posted December 31, 2021 Hi Eyck, That clarifies my doubt. Really appreciate the quick response from your side. 🙂 Regards, Chethan Quote Link to comment Share on other sites More sharing options...
niboaix Posted August 10, 2023 Report Share Posted August 10, 2023 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 ? Quote Link to comment Share on other sites More sharing options...
David Black Posted August 29, 2023 Report Share Posted August 29, 2023 Yes, that is what it is supposed to do. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.