diff --git a/cva6/docs/VerifPlans/FRONTEND/VP_IP003.pck b/cva6/docs/VerifPlans/FRONTEND/VP_IP003.pck index 245a6e94fa..d651e7d6d5 100644 --- a/cva6/docs/VerifPlans/FRONTEND/VP_IP003.pck +++ b/cva6/docs/VerifPlans/FRONTEND/VP_IP003.pck @@ -186,7 +186,7 @@ sg23 VVP_IP003_P001_I002 p76 sg35 -VIf instruction is a JALR and BTB (Branch Target Buffer) returns a valid address, next PC is predicted by BTB. Else JALR is not considered as a control flow instruction, which will generate a mispredict. +VIf instruction is a JALR and BTB (Branch Target Buffer) returns a valid address, next PC is predicted by BTB.\u000a\u000aElse JALR is not considered as a control flow instruction, which will generate a mispredict. p77 sg37 VFRONTEND sub-system/functionality/PC generation stage/Branch Predict diff --git a/cva6/docs/VerifPlans/FRONTEND/runme.sh b/cva6/docs/VerifPlans/FRONTEND/runme.sh index 4db3983ba2..91be506602 100644 --- a/cva6/docs/VerifPlans/FRONTEND/runme.sh +++ b/cva6/docs/VerifPlans/FRONTEND/runme.sh @@ -15,9 +15,18 @@ ROOTDIR=`readlink -f $(dirname "${BASH_SOURCE[0]}")` # Here we use the verification tree from the example directory. export PLATFORM_TOP_DIR="$ROOTDIR" -# Set a meaningful name for the example project. +# Set the printable name for the project that will be used +# in the human-readable documentation. export PROJECT_NAME="FRONTEND" +# Set the alphanumerical identifier of the project that +# will be used to construct file names etc. +export PROJECT_IDENT="FRONTEND" + +# Set the destination directory of Markdown files for this project. +# Since it will be used by VPTOOL, it shall NOT be a relative path. +export MARKDOWN_OUTPUT_DIR=`readlink -f "$ROOTDIR/../source"` + # Set Python path to make vpconfig.py reachable. export PYTHONPATH="$ROOTDIR:$PYTHONPATH" diff --git a/cva6/docs/VerifPlans/FRONTEND/vp_config.py b/cva6/docs/VerifPlans/FRONTEND/vp_config.py index 3cfd9556e9..1202993ed3 100644 --- a/cva6/docs/VerifPlans/FRONTEND/vp_config.py +++ b/cva6/docs/VerifPlans/FRONTEND/vp_config.py @@ -26,6 +26,10 @@ VP_PLATFORM_TOP_DIR = os.environ["PLATFORM_TOP_DIR"] # Name of the project (can be empty if the variable is not defined in environment.) PROJECT_NAME = os.environ["PROJECT_NAME"] + # Identifier of the project, to be used when constructing file names etc. + PROJECT_IDENT = os.environ["PROJECT_IDENT"] + # Location of Markdown output file(s) + MARKDOWN_OUTPUT_DIR = os.environ["MARKDOWN_OUTPUT_DIR"] # Location of database files SAVED_DB_LOCATION = os.path.join(VP_PLATFORM_TOP_DIR, "*.pck") # Location of the Pickle file containing the current IP/Feature lock info. diff --git a/cva6/docs/VerifPlans/VPTOOL-VerifPlan-HOWTO.md b/cva6/docs/VerifPlans/VPTOOL-VerifPlan-HOWTO.md new file mode 100644 index 0000000000..d290f860a0 --- /dev/null +++ b/cva6/docs/VerifPlans/VPTOOL-VerifPlan-HOWTO.md @@ -0,0 +1,144 @@ +[//]: # (Copyright 2022 Thales Silicon Security) +[//]: # (SPDX-License-Identifier: Apache-2.0 WITH SHL-2.0.) +[//]: # (Original Author: Zbigniew CHAMSKI ) + +# HOWTO use VPTOOL to edit and export DV plans + +## Introduction + +New features pertaining to Verification Plan exports are currently being developed and tested within the CVA6 ecosystem. They will be integrated in the `master` branch at a later date. Hence, the instructions below assume that you are working on the `cva6/dev` branch of the `core-v-verif` repository, or on a branch derived from it. + +## Requirements for Markdown output generation + +* VPTOOL (included in the `core-v-verif` distribution under `tools/vptool`) with its dependencies installed, as per instructions in file `core-v-verif/tools/vptool/VPTOOL-readme.txt`. +* Python packages related to the processing of markdown files (listed in file `requirements.txt`). +* Verification Plan directories, one per subsystem. + +## Installation + +### Step 1: Install the required packages + +If your system has access to the internet, you can install the packages using your preferred Python installer. Under Bash shell, you can do this using PIP and the command + +``` + for REQT in `cat requirements.txt` ; do python3 -m pip install $REQT ; done +``` + +Otherwise, up-to-date versions of the packages listed in file `requirements.txt` and their dependencies need to be installed manually. + +### Step 2: Configure per-subsystem databases + +Currently, the verification plan for each subsystem is stored in a separate VPTOOL database. The per-subsystem configuration consists of the following information: + +* a Python configuration file `vp_config.py` that specifies the naming of database files and the layout of database directories. The location of this file is treated as the root of the directory tree for a given database. +* shell variable `PLATFORM_TOP_DIR` which indicates the root location of the database files. It is recommended to use an absolute path; a good choice is the *effective* location of the database as returned by `dirname $(readlink -f )`. +* shell variable `PROJECT_NAME` which specifies the human-friendly name of the subsystem (a free-form string containing no newline characters). The value of this variable will serve as the name of the subsystem in the generated documentation. +* shell variable `PROJECT_IDENT` which specifies the file name stem to use in Markdown processing (no path separators, spaces nor special characters allowed). This string will be used to construct the name of the output Markdown file, and must be unique across all subsystems of a design. +* shell variable `MARKDOWN_OUTPUT_DIR` which designates the directory in which to place the generated per-subsystem Markdown files. The Markdown rendering tools that produce human-friendly output (e.g. HTML) for CVA6 Verification Plans are configured to take Markdown input from directory `core-v-verif/cva6/docs/VerifPlans/source`. It is recommended to use an absolute path; a good choice is the *effective* location of the database (`readlink -f $PLATFORM_TOP_DIR`) suffixed with the *relative* path to `source` as this avoids hardcoded absolute paths.) + +Additionnally, shell variable `PYTHONPATH` needs to contain the per-subsystem directory (in addition to other explicit module paths, if such paths are needed). + +To ensure consistent configurations between consecutive runs of VPTOOL on a given database, it is recommended to set these variables within a shell script (see `core-v-verif/cva6/docs/VerifPlans/FRONTEND/runme.sh` for an example.) + +Typically, creating a new database could be as simple as: + +* Create a directory for a new per-subsystem DV plan, say `cva6/docs/VerifPlans/NEW_ARCH_VARIANT/NEW_SUBSYSTEM`. +* Copy existing `vp_config.py` and `runme.sh` files from an existing per-subsystem Verification Plan directory to the newly created directory. +* Edit the `runme.sh` in the new directory to adjust the vaue of variable `PROJECT_NAME`, `PROJECT_IDENT` and `MARKDOWN_OUTPUT_DIR`. +* Using the adjusted `runme.sh` script, launch VPTOOL to interactively create the new database: + ``` + . cva6/docs/VerifPlans/NEW_ARCH_VARIANT/NEW_SUBSYSTEM/runme.sh + ``` + +### Step 3: Provide initial content of the database(s) + +In VPTOOL, modify the Verification Plan database of the new subsystem as appropriate. + +## Generation of DV plan documents + +### Step 1: Export database content to Markdown document(s) + +Currently, the generation of Markdown output is directly coupled to the action of saving database content of a project. When saving a database, VPTOOL will also create a Markdown file containing a human readable version of the DV plan in file `dvplan_${PROJECT_IDENT}.md` in directory designated by the shell variable `MARKDOWN_OUTPUT_DIR` set in the `runme.sh` script of the given subsystem. + +After editing the databases for projects `FRONTEND` and `NEW_ARCH_VARIANT/NEW_SUBSYSTEM` the directory layout will thus be: + +* `cva6/docs/VerifPlans` + * `FRONTEND` + * `runme.sh` : wrapper script + * `vp_config.py` : database configuration file for subsystem `FRONTEND` + * `VP_IPnnn.pck` : Verification Plan database files for subsystem `FRONTEND` + * ... + * `NEW_ARCH_VARIANT` + * `NEW_SUBSYSTEM` + * `runme.sh` : wrapper script for `NEW_SUBSYSTEM` (Let's assume that it sets `PROJECT_NAME="New Subsystem"` and `PROJECT_IDENT="NEW_SUBSYS"`.) + * `vp_config.py` : database configuration file for `NEW_SUBSYSTEM` + * `VP_IPnnn.pck` : files of the Verification Plan database for `NEW_SUBSYSTEM` + * ... + * `source` + * `conf.py` : configuration file for document generator + * `dvplan_FRONTEND.md` : Markdown version of verification plan for that `PROJECT_IDENT` for + * `dvplan_NEW_SUBSYS.md` : Markdown version of `NEW_SUBSYSTEM` verification plan (since the wrapper script set `PROJECT_IDENT` to `"NEW_SUBSYS"`.) + * `dvplan_intro.rst` : Markdown version of the introduction to the overall verification plan + * `dvplan_index.rst` : Markdown version of the overall verification plan document. + +### Step 2: Generate final DV plan documents + +In order to include the newly generated `NEW_SUBSYSTEM` verification plan into the overall DV Plan document, the file `source/dvplan_index.rst` needs to be modified so that it includes `dvplan_NEW_SUBSYS.md`. This is achieved by simply adding the name of the new DV plan Markdown document (without the `.md` extension) at the appropriate location in the document structure, e.g. after the line containing 'dvplan_FRONTEND`. + +Once the index file has been adjusted, the final document can generated in a variety of formats by invoking `make` in the directory `core-v-verif/cva6/docs/VerifPlans` with the desired output format as argument. The list of formats supported by your local Sphinx installation can be obtained by invoking `make` without arguments: + +``` +me@ariane:cva6/docs/VerifPlans$ make +Sphinx v1.8.4 +Please use `make target' where target is one of + html to make standalone HTML files + dirhtml to make HTML files named index.html in directories + singlehtml to make a single large HTML file + pickle to make pickle files + json to make JSON files + htmlhelp to make HTML files and an HTML help project + qthelp to make HTML files and a qthelp project + devhelp to make HTML files and a Devhelp project + epub to make an epub + latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter + latexpdf to make LaTeX and PDF files (default pdflatex) + latexpdfja to make LaTeX files and run them through platex/dvipdfmx + text to make text files + man to make manual pages + texinfo to make Texinfo files + info to make Texinfo files and run them through makeinfo + gettext to make PO message catalogs + changes to make an overview of all changed/added/deprecated items + xml to make Docutils-native XML files + pseudoxml to make pseudoxml-XML files for display purposes + linkcheck to check all external links for integrity + doctest to run all doctests embedded in the documentation (if enabled) + coverage to run coverage check of the documentation (if enabled) +me@ariane:cva6/docs/VerifPlans$ +``` + +The recommended target during the development of the verification plans is `singlehtml` as it offers the shortest turnaround time and interactive output with good readability. Also, some of the other formatting targets may depend on the availability of additional tools that may or may not be installed (or even installable) on your system. + +``` +me@ariane:cva6/docs/VerifPlans$ make singlehtml +Running Sphinx v1.8.4 +loading translations [en]... done +loading pickled environment... done +building [mo]: targets for 0 po files that are out of date +building [singlehtml]: all documents +updating environment: 0 added, 0 changed, 0 removed +looking for now-outdated files... none found +preparing documents... done +assembling single document... dvplan_intro dvplan_FRONTEND dvplan_NEW_SUBSYS +writing... done +writing additional files... +copying static files... done +copying extra files... done +dumping object inventory... done +build succeeded. + +The HTML page is in build/singlehtml. +me@ariane:cva6/docs/VerifPlans$ +``` + +The resulting document can be viewed by pointing your browser at the file `core-v-verif/cva6/docs/VerifPlans/build/singlehtml/index.html`. diff --git a/cva6/docs/VerifPlans/source/dvplan_FRONTEND.md b/cva6/docs/VerifPlans/source/dvplan_FRONTEND.md index cb44be0656..a18c88fe05 100644 --- a/cva6/docs/VerifPlans/source/dvplan_FRONTEND.md +++ b/cva6/docs/VerifPlans/source/dvplan_FRONTEND.md @@ -1,14 +1,18 @@ -# FRONTEND module +# Module: FRONTEND -## PC generation stage feature +## Feature: PC generation stage -### 001_BTB sub-feature +### Sub-feature: 001_BTB -#### 002 item +#### Item: 002 * **Requirement location:** FRONTEND sub-system/functionality/PC generation stage/Branch Predict -* **Feature Description:** If instruction is a JALR and BTB (Branch Target Buffer) returns a valid address, next PC is predicted by BTB. Else JALR is not considered as a control flow instruction, which will generate a mispredict. -* **Verification goals:** Execute test with JALR instructions. Functional cov: JALR is executed and BTB output is not valid. +* **Feature Description** + If instruction is a JALR and BTB (Branch Target Buffer) returns a valid address, next PC is predicted by BTB. + + Else JALR is not considered as a control flow instruction, which will generate a mispredict. +* **Verification goals** + Execute test with JALR instructions. Functional cov: JALR is executed and BTB output is not valid. * **Pass/Fail Criteria:** Check RM * **Test Type:** RISC-V Arch-test * **Coverage Method:** Functional Coverage @@ -16,13 +20,15 @@ * **Link to Coverage:** VP_IP003_P001_I002 * **Comments:** -### 002_BHT sub-feature +### Sub-feature: 002_BHT -#### 002 item +#### Item: 002 * **Requirement location:** FRONTEND sub-system/functionality/PC generation stage/Branch Predict -* **Feature Description:** If instruction is a branch and BTH (Branch History table) returns a valid address, next PC is predicted by BHT. Else branch is not considered as an control flow instruction, which will generate a mispredict when branch is taken. -* **Verification goals:** Execute test with BRANCH instructions. Functional cov: a BRANCH is executed, BTB output is not valid and the branch is taken. +* **Feature Description** + If instruction is a branch and BTH (Branch History table) returns a valid address, next PC is predicted by BHT. Else branch is not considered as an control flow instruction, which will generate a mispredict when branch is taken. +* **Verification goals** + Execute test with BRANCH instructions. Functional cov: a BRANCH is executed, BTB output is not valid and the branch is taken. * **Pass/Fail Criteria:** Check RM * **Test Type:** RISC-V Arch-test * **Coverage Method:** Functional Coverage @@ -30,13 +36,15 @@ * **Link to Coverage:** VP_IP003_P002_I002 * **Comments:** -### 003_RAS sub-feature +### Sub-feature: 003_RAS -#### 002 item +#### Item: 002 * **Requirement location:** FRONTEND sub-system/functionality/PC generation stage/Branch Predict -* **Feature Description:** If instruction is a RET and RAS (Return Address Stack) returns a valid address and RET has already been consummed by instruction queue. Else RET is considered as a control flow instruction but next PC is not predicted. A mispredict wil be generated. -* **Verification goals:** Execute test with RET instructions. Functional cov: RET is executed and RAS output is not valid. +* **Feature Description** + If instruction is a RET and RAS (Return Address Stack) returns a valid address and RET has already been consummed by instruction queue. Else RET is considered as a control flow instruction but next PC is not predicted. A mispredict wil be generated. +* **Verification goals** + Execute test with RET instructions. Functional cov: RET is executed and RAS output is not valid. * **Pass/Fail Criteria:** Check RM * **Test Type:** RISC-V Arch-test * **Coverage Method:** Functional Coverage @@ -44,13 +52,15 @@ * **Link to Coverage:** VP_IP003_P003_I002 * **Comments:** -### 004_Return from environment call sub-feature +### Sub-feature: 004_Return from environment call -#### 000 item +#### Item: 000 * **Requirement location:** FRONTEND sub-system/functionality/PC generation stage/Return from env call -* **Feature Description:** When CSR asks a return from an environment call, the PC is assigned to the successive PC to the one stored in the CSR [m-s]epc register. -* **Verification goals:** Set two different addresses for mepc and sepc in CSR registers. Use a arc_test returning from machine env call. Check by assertion that when machine return occurs the mepc address is fetched. Functional cov: execute a machine return. +* **Feature Description** + When CSR asks a return from an environment call, the PC is assigned to the successive PC to the one stored in the CSR [m-s]epc register. +* **Verification goals** + Set two different addresses for mepc and sepc in CSR registers. Use a arc_test returning from machine env call. Check by assertion that when machine return occurs the mepc address is fetched. Functional cov: execute a machine return. * **Pass/Fail Criteria:** Assertion * **Test Type:** RISC-V Arch-test * **Coverage Method:** Functional Coverage @@ -58,13 +68,15 @@ * **Link to Coverage:** VP_IP003_P004_I000 * **Comments:** -### 005_Exception/Interrupt sub-feature +### Sub-feature: 005_Exception/Interrupt -#### 000 item +#### Item: 000 * **Requirement location:** FRONTEND sub-system/functionality/PC generation stage/Exception -* **Feature Description:** If an exception (or interrupt, which is in the context of RISC-V systems quite similar) is triggered by the COMMIT, the next PC Gen is assigned to the CSR trap vector base address. The trap vector base address can be different depending on whether the exception traps to S-Mode or M-Mode (user mode exceptions are currently not supported) -* **Verification goals:** Set two different addresses for machine and supervisor handlers in CSR registers. Use a test which executes in machine mode and generates a machine exception by UVM. Check by assertion that when machine exception occurs the machine address is fetched. Functional cov: exception occurs in machine mode. +* **Feature Description** + If an exception (or interrupt, which is in the context of RISC-V systems quite similar) is triggered by the COMMIT, the next PC Gen is assigned to the CSR trap vector base address. The trap vector base address can be different depending on whether the exception traps to S-Mode or M-Mode (user mode exceptions are currently not supported) +* **Verification goals** + Set two different addresses for machine and supervisor handlers in CSR registers. Use a test which executes in machine mode and generates a machine exception by UVM. Check by assertion that when machine exception occurs the machine address is fetched. Functional cov: exception occurs in machine mode. * **Pass/Fail Criteria:** Assertion * **Test Type:** RISC-V Arch-test * **Coverage Method:** Functional Coverage @@ -72,13 +84,15 @@ * **Link to Coverage:** VP_IP003_P005_I000 * **Comments:** -### 006_Pipeline flush sub-feature +### Sub-feature: 006_Pipeline flush -#### 000 item +#### Item: 000 * **Requirement location:** FRONTEND sub-system/functionality/PC generation stage/Pipeline flush -* **Feature Description:** FRONTEND starts fetching from the next instruction again in order to take the up-dated information into account -* **Verification goals:** [no need to verify this point] +* **Feature Description** + FRONTEND starts fetching from the next instruction again in order to take the up-dated information into account +* **Verification goals** + [no need to verify this point] * **Pass/Fail Criteria:** NDY (Not Defined Yet) * **Test Type:** NDY (Not Defined Yet) * **Coverage Method:** NDY (Not Defined Yet) @@ -86,17 +100,19 @@ * **Link to Coverage:** VP_IP003_P006_I000 * **Comments:** -### 007_Debug sub-feature +### Sub-feature: 007_Debug -### 008_Address mapping change sub-feature +### Sub-feature: 008_Address mapping change -### 009_Pc gen priority sub-feature +### Sub-feature: 009_Pc gen priority -#### 000 item +#### Item: 000 * **Requirement location:** FRONTEND sub-system/functionality/PC generation stage -* **Feature Description:** The next PC can originate from the following sources (listed in order of precedence) -* **Verification goals:** Use arc_test executing return from env call and generate Exceptions by UVM during reset, Branch predict, default, mispredict, replay and return from env call. Functional cov: monitor the 6 events +* **Feature Description** + The next PC can originate from the following sources (listed in order of precedence) +* **Verification goals** + Use arc_test executing return from env call and generate Exceptions by UVM during reset, Branch predict, default, mispredict, replay and return from env call. Functional cov: monitor the 6 events * **Pass/Fail Criteria:** Check RM * **Test Type:** RISC-V Arch-test * **Coverage Method:** Functional Coverage @@ -104,11 +120,13 @@ * **Link to Coverage:** VP_IP003_P009_I000 * **Comments:** -#### 002 item +#### Item: 002 * **Requirement location:** FRONTEND sub-system/functionality/PC generation stage -* **Feature Description:** The next PC can originate from the following sources (listed in order of precedence) -* **Verification goals:** [other cases to be elaborated] +* **Feature Description** + The next PC can originate from the following sources (listed in order of precedence) +* **Verification goals** + [other cases to be elaborated] * **Pass/Fail Criteria:** NDY (Not Defined Yet) * **Test Type:** NDY (Not Defined Yet) * **Coverage Method:** NDY (Not Defined Yet) @@ -116,29 +134,31 @@ * **Link to Coverage:** VP_IP003_P009_I002 * **Comments:** -## BTB feature +## Feature: BTB -### 000_flush sub-feature +### Sub-feature: 000_flush -### 001_table depth sub-feature +### Sub-feature: 001_table depth -### 002_Table update sub-feature +### Sub-feature: 002_Table update -### 003_debug is not intrusive sub-feature +### Sub-feature: 003_debug is not intrusive -## BHT feature +## Feature: BHT -### 000_flush sub-feature +### Sub-feature: 000_flush -### 002_table update sub-feature +### Sub-feature: 002_table update -### 003_saturation sub-feature +### Sub-feature: 003_saturation -#### 000 item +#### Item: 000 * **Requirement location:** FRONTEND sub-system/Architecture and Modules/BHT -* **Feature Description:** The Branch History table is a two-bit saturation counter that takes the virtual address of the current fetched instruction by the CACHE. It states whether the current branch request should be taken or not. The two bit counter is updated by the successive execution of the current instructions as shown in the following figure. -* **Verification goals:** Execute a serie of taken and not taken branch to check the saturation mechanism +* **Feature Description** + The Branch History table is a two-bit saturation counter that takes the virtual address of the current fetched instruction by the CACHE. It states whether the current branch request should be taken or not. The two bit counter is updated by the successive execution of the current instructions as shown in the following figure. +* **Verification goals** + Execute a serie of taken and not taken branch to check the saturation mechanism * **Pass/Fail Criteria:** NDY (Not Defined Yet) * **Test Type:** NDY (Not Defined Yet) * **Coverage Method:** NDY (Not Defined Yet) @@ -146,35 +166,37 @@ * **Link to Coverage:** VP_IP005_P003_I000 * **Comments:** -### 004_Table depth sub-feature +### Sub-feature: 004_Table depth -### 005_Debug is not intrusive sub-feature +### Sub-feature: 005_Debug is not intrusive -## RAS feature +## Feature: RAS -### 000_flush sub-feature +### Sub-feature: 000_flush -### 001_table depth sub-feature +### Sub-feature: 001_table depth -### 002_Table update sub-feature +### Sub-feature: 002_Table update -### 003_Debug is not intrusive sub-feature +### Sub-feature: 003_Debug is not intrusive -## Instr_realign feature +## Feature: Instr_realign -### 000_C extension sub-feature +### Sub-feature: 000_C extension -### 001_Flush sub-feature +### Sub-feature: 001_Flush -## Instr_queue feature +## Feature: Instr_queue -### 000_FIFO depth sub-feature +### Sub-feature: 000_FIFO depth -#### 000 item +#### Item: 000 * **Requirement location:** FRONTEND sub-system/Architecture and Modules/Instr_queue -* **Feature Description:** The instruction queue contains max 4 instructions. -* **Verification goals:** Confirm that the best configuration for instruction queue entry number is 4 by monitoring the Coremark performance and silicon footprint +* **Feature Description** + The instruction queue contains max 4 instructions. +* **Verification goals** + Confirm that the best configuration for instruction queue entry number is 4 by monitoring the Coremark performance and silicon footprint * **Pass/Fail Criteria:** Other * **Test Type:** Other * **Coverage Method:** N/A @@ -182,23 +204,25 @@ * **Link to Coverage:** VP_IP008_P000_I000 * **Comments:** -### 001_Page fault exception sub-feature +### Sub-feature: 001_Page fault exception -### 002_Flush sub-feature +### Sub-feature: 002_Flush -## Instr_scan feature +## Feature: Instr_scan -## Fetch stage feature +## Feature: Fetch stage -### 001_MMU translation sub-feature +### Sub-feature: 001_MMU translation -### 002_Exceptions sub-feature +### Sub-feature: 002_Exceptions -#### 000 item +#### Item: 000 * **Requirement location:** FRONTEND sub-system/functionality/Fetch stage -* **Feature Description:** Memory and MMU (MMU is not enabled in CV32A6-step1) can feedback potential exceptions generated by the memory fetch request. They can be bus errors, invalid accesses or instruction page faults. -* **Verification goals:** Generate a bus error exception by UVM or by test (to be decided) and check that the exception address is fetched. Functional cov: a bus error exception occurs. +* **Feature Description** + Memory and MMU (MMU is not enabled in CV32A6-step1) can feedback potential exceptions generated by the memory fetch request. They can be bus errors, invalid accesses or instruction page faults. +* **Verification goals** + Generate a bus error exception by UVM or by test (to be decided) and check that the exception address is fetched. Functional cov: a bus error exception occurs. * **Pass/Fail Criteria:** NDY (Not Defined Yet) * **Test Type:** NDY (Not Defined Yet) * **Coverage Method:** NDY (Not Defined Yet) @@ -206,11 +230,13 @@ * **Link to Coverage:** VP_IP010_P002_I000 * **Comments:** -#### 002 item +#### Item: 002 * **Requirement location:** FRONTEND sub-system/functionality/Fetch stage -* **Feature Description:** Memory and MMU (MMU is not enabled in CV32A6-step1) can feedback potential exceptions generated by the memory fetch request. They can be bus errors, invalid accesses or instruction page faults. -* **Verification goals:** Generate an invalid access exception by UVM or by test (to be decided) and check that the exception address is fetched. Functional cov: an invalid access exception occurs. +* **Feature Description** + Memory and MMU (MMU is not enabled in CV32A6-step1) can feedback potential exceptions generated by the memory fetch request. They can be bus errors, invalid accesses or instruction page faults. +* **Verification goals** + Generate an invalid access exception by UVM or by test (to be decided) and check that the exception address is fetched. Functional cov: an invalid access exception occurs. * **Pass/Fail Criteria:** NDY (Not Defined Yet) * **Test Type:** NDY (Not Defined Yet) * **Coverage Method:** NDY (Not Defined Yet) diff --git a/tools/vptool/vptool/vp.py b/tools/vptool/vptool/vp.py index 3d96be4149..6132faf136 100755 --- a/tools/vptool/vptool/vp.py +++ b/tools/vptool/vptool/vp.py @@ -1727,9 +1727,7 @@ def save_db(self, save_as="no"): list(self.ip_list.items()), key=lambda key: key[1].ip_num ) # Create DVPLAN in Markdown format - md_dir = os.path.join( - os.path.dirname(vp_config.SAVED_DB_LOCATION), "..", "source" - ) + md_dir = vp_config.MARKDOWN_OUTPUT_DIR if os.path.isfile(md_dir): print( "*** MD destination '%s' is not a directory, cannot generate markdown output!" @@ -1747,11 +1745,11 @@ def save_db(self, save_as="no"): md_dir = os.path.dirname(vp_config.SAVED_DB_LOCATION) with open( os.path.join(md_dir, "dvplan_") - + vp_config.PROJECT_NAME + + vp_config.PROJECT_IDENT + ".md", "w", ) as md_file: - md_file.write("# %s module\n\n" % (vp_config.PROJECT_NAME)) + md_file.write("# Module: %s\n\n" % (vp_config.PROJECT_NAME)) for ip_elt in pickle_ip_list: md_file.write(str(ip_elt[1])) for rfu1_elt in ip_elt[1].rfu_list: diff --git a/tools/vptool/vptool/vp_pack.py b/tools/vptool/vptool/vp_pack.py index 8d9d064b3c..b1cab030a2 100755 --- a/tools/vptool/vptool/vp_pack.py +++ b/tools/vptool/vptool/vp_pack.py @@ -107,12 +107,22 @@ def attrval2str(self, attr): else: return "N/A (unsupported field '%s')" % attr + def preserve_linebrs(self, text, indent=" "): + '''Preserve line breaks in the text by inserting two spaces before + each newline. Ensure first line of 'text' starts on a new line.''' + md_linebreak = ' \n' + indent + return md_linebreak + md_linebreak.join(text.split('\n')) + def __str__(self): return0 = "" - return0 += format("#### %s item\n\n" % self.name) + return0 += format("#### Item: %s\n\n" % self.name) return0 += format("* **Requirement location:** %s\n" % self.purpose) - return0 += format("* **Feature Description:** %s\n" % self.description) - return0 += format("* **Verification goals:** %s\n" % self.verif_goals) + return0 += format( + "* **Feature Description** %s\n" % self.preserve_linebrs(self.description) + ) + return0 += format( + "* **Verification goals** %s\n" % self.preserve_linebrs(self.verif_goals) + ) return0 += format("* **Pass/Fail Criteria:** %s\n" % self.attrval2str("pfc")) return0 += format("* **Test Type:** %s\n" % self.attrval2str("test_type")) return0 += format( @@ -178,7 +188,7 @@ def __init__(self, name="", tag="", wid_order=0): self.rfu_dict = {} def __str__(self): - return format("### %s sub-feature\n\n" % (self.name)) + return format("### Sub-feature: %s\n\n" % (self.name)) def prop_clone(self): new_prop = Prop() @@ -300,7 +310,7 @@ def __init__(self, name="", index=""): self.rfu_list_1 = [] def __str__(self): - return format("## %s feature\n\n" % (self.name)) + return format("## Feature: %s\n\n" % (self.name)) def add_property(self, name, tag="", custom_num=""): # adds an Prop instance to Ip if name in list(self.prop_list.keys()):