Formal Verification Sign-Off
Take a critical block from specification to a reviewable sign-off package.
- Agreed sign-off criteria
- Proof status, coverage, residual risk
- Starts with one pilot block
FORMAL VERIFICATION COMPANY · BENGALURU, INDIA
Prove your RTL is right
before tape-out.
Formal verification engineers and sign-off for critical digital IP and SoCs, inside your flow, on your tools.
FORMFORGEIQ
Formal verification workflow platform · Under development
Formal verification pilot flow
Spec and RTL review
Verification plan and sign-off criteria
Constraints and assumptions
SVA property development
Cover and reachability checks
Run proofs and debug counterexamples
Convergence: abstraction and invariants
Vacuity and over-constraint review
Proof depth and coverage closure
Sign-off evidence and peer review
Begin with a scoped pilot on one block, then expand when the goals and results support it.
HOW WE WORK WITH YOU
Choose the right way to engage our formal team
Start with a technical discussion or a focused pilot, then choose the level of support that fits your programme.
Formal Engineers in Your Team
Engineers join your verification team, onsite or remote, on your tools.
- Profiles shared before selection
- Under NDA, on your tools
- Engineering oversight from TSIQ
Managed Formal Team
A TSIQ-led formal team alongside your DV team across a longer programme.
- Scales across blocks, subject to capacity and project needs
- Single point of contact
- Programme-level reporting
Engineering Partnerships
Formal capacity for engineering companies delivering customer programmes, as overflow support or a defined work package.
- Works under your process and end-customer NDAs
- Vendor onboarding documents ready
- Engineering oversight from TSIQ
PILOT BLOCK
What a formal verification pilot includes
NDA, Scope and Tool Access
Agree the block, access, sign-off criteria and scope before work begins.
Plan and Environment
Read the spec and RTL, learn the risks; agree sign-off targets and strategy; build constraints, abstractions and properties.
Proof Results and Findings
Prove, debug, converge and report bugs; deliver the evidence package.
Walk-through With Your Team
Review the evidence, findings and recommended next steps together.
WHAT SIGN-OFF MEANS
Six conditions. One reviewable package.
A green proof run is not sign-off. This is.
- Every assertion proven, or bounded with a justified depth
- Every cover reached: no vacuous assertion
- Every assumption reviewed and checked
- Non-converging proofs analysed, not hidden
- Every counterexample closed as bug or fix
- Results reproducible and peer-reviewed
GATEFormal
sign-off
sign-off
Sign-off package
- Scope and verification plan
- Property list with proof status
- Assumption register and validation
- Abstractions and cut-points used
- Coverage and completeness argument
- Counterexample and bug reports
- Residual risk and known gaps
- SVA, scripts and run configs, in your repository
Reviewable by people who did not run the proofs
HOW WE GET THERE
Four gates, each with a written pass condition
- Scope gate
Block and risks on paper
We read your spec and RTL under NDA and name the behaviours simulation is most likely to miss.
Passes when the block, RTL version and risk list are written down
- Criteria gate
Sign-off defined before any proof runs
Proof targets, bounds, cover goals and the assumption policy are agreed with your team up front.
Passes when you have approved the criteria we will be measured against
- Proof gate
Converged, or explained
Constraints, abstractions and SVA are built, proofs are driven to closure, and every counterexample is triaged.
Passes when no open counterexample and no unexplained inconclusive result
- Review gate
A second engineer signs it
An engineer who did not run the proofs reviews the package before it reaches you.
Passes when the evidence package is reviewed and in your repository
WHY TERASILICON IQ
Built around one discipline
Formal-first engineering, reviewed evidence and a practical way to start small.
- Formal Verification is our flagship domain and the core of our methodology.
- Every result is tied to a property, RTL revision and run, then peer-reviewed.
- Formal and implementation engineers work together across RTL, netlists, ECOs and SDC.
- Start with one pilot block and review the plan, properties and evidence.
FROM RTL TO TAPE-OUT
Formal first, through to tape-out
Proving RTL is essential, but bugs and respins also come from what happens next: synthesis, SDC timing exceptions and late ECOs. We cover that handoff.
- Formal verification engineers and synthesis, LEC and STA engineers in one team
- SDC timing exceptions checked with formal properties before synthesis
- Formal assumptions and SDC reviewed against each other
- Closed loop for ECOs: FPV on the revised RTL, LEC on the netlist, STA on timing
Design areas
What formal checks in each design area
The design areas our formal methodology targets, with the checks and bug classes typical of each. Customer scope is confirmed for each engagement.
Processor and CPU control
Formal checks target decode, illegal instructions, exceptions, pipeline hazards, CSR access, privilege and memory protection.
ISA-derived properties
Write ISA-derived properties for decode, illegal instructions and exceptions.
Pipeline control
Prove pipeline stall, flush and hazard handling.
CSR and privilege rules
Verify CSR access, privilege and memory protection.
Decode errors
Mis-decoded instructions.
Pipeline loss
Instructions lost during flush.
Privilege escapes
Unauthorized CSR or memory access.
Cache coherence and memory
Prove coherence invariants such as single-writer / multiple-reader; check MESI and directory transitions across agents; verify DMA, memory ordering and ECC logic.
Coherence invariants
Prove coherence invariants such as single-writer / multiple-reader.
MESI transitions
Check MESI and directory transitions across agents.
Memory systems
DMA, memory ordering and ECC logic.
SWMR violations
Multiple writers or invalid reader states.
Stale data
Incorrect visibility across agents.
ECC mis-correction
Incorrect correction or error reporting.
Interconnect, NoC and protocols
Build reusable AXI, APB and CHI property sets; prove arbitration fairness and absence of starvation; check deadlock freedom and credit-based flow control.
Reusable protocol properties
Build reusable AXI, APB and CHI property sets.
Arbitration fairness
Prove arbitration fairness and absence of starvation.
Deadlock and credits
Check deadlock freedom and credit-based flow control.
Protocol violations
AXI or CHI rule failures.
Deadlock
Requests that cannot make progress.
Credit leaks
Lost or duplicated credits.
Hardware security
Prove secret data cannot reach untrusted outputs; verify lifecycle, secure-boot and debug-access gating; map checks to hardware security weakness lists.
Information flow
Prove secret data cannot reach untrusted outputs.
Lifecycle control
Verify lifecycle, secure-boot and debug-access gating.
Weakness mapping
Map checks to hardware security weakness lists.
Key leakage
Secret data exposed externally.
Debug bypass
Unauthorized debug unlock.
Illegal lifecycle
Invalid lifecycle states or transitions.
Compute and datapath
Prove RTL arithmetic against a reference model; check overflow, saturation and IEEE 754 rounding; verify pipeline latency and valid alignment.
Reference-model checks
Prove RTL arithmetic against a reference model.
Boundary behavior
Check overflow, saturation and IEEE 754 rounding.
Pipeline alignment
Verify pipeline latency and valid alignment.
Overflow
Incorrect arithmetic bounds.
Rounding errors
IEEE 754 result mismatches.
Latency misalignment
Data and valid output cycles differ.
Power, clock and reset
Prove power-state FSM legality and sequencing; check isolation, retention and clock-gating control; verify reset release order across domains.
Power-state sequencing
Prove power-state FSM legality and sequencing.
Isolation and retention
Check isolation, retention and clock-gating control.
Reset release
Verify reset release order across domains.
Missing isolation
Unisolated outputs during power-down.
Retention order
Incorrect retention sequencing.
Reset races
Reset release timing hazards.
CDC and RDC control
Prove async FIFO full/empty and data ordering; check Gray-code pointer progression; verify handshake and pulse-synchroniser protocols.
Async FIFO safety
Prove async FIFO full/empty and data ordering.
Gray-code pointers
Check Gray-code pointer progression.
Handshake protocols
Verify handshake and pulse-synchroniser protocols.
False full or empty
Incorrect FIFO status.
Gray-pointer errors
Invalid pointer transitions.
Lost events
Dropped synchronized events.
Equivalence and integration
Prove RTL revisions equivalent after refactoring or ECO; check SoC connectivity and pin-muxing; verify CSR maps and X-propagation behaviour.
RTL revision checks
Prove RTL revisions equivalent after refactoring or ECO.
SoC connectivity
Check SoC connectivity and pin-muxing.
Register-map checks
Verify CSR maps and X-propagation behaviour.
Refactoring changes
Unintended functional changes.
Wiring errors
Connectivity mismatches.
CSR policy bugs
Access-policy and register-map errors.
Use the arrows or select a capability to explore the engineering support areas.
FREQUENTLY ASKED
Quick answers
Quick answers about starting a formal verification engagement and reaching sign-off.
The RTL of the target block, its specification and a few sessions with the designer. No in-house formal expertise is needed.
On customer work, we run on your commercial formal tools, licences and infrastructure. Our internal work uses open-source formal tools.
We discuss your design, verification goals, tools and timeline. No design data is needed at this stage. If there is a fit, the next step is an NDA and written scope.
Typically within a few weeks of NDA, scope and tool access. Exact dates are confirmed during scoping.
When all six sign-off conditions are met and documented, not when a proof run turns green.
FORMAL VERIFICATION · BENGALURU, INDIA
Let’s Discuss Your Engineering Requirements
We welcome discussions with semiconductor companies, ASIC and SoC design teams and engineering partners looking for specialised Formal Verification support.