[GPGPU-Sim] Question about potential double consumption of L1/L2_WRBK_ACC requests in `gpgpu_sim::cycle()` (L2 to ICNT)

[2022hitoss]

Hi,

I am currently studying the logic within gpgpu_sim::cycle(), specifically the data path from the L2 Cache to the Interconnect (ICNT). I came across a behavior regarding how L1_WRBK_ACC and L2_WRBK_ACC requests are handled, and I would like to clarify if this is intended behavior.

Context & Observation

In the loop handling the L2-to-ICNT transfer, the code first calls m_memory_sub_partition[i]->top().
Inside the top() function, there is logic to handle write-back requests: if the mem_fetch type is L2_WRBK_ACC or L1_WRBK_ACC, the request is deleted (freed), and the function returns NULL.

I understand the rationale here: once a write-back request reaches its destination memory level, its lifecycle ends, so it does not need to be forwarded to the interconnect.

The Potential Issue

However, looking at the caller in gpgpu_sim::cycle(), if m_memory_sub_partition[i]->top() returns NULL, the code proceeds to call m_memory_sub_partition[i]->pop().
Based on my reading, pop() appears to perform the same check and deletion logic for L1/L2_WRBK_ACC requests.

This suggests a scenario where two L1/L2_WRBK_ACC requests could be discarded in a single simulation cycle:

1. One write-back request is consumed and deleted inside top().
2. Because top() returned NULL, pop() is immediately called, potentially consuming and deleting a second write-back request in the same cycle.

Question

Is this double-consumption behavior intended (e.g., to model higher throughput for dropping write-backs), or is it an oversight where the cycle budget should have been consumed by the first operation?

Thank you for your time and clarification!

[JRPan]

not intended. I didn't look into it, but the behavior you described should be a bug.