github-mirrors/cve2
1
0
Fork 0
mirror of https://github.com/openhwgroup/cve2.git synced 2025-04-23 13:37:20 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge pull request #170 from davideschiavone/main

Browse source 
fix readme and add reference
This commit is contained in:
christian-herber-nxp 2023-11-14 09:13:25 -06:00 • committed by GitHub
commit fd2ff1897a
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.
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).
# 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
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.
@ -43,13 +43,13 @@ that touches any file in 'rtl' (or any of its subdirectories) with *Component:RT
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 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
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.
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)).
| Config | "micro" | "small" |
@ -67,13 +67,13 @@ Notes:
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.
* 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.
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 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.
## 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.
* 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 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
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.
* 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).
@ -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
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)