From ff6037a6a857781c8bf0f426ce2843d26b48e9f1 Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Tue, 11 Dec 2018 14:19:50 +0000 Subject: [PATCH] add conversation notes --- 3d_gpu/microarchitecture.mdwn | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/3d_gpu/microarchitecture.mdwn b/3d_gpu/microarchitecture.mdwn index 0ca845c4f..126e7a1c4 100644 --- a/3d_gpu/microarchitecture.mdwn +++ b/3d_gpu/microarchitecture.mdwn @@ -361,35 +361,35 @@ ok,so continuing some thoughts-in-order notes: * scoreboards are not just scoreboards, they are dependency matrices, and there are several of them: - one for LOAD/STORE-to-LOAD/STORE: -    + most recent LOADs prevent later STOREs -    + most recent STOREs prevent later LOADs. +     * most recent LOADs prevent later STOREs +     * most recent STOREs prevent later LOADs. - one for Function-Unit to Function-Unit. -    + it exxpresses both RAW and WAW hazards through "Go_Write" +     * it exxpresses both RAW and WAW hazards through "Go_Write" and "Go_Read" signals, which are stopped from proceeding by dependent 1-bit CAM latches -    + exceptions may ALSO be made "precise" by holding a "Write prevention" +     * exceptions may ALSO be made "precise" by holding a "Write prevention"      signal.  only when the Function Unit knows that an exception is not going to occur (memory has been fetched, for example), does it release the signal -     + speculative branch execution likewise may hold a "Write prevention", +      * speculative branch execution likewise may hold a "Write prevention", however it also needs a "Go die" signal, to clear out the incorrectly-taken branch. -     + LOADs/STOREs *also* must be considered as "Functional Units" and thus +      * LOADs/STOREs *also* must be considered as "Functional Units" and thus        must also have corresponding entries (plural) in the FU-to-FU Matrix -     + it is permitted for ALUs to *BEGIN* execution (read operands are +      * it is permitted for ALUs to *BEGIN* execution (read operands are valid) without being permitted to *COMMIT*.  thus, each FU must store (buffer) results, until such time as a "commit" signal is received -     + we may need to express an inter-dependence on the instruction order +      * we may need to express an inter-dependence on the instruction order        (raising the WAW hazard line to do so) as a way to preserve execution        order.  only the oldest instructions will have this flag dropped, permitting execution that has *begun* to also reach "commit" phase. - one for Function-Unit to Registers. -     + it expresses the read and write requirements: the source +      * it expresses the read and write requirements: the source and destination registers on which the operation depends.  source registers are marked "need read", dest registers marked "need write". -     + by having *more than one* Functional Unit matrix row per ALU +      * by having *more than one* Functional Unit matrix row per ALU it becomes possible to effectively achieve "Reservation Stations" orthogonality with the Tomasulo Algorithm.  the FU row must, like RS's, take and store a copy of the src register values. -- 2.30.2