gem5 timeBuffer and skidBuffer approach causes an extra bubble after skidBuffer is drained?

Solution for gem5 timeBuffer and skidBuffer approach causes an extra bubble after skidBuffer is drained?
is Given Below:

Looking at the gem5 code, the skidBuffer/timeBuffer approach does provide great flexibility in clocking order, and on adding arbitrary delays. However, in terms of stalling, it seems like it can cause an extra bubble. Consider an “ideal” flow and what gem5 does (please correct me if I’m wrong here) in the attached picture. Is this the expected behavior? I assume I can fix this by reverse the clocking order, and setting the stall release wire delay to 0.

Consider an example of decode, rename, with blocks of instructions A,B,C,D,E flowing through. Assume width is the same at decode and rename.

-> Cycle0: Decode handles block B, rename is handling block A [ [Decode: B, Rename: A]
-> Cycle1: When rename stalls on B, it tells decode, which hears about it the next cycle; [Decode: C, Rename: B-skid]

-> Cycle2: On the next cycle, rename receives C (was sent the previous cycle) and adds to the skidBuffer which now has {B,C}. [Decode: , Rename: B-skid, C-skid]

-> Cycle5: When the stall releases, rename handles B from the skidBuffer. [Decode: , Rename: B, C-skid]

-> Cycle6: Rename handles C from the skidBuffer, and now tells decode [Decode: , Rename: C]

-> Cycle7: Decode hears about the install and handles D, but there is nothing in rename this cycle!

-> Cycle8: Rename gets D

Essentially there is an extra bubble on stall release after all skidbuffer values have been handled.

So instead of a stalling behavior that does this for two given stages below. The concern is the extra unstall related bubble on Stage2

Stage1: ABCDEF****GH

Stage2: ABCDE****FGH

Instead you get:

Stage1: ABCDEFG*****H

Stage2: ABCDE****FG*H

Pipeline diagram