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

Implementing buffer with axis_fifo or axis_pipeline_fifo #37

Open
keegandent opened this issue Oct 16, 2024 · 2 comments
Open

Implementing buffer with axis_fifo or axis_pipeline_fifo #37

keegandent opened this issue Oct 16, 2024 · 2 comments

Comments

@keegandent
Copy link

keegandent commented Oct 16, 2024

These modules are incredibly useful, but I'm a little unclear as to which of the two makes sense for a buffer. (I think what I want is a skid buffer, but honestly I'm struggling to understand the difference. I need to buffer UART RX because my module sometimes has to transmit more data than it receives, but obviously there's no way to convey backpressure over UART without flow control.) I would have thought that axis_pipeline_fifo would make more sense, but despite the ram_style directives, it still uses tens of thousands of registers for a 4096-byte buffer. I would have thought given the 400Kb distributed memory capacity of the Basys3's chip, it would not have difficulty accommodating a FIFO this deep, but maybe I'm fundamentally misunderstanding the buffer mechanisms here. Considering the number of FIFOs in this repo, could there be some sort of decision tree to help those of us struggling to navigate the code as to which one we need to pull? I could try to help or create a visual for it once I understand.

@keegandent keegandent changed the title Implementing skid buffer with axis_fifo or axis_pipeline_fifo Implementing buffer with axis_fifo or axis_pipeline_fifo Oct 17, 2024
@alexforencich
Copy link
Owner

Skid buffer is axis_register. The point of axis_pipeline_fifo is that it can help with placement and routing for long distance connections - it's a chain of registers followed by a FIFO that's deep enough to handle the pipelined ready/valid handshake. It usually consumes less resources than axis_pipeline_register, which is a chain of back-to-back instances of axis_register. And then axis_fifo is a general-purpose FIFO, with a few optional extra features.

@keegandent
Copy link
Author

And then axis_fifo is a general-purpose FIFO, with a few optional extra features.

So the axis_fifo should be sufficient for buffering data from an axis_uart to avoid dropping characters in the scenario where a later part of the AXIS pipeline is going to take long enough that it might miss the next characters, right? But what exactly does something like the RAM_PIPELINE parameter actually do? I can see that it adds a register pipeline to the output, but what does that actually provide for the module using the FIFO? Same with the OUTPUT_FIFO parameter. Is there some benefit from having two queues back to back?

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