On Mar 25, 2011, at 11:57 AM, Anthony Gutierrez wrote: > 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.
Perhaps that is the problem and the mem_dep_unit needs to be checked. Ali _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
