468b3595cd
* Core-V eXtension Interface (CV-X-IF) integration (#277) * minor fixes (#283) * minor fix again * Changes to make the X_if addition compatible with the golden version of the core, minus the rf_we line (#289) * Fix remaining sec inconsistency regarding the X-IF addition (#291) * Changes to make the X_if addition compatible with the golden version of the core, minus the rf_we line * [rt][sec][xif] Made the length of the cve2_id_stage's rf_wdata_sel dependent on the whether the X-IF is present * [rtl][sec][xif] Made the length of the cve2_id_stage's rf_wdata_sel dependent on the whether the X-IF is present * Clean Verilator warning about X-IF addition while keeping the RTL SEC-safe (#292) * Changes to make the X_if addition compatible with the golden version of the core, minus the rf_we line * [rt][sec][xif] Made the length of the cve2_id_stage's rf_wdata_sel dependent on the whether the X-IF is present * [rtl][sec][xif] Made the length of the cve2_id_stage's rf_wdata_sel dependent on the whether the X-IF is present * [rtl][xif][verilator] Clean warnings about enum-logic[] width mismatch on Verilator, while keeping the design logically equivalent. This is due to the cve2_decoder's rf_wdata_sel_o signal, which has its width dependent of the X-IF. * fix xif --------- Co-authored-by: FrancescoDeMalde-synthara <167969440+FrancescoDeMalde-synthara@users.noreply.github.com> Co-authored-by: Cairo Caplan <cairo.caplan@eclipse-foundation.org> |
||
|---|---|---|
| .github | ||
| bhv | ||
| ci | ||
| doc | ||
| dv/riscv_compliance | ||
| examples/obi2ahb | ||
| formal | ||
| lint | ||
| rtl | ||
| scripts | ||
| shared | ||
| syn | ||
| util | ||
| vendor | ||
| .clang-format | ||
| .gitignore | ||
| .readthedocs.yaml | ||
| .svlint.toml | ||
| azure-pipelines.yml | ||
| check_tool_requirements.core | ||
| CONTRIBUTING.md | ||
| CREDITS.md | ||
| cv32e20_manifest.flist | ||
| cve2_configs.yaml | ||
| cve2_core.core | ||
| cve2_icache.core | ||
| cve2_multdiv.core | ||
| cve2_pkg.core | ||
| cve2_top.core | ||
| cve2_top_tracing.core | ||
| cve2_tracer.core | ||
| LICENSE | ||
| Makefile | ||
| python-requirements.txt | ||
| README.md | ||
| src_files.yml | ||
| tool_requirements.py | ||
OpenHW Group CORE-V CVE2 RISC-V IP
CVE2 is a class of 2-stage pipeline OpenHW Group cores. Currently, the only core in this class is the CV32E20. CV32E20 is a fork of the Ibex core. Differently to Ibex, cv32e2 will target low cost as originally intended in the Zero-riscy project. The core will be made compatible with the OpenHW Group OBI protocol, it will use the same sleep unit of CV32E4 family, and it will achieve TRL5 with the industrial-level verification core-v-verif.
CV32E20 RISC-V Core
CV32E20 is a production-quality open source source 32-bit RISC-V CPU core written in SystemVerilog. The CPU core is heavily parametrizable and well-suited for embedded control applications. CV32E20 is being extensively verified and has seen multiple tape-outs. CV32E20 supports the Integer (I) or Embedded (E), Integer Multiplication and Division (M), and Compressed (C) extensions.
The block diagram below shows the small parametrization with a 2-stage pipeline.
CV32E20 was initially developed as part of the PULP platform under the name "Zero-riscy", and has been contributed to lowRISC who maintains it and develops it further. It was further adopted by the OpenHW Group to work towards an improved industrialization
Verification
The verification environment for the CVE2 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.
The verification environment for this core as well as other cores in the OpenHW Group CORE-V family is at the core-v-verif repository on GitHub.
The Makefiles supported in the core-v-verif project automatically clone the appropriate version of the cve2 RTL sources.
Changelog
A changelog is generated automatically in the documentation from the individual pull requests. In order to enable automatic changelog generation within the 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 taht are not labeled or labeled with ignore-for-release are ignored for the changelog generation.
Only the person who actually performs the merge can add these labels (you need committer rights). The changelog flow only works if at most 1 label is applied and therefore pull requests that touch both RTL and documentation files in the same pull request are not allowed.
Configuration
CV32E20 offers several configuration parameters to meet the needs of various application scenarios. The options include different choices for the architecture of the multiplier unit, as well as a range of performance and security features. The table below indicates performance, area, and verification status for a few selected configurations. These are configurations on which lowRISC is focusing for performance evaluation and design verification (see supported configs).
| Config | "micro" | "small" |
|---|---|---|
| Features | RV32EC | RV32IMC, 3 cycle mult |
| Performance (CoreMark/MHz) | 0.904 | 2.47 |
| Area - Yosys (kGE) | 16.85 | 26.60 |
| Area - Commercial (estimated kGE) | ~15 | ~24 |
| Verification status |
Notes:
- Performance numbers are based on CoreMark running on the CV32E20 Simple System platform. Note that different ISAs (use of B and C extensions) give the best results for different configurations. See the Benchmarks README for more information.
- Yosys synthesis area numbers are based on the CV32E20 basic synthesis flow using the latch-based register file.
- Commercial synthesis area numbers are a rough estimate of what might be achievable with a commercial synthesis flow and technology library.
- For comparison, the original "zero-riscy" core yields an area of 23.14kGE using our Yosys synthesis flow.
- Verification status is a rough guide to the overall maturity of a particular configuration. Green indicates that verification is close to complete. Amber indicates that some verification has been performed, but the configuration is still experimental. Red indicates a configuration with minimal/no verification.
- v.1.0.0 of the RISC-V Bit-Manipulation Extension is supported as well as the remaining sub-extensions of draft v.0.93 of the bitmanip spec. The latter is not ratified and there may be changes before ratification. See Standards Compliance in the Ibex documentation for more information.
Documentation (to be updated)
The CVE2 documentation can be
read online at ReadTheDocs. It is also contained in
the doc folder of this repository.
Examples
The CVE2 repository includes Simple System. This is an intentionally simple integration of CV32E20 with a basic system that targets simulation. It is intended to provide an easy way to get bare metal binaries running on CV32E20 in simulation.
Contributing
We highly appreciate community contributions. We are currently using the lowRISC contribution guide. To ease our work of reviewing your contributions, please:
- Create your own fork to commit your changes and then open a Pull Request to the dev branch.
- Split large contributions into smaller commits addressing individual changes or bug fixes. Do not mix unrelated changes into the same commit!
- Do not mix updates within the 'rtl' directory with updates within the 'docs' directory into the same pull request.
- Write meaningful commit messages. For more information, please check out the the Ibex contribution guide.
- If asked to modify your changes, do fix up your commits and rebase your branch to maintain a clean history.
- If the PR gets accepted and merged into the dev branch, an action is triggered automatically to check whether the changes are logically equivalent to the frozen RTL on a given set of parameters. If the changes are logically equivalent, the dev branch is automatically merged into the master branch. Otherwise, we need to investigate manually. If a bug is found, thus the changes are not logically equivalent, we follow the procedure documented here.
For more details on how this is implemented, have a look at this page.
When contributing SystemVerilog source code, please try to be consistent and adhere to the lowRISC Verilog coding style guide.
To get started, please check out the "Good First Issue" list.
The RTL code has been formatted with "Verible" v0.0-1149-g7eae750.
Run ./util/format-verible to format all the files.
Issues and Troubleshooting
If you find any problems or issues with CVE2 or the documentation, please check out the issue tracker and create a new issue if your problem is not yet tracked.
License
Unless otherwise noted, everything in this repository is covered by the Apache License, Version 2.0 (see LICENSE for full text).
Credits
Many people have contributed to CVE2 and its predecessor projects through the years. Please have a look at the credits file and the commit history for more information.