Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Will unprocessed awvalid signals be stored in AXI Crossbar? #65

Open
omeag opened this issue Jan 23, 2024 · 6 comments
Open

Will unprocessed awvalid signals be stored in AXI Crossbar? #65

omeag opened this issue Jan 23, 2024 · 6 comments

Comments

@omeag
Copy link

omeag commented Jan 23, 2024

Hi, sir
I see that S_THREADS is set to 2 by default, which means that SI can initiate two outstanding transfers.
So will the second awvalid and awaddr signal be stored?
During simulation, I did not keep awvalid high all the time. The results show that it will not process the second write operation.
How does your AXI crossbar handle outstanding transfers?

@alexforencich
Copy link
Owner

Well, you have to respect the handshake protocol. *valid MUST be held high until *ready is asserted. If you don't do that, things break in strange ways.

@omeag
Copy link
Author

omeag commented Jan 24, 2024

So if I set S_THREADS to 3 and initiate three write operations, then I need to keep awvalid high until all three write operations are complete, right?
But the write address signal will be staged? Will the second write address be lost?

@alexforencich
Copy link
Owner

alexforencich commented Jan 24, 2024

I recommend reading the AXI specification.

The short story is this: data is ONLY transferred when BOTH *ready and *valid are asserted at the same time.

This means that if *ready is low, the only thing you can do is set up a new operation (set all of the signals and set *valid = 1). If *valid is already high, you must wait for *ready to be asserted. If you change anything when *valid = 1 and *ready = 0, Bad Things will happen (lost transactions, unpredictable behavior, etc.). Similarly, when both *ready and *valid are asserted, you must either deassert tvalid, or set up a new operation. All of this follows from data being transferred only when both *ready and *valid are asserted at the same time.

The spec also states that you are not allowed to wait for *ready to be asserted before starting a new operation. The sink is allowed to wait for *valid before asserting *ready, but the source is not allowed to do the converse as this could result in a deadlock.

@omeag
Copy link
Author

omeag commented Jan 24, 2024

So what is the role of OUTSTANDING?
As you said, it is necessary to keep awvalid and awaddr until awready is high and a successful handshake is done.
However, the Outstanding function allows the Slave Interface initiate multiple operations while waiting for AWREADY, right?

But if I additionally initiate multiple operations while waiting for AWREADY, I have to keep AWVALID and AWADDR ? So in this way, that means I can only initiate ONE another operation, and keep every signal until AWREADY turns low.

Where did I misunderstand?

@alexforencich
Copy link
Owner

No, it means you can issue multiple AW transactions before they are completed on B.

@omeag
Copy link
Author

omeag commented Jan 24, 2024

I understand completely now. Thank you so much for your explanation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants