Merge branch 'esl-epfl:main' into add_hyperbus

Makefile

@@ -98,7 +98,7 @@ environment.yml: python-requirements.txt
 ## @section Installation
 
 ## Generates mcu files core-v-mini-mcu files and build the design with fusesoc
-## @param CPU=[cv32e20(default),cv32e40p,cv32e40x]
+## @param CPU=[cv32e20(default),cv32e40p,cv32e40x,cv32e40px]
 ## @param BUS=[onetoM(default),NtoM]
 ## @param MEMORY_BANKS=[2(default) to (16 - MEMORY_BANKS_IL)]
 ## @param MEMORY_BANKS_IL=[0(default),2,4,8]
@@ -193,7 +193,7 @@ questasim-sim-opt-upf: questasim-sim
 	$(MAKE) -C build/openhwgroup.org_systems_core-v-mini-mcu_0/sim-modelsim opt-upf
 
 ## VCS simulation
-## @param CPU=cv32e20(default),cv32e40p,cv32e40x
+## @param CPU=cv32e20(default),cv32e40p,cv32e40x,cv32e40px
 ## @param BUS=onetoM(default),NtoM
 vcs-sim:
 	$(FUSESOC) --cores-root . run --no-export --target=sim --tool=vcs $(FUSESOC_FLAGS) --build openhwgroup.org:systems:core-v-mini-mcu ${FUSESOC_PARAM} 2>&1 | tee buildsim.log

docs/source/How_to/eXtendingHEEP.md

@@ -2,14 +2,14 @@
 
 `X-HEEP` is meant to be extended with your own custom IPs. `X-HEEP` itself posseses a hardware-software framework capable of working standalone. If you want to extend it, you will need to merge your hardware and software with `X-HEEP`'s.
 
-For this purpose we support the [CORE-V-XIF](https://docs.openhwgroup.org/projects/openhw-group-core-v-xif/en/latest/intro.html) interface with the [cv32e40x](https://github.com/openhwgroup/cv32e40x) RISCV-CPU, and we expose master and slave ports to/from the bus.
+For this purpose we support the [CV-X-IF](https://docs.openhwgroup.org/projects/openhw-group-core-v-xif/en/latest/intro.html) interface with the [cv32e40x](https://github.com/openhwgroup/cv32e40x) or [cv32e40px](https://github.com/esl-epfl/cv32e40px) RISCV-CPU, and we expose master and slave ports to/from the bus.
 
-> `X-HEEP` currently uses the revision [`0.9.0`](https://github.com/openhwgroup/cv32e40x/commit/f17028f2369373d9443e4636f2826218e8d54e0f) of OpenHW Groups's `cv32e40x` core to implement the `CORE-V-XIF`. It is recommended to use the same revision in peripheral IPs to prevent conflicts during RTL compilation.
+> We recommend using the `cv32e40px` for pairing with your CV-X-IF compliant coprocessor. If you choose to use the `cv32e40x`, `X-HEEP` currently uses the revision [`0.9.0`](https://github.com/openhwgroup/cv32e40x/commit/f17028f2369373d9443e4636f2826218e8d54e0f). It is recommended to use the same revision in peripheral IPs to prevent conflicts during RTL compilation.
 
 Here you can find a list of `X-HEEP` based open-source examples. If you want to include your project in this list, please open an issue with a link to your repository.
 
 * [CGRA-X-HEEP](https://github.com/esl-epfl/cgra_x_heep): A CGRA loosely coupled with X-HEEP.
-* [F-HEEP](https://github.com/davidmallasen/F-HEEP): System integrating [fpu_ss](https://github.com/pulp-platform/fpu_ss) into X-HEEP via the eXtension interface and cv32e40x.
+* [F-HEEP](https://github.com/davidmallasen/F-HEEP): System integrating [fpu_ss](https://github.com/pulp-platform/fpu_ss) into X-HEEP via the eXtension interface and cv32e40px.
 * [KALIPSO](https://github.com/vlsi-lab/ntt_intt_kyber) and [KRONOS](https://github.com/vlsi-lab/keccak_integration/tree/keccak_xheep): Loosely-coupled, post-quantum cryptography accelerators for NTT/INTT and Keccak hash function integrated into X-HEEP.
 
 
@@ -98,7 +98,7 @@ To achieve this:
 
 * Create a new top-level repository (`BASE`) and vendorize (or add as git submodules) both your `CORE-V-XIF/OBI` compliant coprocessor/accelerator and `X-HEEP`.
 * Copy the `x-heep/hw/system/x_heep_system.sv` as your new top-level module. Then modify it as needed to include your co-processor and connect it to the `core_v_mini_mcu` with the `XIF`. The `XIF` SystemVerilog interface must be instantiated in the top-level module, where `X-HEEP` and your co-processor are connected. See the `X-HEEP` [testbench](./../../../tb/testharness.sv) as an example.
-* Before building software remember to run `make mcu-gen CPU=cv32e40x`.
+* Before building software remember to run `make mcu-gen CPU=cv32e40px`.
 
 To add this new top-level module to the simulation/synthesis flow you can extend the [FuseSoC](https://fusesoc.readthedocs.io/en/stable/user/index.html) support of `X-HEEP`.
 
@@ -328,7 +328,7 @@ include $(XHEEP_MAKE)
 * The `verilator-sim` rule will override the `X-HEEP` Makefile's one.
 * Any other target will be passed straight to `X-HEEP`'s Makefile. For example
 ```sh
-make mcu-gen CPU=cv32e40x
+make mcu-gen CPU=cv32e40px
 ```
 </details>
 
@@ -401,3 +401,10 @@ If you plan to store source files in a different location that the one proposed,
 make app PROJECT=your_app SOURCE=<path_to_your_sw_relative_to_x_heep_sw>
 ```
 Consider that inside this `sw` folder the same structure than the one proposed is required.
+
+
+## Inter-process communication using Verilator's DPI
+
+The following [repository](https://github.com/specs-feup/x-heep) uses X-HEEP and the Verilator simulator to model a CPU-CGRA hybrid system. This architecture simulates the CPU integrated into the X-HEEP system, and an external Java process simulates the accelerator. Both components require a communication channel to exchange instructions and data. Using the existing infrastructure to to interact with an external OS process is not feasible at first sight, given that the X-HEEP ecosystem's pipeline encapsulates most of the simulation build and execution, with all modules supplied directly to Verilator. 
+
+To circumvent this issue, this project uses [Direct Programming Interface (DPI)](https://verilator.org/guide/latest/connecting.html) calls (defined in `hw/ip_examples/cgraitf/cgraitfdpi.c`) to establish a connection and communicate with an external process through a Unix Domain Socket. This behavior mirrors the UART module (used as the skeleton code) that connects and outputs _printf_ information to the pseudo-terminal. These calls are embedded in a mock CGRA peripheral/interface, located in `hw/ip_examples/cgraitf/cgraitf.sv`. The module overrides reads and writes to the specified peripheral address, with the proper socket-based mechanism (_send_ or _recv_). The _simple_accelerator_ module could also be similarly customized to perform the same operations, using X-HEEP's  interfaces and memory access protocols. A given user program executed in the CPU (such as `sw/applications/cgra_itf/main.c`) must then select assignments to or from the address to trigger the appropriate action.

docs/source/Peripherals/Timer.md

@@ -0,0 +1,107 @@
+
+# Timer SDK
+
+This SDK provides utilities for execution time measurements using HW timers. It includes functions to start, stop, reset, and configure timers, as well as to enable timer interrupts and measure elapsed time.
+
+## Usage
+
+The SDK provides a set of functions to interact with the HW Timer for various timing operations.
+
+### Initialize Timer for Counting Cycles
+
+This function configures the counter at the running clock frequency to count the number of clock cycles. Call this function before any of the other timer SDK functions.
+
+```c
+void timer_cycles_init();
+```
+
+### Start Timer
+
+Start the HW timer.
+
+```c
+void timer_start();
+```
+
+### Get Current Timer Value
+
+Retrieve the current value of the HW timer without stopping it.
+
+```c
+uint32_t timer_get_cycles();
+```
+
+### Complete timer reset
+
+Completely resets the HW counter, disabling all IRQs, counters, and comparators.
+```c
+void timer_reset();
+```
+
+### Stop and Reset Timer
+
+Retrieve the current value of the HW timer and stop it.
+
+```c
+uint32_t timer_stop();
+```
+
+### Set Timer Threshold
+
+Set the timer to go off once the counter value reaches the specified threshold. If the timer interrupts and the timer IRQ have been enabled, when the timer reaches that value an interrupt will be called.
+
+```c
+void timer_arm_set(uint32_t threshold);
+```
+
+### Set Timer Threshold and Start
+
+Set the timer to go off once the counter value reaches the specified threshold, and start the timer. If the timer interrupts and the timer IRQ have been enabled, when the timer reaches that value an interrupt will be called.
+
+```c
+void timer_arm_start(uint32_t threshold);
+```
+
+### Enable Timer IRQ
+
+Enable the timer interrupt request.
+
+```c
+void timer_irq_enable();
+```
+
+### Clear Timer IRQ
+
+Clear the timer interrupt request.
+
+```c
+void timer_irq_clear();
+```
+
+### Enable Timer Machine-level Interrupts
+
+Enable the timer machine-level interrupts for the X-Heep platform.
+
+```c
+void enable_timer_interrupt();
+```
+
+### Wait for Microseconds
+
+Block execution for a specified number of microseconds. This function is not precise for small numbers of microseconds. Enable timer interrupts with `enable_timer_interrupt()` before using this function.
+
+```c
+void timer_wait_us(uint32_t ms);
+```
+
+### Get Execution Time in Microseconds
+
+Get the time taken to execute a certain number of cycles, returned as a float representing the time in microseconds.
+
+```c
+float get_time_from_cycles(uint32_t cycles);
+```
+
+## Example Usage
+
+An example of utilization of the timer SDK can be found in `sw/applications/example_timer_sdk/main.c`.

hw/core-v-mini-mcu/peripheral_subsystem.sv

@@ -452,7 +452,7 @@ module peripheral_subsystem
       .reg_req_t(reg_pkg::reg_req_t),
       .reg_rsp_t(reg_pkg::reg_rsp_t)
   ) i2s_i (
-      .clk_i,
+      .clk_i(clk_cg),
       .rst_ni,
       .reg_req_i(peripheral_slv_req[core_v_mini_mcu_pkg::I2S_IDX]),
       .reg_rsp_o(peripheral_slv_rsp[core_v_mini_mcu_pkg::I2S_IDX]),

hw/core-v-mini-mcu/peripheral_subsystem.sv.tpl

@@ -546,7 +546,7 @@ module peripheral_subsystem
       .reg_req_t(reg_pkg::reg_req_t),
       .reg_rsp_t(reg_pkg::reg_rsp_t)
   ) pdm2pcm_i (
-      .clk_i,
+      .clk_i(clk_cg),
       .rst_ni,
       .reg_req_i(peripheral_slv_req[core_v_mini_mcu_pkg::PDM2PCM_IDX]),
       .reg_rsp_o(peripheral_slv_rsp[core_v_mini_mcu_pkg::PDM2PCM_IDX]),
@@ -569,7 +569,7 @@ module peripheral_subsystem
       .reg_req_t(reg_pkg::reg_req_t),
       .reg_rsp_t(reg_pkg::reg_rsp_t)
   ) i2s_i (
-      .clk_i,
+      .clk_i(clk_cg),
       .rst_ni,
       .reg_req_i(peripheral_slv_req[core_v_mini_mcu_pkg::I2S_IDX]),
       .reg_rsp_o(peripheral_slv_rsp[core_v_mini_mcu_pkg::I2S_IDX]),

hw/fpga/prim_xilinx_clk.sv

@@ -9,15 +9,12 @@ module xilinx_clk_gating (
     output logic clk_o
 );
 
-  logic clk_en;
-
-  // Use a latch based clock gate instead of BUFGCE. Otherwise we quickly run out of BUFGCTRL cells on the FPGAs.
-  always_latch begin
-    if (clk_i == 1'b0) clk_en <= en_i | test_en_i;
-  end
-
-  assign clk_o = clk_i & clk_en;
-
+  // In Zynq7000, just bypass the clock gating because there are not enough BUFGs that can be 
+  // cascaded with the BUFG of the MMCM.
+  // In the Zynq UltraScale+, it can be implemented as BUFGCE without trouble, since there
+  // are > 500 BUFGCEs and the rules for cascading are more relaxed.
+  // NOTE: This **cannot** be substituted by a latch+and
+  assign clk_o = clk_i;
 
 endmodule
 

hw/vendor/esl_epfl_cv32e40px.lock.hjson

@@ -9,6 +9,6 @@
   upstream:
   {
     url: https://github.com/esl-epfl/cv32e40px.git
-    rev: 15b9dd6077513342cf44e6853a5fc33098f2e73b
+    rev: 10b08065c50d44b5355c1535cb8f740e68e4f106
   }
 }

hw/vendor/esl_epfl_cv32e40px.vendor.hjson

@@ -7,7 +7,7 @@
 
   upstream: {
     url: "https://github.com/esl-epfl/cv32e40px.git",
-    rev: "15b9dd6077513342cf44e6853a5fc33098f2e73b",
+    rev: "10b08065c50d44b5355c1535cb8f740e68e4f106",
   },
 
   exclude_from_upstream: [

hw/vendor/esl_epfl_cv32e40px/README.md

@@ -1,8 +1,8 @@
 [![Build Status](https://travis-ci.com/pulp-platform/riscv.svg?branch=master)](https://travis-ci.com/pulp-platform/riscv)
 
-# OpenHW Group CORE-V CV32E40P RISC-V IP
+# OpenHW Group CORE-V CV32E40PX RISC-V IP
 
-CV32E40P is a small and efficient, 32-bit, in-order RISC-V core with a 4-stage pipeline that implements
+CV32E40PX is a small and efficient, 32-bit, in-order RISC-V core with a 4-stage pipeline that implements
 the RV32IM\[F|Zfinx\]C instruction set architecture, and the PULP custom extensions for achieving
 higher code density, performance, and energy efficiency \[[1](https://doi.org/10.1109/TVLSI.2017.2654506)\], \[[2](https://doi.org/10.1109/PATMOS.2017.8106976)\].
 It started its life as a fork of the OR10N CPU core that is based on the OpenRISC ISA.
@@ -14,12 +14,12 @@ when it has been contributed to [OpenHW Group](https://www.openhwgroup.org/).
 
 ## Documentation
 
-The CV32E40P user manual can be found in the _docs_ folder and it is
+The CV32E40PX user manual can be found in the _docs_ folder and it is
 captured in reStructuredText, rendered to html using [Sphinx](https://docs.readthedocs.io/en/stable/intro/getting-started-with-sphinx.html).
 These documents are viewable using readthedocs and can be viewed [here](https://docs.openhwgroup.org/projects/cv32e40p-user-manual/).
 
 ## Verification
-The verification environment for the CV32E40P is _not_ in this Repository.  There is a small, simple testbench here which is
+The verification environment for the CV32E40PX is _not_ in this Repository.  There is a small, simple testbench here which is
 useful for experimentation only and should not be used to validate any changes to the RTL prior to pushing to the master
 branch of this repo.
 
@@ -31,7 +31,7 @@ The Makefiles supported in the **core-v-verif** project automatically clone the
 ## Changelog
 
 A changelog is generated automatically in the documentation from the individual pull requests.
-In order to enable automatic changelog generation within the CV32E40P documentation, the committer is required to label each pull request
+In order to enable automatic changelog generation within the CV32E40PX documentation, the committer is required to label each pull request
 that touches any file in 'rtl' (or any of its subdirectories) with *Component:RTL* and label each pull request that touches any file in
 'docs' (or any of its subdirectories) with *Component:Doc*. Pull requests that are not labeled or labeled with *ignore-for-release* are
 ignored for the changelog generation.
@@ -40,7 +40,7 @@ Only the person who actually performs the merge can add these labels (you need c
 1 label is applied and therefore pull requests that touches both RTL and documentation files in the same pull request are not allowed.
 
 ## Constraints
-Example synthesis constraints for the CV32E40P are provided.
+Example synthesis constraints for the CV32E40PX are provided.
 
 ## Contributing
 
@@ -71,7 +71,7 @@ Run `./util/format-verible` to format all the files.
 
 ## Issues and Troubleshooting
 
-If you find any problems or issues with CV32E40P or the documentation, please check out the [issue
+If you find any problems or issues with CV32E40PX or the documentation, please check out the [issue
  tracker](https://github.com/openhwgroup/cv32e40p/issues) and create a new issue if your problem is
 not yet tracked.