Cone-Of-Influence Analysis

Cone-Of-Influence Analysis (COI)

Concept

Cone-Of-Influence (COI) analysis is a static reduction technique used in model checking that filters the design to include only those signals that may affect a target assertion. By excluding signals outside the cone of influence from proof obligations, COI analysis shrinks the reachable state space and accelerates formal verification.

First seen 7/10/2026

Last seen 7/10/2026

Evidence 2 chunks

Wiki v1

WIKI

Overview

Cone-Of-Influence (COI) analysis is a reduction technique employed in model checking to limit the portion of a design that must be analyzed when proving a specific assertion. The objective is to identify, for each target property, the set of signals whose values can in principle influence whether that property holds, and to exclude all other signals from the verification problem.

Mechanism

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

2 connections

Using Formal Verification to Evaluate Single Event Upsets in a RISC-V Core ← uses 90% 1e

COI analysis is used in model checking to filter irrelevant signals and speed up verification.

Model Checking ← uses 90% 1e

COI analysis is used in model checking to filter irrelevant signals and reduce state space.

LINKED ENTITIES

2 links

Using Formal Verification to Evaluate Single Event Upsets in a RISC-V Core USES Extracted graph relationship

Model Checking USES Extracted graph relationship

CITATIONS

8 sources

8 citations — click to expand

[1] COI analysis is used in model checking to filter signals that may affect the target assertion. Using Formal Verification to Evaluate Single Event Upsets in a RISC-V Core

[2] Signals outside the COI are excluded from proving assertions, contributing to speeding up model checking by filtering the state space. Using Formal Verification to Evaluate Single Event Upsets in a RISC-V Core

[3] COI analysis reported 81 common safe bits that cannot result in SDCs in the Ibex Core. Using Formal Verification to Evaluate Single Event Upsets in a RISC-V Core

[4] The 81 COI-reported safe bits are reliable because none of them is consumed downstream in the Ibex Core. Using Formal Verification to Evaluate Single Event Upsets in a RISC-V Core

[5] The specific COI-reported safe bits are instr_rdata_alu_id_o[24:15], instr_rdata_alu_id_o[11:7], stored_addr_q[31:0], fetch_addr_q[31:0], and imd_val_q[1][33:32]. Using Formal Verification to Evaluate Single Event Upsets in a RISC-V Core

[6] stored_addr_q and fetch_addr_q store memory request addresses aligned to 4 bytes, so the two least significant bits are not consumed and faults in those bits have no effect. Using Formal Verification to Evaluate Single Event Upsets in a RISC-V Core

[7] All bits of stored_addr_q and fetch_addr_q are treated as safe because the memory abstraction assumes faults are corrected within the memory and do not propagate back to the core. Using Formal Verification to Evaluate Single Event Upsets in a RISC-V Core

[8] The Ibex Core contains 71 registers totaling 2008 register bits, with the study focusing on bits internal to the core and excluding Instruction Memory and Data Memory. Using Formal Verification to Evaluate Single Event Upsets in a RISC-V Core