-
Notifications
You must be signed in to change notification settings - Fork 2
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
Striped multiport fifo #15
Comments
If you don't care about throughput, why not use a normal FIFO? The thing you are suggesting will have pretty weird performance behavior, and the only way to reduce the weirdness is to increase the number of internal queues while keeping the number of ports. Also, did you mean "striped"? |
Because in some cases we can optimistically assume, that nearly always all output port will be ready if at least one is ready. In such case using normal FIFO will be not useful because it will always limit to only 1 port instead. Additionally we can not use simply One example about which I thought while creating this issue:
I don't understand why performance behaviour will be weird? In optimistic case whole stripe will be read at once. If there are some stalls and the stripe can not be read at once, then we have to split it to parts and first we process as much data as possible and in next cycle rest.
Fixed EDIT: I solved my issue with vector registers without striped queue, but I think that this can be useful in future, because patter seems generic. |
Currently we have implemented a MultiportFifo, that gives very strong guarantees:
But this comes at cost of exponential complexity, and sometimes we can live with weaker guarantees:
As an example, lets take 2 port fifo with content:
a
,b
c
,d
Now we start to pop elements.
If we pop from such queue one element we get in first cycle
a
orb
. Let assume that we gota
, on the beginning of the second cycle of popping we have:b
c
,d
MultiportFifo
guarantees that we can pop now two elementsb
and eitherc
ord
. InStrippedMultiportFifo
it will be enough if we get onlyb
(so second port will be unused).Such structure can be useful to pass elements between pipeline elements if we care about order between cycles, but don't care about full pipeline usage.
The text was updated successfully, but these errors were encountered: