|
| 1 | +<!-- |
| 2 | +# Copyright lowRISC contributors (OpenTitan project). |
| 3 | +# Licensed under the Apache License, Version 2.0, see LICENSE for details. |
| 4 | +# SPDX-License-Identifier: Apache-2.0 |
| 5 | +--> |
| 6 | +# The `lowrisc-dv-evidence` format |
| 7 | + |
| 8 | +A regression tells you which tests passed. |
| 9 | +A verification plan asks a different question: of everything we said we would verify, how much is now backed by something that ran? |
| 10 | +Answering it needs the regression's own outcomes in a form a planning tool can read, rather than a log directory and a human. |
| 11 | + |
| 12 | +This is that form. |
| 13 | +DVSim writes one of these files per simulation flow, and it is the definition of the format rather than a description of one tool's output. |
| 14 | +Anything that can produce it can be scored against a verification plan, whether or not it is DVSim. |
| 15 | + |
| 16 | +## Where DVSim writes it |
| 17 | + |
| 18 | +`<scratch_path>/cov_vplan/dv_evidence.json`, produced by the `cov_vplan` job, and only when the sim config names a `vplan`. |
| 19 | +It is written before the annotation step runs and is archived alongside the reports, so it outlives the scratch area it describes. |
| 20 | + |
| 21 | +## Shape |
| 22 | + |
| 23 | +```json |
| 24 | +{ |
| 25 | + "schema": "lowrisc-dv-evidence", |
| 26 | + "dut": "hmac", |
| 27 | + "tool": "xcelium", |
| 28 | + "produced_by": "dvsim 1.50.1", |
| 29 | + "revision": "https://github.com/lowRISC/opentitan/tree/a1b2c3d (dirty)", |
| 30 | + "timestamp": "2026-08-18T09:00:00+00:00", |
| 31 | + "testcase": { |
| 32 | + "hmac_smoke": [ |
| 33 | + { "status": "passed", "seed": 1234, "log": "/scratch/hmac/1234.hmac_smoke/run.log" }, |
| 34 | + { "status": "failed", "seed": 5678, "log": "...", "message": "UVM_ERROR", "line": 812 } |
| 35 | + ], |
| 36 | + "hmac_stress_all": [ |
| 37 | + { "status": "not_run" } |
| 38 | + ] |
| 39 | + } |
| 40 | +} |
| 41 | +``` |
| 42 | + |
| 43 | +Fields are omitted when they have no value rather than written as `null`. |
| 44 | + |
| 45 | +### Top level |
| 46 | + |
| 47 | +| Key | Meaning | |
| 48 | +| --- | --- | |
| 49 | +| `schema` | Always `lowrisc-dv-evidence`. Identifies the format to whatever reads the file. | |
| 50 | +| `testcase` | Test name to the list of runs of that test. The only required key. | |
| 51 | +| `dut` | The design the results are about, named as a verification plan addresses it. | |
| 52 | +| `tool` | The simulator that produced them. | |
| 53 | +| `produced_by` | What wrote the file, with its version. | |
| 54 | +| `revision` | The tree the results were produced against, suffixed ` (dirty)` when it was not clean. | |
| 55 | +| `timestamp` | When the run started, as an ISO 8601 datetime with an offset. | |
| 56 | + |
| 57 | +### A run |
| 58 | + |
| 59 | +Every entry under `testcase` is keyed by the test name, because that is the name a plan refers to. |
| 60 | +Reseeds of one test share the key and are told apart by `seed`. |
| 61 | + |
| 62 | +| Key | Meaning | |
| 63 | +| --- | --- | |
| 64 | +| `status` | One of `passed`, `failed`, `killed`, `not_run`. Required. | |
| 65 | +| `seed` | The seed the run used, where the flow randomises. | |
| 66 | +| `log` | Path to the run's log. | |
| 67 | +| `message` | Why it ended that way. Present only on a run that did not pass. | |
| 68 | +| `line` | The log line the failure was first reported at. | |
| 69 | + |
| 70 | +`killed` and `not_run` are separate on purpose. |
| 71 | +A killed test started and was terminated, so the design was exercised and something went wrong. |
| 72 | +A `not_run` test never started, because the scheduler cancelled it once a dependency failed or the run was shut down. |
| 73 | +The two are different answers to "did we verify this", and collapsing them would let a build failure read as a passing plan item. |
| 74 | + |
| 75 | +There is no `waived` status. |
| 76 | +A waiver needs an owner and a date, and a regression can supply neither, so a known failure is recorded as an inspection instead. |
| 77 | + |
| 78 | +## Inspections |
| 79 | + |
| 80 | +The format also carries an `inspection` key, for claims no simulation can measure, such as a parameterisation or a structural fact. |
| 81 | +Those records are written by hand and live in the tree next to the plan they support. |
| 82 | +DVSim never produces them; it only passes their path through to whatever consumes this format, so they are out of scope for this document. |
| 83 | + |
| 84 | +## Consumers |
| 85 | + |
| 86 | +[DVPlan](https://github.com/lowRISC/dvplan) reads it to back-annotate a verification plan. |
| 87 | +It is not the only thing that could: the format carries no DVPlan concepts, and a dashboard or a CI job wanting machine-readable regression results can read the same file. |
| 88 | + |
| 89 | +## Changing it |
| 90 | + |
| 91 | +The pydantic models in `src/dvsim/report/dv_evidence.py` are the normative definition, and this document describes them. |
| 92 | +A change to either is a change to the format, so change both, and bear in mind that a consumer may be reading files this repo wrote months ago. |
0 commit comments