Deploying to gh-pages from @ 43a5652 🚀

master/.buildinfo

@@ -1,4 +1,4 @@
 # Sphinx build info version 1
 # This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
-config: 708d1915cf518e6699309743136fe980
+config: aace8e5615db16234232529189be12e1
 tags: 645f666f9bcd5a90fca523b33c5a78b7

master/VexiiRiscv/BranchPrediction/index.html

@@ -356,7 +356,7 @@ <h2>BtbPlugin<a class="headerlink" href="#btbplugin" title="Permalink to this he
 <p>Note that it may help to not make the BTB learn when there has been a non-taken branch.</p>
 <ul class="simple">
 <li><p>The BTB don't need to predict non-taken branch</p></li>
-<li><p>Keep the BTB entry for something more usefull</p></li>
+<li><p>Keep the BTB entry for something more useful</p></li>
 <li><p>For configs in which multiple instruction can reside in a single fetch word (ex dual issue with RVC),
 multiple branch/jump instruction can reside in a single fetch word =&gt; need for compromises,
 and hope that some of the branch/jump in the chunk are rarely taken.</p></li>
@@ -421,7 +421,7 @@ <h2>LearnPlugin<a class="headerlink" href="#learnplugin" title="Permalink to thi
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>
 
 

master/VexiiRiscv/Debug/index.html

@@ -399,7 +399,7 @@ <h2>EmbeddedRiscvJtag<a class="headerlink" href="#embeddedriscvjtag" title="Perm
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>
 
 

master/VexiiRiscv/Decode/index.html

@@ -443,7 +443,7 @@ <h3>Elaboration<a class="headerlink" href="#elaboration" title="Permalink to thi
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>
 
 

master/VexiiRiscv/Docker/index.html

@@ -354,7 +354,7 @@ <h2>Linux and MacOS X<a class="headerlink" href="#linux-and-macos-x" title="Perm
 </pre></div>
 </div>
 <p>After the image has been fetched and the virtual X server has started you should
-be greated with an XFCE4 desktop in a VNC viewer</p>
+be greeted with an XFCE4 desktop in a VNC viewer</p>
 </section>
 <section id="windows">
 <h2>Windows<a class="headerlink" href="#windows" title="Permalink to this heading"></a></h2>
@@ -435,7 +435,7 @@ <h2>Opening the traces with Konata<a class="headerlink" href="#opening-the-trace
 <a class="reference internal image-reference" href="../../_images/Screenshot_20241203_151217.png"><img alt="Konata Icon" src="../../_images/Screenshot_20241203_151217.png" style="width: 400px;" /></a>
 <p>Next load the konata log by going into the folder as shown in the picture</p>
 <a class="reference internal image-reference" href="../../_images/Screenshot_20241203_151018.png"><img alt="Load konata log" src="../../_images/Screenshot_20241203_151018.png" style="width: 400px;" /></a>
-<p>You should be greated with a colorful representation of the instructions
+<p>You should be greeted with a colorful representation of the instructions
 in the RISC-V pipeline during boot up</p>
 <a class="reference internal image-reference" href="../../_images/Screenshot_20241203_151124.png"><img alt="Pipeline visualization" src="../../_images/Screenshot_20241203_151124.png" style="width: 400px;" /></a>
 </section>
@@ -510,7 +510,7 @@ <h2>Using the build environment<a class="headerlink" href="#using-the-build-envi
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>
 
 

master/VexiiRiscv/Execute/custom.html

@@ -573,7 +573,7 @@ <h3>Conclusion<a class="headerlink" href="#conclusion" title="Permalink to this
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>
 
 

master/VexiiRiscv/Execute/fpu.html

@@ -370,7 +370,7 @@ <h2>Area / Timings options<a class="headerlink" href="#area-timings-options" tit
 and if the user provide floating point constants which are subnormals number,
 they will be considered as 2^exp_subnormal numbers.</p>
 <p>In practice those two option do not seems to creates issues (for regular use cases),
-as it was tested by running debian with various software and graphical environnements.</p>
+as it was tested by running debian with various software and graphical environments.</p>
 </section>
 <section id="optimized-software">
 <h2>Optimized software<a class="headerlink" href="#optimized-software" title="Permalink to this heading"></a></h2>
@@ -413,7 +413,7 @@ <h2>Optimized software<a class="headerlink" href="#optimized-software" title="Pe
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>
 
 

master/VexiiRiscv/Execute/index.html

@@ -379,7 +379,7 @@ <h1>Execute<a class="headerlink" href="#execute" title="Permalink to this headin
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>
 
 

master/VexiiRiscv/Execute/introduction.html

@@ -381,7 +381,7 @@ <h1>Introduction<a class="headerlink" href="#introduction" title="Permalink to t
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>
 
 

master/VexiiRiscv/Execute/plugins.html

@@ -444,11 +444,11 @@ <h3>CsrAccessPlugin<a class="headerlink" href="#csraccessplugin" title="Permalin
 <li><p>Implement the CSR read and write instruction in the execute pipeline</p></li>
 <li><p>Provide an API for other plugins to specify the mapping between the CSR registers and the CSR instruction</p></li>
 </ul>
-<p>See the <a class="reference internal" href="../Privileges/index.html#privileges"><span class="std std-ref">Privileges</span></a> chapter for more informations.</p>
+<p>See the <a class="reference internal" href="../Privileges/index.html#privileges"><span class="std std-ref">Privileges</span></a> chapter for more information.</p>
 </section>
 <section id="envplugin">
 <h3>EnvPlugin<a class="headerlink" href="#envplugin" title="Permalink to this heading"></a></h3>
-<p>See the <a class="reference internal" href="../Privileges/index.html#privileges"><span class="std std-ref">Privileges</span></a> chapter for more informations.</p>
+<p>See the <a class="reference internal" href="../Privileges/index.html#privileges"><span class="std std-ref">Privileges</span></a> chapter for more information.</p>
 <ul class="simple">
 <li><p>Implement a few instructions as MRET, SRET, ECALL, EBREAK, FENCE.I, WFI by producing hardware traps</p></li>
 </ul>
@@ -485,7 +485,7 @@ <h3>EnvPlugin<a class="headerlink" href="#envplugin" title="Permalink to this he
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>
 
 

master/VexiiRiscv/Fetch/index.html

@@ -329,9 +329,9 @@
   <section id="fetch">
 <h1>Fetch<a class="headerlink" href="#fetch" title="Permalink to this heading"></a></h1>
 <p>The goal of the fetch pipeline is to provide the CPU with a stream of words in which the instructions to execute are presents.
-So more precisely, the fetch pipeline doesn't realy have the notion of instruction, but instead, just provide memory aligned chunks of memory block (ex 64 bits).
+So more precisely, the fetch pipeline doesn't really have the notion of instruction, but instead, just provide memory aligned chunks of memory block (ex 64 bits).
 Those chunks of memory (word) will later be handled by the &quot;AlignerPlugin&quot; to extract the instruction to be executed (and also handle the decompression in the case of RVC).</p>
-<p>Here is an example of fetch architecture with an instruction cache, branch predictor aswell as a prefetcher.</p>
+<p>Here is an example of fetch architecture with an instruction cache, branch predictor as well as a prefetcher.</p>
 <img alt="../../_images/fetch_l1.png" src="../../_images/fetch_l1.png" />
 <p>A few plugins operate in the fetch stage :</p>
 <ul class="simple">
@@ -414,7 +414,7 @@ <h2>FetchL1Plugin<a class="headerlink" href="#fetchl1plugin" title="Permalink to
 </table>
 <p>To improve the performances, consider first increasing the number of cache ways to 4.
 The hardware prefetcher can help, but it is very variable in function of the workload. If you enable it, then consider
-increasing the number of refill slots to at least 2, idealy 3.</p>
+increasing the number of refill slots to at least 2, ideally 3.</p>
 </section>
 <section id="prefetchernextlineplugin">
 <h2>PrefetcherNextLinePlugin<a class="headerlink" href="#prefetchernextlineplugin" title="Permalink to this heading"></a></h2>
@@ -481,7 +481,7 @@ <h2>HistoryPlugin<a class="headerlink" href="#historyplugin" title="Permalink to
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>
 
 

master/VexiiRiscv/Framework/index.html

@@ -739,7 +739,7 @@ <h2>Pipeline API<a class="headerlink" href="#pipeline-api" title="Permalink to t
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>
 
 

master/VexiiRiscv/HowToUse/index.html

@@ -613,7 +613,7 @@ <h3>Known issues<a class="headerlink" href="#known-issues" title="Permalink to t
 <h2>Using Konata<a class="headerlink" href="#using-konata" title="Permalink to this heading"></a></h2>
 <p>Konata is a Node JS application started with Electron, so you will have to install npm with your package manager of your system.</p>
 <p>You can setup and start Konata by cloning it and using npm</p>
-<p>The make comman will execute npm electron ., which will open the Konata window</p>
+<p>The make command will execute npm electron ., which will open the Konata window</p>
 <div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git clone https://github.com/shioyadan/konata.git
 <span class="nb">cd</span> konata
 npm install
@@ -652,7 +652,7 @@ <h2>Using Konata<a class="headerlink" href="#using-konata" title="Permalink to t
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>
 
 

master/VexiiRiscv/Introduction/index.html

@@ -458,7 +458,7 @@ <h2>Check list<a class="headerlink" href="#check-list" title="Permalink to this
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>
 
 

master/VexiiRiscv/Memory/index.html

@@ -430,7 +430,7 @@ <h2>With L1<a class="headerlink" href="#with-l1" title="Permalink to this headin
 <p>To improve the performances, consider first increasing the number of cache ways to 4.</p>
 <p>The store buffer will help a lot with the store bandwidth by allowing the CPU to not be blocked by every store miss.
 The hardware prefetcher will help with both store/load bandwidth (but if the store buffer is already enabled, it will not
-realy increase the store bandwidth).</p>
+really increase the store bandwidth).</p>
 <p>For the hardware prefetcher to stretch its leg, consider using 4 refill/writeback slots. This will also help the store buffer.</p>
 <section id="prefetching">
 <h3>Prefetching<a class="headerlink" href="#prefetching" title="Permalink to this heading"></a></h3>
@@ -492,7 +492,7 @@ <h4>PrefetchRptPlugin<a class="headerlink" href="#prefetchrptplugin" title="Perm
 <h4>performance measurements<a class="headerlink" href="#performance-measurements" title="Permalink to this heading"></a></h4>
 <p>Here are a few performance gain measurements done on litex with a :</p>
 <ul class="simple">
-<li><p>quad-core RV64GC running at 200 Mhz</p></li>
+<li><p>quad-core RV64GC running at 200 MHz</p></li>
 <li><p>16 KB L1 cache for each core</p></li>
 <li><p>512 KB of l2 cache shared (128 bits data bus)</p></li>
 <li><p>4 refill slots + 4 writeback slots + 32 entry store queue + 4 slots store queue</p></li>
@@ -539,14 +539,14 @@ <h4>performance measurements<a class="headerlink" href="#performance-measurement
 <h3>Hardware Memory coherency<a class="headerlink" href="#hardware-memory-coherency" title="Permalink to this heading"></a></h3>
 <p>Hardware memory coherency, is the feature which allows multiple memory agents (ex : CPU, DMA, ...)
 to work on the same memory locations and notify each others when they change their contents.
-Without it, the CPU software would have to manualy flush/invalidate their L1 caches to keep things in sync.</p>
+Without it, the CPU software would have to manually flush/invalidate their L1 caches to keep things in sync.</p>
 <p>There is mostly 2 kinds of hardware memory coherency architecture :</p>
 <ul class="simple">
 <li><p>By invalidation : When a CPU/DMA write some memory, it notifies the other CPU caches that they should invalidate any
-old copy that they have of the written memory locations. This is generaly used for write-through L1 caches.
+old copy that they have of the written memory locations. This is generally used for write-through L1 caches.
 This isn't what VexiiRiscv implements.</p></li>
-<li><p>By permition : Memory blocks copies (typicaly 64 aligned bytes blocks which resides in L1 cache lines) can have multiple states.
-Some of which provide read only accesses, while others provide read/write accesses. This is generaly used in write-back L1 caches,
+<li><p>By permission : Memory blocks copies (typically 64 aligned bytes blocks which resides in L1 cache lines) can have multiple states.
+Some of which provide read only accesses, while others provide read/write accesses. This is generally used in write-back L1 caches,
 and this is what VexiiRiscv uses.</p></li>
 </ul>
 <p>In VexiiRiscv, the hardware memory coherency (L1) with other memory agents (CPU, DMA, L2, ..) is supported though a MESI implementation which can be bridged to a tilelink memory bus.</p>
@@ -580,17 +580,17 @@ <h3>Memory system<a class="headerlink" href="#memory-system" title="Permalink to
 <section id="why-tilelink">
 <h4>Why Tilelink<a class="headerlink" href="#why-tilelink" title="Permalink to this heading"></a></h4>
 <p>So, why using Tilelink, while most of the FPGA industry is using AXI4 ? Here are some issues / complexities that AXI4 bring with it.
-(Dolu1990 opinions, with the perspective of using it in FPGA, with limited man power, don't see this as an absolute truth)</p>
+(Dolu1990 opinions, with the perspective of using it in FPGA, with limited manpower, don't see this as an absolute truth)</p>
 <ul class="simple">
 <li><p>The AXI4 memory ordering, while allowing CPU/DMA to get preserved ordering between transactions with the same ID,
 is creating complexities and bottlenecks in the memory system. Typically in the interconnect decoders
-to avoid dead-locks, but even more in L2 caches and DRAM controllers  which ideally would handle every request out of order.
+to avoid dead-locks, but even more in L2 caches and DRAM controllers which ideally would handle every request out of order.
 Tilelink instead specify that the CPU/DMAs shouldn't assume any memory ordering between inflight transactions.</p></li>
 <li><p>AXI4 specifies that memory read response channel can interleave between multiple ongoing bursts.
 While this can be use full for very large burst (which in itself is a bad idea, see next chapter),
 this can lead to big area overhead for memory bridges, especially with width adapters.
-Tilelink doesn't allows this behaviour.</p></li>
-<li><p>AXI4 splits write address from write data, which add additional synchronisations points in the interconnect decoders/arbiters and peripherals (bad for timings)
+Tilelink doesn't allows this behavior.</p></li>
+<li><p>AXI4 splits write address from write data, which add additional synchronizations points in the interconnect decoders/arbiters and peripherals (bad for timings)
 as well as potentially decrease performances when integrating multiple AXI4 modules which do not use similar address/data timings.</p></li>
 <li><p>AXI4 isn't great for low latency memory interconnects, mostly because of the previous point.</p></li>
 <li><p>AXI4 splits read and write channels (ar r / aw w b), which mostly double the area cost of address decoding/routing for DMA and non-coherent CPUs.</p></li>
@@ -611,15 +611,15 @@ <h4>Efficiency cookbook<a class="headerlink" href="#efficiency-cookbook" title="
 <li><p>DMA should access up to 64 aligned bytes per burst, this should be enough to reach peak bandwidth. No need for 4KB Rambo bursts.
 Asking a system to support bursts bigger than 64 aligned bytes can lead to extra cost, as it create new ordering constraints between the memory block of the burst.
 For instance in a L2 cache it can lead to implementation of a reorder buffer to deal between transaction which hit/miss the cache. Adding extra complexity/area/timings to deal with.
-Additionaly, big burst can create high latency spike for other agents (CPU/DMA).</p></li>
+Additionally, big burst can create high latency spike for other agents (CPU/DMA).</p></li>
 <li><p>DMA should only do burst aligned memory accesses (to keep them easily portable to Tilelink)</p></li>
 <li><p>It is fine for DMA to over fetch (let's say you need 48 bytes, but access aligned 64 bytes instead),
 as long as the bulk of the memory bandwidth is not doing it.</p></li>
 <li><p>DMA should avoid doing multiple accesses in a 64 byte block if possible, and instead use a single access.
 This can preserve the DRAM controller bandwidth (see DDR3/4/5 comments above),
 but also, L2/L3 cache designs may block any additional memory request targeting a memory block which is already under operation.</p></li>
-<li><p>When a DMA start a write burst, it has to complet as fast as possible. The reason is that the interconnect can lock itself on your burst until you finish it.</p></li>
-<li><p>When a DMA start a read burst, it should avoid putting backpresure on the read responses. The reason is that the interconnect can lock itself on your burst until you finish it.</p></li>
+<li><p>When a DMA start a write burst, it has to complete as fast as possible. The reason is that the interconnect can lock itself on your burst until you finish it.</p></li>
+<li><p>When a DMA start a read burst, it should avoid putting backpressure on the read responses. The reason is that the interconnect can lock itself on your burst until you finish it.</p></li>
 </ul>
 </section>
 </section>
@@ -655,7 +655,7 @@ <h4>Efficiency cookbook<a class="headerlink" href="#efficiency-cookbook" title="
     <!-- source/_templates/footer.html -->
 
     <div class="doc-footer-current-version"><p>
-    Version: master git~666c586 2024-12-27
+    Version: master git~43a5652 2024-12-27
     </p></div>