Rename Development Discussion

[aarongchan]

Continuing the email discussion around the stalling of rename:
"When you receive a group of instructions from Decode and you do not have any renames, you must stall (i.e. do not send credits back to Decode). Rename will “sleep” until it receives retired instructions from the ROB and reclaims Renames. If enough renames have been collected to service the given instruction group from Decode, Rename starts up renaming (and sends credits back to Decode for each instruction renamed)."
Would the dispatch credits/instructions being sent from rename also need to be stalled?

Regarding a "smarter" test plan:
Ideally I would like to test:
One instruction -> PRF assigned -> reference counter updated -> retired -> PRF added back to free list -> reference counter updated
Two instructions -> RAW dependency -> PRF assigned -> reference counter updated (make sure the source uses the PRF and not the ARF)-> retired -> PRF added back to free list -> reference counter updated
Fill freelist -> (this one might have to be implemented later, as due to the current nature, the freelist doesn't get filled, as we aren't checking for dependencies yet, and thus we're not hitting stalls that could lead to a freelist being empty) Fill the freelist -> check that no instruction group is processed -> check dispatch/decode credits aren't incremented
Reference_counter -> Have a couple of instructions reference a destination PRF, once all the instructions retire, reference_counter should be 0, and PRF should be freed.

Is there an example of how to test a module at such a fine grain level, such as the ones in SPARTA? Also, does my logic from above around the freelist never being empty due to the current OOO nature of Olympia, pass through without true operand dependency correct? When I run on the example dhrystone trace I never hit the freelist being empty, but I wanted to double check as I could've made an error in my implementation.

[klingaard]

Would the dispatch credits/instructions being sent from rename also need to be stalled?

Not sure I follow your question. Rename does not send any credits to Dispatch. Dispatch will continue to drain and send credits back to Rename, but unless Rename has resources to actually rename the instructions it has, it will remain asleep.

Your test plan is looking good!

Is there an example of how to test a module at such a fine grain level, such as the ones in SPARTA?

Not in Sparta nor in the examples, unfortunately. For the Rename test, I recommend you implement a TesterUnit that takes parameters, such as -p top.tester.params.test_one_instruction true and -p top.tester.params.test_two instructions true -p top.tester.params.add_dependencies true or whatever. Either that or regular command line arguments instead, whichever you feel is easier.

Also, does my logic from above around the freelist never being empty ... pass through without true operand dependency correct?

The number of entries in the FreeList corresponds to the number of outstanding instructions past rename. So, if you can have 100 instructions outstanding, but only have 50 freelist renames, you'll definitely stall.

[aarongchan]

Not sure I follow your question. Rename does not send any credits to Dispatch. Dispatch will continue to drain and send credits back to Rename, but unless Rename has resources to actually rename the instructions it has, it will remain asleep.

I think I may have misinterpreted what this part of the code was doing. But for the decrementing of the dispatch credits in the code referenced, it should only happen if rename is not asleep right?

The number of entries in the FreeList corresponds to the number of outstanding instructions past rename. So, if you can have 100 instructions outstanding, but only have 50 freelist renames, you'll definitely stall.

Could you clarify what you mean by "outstanding instructions past rename"? I interpreted the freelist as a PRF from the freelist should be assigned during rename, if there are enough PRFs in the freelist to process the rename of the instruction group. For example, if the number of renaming instructions is 4 and the freelist size is 3, then we don't process the instruction group until we get 4 PRFs in the freelist. Likewise, the mapping and reference counter tables are updated in the renaming instructions function. I think I may have gotten confused, as I assumed the map table/freelist updates happened in rename file, but when I look at the slides for the R10k referenced in the rename design, I see that they implement it after dispatch?

Link to my fork with my current implementation:
https://github.com/AaronGChan/riscv-perf-model/blob/issue_2_task_1/core/Rename.cpp#L175

[klingaard]

But for the decrementing of the dispatch credits in the code referenced, it should only happen if rename is not asleep right?

Rename keeps track of the downstream credits given to it by Dispatch. When Rename renames an instruction and sends it to Dispatch, it will decrement it's local credit count. Dispatch will send an update to that number when Dispatch has room to accept new instructions.

As an example, at the beginning of simulation, Dispatch will send, say 9 credits to Rename (meaning Dispatch has room in its buffers for 9 instructions). Rename locally caches that number and decrements it when it sends instructions to Dispatch. So, if the machine width is 3 and Rename successfully renames 3 instructions, it will decrement that local credit count by 3 -> 6. Unless Dispatch sends credits back to Rename in the next cycle, that number will remain at 6.

Could you clarify what you mean by "outstanding instructions past rename"?

After Rename, there are instructions in Dispatch (D) and instructions in Retire (R) since Dispatch appends to Retire when it dispatches. So the total number of instructions past rename is D + R. If each instruction writes to a destination of the same register file type, that would be D+R renames of that register file type outstanding. Of course, this is assuming the Retire block is stalled on the oldest instruction for a long time (like a load to main memory).

Link to my fork with my current implementation

I took a look at your fork and a couple of comments:

1. You must rename sources before you rename destinations (I'll let you ponder on that one. ;) )
2. The event ev_rename_insts_ should only be scheduled if:
   • You have credits from Dispatch (checked on line 164) AND
   • You have enough renames to rename the instructions in the group
3. These conditions can be added to a new method like scheduleRenaming_ that is called from decodedInstructions_ and getAckFromROB_
   • The new method scheduleRenaming_ will schedule ev_rename_insts_ if all stall conditions are alleviated
4. The method renameInstructions_ should only be called if there are absolutely no stall reasons. This means you can pop a freelist entry without being concerned about running out (you checked those conditions in scheduleRenaming_ before scheduling the event)
5. There seems to be a lot of work being done in getAckFromROB_. Remember that an instruction only has 1 destination. Not sure why there are so many for loops.

[aarongchan]

Thanks for all the feedback! I made edits according to your feedback.

I'm currently using the simulation test to run through the instructions, and then check the freelist, map_table, and reference_counter tables to see if all values are cleared. With the test, I noticed that the test simulator doesn't wait until all instructions are retired before ending it. Is there a way to tell the test simulator to wait until all instructions have been retired?

Also, right now the only testing I can do is at the end of a simulation, which can give some checking. However, the ideal timing would be after each instruction, check if the rename structures are updated properly and counts are correct. Is there a way I can run the simulation one instruction at a time, and being able to exit it to check the rename structures, and then resume processing instructions?

Link to my rename test

[furuame]

I'm currently using the simulation test to run through the instructions, and then check the freelist, map_table, and reference_counter tables to see if all values are cleared. With the test, I noticed that the test simulator doesn't wait until all instructions are retired before ending it. Is there a way to tell the test simulator to wait until all instructions have been retired?

I think Sparta simulator ends only when there are no more events. Could you check whether events are scheduled properly?

Also, right now the only testing I can do is at the end of a simulation, which can give some checking. However, the ideal timing would be after each instruction, check if the rename structures are updated properly and counts are correct. Is there a way I can run the simulation one instruction at a time, and being able to exit it to check the rename structures, and then resume processing instructions?

I think Sparta supported this, but does not now. I'll take a look at it for you. ** Edited ** Here is the patch: sparcians/map#411

[aarongchan]

I'm working on the operand dependency checking in ExecutePipe and LSU, is there any difference between LSU and ExecutePipe for operand dependency checking? In either case, we check for operand readiness via scoreboard views, if they're not ready we do a RegisterCallBack, when it's ready we then issue. On completion we then mark the scoreboard register destination as ready. There's no difference in this logic between an add, load, or store, because we're either waiting on 2 or 1 operands to be ready, whether it's for address calculation or integer/float calculation. Is my thought process on this correct?

[klingaard]

That's correct.

[aarongchan]

I'm trying to write tests for my operand dependency checking in the ExecutePipe and LSU resources. However, the rename tests use the SinkUnit used in the dispatch test, which doesn't initialize the full execute pipe and LSU. Instead of trying to modify the simulation used for testing, would it be easier if I use the OlympiaSim cpp/hpp in the sim folder to run a full Olympia simulation in order to then check the values of the ExecutePipe and LSU for testing, since at this point I need a fully initialized ExecutePipe, LSU, and ROB?

[klingaard]

I do not see a problem with that. You can make it an independent sim test.

[arupc]

Do we have any existing experimental data gathered using olympia changing num_integer_rename param to see effect of register renaming on existing workloads such as dhrystone / coremark?

[danbone]

Is there any reason why reference counters are used for Rename. It should be enough to release a register when the instruction that remaps it retires? Or am I missing something?

[aarongchan]

Hey Dan,
The thought process for the reference counters is so that we can release a PRF as soon as the last instruction using it is retired. In your approach, there could be multiple cycles/instructions before the remapping instruction for an ARF is retired, so in some cases, we wouldn't release the PRF until much later then using a reference counter. I think either approach works, and I've thought about removing it before, but I thought the faster release on PRF would be more beneficial vs the extra complexity/overhead of tracking.

1/3/24 Meeting

• Knute also mentioned that reference counters would be necessary if we were to ever implement move elimination optimization in Rename

[egieske]

I missed the meeting discussion, but yes, reference counters are the common way to implement move elimination which may even be through memory e.g., calculate rd1 X, ... store rd1 [Addr], ..., load rd2 [Addr] can become rd2 is renamed to rd1.