2010-10-13: Some Thoughts on Synchronizing an Architectural Reference Model
Category: General
Posted by: afeldstein
When should an architectural reference model execute an instruction? How do we synchronize this execution with that going on in the design under verification (DUV)? What we need is some sort of throttle control, but we are challenged by the fact that an architectural reference model, and indeed all of FSS, is to remain ignorant of the implementation details of the DUV.
In a von Neumann architecture (e.g. Sputnik), when we observe a memory read, we don't even know that that was an instruction fetch! Of course, FSS will need to evolve to support Harvard architecture DUVs as well, but let's not open that Pandora's box just yet.
In the Software Requirements Specification, I relaxed the requirement that the SPARC-V9 Standard Reference Model be written as behavioral JHDL.
Note that all Sputnik memory access is doubleword. This will not be true in general.
I committed to CVS a stub of MemoryReadMonitor, along with a simplified SparcView/monitor interface. SparcView now passes the SparcSimulation object to its monitors. The monitors take care of the details by making various calls to the SparcSimulation object.
Before designing Scoreboard (superclass) and InstructionFetchScoreboard (subclass), let me try to figure out what the MemoryReadMonitor would report to the InstructionFetchScoreboard. I intend to give MemoryReadMonitor the ability to provide post-simulation information to the verification engineer; record interface events to a runtime file, formatting it for readability and debugging assistance. But I want to push much of this functionality from MemoryInitializationMonitor (subclass) up to Monitor (superclass). That is, make the common functionality reusable.
When MemoryRead Monitor records interface events to a runtime file, it looks like this:
It's just a series of times and addresses.
Initially, I thought the file showed evidence of a race condition. If we supposedly waited until Power-On Reset (POR) before enabling the monitor, then why did the monitor see reads of address 0?
Ultimately, I concluded that I had been neglecting to check to see if the monitor was enabled (effectively enabling always regardless of the boolean) until after 2010-07-31. Once this problem was fixed, I disabled MemoryReadMonitor's reporting to a file.
At this point, I wanted to begin designing the Scoreboard and InstructionFetchScoreboard classes.
Here is the communication diagram so far:
Paraphrasing from Comprehensive Functional Verification (CFV), a scoreboard is a temporary holding location for information the [reference model] will require. I began to realize that the "scoreboard" I have in mind stretches the Wile/Goss/Roesner description. I began with a direct quote from CFV:
"A checker can use a scoreboard in two ways ... In the first method, the checker component contains the reference model. The scoreboard's role is to examine the inputs for transactions to occur, capture pertinent information, and store the information for later use. Then when the checker observes some condition on the outputs of the DUV, it makes a call to the scoreboard to get the data (referred to as a callback).
Next, I iteratively adapted that paragraph for my purposes.
There is the SPARC-V9 Standard Reference Model. The scoreboard's role is to examine the inputs for instructions to occur, capture pertinent information, and store the information for later use. Then when the reference model observes some condition on the outputs of the DUV, it makes a call to the scoreboard to get the data (referred to as a callback).
I didn't really like that. There's no checker component that contains the reference model, but there is a reference model. This first attempt at adaptation put the reference model in the role of the checker.
I'll deal with who performs the observing later and first make another refinement pass.
There is the SPARC-V9 Standard Reference Model. The MemoryReadMonitor examines the inputs [of the DUV] for instructions to occur. The MemoryReadMonitor does this for the scoreboard. The scoreboard's role is to capture pertinent information and store the information for later use. Then when the reference model observes some condition on the outputs of the DUV, it makes a call to the scoreboard to get the data (referred to as a callback).
Now let me clarify what does not happen at the outputs of the DUV.
There is the SPARC-V9 Standard Reference Model. The MemoryReadMonitor examines the inputs [of the DUV] for instructions to occur. The MemoryReadMonitor does this for the scoreboard. The scoreboard's role is to capture pertinent information and store the information for later use. The reference model does not observe the outputs of the DUV. When the reference model observes some condition, it makes a call to the scoreboard to get the data (referred to as a callback).
The pertinent information captured by the scoreboard is a set of possible instruction fetch addresses. Certainly, the DUV will have fetched no instruction whose address has not been captured by the scoreboard. The condition that the reference model observes is its own instruction fetch. When the reference model observes that condition, it ...
You can almost hear the wheels turning in my head. And perhaps you're screaming for me to get to the punchline already. But it's a thought process. I want FSS designed correctly.
Previously, I wrote that "I think the reference model should run in another thread", so let me put some more thought into that.
In Java: How to Program, Sixth Edition, I began to review "Thread States: Life Cycle of a Thread".
"A new thread begins its life in the new state. It remains in this state until the program starts the thread, which places the thread in the runnable state. A thread in this state is considered to be executing its task. Sometimes a thread transitions to the waiting state while the thread waits for another thread to perform a task. Once in this state, a thread transitions back to the runnable state only when another thread signals the waiting thread to continue executing."
The "new thread" refers to the SPARC-V9 Standard Reference Model thread. What is the other thread that the reference model waits for?
503 Service Unavailable
In a von Neumann architecture (e.g. Sputnik), when we observe a memory read, we don't even know that that was an instruction fetch! Of course, FSS will need to evolve to support Harvard architecture DUVs as well, but let's not open that Pandora's box just yet.
In the Software Requirements Specification, I relaxed the requirement that the SPARC-V9 Standard Reference Model be written as behavioral JHDL.
Note that all Sputnik memory access is doubleword. This will not be true in general.
I committed to CVS a stub of MemoryReadMonitor, along with a simplified SparcView/monitor interface. SparcView now passes the SparcSimulation object to its monitors. The monitors take care of the details by making various calls to the SparcSimulation object.
Before designing Scoreboard (superclass) and InstructionFetchScoreboard (subclass), let me try to figure out what the MemoryReadMonitor would report to the InstructionFetchScoreboard. I intend to give MemoryReadMonitor the ability to provide post-simulation information to the verification engineer; record interface events to a runtime file, formatting it for readability and debugging assistance. But I want to push much of this functionality from MemoryInitializationMonitor (subclass) up to Monitor (superclass). That is, make the common functionality reusable.
When MemoryRead Monitor records interface events to a runtime file, it looks like this:
2010-07-31T18:59 0
2010-07-31T18:59 1
2010-07-31T18:59 2
...
2010-08-01T20:29 0000000000000020
2010-08-01T20:29 0000000000000021
2010-08-01T20:29 0000000000000022
...
It's just a series of times and addresses.
Initially, I thought the file showed evidence of a race condition. If we supposedly waited until Power-On Reset (POR) before enabling the monitor, then why did the monitor see reads of address 0?
Ultimately, I concluded that I had been neglecting to check to see if the monitor was enabled (effectively enabling always regardless of the boolean) until after 2010-07-31. Once this problem was fixed, I disabled MemoryReadMonitor's reporting to a file.
At this point, I wanted to begin designing the Scoreboard and InstructionFetchScoreboard classes.
Here is the communication diagram so far:
Paraphrasing from Comprehensive Functional Verification (CFV), a scoreboard is a temporary holding location for information the [reference model] will require. I began to realize that the "scoreboard" I have in mind stretches the Wile/Goss/Roesner description. I began with a direct quote from CFV:
"A checker can use a scoreboard in two ways ... In the first method, the checker component contains the reference model. The scoreboard's role is to examine the inputs for transactions to occur, capture pertinent information, and store the information for later use. Then when the checker observes some condition on the outputs of the DUV, it makes a call to the scoreboard to get the data (referred to as a callback).
Next, I iteratively adapted that paragraph for my purposes.
There is the SPARC-V9 Standard Reference Model. The scoreboard's role is to examine the inputs for instructions to occur, capture pertinent information, and store the information for later use. Then when the reference model observes some condition on the outputs of the DUV, it makes a call to the scoreboard to get the data (referred to as a callback).
I didn't really like that. There's no checker component that contains the reference model, but there is a reference model. This first attempt at adaptation put the reference model in the role of the checker.
I'll deal with who performs the observing later and first make another refinement pass.
There is the SPARC-V9 Standard Reference Model. The MemoryReadMonitor examines the inputs [of the DUV] for instructions to occur. The MemoryReadMonitor does this for the scoreboard. The scoreboard's role is to capture pertinent information and store the information for later use. Then when the reference model observes some condition on the outputs of the DUV, it makes a call to the scoreboard to get the data (referred to as a callback).
Now let me clarify what does not happen at the outputs of the DUV.
There is the SPARC-V9 Standard Reference Model. The MemoryReadMonitor examines the inputs [of the DUV] for instructions to occur. The MemoryReadMonitor does this for the scoreboard. The scoreboard's role is to capture pertinent information and store the information for later use. The reference model does not observe the outputs of the DUV. When the reference model observes some condition, it makes a call to the scoreboard to get the data (referred to as a callback).
The pertinent information captured by the scoreboard is a set of possible instruction fetch addresses. Certainly, the DUV will have fetched no instruction whose address has not been captured by the scoreboard. The condition that the reference model observes is its own instruction fetch. When the reference model observes that condition, it ...
You can almost hear the wheels turning in my head. And perhaps you're screaming for me to get to the punchline already. But it's a thought process. I want FSS designed correctly.
Previously, I wrote that "I think the reference model should run in another thread", so let me put some more thought into that.
In Java: How to Program, Sixth Edition, I began to review "Thread States: Life Cycle of a Thread".
"A new thread begins its life in the new state. It remains in this state until the program starts the thread, which places the thread in the runnable state. A thread in this state is considered to be executing its task. Sometimes a thread transitions to the waiting state while the thread waits for another thread to perform a task. Once in this state, a thread transitions back to the runnable state only when another thread signals the waiting thread to continue executing."
The "new thread" refers to the SPARC-V9 Standard Reference Model thread. What is the other thread that the reference model waits for?
Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request.