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

axi_dw_downsizer: Fix i_forward_b_beats_queue underflow #323

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

colluca
Copy link
Contributor

@colluca colluca commented Oct 3, 2023

The forward_b_beat_push signal should be asserted every time the last W handshake in a burst occurs on the master port. However, pushing to the FIFO should also be conditional on forward_b_beat_full not being asserted.

The way this second condition was ensured allowed the W handshake to occur, without tracking it through a push to the queue. The corresponding B handshake would then trigger a pop, causing an underflow in the FIFO counter.

This PR corrects this behaviour, by stalling the W handshake until the FIFO is no longer full, so it is ensured that pushing to the FIFO is possible.

  • Revert first commit after review and wait for CI to pass (see comment below)

@colluca colluca marked this pull request as ready for review October 3, 2023 11:18
@colluca
Copy link
Contributor Author

colluca commented Oct 11, 2023

The first commit modifies the testbench to replicate the error originally found in Occamy.

You can see from the Gitlab CI that the first commit fails with a Fatal: Trying to pop data although the FIFO is empty error. The second corrects this behaviour (CI times out because I incremented the number of tests, but the tests are passing).

I would revert the first commit and then I believe this should be ready to merge. If the MIN_WAIT_CYCLES and MAX_WAIT_CYCLES parameters could be changed at run time then we could keep some tests also in the modified conditions, but this should probably be addressed in a separate PR anyways.

@micprog
Copy link
Member

micprog commented Feb 16, 2024

I think it would be valuable to ensure this corner case is triggered in the future to prevent this fix from being removed, so it would be great if we could figure out a way to keep this task triggering the error as part of the CI. Could we trigger this with a few individual transactions?
Other than this, I did not look at the details yet and am not super familiar with the module, but I will look through it properly.

@colluca
Copy link
Contributor Author

colluca commented Feb 16, 2024

Thanks Michael :)

It's been a long time so I have to familiarize myself with this again, but I'll look into options to keep it triggered. Probably have some notes in an old WR, but I remember it not being trivial. I'll let you know ASAP.

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

Successfully merging this pull request may close these issues.

None yet

2 participants