From: Luke Kenneth Casson Leighton Date: Wed, 19 Dec 2018 08:13:06 +0000 (+0000) Subject: add register file mux X-Git-Url: https://git.libre-soc.org/?p=crowdsupply.git;a=commitdiff_plain;h=b49ff837818de691693548ab1b01e0fa9561b8dd add register file mux --- diff --git a/images/regfile.jpg b/images/regfile.jpg new file mode 100644 index 0000000..c958408 Binary files /dev/null and b/images/regfile.jpg differ diff --git a/images/register_file_multiplexing.jpg b/images/register_file_multiplexing.jpg new file mode 100644 index 0000000..cc0ad81 Binary files /dev/null and b/images/register_file_multiplexing.jpg differ diff --git a/updates/005_2018dec14_simd_without_simd.mdwn b/updates/005_2018dec14_simd_without_simd.mdwn index 69f19af..fb75a04 100644 --- a/updates/005_2018dec14_simd_without_simd.mdwn +++ b/updates/005_2018dec14_simd_without_simd.mdwn @@ -99,6 +99,8 @@ So in fact, it's actually quite simple, and this "cascade" is simply and easily propagated down to the Function Unit Dependency Matrices, stopping 32-bit operations from overwriting 8-bit and vice-versa. +# Virtual Registers + The fourth part is the grid in green, in the top left corner. This is a "virtual" to "real" one-bit table. It's here because the size of these matrices is so enormous that there is deep concern about the line @@ -117,6 +119,8 @@ if this table is not high enough (not enough IRs), the processor has to stall until an instruction is completed, so that one register becomes free. Again, another thing to keep an eye on, in simulations. +# Refinements + The second major concern is the purple matrix: the FU-to-FU one. Basically where previously we would have FU1 cover all ADDs, FU2 would cover all MUL operations, FU3 covers BRANCH and so on, now we have to multiply those @@ -124,3 +128,17 @@ numbers by **four** (64-bit ops, 32-bit ops, 16-bit and 8), which in turn means that the size of the FU-to-FU Matrix has gone up by a staggering **sixteen** times. This is not really acceptable, so we have to do something different. + +So the refinement is based on an observation that 16-bit operations of +course may be constructed from 8-bit values, and that 64-bit operations +can be constructed from 32-bit ones. So, what if we skipped the +cascade on 64 and 16 bit, and made the cascade out of just 32-bit and 8-bit? +Then, very simply, the top half of a 64-bit source register is allocated +to one Function Unit, the bottom half to the one next to it, and when it +comes to actually passing the source registers to the relevant ALU, take +from *both* FUs. + +The primary focus is on 32-bit (single-precision floating-point) performance +anyway, for 3D, so if 64-bit operations happen to have half the number of +Reservation Stations / Function Units, and block more often, we actually +don't mind so much.