Why "iu_rv_iu6_t0_i0_t1_p" and "rn_cp_iu6_t0_i0_t1_p" are the same

[zhaoxiahust]

Hi,

In the iuq.v file, the output signal "rn_cp_iu6_t0_i0_t1_p" of the iuq_slice_top module is sent to the iuq_cpl_top module and is also assigned to the signal "iu_rv_iu6_t0_i0_t1_p" which is sent to RV module. Based on my understanding, "rn_cp_iu6_t0_i0_t1_p" represents the real physical register id of the current dispatched instruction. I can understand why this value is sent to the RV module since this register id should be stored in the RV entry and being snooped on the data bus to detect when the instruction can be issued.

However, I cannot understand why this signal is also sent to the complete buffer. When an instruction in the complete buffer commits, the corresponding physical register will be returned to the free list. However, in this case, the register indicated by "rn_cp_iu6_t0_i0_t1_p" might be used by later instructions. In my opinion, instead of the using the "rn_cp_iu6_t0_i0_t1_p", we should use the old/previous physical register id which corresponds to the architectural register?

[openpowerwtf]

Isn't that what is happening in the mapper (iuq_rn_map)? Seems that on completion, cpl tells rn the arch/rename reg values, and rn updates the map and free pool accordingly. It also handles the concurrent completion of two ops to same reg.

[zhaoxiahust]

Great! I got it. The related logics are indeed in the iuq_rn_map file. "._d" and "._l2" are used to represent the current physical register id and the old/previous physical register id which corresponds to the architectural register.

Thanks for your help! Sometimes, a small hint can save us a lot of time!!

Cheers!

[openpowerwtf]

Yes, the completion buffer tracks speculative ops and the mapper updates for architected results.

FYI: _l2 is normally written _q now; the naming convention comes from the L1/L2 LSSD latch design.