Deployed 9cfaeb6 with MkDocs version: 1.5.3

um/arch/index.html

@@ -1200,7 +1200,7 @@ <h1 id="architecture">Architecture</h1>
 </ul>
 </li>
 <li>
-<p><strong>Peripheral Domain</strong>:</p>
+<p><strong>Peripherals</strong>:</p>
 <ul>
 <li>Generic timers</li>
 <li>PWM timers</li>

um/sw/index.html

@@ -598,9 +598,9 @@
 </li>
 
           <li class="md-nav__item">
-  <a href="#linux-programs" class="md-nav__link">
+  <a href="#gpos-eg-linux-programs" class="md-nav__link">
     <span class="md-ellipsis">
-      Linux programs
+      GPOS (e.g., Linux) programs
     </span>
   </a>
 
@@ -622,9 +622,9 @@
       <ul class="md-nav__list">
 
           <li class="md-nav__item">
-  <a href="#baremetal-offload" class="md-nav__link">
+  <a href="#baremetal-offload-non-openmp-based" class="md-nav__link">
     <span class="md-ellipsis">
-      Baremetal offload
+      Baremetal offload (non OpenMP based)
     </span>
   </a>
 
@@ -733,9 +733,9 @@
 </li>
 
           <li class="md-nav__item">
-  <a href="#linux-programs" class="md-nav__link">
+  <a href="#gpos-eg-linux-programs" class="md-nav__link">
     <span class="md-ellipsis">
-      Linux programs
+      GPOS (e.g., Linux) programs
     </span>
   </a>
 
@@ -757,9 +757,9 @@
       <ul class="md-nav__list">
 
           <li class="md-nav__item">
-  <a href="#baremetal-offload" class="md-nav__link">
+  <a href="#baremetal-offload-non-openmp-based" class="md-nav__link">
     <span class="md-ellipsis">
-      Baremetal offload
+      Baremetal offload (non OpenMP based)
     </span>
   </a>
 
@@ -834,19 +834,18 @@ <h1 id="software-stack">Software Stack</h1>
 <li>Linux</li>
 </ul>
 <p>Therefore, we defer the reader to Cheshire's Software Stack description for more information.</p>
-<p>Programs compiled for Carfield that requiree additional, Carfield-specific drivers (for domains'
-offload, peripheral control, etc) are linked against Cheshire's static library (<code>libcheshire.a</code>).
-This operation is transparent to the programmer, that can take advantage of Cheshire's device
-drivers and SW routines within Carfield seamlessly.</p>
+<p>Programs compiled for Carfield are linked against Cheshire's static library (<code>libcheshire.a</code>). This
+operation is transparent to the programmer, that can take advantage of Cheshire's device drivers and
+SW routines within Carfield seamlessly.</p>
 <p>Provided the equivalence and reuse between Carfield and Cheshire, in this page we focus on
 Carfield-specific SW components and build flow, with an emphasis on domains different than Cheshire.</p>
 <h2 id="compiler-requirements">Compiler requirements</h2>
 <p>General-purpose processing elements (PEs) integrated in Carfield implement the RISC-V ISA, targeting
 either RV64 (<em>host domain</em>) or RV32 (all the others: <em>safe domain</em>, <em>secure domain</em>, <em>integer PMCA</em>,
 and <em>vectorial PMCA</em>).</p>
-<p>To build programs written in plain C for a Carfield domain with the base ISA and its regular
-extensions (namely, <code>RV64G</code> and <code>RV32IMACF</code>) <em>without</em> using <em>custom</em> extensions that each domain
-provide, you simply need vanilla RV64 and RV32 compilers.</p>
+<p>To build programs for a Carfield domain with the base ISA and its regular extensions (namely,
+<code>RV64G</code> and <code>RV32IMACF</code>) <em>without</em> using <em>custom</em> extensions that each domain provide, you simply
+need vanilla RV64 and RV32 compilers.</p>
 <p>Otherwise, to use <em>custom</em> instruction supported in HW for a domain, specific compiler support is
 required. We are working to improve compiler support by providing pointers to pre-built releases or
 a container-based build flow.</p>
@@ -884,27 +883,28 @@ <h3 id="baremetal-programs-bmps">Baremetal programs (BMPs)</h3>
 <hr />
 <p>As in Cheshire, Carfield programs can be created to be executed from several memory locations:</p>
 <ul>
-<li>Dynamic SPM (<code>l2</code>): the linkerscript is provided in Carfield's <code>sw/link/</code> folder, since Dynamic
-  SPM is not integrated in the minimal Cheshire</li>
-<li>LLC SPM (<code>spm</code>): valid when the LLC is configured as such. In Carfield, half of the LLC is
+<li>Dynamic SPM (<code>*.l2.elf</code>): the linkerscript is provided in Carfield's <code>sw/link/</code> folder, since
+  Dynamic SPM is not integrated in the minimal Cheshire</li>
+<li>LLC SPM (<code>*.spm.elf</code>): valid when the LLC is configured as such. In Carfield, half of the LLC is
   configured as SPM from the boot ROM during system bringup, as this is the default behavior in
   Cheshire.</li>
-<li>DRAM (<code>dram</code>): the HyperRAM</li>
+<li>DRAM (<code>*.dram.elf</code>): the off-chip DRAM, e.g., the HyperRAM</li>
 </ul>
 <p>For example, to build a specific BMP (here <code>sw/tests/bare-metal/hostd/helloworld.c</code> to be run on
 Cheshire) executing from the Dynamic SPM, run:</p>
 <pre><code>make sw/tests/bare-metal/hostd/helloworld.car.l2.elf
 </code></pre>
 <p>To create the same program executing from DRAM, <code>sw/tests/bare-metal/hostd/helloworld.car.dram.elf</code>
 can instead be built from the same source. Depending on their assumptions and behavior, not all
-programs may be built to execute from both locations.</p>
-<h3 id="linux-programs">Linux programs</h3>
-<p>When executing <em>host domain</em> programs in Linux (on FPGA/ASIC targets) that require access to memory
-mapped components of other domains, SW intervention is needed to map virtual to physical addresses,
-since domains different than the host <em>currently</em> lack support for HW-based virtual memory
-translation.</p>
-<p>In the current SW stack, this mapping is already provided and hence transparent to the user. Test
-programs targeting Linux that require it are located in different folder, <code>sw/tests/linux/&lt;domain&gt;</code>.</p>
+programs may be built to execute from all locations.</p>
+<h3 id="gpos-eg-linux-programs">GPOS (e.g., Linux) programs</h3>
+<p>When executing <em>host domain</em> programs on a GPOS such as Linux (on FPGA/ASIC targets) requiring
+access to memory mapped components of other domains, SW intervention is needed to map virtual to
+physical addresses, since domains different than the host <em>currently</em> lack support for HW-based
+virtual memory translation.</p>
+<p>In the current SW stack, this mapping is already provided and hence transparent to the user. For
+example, test programs targeting Linux that require it are located in different folder,
+<code>sw/tests/linux/&lt;domain&gt;</code>.</p>
 <h2 id="inter-domain-offload">Inter-domain offload</h2>
 <p>Offload of programs to Carfield domains involves:</p>
 <ul>
@@ -915,28 +915,28 @@ <h2 id="inter-domain-offload">Inter-domain offload</h2>
 <p>Programs can be offloaded with:</p>
 <ul>
 <li>
-<p><strong>Simple baremetal offload (BMO)</strong>, recommended for regression tests use cases that are simple
-  enough to be executed with cycle-accurate RTL simulations. For instance, this can be the case of
-  dynamic timing analysis (DTA) carried out during an ASIC development cycle.</p>
+<p><strong>Simple baremetal offload (BMO)</strong>, useful for regression tests that are simple enough to be
+  executed with cycle-accurate RTL simulations. For instance, this can be the case of dynamic timing
+  analysis (DTA) carried out during an ASIC development cycle.</p>
 </li>
 <li>
 <p><strong>The <a href="https://www.openmp.org/">OpenMP</a> API</strong>, recommended when developing SW for Carfield on a
   FPGA or, eventually, ASIC implementing Carfield, because of the ready-to-use OS support
-  (currently, Linux). Usage of the OpenMP API with non OS-directed (baremetal) SW can be supported,
-  but is mostly suited for heterogeneous embedded systems with highly constrained resources</p>
+  (currently, Linux). Note that usage of the OpenMP API with non OS-directed (baremetal) SW can be
+  supported, and would eventually replace the BMO described above.</p>
 </li>
 </ul>
 <p>In the following, we briefly describe both.</p>
 <hr />
 <p><strong>Note for the reader</strong></p>
 <p>Since by default all domains are clock gated and isolated after POR except for the <em>host domain</em>
 (Cheshire), as described in <a href="../arch/">Architecture</a>, the wake-up process must be handled from
-the C source code.</p>
-<h3 id="baremetal-offload">Baremetal offload</h3>
+the application source code.</p>
+<h3 id="baremetal-offload-non-openmp-based">Baremetal offload (non OpenMP based)</h3>
 <p>For BMO, the offloader takes care of bootstrapping the target device ELF in the correct memory
 location, initializing the target and launching its execution through a simple ELF Loader. The ELF
 Loader source code is located in the offloader's SW directory, and follows a naming convention:</p>
-<pre><code>&lt;target_device&gt;_offloader_&lt;blocking | non_blocking&gt;.c 
+<pre><code>&lt;target_device&gt;_offloader_&lt;blocking|non_blocking&gt;.c 
 </code></pre>
 <p>The target device's ELF is included into the offloader's ELF Loader as a <em>header file</em>. The target
 device's ELF sections are first pre-processed offline to extract instruction addresses.The resulting
@@ -962,17 +962,18 @@ <h3 id="baremetal-offload">Baremetal offload</h3>
    from each integer PMCA regression test</li>
 </ol>
 <p>The resulting offloader ELF's name reads:</p>
-<pre><code>&lt;target_device&gt;_offloader_&lt;blocking | non_blocking&gt;.&lt;target_device_test_name&gt;.car.&lt;l2 | spm | dram&gt;.elf
+<pre><code>&lt;target_device&gt;_offloader_&lt;blocking|non_blocking&gt;.&lt;target_device_test_name&gt;.car.&lt;l2|spm|dram&gt;.elf
 </code></pre>
 <p>According to the memory location where the BMP will be executed.</p>
 <p>The final offloader ELF can be preloaded with simulation methods described in the
 <a href="../../tg/sim/">Simulation</a> section, and can be built again as explained above.</p>
 <hr />
-<p><em>Note for the reader</em></p>
+<p><strong>Note for the reader</strong></p>
 <p>BMO is in general not recommended for developing SW for Carfield, as it was introduced during ASIC
 development cycle and can be an effective litmus test to find and fix HW bugs, or during DTA.</p>
 <p>For SW development on Carfield and in particular domain-driven offload, it is recommended to use
-OpenMP offload on FPGA/ASIC, described below.</p>
+OpenMP offload on FPGA/ASIC, described below. The latter will eventually replace the simple BMO also
+for baremetal regression checks in future releases of the project.</p>
 <h3 id="openmp-offload-recommended-use-on-fpgaasic">OpenMP offload (recommended: use on FPGA/ASIC)</h3>
 <p>TODO Cyril</p>
 <h2 id="external-benchmarks">External benchmarks</h2>