Hi, 1. First, isLocked is part of the implementation of atomics based on load-linked-store-conditional. When processing a request in ruby controllers, lines will not get blocked manually. In order to avoid request hasards, several mechanisms are available.
1. The block_on mechanism of peek. Used for RMW atomic implementation. You can find an example in MSI-cache.sm, in the mandatory_in port. 2. Special actions like z_stall (retry every cycle until unblocked, might cause deadlock depending on the protocol), Can be coupled with rsc_stall_handler as introduced with the CHI protocol to cycle the queue and let subsequent messages pass. Might introduce ordering violations depending on the protocol requirements. 3. The stall_and_wait special function that you can call in an action and that will put the pending message in a special stall map located in the MessageBuffer implementation. You need to wakeup the stalled messages when the conditions are fulfilled. 4. Build your protocol to support more concurrence between transactions to a same address. This is where is gets really interesting but also a lot more complex ;) 2. Ruby controllers check each incoming queue in the order of definition of the in_port blocks. You need to make sure that the input ports have been sorted in the correct order based on your protocol requirements. One thing is certain: no action will be taken based on message content (e.g., address) unless you explicitly take care of that message in an in_port block. Regards, Gabriel
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
