Immediately after each uop is issued and the ReorderBufferEntry::issue() method actually generates its result, the cycles_left field of the ROB is set to the expected latency of the uop (e.g. between 1 and 5 cycles). The uop is then moved to the issued state and placed on the rob_issued_list. Every cycle, the complete() method iterates through each ROB in issued state and decrements its cycles_left field. If cycles_left becomes zero, the corresponding uop has completed execution. The ROB is moved to the completed state (on rob_completed_list) and its physical register or store queue entry is moved to the bypass state so newly dispatched uops do not try to wait for it.
The transfer() function is also called every cycle. This function examines the list of ROBs in the completed state and is responsible for broadcasting the completed ROB's tag (ROB index) to the issue queues. Because of clustering (Section 19.1), some issue queues will receive the broadcast later than others. Specifically, the ROB's forward_cycle field determines which issue queues and remote clusters are visible forward_cycle cycles after the uop completed. The forward() method, called by transfer() for each uop in the completed state, indexes into a lookup table forward_at_cycle_lut[cluster][forward_cycle] to get a bitmap of which remote clusters are accessible forward_cycle cycles after he uop completed, relative to the original cluster.the uop issued in. The IssueQueue::broadcast() method (Section 19.3) is then called for each applicable cluster to wake up any operands of uops in that cluster waiting on the newly completed uop.
The MAX_FORWARDING_LATENCY constant (in ooocore.h) specifies the maximum number of cycles between any two clusters. After the ROB has progressed through MAX_FORWARDING_LATENCY cycles in the completed state, it is moved to the ready-to-writeback state, effectively meaning the result has arrived at the physical register file and is eligible for writeback in the next cycle.
Every cycle, the writeback() function scans the list of ROBs in the ready-to-writeback state and selects at most WRITEBACK_WIDTH results to write to the physical register file. The forward() method is first called one final time to catch the corner case in which a dependent uop was dispatched while producer uop was waiting in the ready-to-writeback state.
As mentioned in Section 19.4, for simulation purposes only, each uop puts its result directly into its assigned physical register at the time of issue, even though the data technically does not appear there until writeback. This is done to simplify the simulator implementation; it is assumed that any data ``read'' from physical registers before writeback is in fact being read from the bypass network instead. Therefore, no actual data movement occurs in the writeback() function; its sole purpose is to place the uop's physical register into the written state (via the PhysicalRegister::writeback() method) and to move the ROB into its terminal state, ready-to-commit.