Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.arch    |    Apparently more than just beeps & boops    |    131,241 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 130,569 of 131,241    |
|    Robert Finch to All    |
|    Re: Tonights Tradeoff - write port histo    |
|    18 Dec 25 21:33:10    |
      From: robfi680@gmail.com              Tonight’s quandry. Can a register file write history be used in       reservation stations to reduce the number of register read ports       required on the register file? And would it be smaller, faster than       adding register file ports?              There are a couple of cases:       1) The operands were ready at time of queue.       2) The operands were not ready at time of queue. That means there must       be an outstanding operation that at some point will update the register       file.              Operands that are valid at time of queue are stored in the re-order       buffer temporarily until dispatch. So, it should be possible to update       the operands in the reservation stations either from the instruction       dispatch, or later when the value is written to the register file.              An issue arises between queue and dispatch. If a value was updated in       the register file between queue and dispatch then it will not be latched       by the reservation station because it does not have the instruction yet.       If the reservation station has the instruction already waiting then the       register file write port can be used.              Rather than having more register file read ports, I was thinking of       having the reservation stations track (snoop) the register file write       history using a tapped shift register. The only time that must be       accounted for is between queue and dispatch. So, assuming that       instructions dispatched within a certain time frame, then using write       history could work.              I was thinking a 64 deep shift register with several taps could be used       to supply written values.              It is going to be at least two clock cycles between queue and dispatch       until operands/instructions are updated in the reservation stations. So,       the first tap would be at shift 3. Then maybe taps at 6, 12, 24, and 64       clocks.              There is not usually a huge amount of time between queue and dispatch,       unless the functional unit is busy. I think the longest operation is <80       clocks, so in worst case a 128-deep shift register should work.              LUTs can be turned into shift registers up to 64 bits IIRC. With four       64-bit write ports and 10 bit register tag about 300 LUTs would be       required for each shift level.              The history could be shared between several reservation stations.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca