From: Andrey Miroshnikov Date: Wed, 9 Aug 2023 18:27:24 +0000 (+0000) Subject: inorder_model: Formatting fixes. X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=c2da438b18ec2805a5805c86f9c6bbafdd2abf42;p=libreriscv.git inorder_model: Formatting fixes. --- diff --git a/3d_gpu/architecture/inorder_model.mdwn b/3d_gpu/architecture/inorder_model.mdwn index 59f8d5abb..126c864c5 100644 --- a/3d_gpu/architecture/inorder_model.mdwn +++ b/3d_gpu/architecture/inorder_model.mdwn @@ -18,7 +18,10 @@ task to develop the model for the simulator first. The model will be used to determine performance (and eventually to write the HDL). # The Model -## Brief [src](https://bugs.libre-soc.org/show_bug.cgi?id=1039) +## Brief + +* [Bug description](https://bugs.libre-soc.org/show_bug.cgi?id=1039) + The model for the Single-Issue In-Order core needs to be added to the in-house Python simulator (`ISACaller`, called by `pypowersim`), which will allow basic *performance estimates*. @@ -29,7 +32,11 @@ is *completely standalone*. Eventually, Cavatools code will be studied to extract and re-implement in Python power consumption estimation. -## Task given [src](https://bugs.libre-soc.org/show_bug.cgi?id=1039#c1) [src](https://libre-soc.org/irclog/%23libre-soc.2023-05-02.log.html#t2023-05-02T10:51:45) +## Task given + +* [Bug comment #1](https://bugs.libre-soc.org/show_bug.cgi?id=1039#c1) +* [IRC log](https://libre-soc.org/irclog/%23libre-soc.2023-05-02.log.html#t2023-05-02T10:51:45) + An offline instruction ordering analyser need to be written that models a (simple, initially V3.0-only) **in-order core** and gives an estimate of instructions per clock (IPC). @@ -49,7 +56,7 @@ Input should be: - Instruction with its operands (as assembler listing) - plus an optional memory-address and whether it is read or written. -The input will come from as trace output from the ISACaller simulator, +The input will come as a trace output from the ISACaller simulator, [see bug comments #7-#16](https://bugs.libre-soc.org/show_bug.cgi?id=1039#c7) Some classes needed which "model" pipeline stages: fetch, decode, issue, @@ -76,26 +83,27 @@ and thus a STALL will occur when `cmpi` is in the decode phase. The output diagram will look like this: -| clk # | fetch | decode | issue | execute | -| 1 | addi 3, 4, 5 | | | | | -| 2 | cmpi 1, 0, 3, 4 | addi 3, 4, 5 | | | -| 3 | STALL | cmpi 1, 0, 3, 4 | addi 3, 4, 5 | | -| 4 | STALL | cmpi 1, 0, 3, 4 | | addi 3, 4, 5 | -| 5 | ld 1, 2(3) | | cmpi 1, 0, 3, 4 | | -| 6 | | ld 1, 2(3) | | cmpi 1, 0, 3, 4 | -| 7 | | | ld 1, 2(3) | | -| 8 | | | | ld 1, 2(3) | +| clk # | fetch | decode | issue | execute | +|-------|--------------|--------------|--------------|--------------| +| 1 | addi 3,4,5 | | | | +| 2 | cmpi 1,0,3,4 | addi 3,4,5 | | | +| 3 | STALL | cmpi 1,0,3,4 | addi 3,4,5 | | +| 4 | STALL | cmpi 1,0,3,4 | | addi 3,4,5 | +| 5 | ld 1,2(3) | | cmpi 1,0,3,4 | | +| 6 | | ld 1,2(3) | | cmpi 1,0,3,4 | +| 7 | | | ld 1,2(3) | | +| 8 | | | | ld 1,2(3) | Explanation: - 1: Fetched `addi`. - 2: Decoded `addi`, fetched `cmpi`. - 3: Issued `addi`, decoded `cmpi`, must stall decode phase, stop fetching. - 4: Executed `addi`, everything else stalled. - 5: Issued `cmpi`, fetched `ld`. - 6: Executed `cmpi`, decoded `ld`. - 7: Issued `ld`. - 8: Executed `ld`. + 1: Fetched addi. + 2: Decoded addi, fetched cmpi. + 3: Issued addi, decoded cmpi, must stall decode phase, stop fetching. + 4: Executed addi, everything else stalled. + 5: Issued cmpi, fetched ld. + 6: Executed cmpi, decoded ld. + 7: Issued ld. + 8: Executed ld. For this initial model, it is assumed that all instructions take one cycle to execute (not the case for mul/div etc., but will be dealt with later.