Date: | Tue, 22 Mar 2011 21:55:29 +0900 |
---|---|
From: | "Jiho \"Ray\" Choi" <jray319@xxxxxxxxx> |
Subject: | [Gems-users] how to manually stall/unstall Simics |
Hello, I am writing a new protocol, and my protocol needs to stall the processor at acquire/release. I come up with two different approaches, and I got some questions (in bold below) related to them.
1. The first idea is to use Simics APIs such as SIMICS_stall_proc and SIMICS_unstall_proc. I referred to the previous mailing lists and tried to imitate how memory operations stall/unstall the processor.
It is clear when it unstall the processor. When the memory transaction is satisfied, SIMICS_unstall_proc is called through the sequencer, SimicsDriver and SimicsProcessor. However, on the other hand, it doesn't explicitly call SIMICS_stall_proc to stall the processor. It looks like ruby_operate is called for every memory transaction by Simics, and ruby_operate returns the number of cycles to stall the processor which is 2 billion cycles for the most cases. I guess SIMICS_stall_proc or its equivalent will be called later. Anyone knows what happens here exactly?
Anyway, the first plan is to add magic instructions at acquire/release, and the magic instruction calls SIMICS_stall_proc and signals the sequencer to handle acquire/release. After the protocol is done with acquire/release requests, the sequencer calls SIMICS_unstall_proc. Does it sound okay? Am I using Simics APIs appropriately?
2. The second idea is to mimic Simics APIs. It is to use a certain memory location as a flag telling if previous acquire/release are satisfied and it is ready to continue. While the protocol is handling previous acquire/release, the processor will busy-wait on the flag.
Similarly, I will add magic instructions at acquire/release, and the magic instruction sets the flag. After the protocol is done, the sequencer sets off the flag. I think the first approach is more intuitive and easier to implement if Simics APIs suit my purpose.
Any comment or feedback will be highly appreciated. Best regards, Ray p.s. thank you for the responses to my previous email. I wanted to say thank you, but I didn't want to bother the mailing list.
|
[← Prev in Thread] | Current Thread | [Next in Thread→] |
---|---|---|
|
Previous by Date: | [Gems-users] Running problem of Ruby (GEMS 2.1.1 & Simics 4.2) (failed assertion 'valid_bytes == 4'), Woomin Hwang |
---|---|
Next by Date: | [Gems-users] Help GEMS-2.1.1 and Simics 4.2, wangshuz |
Previous by Thread: | Re: [Gems-users] How doest GEMS simulate traps?, Gedare Bloom |
Next by Thread: | [Gems-users] Invitation to connect on LinkedIn, Dai Chen via LinkedIn |
Indexes: | [Date] [Thread] |