GitHub - Jeries9947/fusa_cpu: Single cycle RISC lockstep CPU with comparator and watchdog · GitHub
Skip to content
Jeries9947Public

About

Single cycle RISC lockstep CPU with comparator and watchdog

Resources

Stars

0 stars

Watchers

0 watching

Forks

Repository files navigation

FuSa Lockstep CPU

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.

Project Goal

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.

Project Targets and Final Results

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

Architecture

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:

  1. Next Program Counter
  2. Register write enable
  3. Register destination address
  4. Register write-back data
  5. Memory write enable
  6. Memory address
  7. Memory write data

A difference between the corresponding Core A and Core B fields produces an immediate mismatch indication and a sticky mismatch flag.

Processor Implementation

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

Fault injection is implemented at two different levels.

Commit-Interface Fault Injection

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.

Internal Fault Injection

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.

Final Fault-Injection Results

Campaign 1: Commit-Interface Fault Injection

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.

Campaign 2: Internal Checker-Core Fault Injection

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.

Combined Structured Campaigns

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.

Campaign 3: Watchdog PC-Hold Fault

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 Evaluation

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.

Repository Structure

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

Verification Environment

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:

Testbench Purpose
tb_cpu_basic.sv Basic standalone CPU execution
tb_lockstep.sv Normal lockstep execution and mismatch testing
tb_fault_campaign.sv Commit-interface fault campaign
tb_internal_fault_campaign.sv Internal Core B fault campaign
tb_watchdog_campaign.sv PC-hold and watchdog evaluation

Running the Simulations

Clean previous generated simulation files:

make clean

Run the standalone processor test:

make cpu

Run the basic dual-core lockstep test:

make lockstep

Run the commit-interface fault campaign:

make fault_campaign

Run the internal fault campaign:

make internal_fault_campaign

Run the watchdog campaign:

make watchdog_campaign

Run all major fault campaigns:

make campaigns

The Fusion Compiler flow is stored under fusion/ and requires an appropriate Synopsys Fusion Compiler environment together with the SAED14nm technology libraries.

Main Deliverables

  • 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

Conclusion

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.

About

Single cycle RISC lockstep CPU with comparator and watchdog

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages