Skip to content

Commit

Permalink
[difftest] draft difftest organization doc
Browse files Browse the repository at this point in the history
  • Loading branch information
Clo91eaf committed Sep 10, 2024
1 parent 805d53e commit 4623b0f
Showing 1 changed file with 31 additions and 0 deletions.
31 changes: 31 additions & 0 deletions difftest/doc/organization.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
## Organizational Summary

`difftest` is a verification framework designed to separate the driver and diff test phases. The framework supports testing for two verification objects: `t1` and `t1rocket`. The basic structure and functionality are as follows:

### Directory Structure

1. **Top-Level Directory**
- `Cargo.lock` and `Cargo.toml`: For project management and dependency configuration.
- `default.nix`: Nix configuration file for building and managing the project environment.
- `doc/`: Documentation directory containing information about the project organization and structure.

2. **Verification Object Directories**
- `dpi_common/`: Contains shared library code, which are used across different verification objects.
- `dpi_t1/` and `dpi_t1rocket/`: Contain the TestBench code for `t1` and `t1rocket`, respectively. Each directory includes source files providing the DPI library linked by emulator(vcs or verilator), these DPIs will be called by corresponding Testbench.

3. **Verification and Driver Directories**
- `offline_t1/` and `offline_t1rocket/`: Correspond to the verification projects for `t1` and `t1rocket`, respectively. These directories include the main test code files, used for executing verification and testing.
- `spike_interfaces/`: Contains C++ code files for interface definitions.
- `spike_rs/`: Source files include `lib.rs`, `runner.rs`, and `spike_event.rs`, which provide the methods and tools needed during the verification phase.

### Workflow

1. **TestBench Generation**
- For each verification object (`t1` and `t1rocket`), corresponding TestBench code is used with emulator to generate the static library.

2. **Driving and Verification**
- The generated static library is driven by the Rust code in `spike_rs`.
- During the verification phase, interfaces provided by `spike_rs` generate the architectural information.

3. **Testing and Validation**
- Code in the `offline_t1` and `offline_t1rocket` directories carries out the actual offline difftest verification work, using `difftest.rs` and other test code to test the generated architectural information.

0 comments on commit 4623b0f

Please sign in to comment.