From: Luke Kenneth Casson Leighton Date: Wed, 12 Dec 2018 12:51:10 +0000 (+0000) Subject: update conversation X-Git-Tag: convert-csv-opcode-to-binary~4779 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=aaf8d59b3e644037632023db60be56319cfecf95;p=libreriscv.git update conversation --- diff --git a/3d_gpu/microarchitecture.mdwn b/3d_gpu/microarchitecture.mdwn index 7b95d02f3..e7da4e7f7 100644 --- a/3d_gpu/microarchitecture.mdwn +++ b/3d_gpu/microarchitecture.mdwn @@ -363,36 +363,36 @@ 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. -- one for Function-Unit to Function-Unit. -    - it expresses both RAW and WAW hazards through "Go_Write" +* one for LOAD/STORE-to-LOAD/STORE + - most recent LOADs prevent later STOREs + - most recent STOREs prevent later LOADs. +* one for Function-Unit to Function-Unit. + - it expresses 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.