[libre-riscv-dev] GPU design

[Jacob Lifshay]

On Tue, Dec 4, 2018, 04:31 Luke Kenneth Casson Leighton <lkcl at lkcl.net
wrote:

>
> https://passlab.github.io/CSE564/notes/lecture18_ILP_DynamicMultIssueSpeculationAdvanced.pdf
>
> page 8.  i had a feeling this might be the case: a standard scoreboard
> with explicit register-renaming requires a "real" register file that's
> larger than the one that the ISA has.  we *already* have an absolutely
> massive register file: 2x 128 64-bit.
>
If we use renaming and my idea for having the integer and fp register files
be the same thing, we can get away with 1.5x 128 64-bit or less. I found a
pdf that describes how big a 6r3w register file is in 48nm, they have a
32x128 register file that takes up about 30,000 um^2 (figure 1, fabmem), so
we can expect somewhere around 50,000 um^2 for a 64x192 6r3w register file
in 28nm.

https://www.researchgate.net/publication/316727584_A_case_for_standard-cell_based_RAMs_in_highly-ported_superscalar_processor_structures

>
> by contrast, tomasulo style reservation stations don't actually have
> registers at *all*.  the registers are eliminated, being replaced by
> "values" (or copies of values), having temporary "ROB" tag-indexes
> that replace the registers.  multiple copies of those end up in the
> reservation stations leading to the ALUs, as well as in the LOAD
> buffer.
>
> thus, the resources needed for renaming are fixed: each ALU will have
> 2 or possibly 3 sets of reservation stations, and the LOAD buffer has
> a fixed number of entries.
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>