I finally got the logic for dispatch sink (sends the number of output fires followed by the indices which fired) figured out, but it has a substantial compromise. It was not possible to calculate the output queue in a single clock cycle, possibly just because of the sheer number of combinations, but more likely because the dynamic indexing of assignments in a combinational logic block wouldn't be synthesizable.
This means there's an intermediate processing step to populate that array which will always take NUM_OUT clock cycles. For an infinitely fast (always ready) sink, this would make the process O(NUM_OUT + num_fires), which would be awful. Therefore, such a sink should always use stream_sink. For an infinitely slow sink (almost never ready), the process would approach O(num_fires) which is what we want.
So, the choice of dispatch or stream for slow interfaces still largely reduces down to the density of fires relative to output width and timescale. However any advantage provided by the dispatch sink is inversely proportional to interface speed up to the crossover point.
It may be useful to have some sort of calculation logic in the future which can take interface speed, clock speed, number of output neurons, and estimated number of input spikes and output fires per run to then provide minimum, maximum, and estimated "runs per second" rates for the processor type permutations in a table.
I finally got the logic for dispatch sink (sends the number of output fires followed by the indices which fired) figured out, but it has a substantial compromise. It was not possible to calculate the output queue in a single clock cycle, possibly just because of the sheer number of combinations, but more likely because the dynamic indexing of assignments in a combinational logic block wouldn't be synthesizable.
This means there's an intermediate processing step to populate that array which will always take
NUM_OUTclock cycles. For an infinitely fast (always ready) sink, this would make the process O(NUM_OUT+num_fires), which would be awful. Therefore, such a sink should always usestream_sink. For an infinitely slow sink (almost never ready), the process would approach O(num_fires) which is what we want.So, the choice of dispatch or stream for slow interfaces still largely reduces down to the density of fires relative to output width and timescale. However any advantage provided by the dispatch sink is inversely proportional to interface speed up to the crossover point.
It may be useful to have some sort of calculation logic in the future which can take interface speed, clock speed, number of output neurons, and estimated number of input spikes and output fires per run to then provide minimum, maximum, and estimated "runs per second" rates for the processor type permutations in a table.
Speaking of, here's how I worked out the logic: