Efficient methods for out-of-order load/store execution for high-performance soft processors

Abstract

Abstract-As FPGAs continue to increase in size, it becomes increasingly feasible and desirable to build higher performance soft processors. Preserving the familiar single-threaded programming model can be done with an out of order processor. The ability to execute memory loads and stores out of order has a large impact on performance, but this is difficult to do because the dependencies between stores and loads are not known until addresses are computed. Out of order memory disambiguation is traditionally done with CAMs in the load queue and store queue, but large CAMs are inefficient on FPGAs. Store Queue Index Prediction (SQIP) and NoSQ propose to replace CAMs with store-load forwarding prediction and load re-execution.We implement four memory disambiguation schemes (in-order, CAM, SQIP, NoSQ) on a Stratix IV FPGA and evaluate the area and delay trade-offs. We find that CAM area and delay degrade quickly with load/store queue size, while SQIP and NoSQ have little degradation with queue size but have area overhead for prediction and predictor training hardware. SQIP and NoSQ use less area than CAMs beyond 32 and 16 load/store queue entries, respectively, and have higher maximum frequency beyond 4 entries.

An Out-of-Order Load-Store Queue for Spatial Computing

“…These scheme is also impractical, as the LSQ would have as many entries as the number of static memory accesses in the application, which would be unrealistically large in all but the most trivial of cases. Others have shown that both the critical path (assuming single-cycle accesses) and resource requirement demands grow as a function of the number of LSQ entries [21]; our implementation results confirm this observation.…”

“…Although our design exhibits ample parallelism and performs most operations concurrently, some functionalities cannot be implemented in constant time-for instance, to bypass data from the store to the load queue, one needs to check the store queue from the head to the tail to find the last conflicting data, and this requires at best O(log n) time for an n-depth queue. This sensitivity to the number of queue entries is in line with results reported by others in conventional LSQ designs-previous efforts to implement conventional LSQs in FPGAs have exhibited the same trends of resource and clock degradation with queue size [21]. These results motivate us to consider alternative design options in the future-our group allocation policy is generally applicable and can be incorporated into different queue architectures.…”

A High-Frequency Load-Store Queue with Speculative Allocations for High-Level Synthesis

“…To avoid pipeline stalls due to unpredictable memory accesses, a circuit can use additional logic to handle memory accesses at runtime [20]. If proven safe to do so, the logic should allow loads from later loop iterations to be executed without waiting for stores from earlier iterations to commit.…”

“…Such functionality is most often implemented as a load-store queue (LSQ). Most LSQs aimed at HLS use a content-addressable memory (CAM) structure to implement the load and store queue [20], [23], with a similar operating principle as LSQs used in out-of-order CPUs [24]. CAMs map poorly to FPGA technology resulting in a high critical path and resource usage overhead [20], [25].…”

“…Most LSQs aimed at HLS use a content-addressable memory (CAM) structure to implement the load and store queue [20], [23], with a similar operating principle as LSQs used in out-of-order CPUs [24]. CAMs map poorly to FPGA technology resulting in a high critical path and resource usage overhead [20], [25]. Our LSQ design is fundamentally different from previous LSQs in that we use shift registers instead of CAMs.…”