Yes, that makes sense. That is how I though the drain() functionality should work. But when I looked at the code I was confused. What it (the cpu drain()) looks like it's doing to me is just counting the number of stages that need to be drained, and each stage seems to be just signalling that they are drained when they're drain() function is called. The only one that doesn't immediately signal drained is the commit stage. But, during commit's tick() function it will signal drained if the ROB is empty, there is a drain pending, and there are no stores to wb in the iew stage. I imagine what is happening is that since it's an uncacheable load it is being removed from the ROB and passed to commit where commit will handle it. So it's technically not done but commit thinks it can drain since the ROB is empty, and the load is removed from the LSQ. And I don't see anywhere in the code where the mem_dep_unit is checked during drain, and it doesn't have its own drain() function.

-Tony
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users

Reply via email to