Currently there is logic to stop the stream source from being ready for two consecutive clock cycles. The reason for this hack was to fix an issue where to get the output of the processor's Nth run you need to run the processor N+1 times. Obviously, that would violate the API and create complications in applications where you would need the Nth output but do not yet have data for the N+1th input.
Operating at half-clock was the only fix I could think of, and I am kicking the can until we have an interface fast enough to make this a bottleneck.
Currently there is logic to stop the stream source from being ready for two consecutive clock cycles. The reason for this hack was to fix an issue where to get the output of the processor's Nth run you need to run the processor N+1 times. Obviously, that would violate the API and create complications in applications where you would need the Nth output but do not yet have data for the N+1th input.
Operating at half-clock was the only fix I could think of, and I am kicking the can until we have an interface fast enough to make this a bottleneck.
https://github.com/TENNLab-UTK/fpga/blob/52ce14d1d7d8102b64305b7a477ff033cb1571f6/fpga/rtl/stream_source.sv#L56-L70