You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two distinct concepts were both being called testcases. This clarifies
the terminology and lays out a clear hierarchy:
```
test suite
└── test file
└── test chunk
└── testcase
```
Copy file name to clipboardExpand all lines: docs/DeveloperGuide.md
+39-19Lines changed: 39 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,6 +8,7 @@ Each is described below.
8
8
## Table of Contents
9
9
10
10
-[Certification Test Plan](#certification-test-plan)
11
+
-[Test Hierarchy](#test-hierarchy)
11
12
-[Table-Driven Unprivileged Coverpoints and Tests](#table-driven-unprivileged-coverpoints-and-tests)
12
13
-[Creating New CSV Testplans](#creating-new-csv-testplans)
13
14
-[Adding New Coverpoints](#adding-new-coverpoints)
@@ -59,6 +60,25 @@ The `generate_param_table.py` script turns these into .adoc files in ctp/src/par
59
60
60
61
This script is also run automatically when making the CTP. Hence, all the developer must do is create YAML files in `coverpoints/param` for test suites with parameters.
61
62
63
+
## Test Hierarchy
64
+
65
+
The testgen package organizes generated tests into four levels:
66
+
67
+
```
68
+
test suite
69
+
└── test file
70
+
└── test chunk
71
+
└── testcase
72
+
```
73
+
74
+
-**Testcase**: The smallest unit of testing. Each testcase checks a single bin of a coverpoint. In the generated assembly, a testcase corresponds to one call to `test_data.add_testcase()`, which creates a label and debug string for that specific bin. For example, testing that `add` writes to `x5` is one testcase of the `cp_rd` coverpoint.
75
+
76
+
-**Test chunk** (`TestChunk`): An unsplittable group of one or more testcases. A test chunk is the building block of test files. Test chunks are never split across multiple files. Standard coverpoint generators (e.g., `cp_rd`, `cp_imm_edges`) produce one chunk per testcase via `format_single_testcase()`. Special coverpoint generators and privileged tests bundle multiple testcases into a single chunk using `test_data.begin_test_chunk()` / `test_data.end_test_chunk()`, typically because the testcases share setup code.
77
+
78
+
-**Test file**: A complete `.S` assembly file that is compiled into a self-checking ELF. Each test file contains one or more test chunks. When an instruction has many testcases (e.g., hundreds of register/immediate combinations), the framework splits the chunks across multiple test files using `TESTCASES_PER_FILE` as the limit. Test files are named like `I-add-00.S`, `I-add-01.S`, etc., where the suffix indicates the file index.
79
+
80
+
-**Test suite**: All test files in a given directory. Each test suite corresponds to one extension or combination of extensions (e.g., `I`, `Zcb`, `ZcbZbb`, `ExceptionsSm`) and maps to a single coverage file. Unprivileged test suites contain one or more test files per instruction. For privileged tests, a test suite typically contains a single test file covering all coverpoints for that feature.
81
+
62
82
## Table-Driven Unprivileged Coverpoints and Tests
63
83
64
84
Unprivileged tests are tests that exercise individual instructions and do not trap.
@@ -137,14 +157,14 @@ The following applies to all coverpoint test generators:
137
157
- All coverpoint generator functions must use the following signature:
-`instr_name` is the instruction currently being tested. This allows coverpoint test generators to be reused for multiple instructions.
144
164
-`instr_type` is the type of the instruction currently being tested. This allows the correct instruction formatter (see below) to be selected.
145
165
-`coverpoint` is the full name of the coverpoint, including any variant suffix. Coverpoint test generators can match multiple variants of a coverpoint. This argument allows different values, registers, etc. to be selected based on the variant.
146
-
-`test_data` is the generation context that is passed to all parts of the test generation process and manages register allocation, test counting, and the active `TestCase`.
147
-
- The generator must return a list of `TestCase` objects. Each `TestCase`holds its own assembly code, data values, debug strings, and signature update count. The framework uses these to split tests across files and combine them into the final output.
166
+
-`test_data` is the generation context that is passed to all parts of the test generation process and manages register allocation, test counting, and the active `TestChunk`.
167
+
- The generator must return a list of `TestChunk` objects. Each `TestChunk` is an unsplittable group of one or more testcases. It holds its own assembly code, data values, debug strings, and signature update count. The framework uses these to split test chunks across test files and combine their data for the final output.
148
168
149
169
Coverpoint test generators can largely be broken into two categories: standard and special.
150
170
Standard generators use the [instruction formatters](#python-instruction-formatters) and can be applied to a wide range
@@ -166,7 +186,7 @@ It is also included below with many additional comments added to explain how it
166
186
# which coverpoints they apply to.
167
187
@add_coverpoint_generator("cp_rd")
168
188
# Coverpoint generators all use the standard signature described above.
0 commit comments