Harmonic expands Aristotle into C and Verilog verification

Testing can show that a program behaved correctly on the inputs engineers chose. A proof can establish that a specified property holds across the inputs and states covered by its mathematical model. That distinction is the basis of Harmonic's latest expansion of Aristotle, its AI-assisted reasoning system, into formal verification for C software and Verilog hardware, announced on 27 October. The commercial ambition is to make a historically specialist discipline usable within ordinary code-review and continuous-integration workflows.[1]

The company says Aristotle can propose properties from source code, present the assumptions behind them and identify which properties have been proved, which have been refuted and which remain unresolved. Engineers are intended to review the proposed specifications, commit them to a repository and rerun verification as changes are made. Support for C targets program requirements and classes of undefined behaviour. Support for Verilog covers safety and liveness in control logic as well as mathematical data-path properties. A proof is machine checked against a declared specification, not accepted merely because a generative model says the code seems safe.[1]

The specification is part of the engineering work

The promise comes with a non-negotiable qualification. Formal verification does not establish that software is universally harmless or that engineers wrote the right requirements. If a property omits a failure mode, proving it may leave that failure mode untouched. A hardware proof may rely on an abstraction that excludes timing, analog effects or a particular external dependency. The disclosed assumptions and definition of valid inputs therefore deserve at least as much scrutiny as the tool's success message. A model that automatically proposes properties can accelerate specification discovery, but it cannot eliminate the need to decide what matters.[1]

Harmonic cites two concrete examples. At Tensordyne, it reports finding defects up to 110,000 clock cycles after reset in a complex hardware block. Its case study separates 185 properties proved from 56 refuted with counterexamples. At LibTomMath, the system repaired three bugs in version 1.2.0 and optimised two arithmetic routines. Benchmarks of full modular exponentiation then ran 1.31–1.38 times as fast as the repaired baseline on the disclosed hardware and compiler configuration. These are vendor-reported case studies, rather than an independent estimate of typical results.[1][2][3]

The LibTomMath distinction is especially useful. The proofs cover selected routines and their required helpers; full modular exponentiation was benchmarked, not proved. Harmonic also excludes termination, the rest of the library and performance from the proof. The reported speed gain and the assurance claim therefore have different scopes. An engineering team would need to compare both with its own platform, calling assumptions and security requirements before treating the result as applicable to its software.[3]

Why the AI coding boom changes verification demand

Code-generation tools can dramatically increase the volume of plausible implementations awaiting review. That does not guarantee more defects, but it does create pressure to check more changes without proportionate expansion of human reviewer time. A verification tool tied into continuous integration can make previously established guarantees visible when a change threatens them. The resulting workflow is most valuable where properties are specific and checkable—bounds, invariants, state transitions and defined numerical behaviour—rather than open-ended assurances such as reliable, ethical or secure.[1]

Harmonic offers self-service consumption-based access and says enterprise deployment choices include private-cloud and on-premises arrangements. Availability is not proof of affordability for a particular codebase. The practical costs include specifying what to prove, understanding failed proofs, adjusting abstractions and ensuring that developers do not treat incomplete verification as a green light. Those are organisational tasks as much as model capabilities.[1]

A useful trial would begin with a bounded component and written requirements, then record which properties were proved, refuted or left unresolved and how much engineering time the process required. That would test whether the tool improves a real verification workload while keeping the specification, assumptions and evidence available for review.[1][2][3]

Report an error or suggest a correction