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

Why is tready signal from output_queues.v is set to always 1? #4

Open
Horacehxw opened this issue Sep 26, 2022 · 1 comment
Open

Why is tready signal from output_queues.v is set to always 1? #4

Horacehxw opened this issue Sep 26, 2022 · 1 comment

Comments

@Horacehxw
Copy link

hw\lib\std\output_queues_v1_0_0\hdl\output_queues.v, line 411.

The tready signal is set to always 1, is there any reason not to set it according to fifo status?

If I want the tready signal to be 0 when the fifo is full like the following snippet, will the logic be valid?

assign s_axis_tready = ~|((nearly_full | metadata_nearly_full) & oq);

@aomtoku
Copy link
Contributor

aomtoku commented Aug 26, 2023

Hi @Horacehxw , I am really sorry for my late response.

Our architecture takes basic network datapath - aggregating all of interfaces to single datapath, and disaggregating packets to ports. When one of ports is congested then, all traffic has to be stopped here if the logic is valid.
So, currently, output queue module always accept packet from the behind module (output port look module).
And, If output queue module cannot handle the packet, the packet will go to the DROP state to be discarded, so I think this logic should work for switch and router cases. If you find any corner cases, please let me know.

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