Hi Nilay, There is often a tradeoff between doing operations in actions versus the input port. Overall, I agree with you that we should concentrate on doing most/all operations in actions, not the input ports. The input port logic is often a confusing nested conditional mess and performing other operations inside the input port logic only further confuses things. I believe the reason why the ExternalResponse is monitored at the input port for the token protocol, is because this is a critical piece of information needed for tuning the dynamic timeout latency. It is likely that Mike Marty (who I believe is the original author) just wanted to make sure he always correctly identified external responses.
My suggestion for you is not to worry about it and just keep the logic as is. There is no need to give yourself extra work. To my knowledge GEM5 has yet to be configured into multiple chips and most of the ExternalResponse logic deals with separating local cache hits vs. remote cache hits. Once we configure multiple chip systems, we can revisit the ExternalResponse logic and possibly optimize it. Brad > -----Original Message----- > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On > Behalf Of Nilay > Sent: Friday, January 14, 2011 1:12 AM > To: m5-dev@m5sim.org > Subject: [m5-dev] MOESI_CMP_token > > I am trying to update the MOESI CMP token protocol. Line 563 in the > file > for the L1 cache controller caught my eye. While processing a message > received through the response network, the transaction buffer entry for > the address is edited. > tbe.ExternalResponse := true; > > Should this happen where it is happening currently? I think this change > should appear in some action. > > -- > Nilay > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
