You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
keegandent
changed the title
Implementing skid buffer with axis_fifo or axis_pipeline_fifo
Implementing buffer with axis_fifo or axis_pipeline_fifoOct 17, 2024
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.
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?
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 theram_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.The text was updated successfully, but these errors were encountered: