docs: Touch on wording more

Signed-off-by: Martin Povišer <povik@cutebit.org>

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.