diff --git a/.github/ISSUE_TEMPLATE/1-bug.yaml b/.github/ISSUE_TEMPLATE/1-bug.yaml new file mode 100644 index 00000000000..f258ad58efe --- /dev/null +++ b/.github/ISSUE_TEMPLATE/1-bug.yaml @@ -0,0 +1,37 @@ +name: Bug +description: Report a CVA6 RTL bug +title: "[BUG]
{{ wf.latest.head_sha }}
+ | Arch | +Config | +Test Suite | +Status | +Duration | +
|---|---|---|---|---|
| {{ job.arch|upper }} | +{{ job.config }} |
+ {{ job.testcase }} | ++ {% if job.conclusion == 'success' %} + PASS + {% elif job.conclusion == 'failure' %} + FAIL + {% else %} + {{ job.conclusion|upper }} + {% endif %} + | +{{ job.duration_display }} | +
`ifdef, etc. are strongly discouraged.
+ - Please review our wiki on the topic of [Configuring SystemVerilog RTL Models](https://github.com/openhwgroup/cva6/wiki/Configuring-SystemVerilog-RTL-Models), in particular the [CVA6 use case](https://github.com/openhwgroup/cva6/wiki/Configuring-SystemVerilog-RTL-Models#use-case-the-openhw-foundation-cva6).
+ - Synchronize with CVA6 team if you do not find an appropriate solution.
* Commit to maintain your contribution 2 years after the pull request
- We know it's not always possible, so refer to the next rule.
- * Your complete contribution shall be identifiable with parameters (or `directives / templating if together we decide to go this way).
+ * Your complete contribution shall be identifiable with parameters.
- If at some point we need to revert it, e.g. if there is no-one maintaining nor using it and it has become a burden to the project.
- We call this the "parachute" rule: The CVA6 team does not want to use it but is far more comfortable getting one.
+ - Also, this allows not to lose code coverage in verification when your contribution is not enabled (with some tweaks in the coverage tool).
+ - This rule also applies to CSRs which are specific to your contribution.
+ * To ease maintenance, all common code lines shall exist only once.
+ - Counter-example: CVA6 used to have two different MMU modules (Sv32 and Sv39) for CV32A6 and CV64A6. It took time to refactor both in a joint design to ease maintenance.
+ - Related reading for reference: [DRY principle](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
* Your contribution shall pass the Continuous Integration (CI) flow
- When the contribution is disabled: in all cases, to ensure you have not broken the design.
- When the contribution is disabled: the line and condition code coverage shall not be impacted.
@@ -44,12 +60,34 @@ Therefore here are guidelines to help the CVA6 team accept new contributions:
- So that we can detect quickly if future updates break your contribution.
- To avoid impacting those users who use your contribution in their project.
- At this point, we do not request a 100%-coverage verification suite.
+ * Please consider adding related documentation in the user's guide and design document.
+ * Be kind to the people who process your pull request(s)
+ - Explain your contribution in the pull request.
+ - If your contribution solves an issue, fill in an issue and cross link it in the pull-request.
+ - The reviewer(s) prefer to review several small pull requests rather one large pull request. Synchronize with the team to identify the right breakdown.
If you encounter difficulties with these guidelines, get in touch with the team!
### Bug fixing
-Bug fixing is always welcome. You can issue a GitHub issue. Better: solve the bug and trigger a pull request.
+Bug fixing is always welcome. You can open a GitHub issue.
+Better: in addition to the issue, solve the bug and trigger a pull request.
+Ideally, your pull request will include a testcase that illustrates the bug.
+
+### Use of AI
+
+We understand that some developers are assisted by large language models to help write code. However, AI-generated code shall always be reviewed and endorsed **by the human contributor** before submitting the pull request.
+The review by the human contributor shall be as thorough as if they had written the code themselves. Notably the human contributor shall understand and explain all generated code and assess the relevance of comments.
+
+Contributions through code/documentation (pull requests) or feedback (issues) are highly appreciated, but keep in mind that each contribution has a cost for the project, as reviewers will spend time discussing the contributions.
+For more information on this topic, see:
@@ -56,403 +64,15 @@ export DV_SIMULATORS=veri-testharness,spike
bash verif/regress/smoke-tests.sh
```
-# Running standalone simulations
-
-Simulating the CVA6 is done by using `verif/sim/cva6.py`.
-
-The environment variable `DV_SIMULATORS` allows you to specify which simulator to use.
-
-Four simulation types are supported:
-- **veri-testharness**: verilator with corev_apu/testharness testbench
-- **vcs-testharness**: vcs with corev_apu/testharness testbench
-- **vcs-uvm**: vcs with UVM testbench
-- **Spike** ISS
-
-You can set several simulators, such as :
-
-```sh
-export DV_SIMULATORS=veri-testharness,vcs-testharness,vcs_uvm
-```
-
-If exactly 2 simulators are given, their trace is compared ([see the Regression tests section](#running-regression-tests-simulations)).
-
-Here is how you can run the hello world C program with the Verilator model:
-
-```sh
-# Make sure to source this script from the root directory
-# to correctly set the environment variables related to the tools
-source verif/sim/setup-env.sh
-
-# Set the NUM_JOBS variable to increase the number of parallel make jobs
-# export NUM_JOBS=
-
-export DV_SIMULATORS=veri-testharness
-
-cd ./verif/sim
-
-python3 cva6.py --target cv32a60x --iss=$DV_SIMULATORS --iss_yaml=cva6.yaml \
---c_tests ../tests/custom/hello_world/hello_world.c \
---linker=../../config/gen_from_riscv_config/linker/link.ld \
---gcc_opts="-static -mcmodel=medany -fvisibility=hidden -nostdlib \
--nostartfiles -g ../tests/custom/common/syscalls.c \
-../tests/custom/common/crt.S -lgcc \
--I../tests/custom/env -I../tests/custom/common"
-```
-
-You can run either assembly programs (check `verif/test/custom/hello_world/custom_test_template.S`) or C programs. Run `python3 cva6.py --help` to have more informations on the available parameters.
-
-## Simulating with VCS and Verdi
-
-You can set the environment variable `VERDI` as such if you want to launch Verdi while simulating with VCS:
-
-```sh
-export VERDI=1
-```
-
-
-# Running regression tests simulations
-
-The smoke-tests script installs a random instruction generator and several tests suites:
-- [riscv-dv](https://github.com/chipsalliance/riscv-dv)
-- [riscv-compliance](https://github.com/lowRISC/riscv-compliance)
-- [riscv-tests](https://github.com/riscv-software-src/riscv-tests)
-- [riscv-arch-test](https://github.com/riscv-non-isa/riscv-arch-test)
-
-
-The regression tests are done by comparing a model simulation trace with the Spike trace.
-
-Several tests scripts can be found in `./verif/regress`
-
-For example, here is how would run the riscv-arch-test regression test suite with the Verilator model:
-
-```sh
-export DV_SIMULATORS=veri-testharness,spike
-bash verif/regress/dv-riscv-arch-test.sh
-```
-
-
-# Logs
-
-The logs from cva6.py are located in `./verif/sim/out_YEAR-MONTH-DAY`.
-
-Assuming you ran the smoke-tests scripts in the previous step, here is the log directory hierarchy:
-
-- **directed_asm_tests/**: The compiled (to .o then .bin) assembly tests
-- **directed_c_tests/**: The compiled (to .o then .bin) c tests
-- **spike_sim/**: Spike simulation log and trace files
-- **veri_testharness_sim**: Verilator simulation log and trace files
-- **iss_regr.log**: The regression test log
-
-The regression test log summarizes the comparison between the simulator trace and the Spike trace. Beware that a if a test fails before the comparison step, it will not appear in this log, check the output of cva6.py and the logs of the simulation instead.
-
-
-# Waveform generation
-
-Waveform generation is currently supported for Verilator (`veri-testharness`)
-and VCS with full UVM testbench (`vcs-uvm`) simulation types. It is disabled
-by default to save simulation time and storage space.
-
-To enable waveform generation for a supported simulation mode, set either
-of the two shell variables that control tracing before running any of the
-test scripts under `verif/regress`:
-- `export TRACE_FAST=1` enables "fast" waveform generation (keep simulation
- time low at the expense of space). This will produce VCD files when using
- Verilator, and VPD files when using Synopsys VCS with UVM testbench (`vcs-uvm`).
-- `export TRACE_COMPACT=1` enables "compact" waveform generation (keep waveform
- files smaller at the expense of increased simulation time). This will
- produce FST files when using Verilator, and FSDB files when using Synopsys
- VCS with UVM testbench (`vcs-uvm`).
-
-To generate VCD waveforms of the `smoke-tests` regression suite using Verilator, use:
-```sh
-export DV_SIMULATORS=veri-testharness,spike
-export TRACE_FAST=1
-bash verif/regress/smoke-tests-+ ``` @article{zaruba2019cost, author={F. {Zaruba} and L. {Benini}}, @@ -518,15 +134,11 @@ If you use CVA6 in your academic work you can cite us: month={Nov}, } ``` -
-
+ Figure: Digilent Genesys2 development board
+
+ Figure: USB-JTAG bridge
+
+ Figure: FT2232H MiniModule wired to Genesys2 PMODs
+Figure: Valid EEPROM for DPTI
+
+ Figure: Valid execution ./Receiver_DPTI
+
+ Figure: Excerpt from decoded trace
+Table 9: Entry Selection for Reaplacement
+Table 9: Entry Selection for Replacement
+-------------------+---------------+----------------------+ | **Path Traverse** | **PLRU Bits** | **Entry to replace** | @@ -1887,7 +1887,7 @@ Page Table Walker is implemented as a finite state machine. It listens to shared * **IDLE:** The initial state where the PTW is awaiting a trigger, often a Shared TLB miss, to initiate a memory access request. In the case of the Hypervisor extension, the stage to which the translation belongs is determined by the enable_translation_XX and en_ld_st_translation_XX signals. There are 3 possible stages: (i) S-Stage - the PTW current state is translating a guest-virtual address into a guest-physical address; (ii) G-Stage Intermed - the PTW current state is translating memory access made from the VS-Stage during the walk to host-physical address; and (iii) G-Stage Final - the PTW current state is translating the final output address from VS-Stage into a host-physical address. When Hypervisor is not enabled PTW is always in S_STAGE. * **WAIT_GRANT:** Request memory access and wait for data grant -* **PTE_LOOKUP:** Once granted access, the PTW examines the valid Page Table Entry (PTE), checking attributes to determine the appropriate course of action. Depending on the STAGE determined in the previous state, pptr and other atributes are updated accordingly. +* **PTE_LOOKUP:** Once granted access, the PTW examines the valid Page Table Entry (PTE), checking attributes to determine the appropriate course of action. Depending on the STAGE determined in the previous state, pptr and other attributes are updated accordingly. * **PROPAGATE_ERROR:** If the PTE is invalid, this state handles the propagation of an error, often leading to a page-fault exception due to non-compliance with access conditions. * **PROPAGATE_ACCESS_ERROR:** Propagate access fault if access is not allowed from a PMP perspective * **WAIT_RVALID:** After processing a PTE, the PTW waits for a valid data signal, indicating that relevant data is ready for further processing. diff --git a/docs/03_cva6_design/_static/bht2lvl.png b/docs/03_cva6_design/_static/bht2lvl.png new file mode 100644 index 00000000000..60f53c6cb40 Binary files /dev/null and b/docs/03_cva6_design/_static/bht2lvl.png differ diff --git a/docs/03_cva6_design/_static/ld_pipeline_diagram.svg b/docs/03_cva6_design/_static/ld_pipeline_diagram.svg index f559adbe923..6ff74956961 100644 --- a/docs/03_cva6_design/_static/ld_pipeline_diagram.svg +++ b/docs/03_cva6_design/_static/ld_pipeline_diagram.svg @@ -142,7 +142,7 @@