Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
17159 Discussions

Unclear interpretation of readyAllowance in Avalon Streaming Interfaces

MBiek
Beginner
1,364 Views

Hello,

 

I have a question about the interpretation of the readyAllowance property in back-pressured Avalon ST interfaces. It would be great if someone could help me out.

 

The Avalon specification defines readyAllowance in Sec. 5.4 as follows:

Defines the number of transfers that the sink can capture after ready is deasserted.

When readyAllowance = 0, the sink cannot accept any transfers after ready is deasserted. If readyAllowance = <n> where <n> is greater than 0, the sink can accept up to <n> transfers after ready is deasserted.

According to my reading, this definition does not require these possible <n> transfers to be consecutive.

For example,  looking at the timing diagram below and assuming readyLatency=2 (According to the specification, if nothing else is specified, readyAllowance will also be 2):

Screenshot 2024-02-17 at 20.04.11.png

  • The first transfer (cycle 0 to 3) should be valid. In fact, Fig. 30 (Sec. 5.9.2) of the specification shows an equivalent transfer.
  • But what about the second one (cycle 5 to 9)? ready is de-asserted in cycle 6 and 2 transfers follow.Is there something in the definitions that does not allow this?

Any help on this would be greatly appreciated; thanks in advance.

Labels (1)
0 Kudos
3 Replies
Wincent_Altera
Employee
1,316 Views

Hi,

 

Thanks for contacting Intel. I'm assigned to support request.

I'll investigate and get back to you soon. Thanks for your patience.

 

Best regards,

Wincent_Intel


0 Kudos
Wincent_Altera
Employee
1,314 Views

Hi Martin,


First under section 5.4 explains the basic property of AVST interface.

You may choose to transfer your data with 5.9.1. Data Transfers Using readyLatency and readyAllowance or 5.9.2. Data Transfers Using readyLatency

The reason why the <n> transfers do not have to be consecutive is to allow for flexibility in the implementation of the Avalon ST interface.

In a system where back pressure is used to control the flow of data, it may be beneficial for the sink to have the ability to accept a burst of data even after indicating that it is not ready to accept more data. This flexibility allows for better utilization of the data path and can improve overall system performance.

By allowing the <n> transfers to be non-consecutive, the Avalon ST interface provides a mechanism for the sink to manage its data reception in a way that best suits its internal processing requirements.


Hope that answer your question.


Regards,

Wei Chuan



Wincent_Altera
Employee
1,277 Views

Hi

 

Thanks for the kudos, I think I had answer your question.

If you have a new question, feel free to open a new thread to get support from Intel experts.

Otherwise, the community users will continue to help you on this thread. Thank you

If your support experience falls below a 9 out of 10, I kindly request the opportunity to rectify it before concluding our interaction. If the issue cannot be resolved, please inform me of the cause so that I can learn from it and strive to enhance the quality of future service experiences. 

 

Regards,

Wincent_Intel

p/s: If any answer from the community or Intel Support is helpful, please feel free to give the best answer or rate 9/10 survey.


0 Kudos
Reply