diff --git a/docs/specifications/cva6_requirement_specification.rst b/docs/specifications/cva6_requirement_specification.rst new file mode 100644 index 000000000..75cb4a475 --- /dev/null +++ b/docs/specifications/cva6_requirement_specification.rst @@ -0,0 +1,807 @@ +============================== +CVA6 requirement specification +============================== + +Revision 1.0.0 + +.. __license: + +License +======= + +| Copyright 2022 OpenHW Group and Thales +| Copyright 2018 ETH Zürich and University of Bologna +| SPDX-License-Identifier: Apache-2.0 WITH SHL-2.1 +| Licensed under the Solderpad Hardware License v 2.1 (the “License”); + you may not use this file except in compliance with the License, or, + at your option, the Apache License version 2.0. You may obtain a copy + of the License at https://solderpad.org/licenses/SHL-2.1/. +| Unless required by applicable law or agreed to in writing, any work + distributed under the License is distributed on an “AS IS” BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or + implied. See the License for the specific language governing + permissions and limitations under the License. + +.. __introduction: + +Introduction +============ + +CVA6 is a RISC-V compatible application processor core that can be +configured as a 32- or 64-bit core (RV32 or RV64). It includes L1 +caches, optional MMU, optional PMP and optional FPU. + +It is an industrial evolution of ARIANE created by ETH Zürich and the +University of Bologna. It is written in SystemVerilog and maintained by +the OpenHW Group. + +This specification is organized as requirements that apply to the “Scope +of the IP”. + +The requirement list is to be approved by the OpenHW Group Technical +Work Group (TWG), as well as its change requests. + +The specification will be complemented by a user’s guide. + +Revision 1.0.0 refers to the product of the first CVA6 project led at +OpenHW Group. It is a placeholder in case of future evolutions after +project freeze (PF gate). + +A list of abbreviations is available at the end of this document. + +.. __scope: + +Scope +===== + +.. __scope_of_the_ip: + +Scope of the IP +--------------- + +The **scope of the IP** is the subsystem that is specified below and +that will undergo verification with a 100% coverage goal. In the +verification plans, the scope of the IP can be broken down in several +DUT (design under test). + +The scope of the IP is the **CVA6 hardware** supporting all the features +used in products based on CVA6. + +CVA6 exists in two main configurations: **CV64A6** and **CV32A6**. A +requirement referring to CVA6 applies to both configurations. + +|cva6 scope| + +As displayed in the picture above, the IP comprises: + +- The CVA6 core; + +- L1 write-through cache; + +- Optional FPU; + +- Optional MMU; + +- Optional PMP; + +- CSR; + +- Performance counters; + +- AXI interface; + +- Interface with the P-Mesh coherence system of OpenPiton. + +These are not part of the IP (several solutions can be used): + +- CLINT or PLIC Interrupt modules; + +- Debug module (such as DTM); + +- Support of L1 write-back cache (this might come later as an update). + +In addition to these main configurations, several fine grain parameters +are available. + +Unless otherwise stated, an optional feature is controlled by a +SystemVerilog parameter. If not selected, the optional feature will not +be present in the netlist after synthesis. + +The reader’s attention is drawn to the difference between an optional +feature (“…​shall support as an option…​”) and a desired goal (“…​should +support…​”, “…​should reduce latency…​”). + +These are not in the scope of this specification: + +- SW layers, such as compiler and OSes (that can however be part of the + OpenHW Group CVA6 project); + +- SW emulation of RISC-V optional extensions ( feasible but the scope + of the IP is the core hardware); + +- Other features included in the testbench (main memory, firmware, + interconnect…), the verification coverage of which will not be + measured; + +- The vector coprocessor (CV-VEC) that is planned to interface with + CV64A6. + +.. __verified_configurations: + +Verified configurations +----------------------- + +It is not possible to verify all possible combinations of parameters. +Below is the list of configurations that will undergo verification in +the project and their main parameters. The full list of parameters for +each configuration will be detailed in the users’ guide. + ++--------------------+---------+---------+---------+---------+---------+---------+ +| Config# | Target | 32/64 | FPU | MMU | L1 D$ | L1 I$ | ++====================+=========+=========+=========+=========+=========+=========+ +| cv32a6_imacf_sv32 | FPGA | CV32A6 | F | Sv32 | 32 kB | 16 kB | ++--------------------+---------+---------+---------+---------+---------+---------+ +| cv32a6_imac_sv32 | FPGA | CV32A6 | None | Sv32 | 32 kB | 16 kB | ++--------------------+---------+---------+---------+---------+---------+---------+ +| cv64a6_imacfd_sv39 | ASIC | CV64A6 | FD | Sv39 | 16 kB | 16 kB | ++--------------------+---------+---------+---------+---------+---------+---------+ +| cv32a6_imac_sv0 | ASIC | CV32A6 | None | None | None | 4 kB | ++--------------------+---------+---------+---------+---------+---------+---------+ + +.. __references: + +References +========== + +.. __applicable_specifications: + +Applicable specifications +------------------------- + +To ease the reading, the reference to these specifications can be +implicit in the requirements below. For the sake of precision, the +requirements identify the versions of RISC-V extensions from these +specifications. + +[RVunpriv] “The RISC-V Instruction Set Manual, Volume I: User-Level ISA, +Document Version 20191213”, Editors Andrew Waterman and Krste Asanović, +RISC-V Foundation, December 13, 2019. + +[RVpriv] “The RISC-V Instruction Set Manual, Volume II: Privileged +Architecture, Document Version 20211203”, Editors Andrew Waterman, Krste +Asanović and John Hauser, RISC-V Foundation, December 4, 2021. + +[RVdbg] “RISC-V External Debug Support, Document Version 0.13.2”, +Editors Tim Newsome and Megan Wachs, RISC-V Foundation, March 22, 2019. + +[RVcompat] “RISC-V Architectural Compatibility Test Framework”, +https://github.com/riscv-non-isa/riscv-arch-test. + +[AXI] AXI Specification, +https://developer.arm.com/documentation/ihi0022/hc. + +[CV-X-IF] Placeholder for the CV-X-IF coprocessor interface currently +prepared at OpenHW Group; current version in +https://docs.openhwgroup.org/projects/openhw-group-core-v-xif/. + +[OpenPiton] “OpenPiton Microarchitecture Specification”, Princeton +University, +https://parallel.princeton.edu/openpiton/docs/micro_arch.pdf. + +.. __reference_documents: + +Reference documents +------------------- + +[RVcmo] “RISC-V Base Cache Management Operation ISA Extensions, +version 1.0-fd39d01, 2022-01-12” + +[CLINT] Core-Local Interruptor (CLINT), “SiFive E31 Core Complex +Manual v2p0”, chapter 6, +https://static.dev.sifive.com/SiFive-E31-Manual-v2p0.pdf + +.. __functional_requirements: + +Functional requirements +======================= + +.. __general_requirement: + +General requirement +------------------- + ++-----------------------------------+-----------------------------------+ +| GEN‑10 | CVA6 shall be **fully compliant | +| | with RISC-V specifications** | +| | [RVunpriv], [RVpriv] and [RVdbg] | +| | by implementing all mandatory | +| | features for the set of | +| | extensions that are selected and | +| | by passing [RVcompat] | +| | compatibility tests. | ++-----------------------------------+-----------------------------------+ + +As the RISC-V specification leaves space for variations, this +specification specificies some of these variations. + +.. __risc_v_standard_instructions: + +RISC-V standard instructions +---------------------------- + +To ease tracing to verification, the extensions have been split in +independent requirements. + ++-----------------------------------+-----------------------------------+ +| ISA‑10 | CV64A6 shall support **RV64I** | +| | base instruction set, version | +| | 2.1. | ++-----------------------------------+-----------------------------------+ +| ISA‑20 | CV32A6 shall support **RV32I** | +| | base instruction set, version | +| | 2.1. | ++-----------------------------------+-----------------------------------+ +| ISA‑30 | CVA6 shall support the **M** | +| | extension (integer multiply and | +| | divide), version 2.0. | ++-----------------------------------+-----------------------------------+ +| ISA‑40 | CVA6 shall support the **A** | +| | extension (atomic instructions), | +| | version 2.1. | ++-----------------------------------+-----------------------------------+ +| ISA‑50 | CV32A6 shall support as an | +| | **option** the **F** extension | +| | (single-precision | +| | floating-point), version 2.2. | ++-----------------------------------+-----------------------------------+ +| ISA‑60 | CV64A6 shall support as an | +| | **option** the **F** and **D** | +| | extensions (single- and | +| | double-precision floating-point), | +| | version 2.2. | ++-----------------------------------+-----------------------------------+ +| ISA‑70 | CV64A6 shall support as an | +| | **option** the **F** extension | +| | (single-precision without | +| | double-precision floating-point), | +| | version 2.2. | ++-----------------------------------+-----------------------------------+ +| ISA‑80 | CVA6 shall support as an | +| | **option** the **C** extension | +| | (compressed instructions), | +| | version 2.0. | ++-----------------------------------+-----------------------------------+ +| ISA‑90 | CVA6 shall support the **Zicsr** | +| | extension (CSR instructions), | +| | version 2.0. | ++-----------------------------------+-----------------------------------+ +| ISA‑100 | CVA6 shall support the | +| | **Zifencei** extension, version | +| | 2.0. | ++-----------------------------------+-----------------------------------+ +| ISA‑110 | | As an **option**, the duration | +| | of instructions shall be | +| | independent from the operand | +| | values. | +| | | *Unlike other options, this one | +| | can be design-time (selected | +| | before compiling the RTL) or | +| | run-time (selected through a | +| | register).* | ++-----------------------------------+-----------------------------------+ + +Note to ISA-60 and ISA-70: CV64A6 cannot support the D extension with +the F extension. + +Note to ISA-110: In the current design, the duration of the division +is data-dependent, which can be a security issue. + +.. __privileges_and_virtual_memory: + +Privileges and virtual memory +----------------------------- + +The MMU includes a TLB and a hardware PTW. + ++-----------------------------------+-----------------------------------+ +| PVL‑10 | CVA6 shall support **machine**, | +| | **supervisor,** **user** and | +| | **debug** privilege modes. | ++-----------------------------------+-----------------------------------+ +| PVL‑20 | CV64A6 shall support as an | +| | **option** the **Sv39** virtual | +| | memory, version 1.11. | ++-----------------------------------+-----------------------------------+ +| PVL‑30 | CV32A6 shall support as an | +| | **option** the **Sv32** virtual | +| | memory version 1.11. | ++-----------------------------------+-----------------------------------+ +| PVL‑40 | CVA6 instances that do not | +| | feature virtual memory shall | +| | support the **Bare** mode. | ++-----------------------------------+-----------------------------------+ +| PVL‑50 | CVA6 shall feature PMP (physical | +| | memory protection) as an | +| | **option**. | ++-----------------------------------+-----------------------------------+ +| PVL‑60 | CV64A6 shall support as an | +| | **option** the **H** extension | +| | (hypervisor) version 1.0. | ++-----------------------------------+-----------------------------------+ + +.. __csr: + +CSR +--- + +There are no requirements related to CSR as they derive from other +requirements, such as PVL-10, PVL-60… Details of CSRs will be available +in the user’s manual. + +.. __performance_counters: + +Performance counters +-------------------- + +Performance counters are important features for safety-critical +applications. + ++-----------------------------------+-----------------------------------+ +| HPM‑10 | CVA6 shall implement the 64-bit | +| | ``mcycle`` and ``minstret`` | +| | standard performance counters | +| | (including their upper 32 bits | +| | counterparts ``mcycleh`` and | +| | ``minstreth`` in CV32A6) as per | +| | [RVpriv]. | ++-----------------------------------+-----------------------------------+ +| HPM‑20 | CVA6 shall implement as an | +| | **option** six generic 64-bit | +| | performance counters located in | +| | ``hpmcounter3`` to | +| | ``hpmcounter8`` (including their | +| | upper 32 bits counterparts in | +| | CV32A6: ``hpmcounter3h`` to | +| | ``hpmcounter8h``). | ++-----------------------------------+-----------------------------------+ +| HPM‑30 | Each of the six generic | +| | performance counters shall be | +| | able to count events from one | +| | of these sources: | +| | | +| | #. L1 I-Cache misses | +| | #. L1 D-Cache misses | +| | #. ITLB misses | +| | #. DTLB misses | +| | #. Load accesses | +| | #. Store accesses | +| | #. Exceptions | +| | #. Exception handler returns | +| | #. Branch instructions | +| | #. Branch mispredicts | +| | #. Branch exceptions | +| | #. Call | +| | #. Return | +| | #. MSB Full | +| | #. Instruction fetch Empty | +| | #. L1 I-Cache accesses | +| | #. L1 D-Cache accesses | +| | #. L1$ line invalidation | +| | #. I-TLB flush | +| | #. Integer instructions | +| | #. Floating point instructions | +| | #. Pipeline bubbles | ++-----------------------------------+-----------------------------------+ +| HPM‑40 | The source of events counted by | +| | the six generic performance | +| | counters shall be selected by the | +| | ``mhpmevent3`` to ``mhpmevent8`` | +| | CSRs. | ++-----------------------------------+-----------------------------------+ +| HPM‑50 | CVA6 shall allow the supervisor | +| | access of performance counters | +| | through enabling of | +| | ``mcounteren`` CSR. | ++-----------------------------------+-----------------------------------+ +| HPM‑60 | CVA6 shall allow the user access | +| | of performance counters through | +| | enabling of ``scounteren`` CSR. | ++-----------------------------------+-----------------------------------+ +| HPM‑70 | CVA6 shall implement the | +| | ``mcountinhibit`` counter-inhibit | +| | register. | ++-----------------------------------+-----------------------------------+ +| HPM‑80 | CVA6 shall implement the | +| | read-only ``cycle``, ``instret``, | +| | ``hpmcounter3`` to | +| | ``hpmcounter8`` access to | +| | counters (and their upper 32-bit | +| | counterparts in CV32A6). | ++-----------------------------------+-----------------------------------+ + +The user’s manual will detail the list of counters, events and related +controls. + +.. __cache_requirements: + +Cache requirements +------------------ + +Caches increase the performance of the processor with regard to memory +accesses. Most of their added value for the IP is specified through +performance requirements in another section. Here below are specific +requirements for these caches. + +The project would like to adopt the recently ratified [RVcmo] +specification. The analysis yet needs to be performed and will likely +lead to an evolution of this specification. + +.. __l1_write_through_data_cache: + +L1 write-through data cache +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the requirements below, L1WTD refers to the L1 write-through data +cache that is part of the CVA6. + +The first two requirements express the write-through feature. Some +requirements are useful for security- and safety-critical applications +where a high level of timing predictability is needed. + ++-----------------------------------+-----------------------------------+ +| L1W‑10 | L1WTD shall reflect all write | +| | accesses (stores) by the CVA6 | +| | core to the external memory | +| | within an upper-bounded number of | +| | cycles. The upper-bound is fixed | +| | but not specified here. | ++-----------------------------------+-----------------------------------+ +| L1W‑20 | L1WTD shall not change the order | +| | of write accesses to the external | +| | memory with respect to the order | +| | of write accesses (stores) | +| | received from the CVA6 core. | ++-----------------------------------+-----------------------------------+ +| L1W‑30 | L1WTD should offer the | +| | following size/ways | +| | configurations: | +| | | +| | - 0 kbyte (no cache), | +| | - 4 kbytes (4 or 8 ways), | +| | - 8 kbytes (4, 8 or 16 ways), | +| | - 16 kbytes (4, 8 or 16 ways), | +| | - 32 kbytes (8 or 16 ways). | ++-----------------------------------+-----------------------------------+ +| L1W‑40 | L1WTD shall support datasize | +| | extension to store EDC, ECC or | +| | other information. The numbers of | +| | bits of the extension is defined | +| | by a compile-time parameter. | ++-----------------------------------+-----------------------------------+ +| L1W‑50 | To interface with the P-Mesh | +| | coherence system of OpenPiton, | +| | L1WTD shall have a line | +| | invalidate external command that | +| | invalidates the content of a line | +| | upon request. | ++-----------------------------------+-----------------------------------+ +| L1W‑60 | Some physical memory regions | +| | shall be configurable as not | +| | L1WTD cacheable at design time. | ++-----------------------------------+-----------------------------------+ +| L1W‑70 | It shall be possible to | +| | invalidate L1WTD content with the | +| | ``FENCE.T`` command. | ++-----------------------------------+-----------------------------------+ +| L1W‑80 | The replacement policy of L1WTD | +| | shall be LFSR (pseudo-random) or | +| | LRU (least recently used). | ++-----------------------------------+-----------------------------------+ +| L1W‑90 | L1WTD should offer a feature to | +| | transform cache ways into a | +| | scratchpad. | ++-----------------------------------+-----------------------------------+ +| L1W‑100 | A custom CSR shall allow to | +| | disable or enable L1WTD. | ++-----------------------------------+-----------------------------------+ + +Cache counters are defined in the performance counters. + +32 kbytes & 4 ways is not feasible with the current architecture. Other +size/ways configurations may be implemented in the design. + +The design will support one replacement policy allowed by L1W-80. + +.. __l1_instruction_cache: + +L1 Instruction cache +~~~~~~~~~~~~~~~~~~~~ + +In the requirements below, L1I refers to the L1 instruction cache that +is part of the CVA6. + +Some requirements are useful for security- and safety-critical +applications where a high level of timing predictability is needed. + ++-----------------------------------+-----------------------------------+ +| L1I‑10 | L1I should offer the following | +| | size/ways configurations: | +| | | +| | - 4 kbytes: 3, 4 or 8 ways, | +| | - 8 kbytes: 4, 8, or 16 ways, | +| | - 16 kbytes: 4, 8 or 16 ways, | +| | - 32 kbytes: 8 or 16 ways. | ++-----------------------------------+-----------------------------------+ +| L1I‑20 | L1I shall support datasize | +| | extension to store EDC, ECC or | +| | other information. The numbers of | +| | bits of the extension is defined | +| | by a compile-time parameter. | ++-----------------------------------+-----------------------------------+ +| L1I‑30 | To interface with the P-Mesh | +| | coherence system of OpenPiton, | +| | L1I shall have a line invalidate | +| | external command that invalidates | +| | the content of a line upon | +| | request. | ++-----------------------------------+-----------------------------------+ +| L1I‑40 | It shall be possible to | +| | invalidate L1I content with the | +| | ``FENCE.T`` command. | ++-----------------------------------+-----------------------------------+ +| L1I‑50 | The replacement policy of L1I | +| | shall be LFSR (pseudo-random) or | +| | LRU (least recently used). | ++-----------------------------------+-----------------------------------+ +| L1I‑60 | L1I should offer a feature to | +| | transform cache ways into a | +| | scratchpad. | ++-----------------------------------+-----------------------------------+ +| L1I‑70 | A custom CSR shall allow to | +| | disable or enable L1I. | ++-----------------------------------+-----------------------------------+ + +Cache counters are defined in the performance counters section. + +32 kbytes & 4 ways is not feasible with the current architecture. Other +size/ways configurations may be implemented in the design. + +The design will support one replacement policy allowed by L1I-50. + +.. __fence_t_custom_instruction: + +FENCE.T custom instruction +-------------------------- + +There are discussions within RISC-V International to define a +specification for ``FENCE.T``. The specification below reflects the +situation prior to this RISC-V specification, based on Nils Wistoff’s +work. If a RISC-V specification is ratified, the CVA6 specification will +likely switch to it. + ++-----------------------------------+-----------------------------------+ +| FET‑10 | CVA6 shall support the | +| | ``FENCE.T`` instruction that | +| | ensures that the execution time | +| | of subsequent instructions is | +| | unrelated with predecessor | +| | instructions. | ++-----------------------------------+-----------------------------------+ +| FET‑20 | ``FENCE.T`` shall be available in | +| | all privilege modes (machine, | +| | supervisor, user and hypervisor | +| | if present). | ++-----------------------------------+-----------------------------------+ + +FENCE.T goes beyond ``FENCE`` and ``FENCE.I`` as it clears L1 caches, +TLB, branch predictors…​ It is a countermeasure for SPECTRE-like +attacks. It is also useful in safety-critical applications to increase +execution time predictability. + +It is not yet decided if the ``FENCE.T`` instruction arguments can be +used to select a subset of microarchitecture features that will be +cleared. The list of arguments, if any, will be detailed in the user’s +guide. + +Anticipation of verification: It can be cumbersome to prove the timing +decorrelation as expressed in the requirement with digital simulations. +We can simulate the microarchitecture features and explain how they +satisfy the requirement as Nils Wistoff’s work demonstrated. + +.. __ppa_targets: + +PPA targets +=========== + +These PPA targets will likely be updated when performance monitoring is +integrated in the continuous integration flow. + ++-----------------------------------+-----------------------------------+ +| PPA‑10 | CVA6 should be resource-optimized | +| | on FPGA and ASIC targets. | ++-----------------------------------+-----------------------------------+ +| PPA‑20 | CVA6 should deliver more than 2.1 | +| | CoreMark/MHz. | ++-----------------------------------+-----------------------------------+ +| PPA‑30 | CV32A6 should run at more than | +| | 150 MHz in the cv32a6_imac_sv32 | +| | configuration on Kintex 7 FPGA | +| | technology, commercial -2 speed | +| | grade. | ++-----------------------------------+-----------------------------------+ +| PPA‑40 | CV64A6 should run at more than | +| | 900 MHz in the cv64a6_imacfd_sv39 | +| | configuration on 28FDSOI | +| | technology in the worst case | +| | frequency corner with the fastest | +| | threshold voltage. | ++-----------------------------------+-----------------------------------+ +| PPA‑50 | TBD: Placeholder for | +| | single-precision floating | +| | performance per MHz. | ++-----------------------------------+-----------------------------------+ +| PPA‑60 | TBD: Placeholder for | +| | double-precision floating | +| | performance per MHz. | ++-----------------------------------+-----------------------------------+ + +.. __interface_requirements: + +Interface requirements +====================== + +.. __memory_bus: + +Memory bus +---------- + ++-----------------------------------+-----------------------------------+ +| MEM‑10 | CVA6 memory interface shall | +| | comply with AXI5 specification | +| | including the Atomic_Transactions | +| | property support as defined in | +| | [AXI] section E1.1. | ++-----------------------------------+-----------------------------------+ +| MEM‑20 | CVA6 AXI memory interface shall | +| | feature user bit extensions on | +| | the data bus (``WUSER`` and | +| | ``RUSER`` as per [AXI]) in | +| | connection with the L1I and L1WTD | +| | datasize extensions, with a | +| | number of user bits greater or | +| | equal to 0. | ++-----------------------------------+-----------------------------------+ + +The interface complies with AXI4. However, Atomic_Transactions is only +defined in AXI5. For the sake of clarity, we do not use the AXI5-Lite +interface. + +.. __debug: + +Debug +----- + ++-----------------------------------+-----------------------------------+ +| DBG‑10 | CVA6 shall implement both the | +| | Abstracted Command and Execution | +| | based features outlined in | +| | chapter 4 of [RVdbg]. | ++-----------------------------------+-----------------------------------+ + +In addition, there can be an external debug module, not in the scope of +the IP. + +.. __interrupts: + +Interrupts +---------- + ++-----------------------------------+-----------------------------------+ +| IRQ‑10 | CVA6 shall implement interrupt | +| | handling registers as per the | +| | RISC-V privilege specification | +| | and interface with a CLINT | +| | implementation. | ++-----------------------------------+-----------------------------------+ + +.. __coprocessor_interface: + +Coprocessor interface +--------------------- + ++-----------------------------------+-----------------------------------+ +| XIF‑10 | To extend the supported | +| | instructions, CVA6 shall have a | +| | coprocessor interface that | +| | supports the “Issue”, “Commit” | +| | and “Result” interfaces of the | +| | [CV-X-IF] specification. | ++-----------------------------------+-----------------------------------+ + +The goal is to have a compatible interface between CORE-V cores (CVA6, +CV32E40X…). The feasibility still needs to be confirmed; including the +speculative execution. + +CVA6 can interface with several coprocessors simultaneously through a +specific external feature implemented on the CV-X-IF interface. + +.. __multi_core_interface: + +Multi-core interface +-------------------- + ++-----------------------------------+-----------------------------------+ +| TRI‑10 | CVA6 shall have the | +| | Transaction-Response Interface | +| | (TRI) needed to interface with | +| | the P-Mesh coherence system of | +| | OpenPiton, according to | +| | [OpenPiton]. | ++-----------------------------------+-----------------------------------+ + +.. __design_rules: + +Design rules +============ + +As different teams have different design rules and to ease the +integration in FPGA and ASIC design flows: + ++-----------------------------------+-----------------------------------+ +| RUL‑10 | CVA6 should have a configurable | +| | reset signal: | +| | synchronous/asynchronous, active | +| | on high or low levels. | ++-----------------------------------+-----------------------------------+ +| RUL‑20 | CVA6 shall be a super-synchronous | +| | design with a single clock input. | ++-----------------------------------+-----------------------------------+ +| RUL‑30 | CVA6 should not include | +| | multi-cycle paths. | ++-----------------------------------+-----------------------------------+ +| RUL‑40 | CVA6 should not include | +| | technology-dependent blocks. | ++-----------------------------------+-----------------------------------+ + +If technology-dependent blocks are used, e.g. to improve PPA on certain +targets, the equivalent technology-independent block should be +available. Parameters can be used to select between the implementations. + +.. __list_of_abbreviations: + +List of abbreviations +===================== + +| ASIC: Application Specific Integrated Circuit +| CSR: Control and Status Register +| D$: Data cache +| DTM: Debug Transport Module +| DUT: Design Under Test +| DV: Design Verification +| ECC: Error Correction Code +| EDC: Error Detection Code +| FPGA: Field Programmable Gate Array +| FPU: Floating Point Unit +| I$: Instruction cache +| IP: Intellectual Property block +| ISA: Instruction Set Architecture +| kB: kilo-bytes +| L1: Level 1 cache +| L1I: Level 1 Instruction cache +| L1WTD: Level 1 Write-Through data cache +| LFSR: Linear Feedback Shift Register +| LRU: Least Recently Used +| MMU: Memory Management Unit +| OS: Operating System +| PF: Project Freeze +| PPA: Power Performance Area +| PMP: Physical Memory Protection +| PTW: Page Table Walk +| RW: Read Write +| SW: Software +| TLB: Translation Lookaside Buffer +| TWG: Technical Work Group +| WB: Write-Back +| WT: Write-Through + +.. |cva6 scope| image:: images/cva6_scope.png diff --git a/docs/specifications/images/cva6_scope.png b/docs/specifications/images/cva6_scope.png new file mode 100644 index 000000000..bf5ae6e07 Binary files /dev/null and b/docs/specifications/images/cva6_scope.png differ