From b1969da0c1c1a6abda40d15fa3681a7cd3c106c6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Martin=20Povi=C5=A1er?= Date: Thu, 4 Jan 2024 12:16:18 +0100 Subject: [PATCH] docs: Touch on wording more MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Martin PoviĊĦer --- docs/QuickStart.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/QuickStart.md b/docs/QuickStart.md index e0efbd9..45cc34d 100644 --- a/docs/QuickStart.md +++ b/docs/QuickStart.md @@ -285,7 +285,7 @@ Even then, in our core as it stands, there's still yet another data causality vi 4. write to `regs[rd]` with data fetched in step 3 -As we trace execution from step 2 to step 4, we are delayed by one virtual cycle with the `delay(1);` statement we have just added. Because in steps 2 and 4 we are once again accessing the same memory-backed variable, this time it's `regs`, we are constraining the physical timing: The memory write in step 4 ought to be performed in the next cycle after the memory read in step 2. Now as an important detail, for both memory reads and writes, Fold considers memory accesses carried out in the cycle in which the address is presented on the memory port, so for a write this would the same cycle in which the data to be written is presented, and for reads this would be one cycle ahead of the read data being produced back. So considering the memory accesses 2, 3, 4 in our core, with similar reasoning as before, we find out step 4 can only be carried out *two cycles* past step 2 for data causality sake. To resolve the violation here, we can add another `delay(1);` statement in front of the write to the register file (this delay will be specific to the `LOAD` opcode). +As we trace execution from step 2 to step 4, we are delayed by one virtual cycle with the `delay(1);` statement we have just added. Because in steps 2 and 4 we are once again accessing the same memory-backed variable, this time it's `regs`, we are constraining the physical timing: The memory write in step 4 ought to be performed in the next cycle after the memory read in step 2. Now as an important detail, for both memory reads and writes, Fold considers memory accesses carried out in the cycle in which the address is presented on the memory port, so for a write this would be the same cycle in which the data to be written is presented, and for a read this would be one cycle ahead of the read data being produced back. So considering the memory accesses 2, 3, 4 in our core, with similar reasoning as before, we find out step 4 can only be carried out *two cycles* past step 2 for data causality sake. To resolve the violation here, we can add another `delay(1);` statement in front of the write to the register file (this delay will be specific to the `LOAD` opcode). Once we have added those new `delay(1);` statements to help with data causality, we can remove the one final `delay(1);` statement at the end of the loop body that we introduced to avoid usage conflicts with execution paths looping back, since this final delay is now redundant.