Download PTLsim User's Guide and Reference - Facom-UFMS

Valid
0
0
1
1
Table 19.1: Issue Queue State Machine
Issued Meaning
0
Unused slot
1
(invalid)
0
Dispatched but waiting for operands
1
Issued to a functional unit but not yet completed
After insert() is called, the slot is placed in the dispatched state. As each uop completes, its tag
(ROB index) is broadcast using the broadcast() method to one or more issue queues accessible
in that cycle. Because of clustering, some issue queues will receive the broadcast later than others;
this is discussed below. Each slot in each of the four operand arrays is compared against the
broadcast value. If the operand tag in that slot is valid and matches the broadcast tag, the slot (in
one of the operand arrays only, not the entire issue queue) is invalidated to indicate it is ready and
no longer waiting for further broadcasts.
Every cycle, the clock() method uses the valid and issued bitmaps together with the valid
bitmaps of each of the operand arrays to compute which issue queue slots in the dispatched state
are no longer waiting on any of their operands. This bitmap of ready slots is then latched into the
allready bitmap.
The issue() method simply finds the index of the first set bit in the allready bitmap (this is the
slot of the oldest ready uop in program order), marks the corresponding slot as issued, and returns
the slot. The processor then selects a functional unit for the uop in that slot and executes it via the
ReorderBufferEntry::issue() method. After the uop has completed execution (i.e. it cannot
possibly be replayed), the release() method is called to remove the slot from the issue queue,
freeing it up for incoming uops in the dispatch stage. The collapsing design of the issue queue
means that the slot is not simply marked as invalid - all slots after it are physically shifted left by
one, leaving a free slot at the end of the array. This design is relatively simple to implement in
hardware and makes determining the oldest ready to issue uop very trivial.
Because of the collapsing mechanism, it is critical to note that the slot index returned by issue()
will become invalid after the next call to the remove() method; hence, it should never be stored
anywhere if a slot could be removed from the issue queue in the meantime.
If a uop issues but determines that it cannot actually complete at that time, it must be replayed. The
replay() method clears the issued bit for the uop’s issue queue slot, returning it to the dispatched
state. The replay mechanism can optionally add additional dependencies such that the uop is only
re-issued after those dependencies are resolved. This is important for loads and stores, which may
need to add a dependency on a prior store queue entry after finding a matching address in the load
or store queues. In rare cases, a replay may also be required when a uop is issued but no applicable
functional units are left for it to execute on. The ReorderBufferEntry::replay() method is a
wrapper around IssueQueue::replay() used to collect the operands the uop is still waiting for.
98