github-mirrors/cve2
1
0
Fork 0
mirror of https://github.com/openhwgroup/cve2.git synced 2025-06-28 01:29:10 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

add references and fix typos in README

Browse source
This commit is contained in:
Davide Schiavone 2023-11-14 10:20:20 +01:00 • committed by GitHub
parent 9e0615bc3b
commit a325e5ebba
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 17 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

26
README.md
View file

@ -2,13 +2,13 @@
CVE2 is a class of 2-stage pipeline OpenHW Group cores. Currently, the only core in this class is the CV32E20. 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](https://github.com/lowRISC/ibex) core. CV32E20 is a fork of the [Ibex](https://github.com/lowRISC/ibex) core.
Differently to Ibex, cv32e2 will target low cost as originally intented in the [Zero-riscy](https://doi.org/10.1109/PATMOS.2017.8106976) project. Differently to Ibex, cv32e2 will target low cost as originally intended in the [Zero-riscy](https://doi.org/10.1109/PATMOS.2017.8106976) 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](https://github.com/openhwgroup/core-v-verif). 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](https://github.com/openhwgroup/core-v-verif).
# CV32E20 RISC-V Core # CV32E20 RISC-V Core
CV32E20 is a production-quality open source source 32-bit RISC-V CPU core written in 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 SystemVerilog. The CPU core is heavily parametrizable and well-suited for
embedded control applications. CV32E20 is being extensively verified and has embedded control applications. CV32E20 is being extensively verified and has
seen multiple tape-outs. CV32E20 supports the Integer (I) or Embedded (E), seen multiple tape-outs. CV32E20 supports the Integer (I) or Embedded (E),
Integer Multiplication and Division (M), and Compressed (C) extensions. Integer Multiplication and Division (M), and Compressed (C) extensions.
@ -43,13 +43,13 @@ that touches any file in 'rtl' (or any of its subdirectories) with *Component:RT
ignored for the changelog generation. 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 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 touches both RTL and documentation files in the same pull request are not allowed. 1 label is applied and therefore pull requests that touch both RTL and documentation files in the same pull request are not allowed.
## Configuration ## Configuration
CV32E20 offers several configuration parameters to meet the needs of various application scenarios. 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 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. 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](cve2_configs.yaml)). These are configurations on which lowRISC is focusing for performance evaluation and design verification (see [supported configs](cve2_configs.yaml)).
| Config | "micro" | "small" | | Config | "micro" | "small" |
@ -67,13 +67,13 @@ Notes:
See the [Benchmarks README](examples/sw/benchmarks/README.md) for more information. See the [Benchmarks README](examples/sw/benchmarks/README.md) for more information.
* Yosys synthesis area numbers are based on the CV32E20 basic synthesis [flow](syn/README.md) using the latch-based register file. * Yosys synthesis area numbers are based on the CV32E20 basic synthesis [flow](syn/README.md) 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. * 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. * 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. * Verification status is a rough guide to the overall maturity of a particular configuration.
Green indicates that verification is close to complete. Green indicates that verification is close to complete.
Amber indicates that some verification has been performed, but the configuration is still experimental. Amber indicates that some verification has been performed, but the configuration is still experimental.
Red indicates a configuration with minimal/no verification. 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. * 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 are *not ratified* and there may be changes before ratification. The latter is *not ratified* and there may be changes before ratification.
See [Standards Compliance](https://ibex-core.readthedocs.io/en/latest/01_overview/compliance.html) in the Ibex documentation for more information. See [Standards Compliance](https://ibex-core.readthedocs.io/en/latest/01_overview/compliance.html) in the Ibex documentation for more information.
## Documentation (to be updated) ## Documentation (to be updated)
@ -97,12 +97,12 @@ please:
* Create your own fork to commit your changes and then open a Pull Request to the **dev** branch. * 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 * Split large contributions into smaller commits addressing individual changes or bug fixes. Do not
mix unrelated changes into the same commit! mix unrelated changes into the same commit!
* Do not mix updates within the 'rtl' directory with updates within the 'docs' directory ino the same pull request. * 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 * Write meaningful commit messages. For more information, please check out the [the Ibex contribution
guide](https://github.com/lowrisc/ibex/blob/master/CONTRIBUTING.md). guide](https://github.com/lowrisc/ibex/blob/master/CONTRIBUTING.md).
* If asked to modify your changes, do fixup your commits and rebase your branch to maintain a * If asked to modify your changes, do fix up your commits and rebase your branch to maintain a
clean history. clean history.
* If the PR gets accepted and merged into the 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](https://docs.openhwgroup.org/projects/cv32e40p-user-manual/core_versions.html). * 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](https://docs.openhwgroup.org/projects/cv32e40p-user-manual/core_versions.html).
For more details on how this is implemented, have a look at this [page](https://github.com/openhwgroup/cv32e40p/blob/master/.github/workflows/aws_cv32e40p.md). For more details on how this is implemented, have a look at this [page](https://github.com/openhwgroup/cv32e40p/blob/master/.github/workflows/aws_cv32e40p.md).
@ -130,3 +130,11 @@ License, Version 2.0 (see LICENSE for full text).
Many people have contributed to CVE2 and its predecessor projects through the years. Please have a look at Many people have contributed to CVE2 and its predecessor projects through the years. Please have a look at
the [credits file](CREDITS.md) and the commit history for more information. the [credits file](CREDITS.md) and the commit history for more information.
## References
[Schiavone, Pasquale Davide, et al. "Slow and steady wins the race? A comparison of
ultra-low-power RISC-V cores for Internet-of-Things applications."
_27th International Symposium on Power and Timing Modeling, Optimization and Simulation
(PATMOS 2017)_](https://doi.org/10.1109/PATMOS.2017.8106976)