A dual-core lockstep RISC processor implemented in SystemVerilog RTL for a final-year engineering project.
The system demonstrates hardware fault-detection concepts using two synchronized processor instances, an extended commit-interface comparator, controlled RTL fault injection, a watchdog for execution-progress monitoring, and automated fault-injection campaigns.
The goal of the project is to design and evaluate a compact hardware fault-detection architecture based on dual-core lockstep execution.
The system was evaluated according to three project-defined quantitative targets:
- Fault-detection coverage of at least 95%
- Fault-detection latency of no more than 5 clock cycles
- Additional safety-logic area overhead below 5%
The project demonstrates functional-safety concepts and fault-detection techniques. It does not claim ISO 26262 compliance or certification.
| Metric | Target | Measured Result | Status |
|---|---|---|---|
| Commit-interface fault detection coverage | >= 95% | 100.00% | PASS |
| Internal fault detection coverage | >= 95% | 98.67% | PASS |
| Combined structured campaign coverage | >= 95% | 99.09% | PASS |
| Comparator detection latency | <= 5 cycles | 0 cycles max | PASS |
| Watchdog detection latency | <= 5 cycles | 5 cycles | PASS |
| Safety-logic area overhead | < 5% | approximately 1.30% | PASS |
The system contains two identical single-cycle 32-bit RISC processor instances operating synchronously:
- Core A acts as the reference processor.
- Core B acts as the checker processor.
- Extended commit-interface comparator compares architecturally visible effects from both processors.
- RTL fault-injection logic introduces controlled faults into Core B.
- Watchdog independently monitors the execution progress of both processors using their Program Counters.
The comparator monitors seven architectural fields:
- Next Program Counter
- Register write enable
- Register destination address
- Register write-back data
- Memory write enable
- Memory address
- Memory write data
A difference between the corresponding Core A and Core B fields produces an immediate mismatch indication and a sticky mismatch flag.
The base processor is a simple single-cycle 32-bit RISC design implemented in SystemVerilog.
The RTL includes:
- Arithmetic Logic Unit
- Control unit
- Register file
- Instruction memory
- Data memory
- Sign extension
- Branch and jump control
- Program Counter update logic
- Architectural commit-interface outputs
The processor was intentionally kept compact so that lockstep execution, controlled fault injection, fault propagation, and detection behavior could be studied directly.
Fault injection is implemented at two different levels.
Core B's commit-interface signals can be modified using parameterized XOR-based fault-injection blocks.
The following fields can be faulted:
- Next PC
- Register write enable
- Register address
- Register write-back data
- Memory write enable
- Memory address
- Memory write data
Core A remains unmodified and acts as the reference for comparison.
A faultable version of Core B provides additional injection points inside the processor datapath and control logic.
The internal campaign includes faults affecting signals such as:
- ALU operands and results
- Register write-back paths
- Branch control
- Jump control
- ALU control
- Next-PC logic
- Memory-related control and datapath signals
This campaign evaluates whether an internal fault propagates to an architecturally visible difference that can be detected by the lockstep comparator or watchdog.
The first structured campaign injected faults directly into the seven Core B commit-interface fields.
| Metric | Result |
|---|---|
| Total injected faults | 105 |
| Detected faults | 105 |
| Undetected faults | 0 |
| Detection coverage | 100.00% |
| Average comparator latency | 0.00 cycles |
| Maximum comparator latency | 0 cycles |
All 105 injected faults produced a detectable difference between the two processor instances.
The second structured campaign injected faults into selected internal signals of Core B.
| Metric | Result |
|---|---|
| Total injected faults | 225 |
| Detected faults | 222 |
| Not observed | 3 |
| Detection coverage | 98.67% |
| Average comparator latency | 0.00 cycles |
| Maximum comparator latency | 0 cycles |
The three not-observed cases were all BRANCH_EQ faults injected while a jump instruction was executing.
The next-PC logic gives the unconditional jump path priority over the branch decision:
assign pc_next_raw = jump ? jump_target :
take_branch ? branch_target :
pc_plus4;Therefore, while jump = 1, corruption of BRANCH_EQ cannot affect the selected next PC. The injected faults are masked before reaching the monitored architectural interface and do not produce a mismatch between the two cores under this execution condition.
Across the commit-interface and internal campaigns:
| Metric | Result |
|---|---|
| Total injected faults | 330 |
| Detected faults | 327 |
| Not observed / masked faults | 3 |
| Combined fault-detection coverage | 99.09% |
The reported coverage is empirical fault-detection coverage for the fault models and test cases used in this project. It should not be interpreted as formal ISO 26262 diagnostic coverage.
A separate watchdog experiment evaluated detection of a processor that stops making forward execution progress.
A PC_HOLD fault was applied to Core B while Core A continued executing normally.
| Metric | Result |
|---|---|
| Fault type | Core B PC_HOLD |
| Detection result | Detected |
| Injection cycle | 6 |
| Detection cycle | 11 |
| Detection latency | 5 cycles |
The watchdog is configured with a timeout of four consecutive cycles without PC progress. The stall condition is subsequently captured by the sticky watchdog indication, producing a measured injection-to-detection latency of five clock cycles.
Hardware area was evaluated using Synopsys Fusion Compiler with the SAED14nm RVT technology library.
The dual-core hierarchy was preserved during synthesis so that Core A, Core B, and the additional top-level logic could be evaluated separately.
| Component | Fusion Compiler Cell Area |
|---|---|
| Core A | 13,677.80 |
| Core B | 13,663.54 |
| Combined processor cores | 27,341.34 |
| Additional top-level safety/wrapper logic | 355.96 |
| Complete lockstep system | 27,697.29 |
The additional area overhead is calculated as:
Area overhead = 355.96 / 27341.34 x 100%
= approximately 1.30%
The resulting area overhead is below the project target of 5%.
The area values above are taken from the hierarchy-preserved Fusion Compiler area report. The percentage comparison is the primary area metric used by the project.
fusa_cpu/
├── rtl/ # Processor, lockstep, comparator, FI and watchdog RTL
├── tb/ # SystemVerilog testbenches and fault campaigns
├── fusion/ # Fusion Compiler synthesis and implementation flow
│ ├── constraints/ # Timing constraints
│ ├── reports/ # Area, timing and implementation reports
│ ├── results/ # Generated implementation results and netlists
│ ├── rtl_synth/ # RTL used by the synthesis flow
│ ├── scripts/ # Fusion Compiler scripts
│ ├── setup/ # Technology and flow setup
│ └── work/ # Fusion Compiler work data
├── docs/ # Supporting technical documentation
├── results/ # Generated campaign results and summaries
├── scripts/ # Assembly and supporting utility scripts
├── fault_results.csv # Commit-interface campaign results
├── internal_fault_results.csv # Internal fault campaign results
├── Makefile # Simulation and campaign automation
└── README.md # Project overview and documentation
The RTL verification environment uses:
- SystemVerilog for RTL and testbenches
- Icarus Verilog for compilation
- VVP for simulation
- GTKWave / VCD waveforms for signal-level analysis
- GNU Make for test and campaign automation
- Synopsys Fusion Compiler for synthesis and hardware-area evaluation
The main testbenches are:
Clean previous generated simulation files:
make cleanRun the standalone processor test:
make cpuRun the basic dual-core lockstep test:
make lockstepRun the commit-interface fault campaign:
make fault_campaignRun the internal fault campaign:
make internal_fault_campaignRun the watchdog campaign:
make watchdog_campaignRun all major fault campaigns:
make campaignsThe Fusion Compiler flow is stored under fusion/ and requires an appropriate Synopsys Fusion Compiler environment together with the SAED14nm technology libraries.
- Single-cycle 32-bit RISC processor RTL
- Dual-core lockstep architecture
- Seven-field commit-interface comparator
- Reusable RTL fault-injection module
- Internal faultable processor implementation
- Execution-progress watchdog
- Automated commit-interface fault campaign
- Automated internal fault campaign
- Dedicated watchdog fault experiment
- CSV fault-injection results
- Coverage and latency measurements
- Fusion Compiler synthesis and area reports
The implemented dual-core lockstep processor satisfies all three quantitative objectives defined for the project.
The commit-interface campaign achieved 100.00% fault detection, while the internal campaign achieved 98.67% fault detection. Across both structured campaigns, 327 of 330 injected faults were detected, corresponding to an overall empirical fault-detection coverage of 99.09%.
Comparator-visible faults were detected with a measured maximum latency of 0 cycles, while the dedicated watchdog PC-hold experiment produced a detection latency of 5 cycles.
Fusion Compiler synthesis resulted in approximately 1.30% additional safety and wrapper logic area relative to the combined area of the two processor cores.
These results demonstrate the effectiveness of the implemented lockstep, comparator, watchdog, and fault-injection architecture under the fault models evaluated in this project.
