Allowing multiple outstanding reads to a single dramsim3 channel to return at …

[dpetrisko]

…once.

This reflects a DRAM controller which received multiple requests for a single address and returns them sequentially. Current behavior is to silently drop the second request in a monkey's paw form of coalescing.

You can expose this bug by modifying the testbench like so:

diff --git a/testing/bsg_test/bsg_nonsynth_dramsim3/hbm_trace_gen.py b/testing/bsg_test/bsg_nonsynth_dramsim3/hbm_trace_gen.py
index 9a2fdd8a..48a6d168 100644
--- a/testing/bsg_test/bsg_nonsynth_dramsim3/hbm_trace_gen.py
+++ b/testing/bsg_test/bsg_nonsynth_dramsim3/hbm_trace_gen.py
@@ -68,7 +68,7 @@ if __name__ == "__main__":
   tg = HBMTraceGen(addr_width_p)
   for i in range(n_strides):
     # stride is by column
-    tg.send(READ, start + i * stride)
-    tg.wait_cycles(500)
+    tg.send(READ, start)# + i * stride)
+    #tg.wait_cycles(500)

which will drop some number of duplicate requests

[petrisko@kk9 bsg_nonsynth_dramsim3]$ grep "req sent" vcs.log | wc -l
1000
[petrisko@kk9 bsg_nonsynth_dramsim3]$ grep "read done" vcs.log | wc -l
493