💻 computer science

Embedding Formal Worst-Case Latency Proofs and Memory-Safety Certificates into the snn-mlir MLIR Lowering Pipeline for IEC 62304-Compliant Edge Deployment of Spiking Neural Networks

This paper introduces a post-processing MLIR analysis pass for the snn-mlir compiler that generates machine-checkable worst-case latency proofs and memory-safety certificates, thereby enabling the IEC 62304 Class B compliant deployment of spiking neural networks for safety-critical edge medical devices like seizure detectors.

Original authors: Hassan Farooq

Published 2026-07-07

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Hassan Farooq

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have built a very smart, energy-efficient robot brain (called a Spiking Neural Network or SNN) designed to listen to a patient's brainwaves and spot seizures before they happen. This robot brain is perfect for tiny, battery-powered medical devices because it's fast and uses very little power.

However, there's a big problem: No one trusts it yet.

In the world of medical devices, you can't just say, "It works most of the time." You need absolute proof that it will never be too slow or crash, even in the worst possible scenario. If the robot brain takes too long to react, the patient could be in danger. Currently, the tools used to build these robot brains are like a bakery that bakes delicious cakes but refuses to give you a certificate proving the oven temperature was safe or that the cake won't burn your tongue.

This paper introduces a new "safety inspector" that fixes this gap. Here is how it works, using simple analogies:

1. The Missing Link: The "Safety Inspector"

The authors created a special software tool (a "post-processing pass") that acts like a super-strict safety inspector.

The Old Way: You build the robot brain, turn it into code (C11), and hope it's fast enough.
The New Way: After the code is built, this inspector looks at the blueprint (the control-flow graph), calculates the absolute slowest possible time the robot could ever take to think, and writes a certificate right onto the code.

2. The "Worst-Case" Calculation (The Traffic Jam Analogy)

To prove the robot brain is safe, the inspector uses a method called IPET. Think of the robot's thinking process as a car driving through a city with many intersections (loops and decisions).

Usually, the car drives fast.
But the inspector asks: "What is the absolute worst traffic jam that could happen? What if every light is red, and every road is blocked?"
The inspector solves a complex math puzzle (an "Integer Linear Program") to find that worst-case traffic jam.
The Result: They found that even in the worst traffic jam, the robot brain takes only 100.6 microseconds to make a decision.
The Safety Margin: The medical device needs to react within 50 milliseconds (50,000 microseconds). The robot brain is 497 times faster than the deadline. It's like finishing a 100-meter race in 0.2 seconds when the rule says you have 100 seconds to finish. You are safe.

3. The "Proof Book" (Lean4 Stubs)

The paper also mentions Lean4, which is like a digital notary public.

The inspector doesn't just write a note saying "It's fast." It writes a formal mathematical promise (a "proof obligation") into a special language that computers can check.
Think of these as "placeholders" in a contract. The paper says, "We have written the contract that says 'This code is safe.' A lawyer (a human expert) could sign off on it later."
This is the first time such a formal contract has been attached to this type of robot brain code.

4. The Medical Standard (IEC 62304)

Medical devices must follow a strict rulebook called IEC 62304. It's like a checklist for building a safe airplane.

The authors showed that their new process creates a "paper trail" that covers most of the checklist (about 75% of the core requirements).
They proved they can trace the code all the way back to the original design, which is a huge step toward getting official approval for medical use.

5. The Test Drive (Seizure Detection)

To prove this works, they tested it on real data from two patients with epilepsy (from the CHB-MIT dataset).

The Result: The robot brain correctly identified seizures 78.8% of the time.
The Speed: It ran so fast that it had a massive safety buffer. Even though they tested it on a standard computer (not the tiny medical chip yet), the math proved it would be safe on the tiny chip too.

Summary of What Was Achieved

The Problem: We had smart medical AI, but no way to prove it was fast enough for life-or-death situations.
The Solution: A new tool that automatically calculates the "worst-case" speed and attaches a formal safety certificate to the code.
The Outcome: They successfully built a seizure-detection robot brain, proved mathematically that it is 497 times faster than the safety limit, and created the documentation required to start the process of making it a certified medical device.

Important Note: The paper admits this is a "first draft" of the safety process. They haven't built the final medical device yet, and they haven't fully signed the final legal contracts (the "Lean4 proofs" are currently just the outline of the contract). But they have built the roadmap and the tools to get there, which has never been done before for this specific type of technology.

Technical Summary: Embedding Formal Worst-Case Latency Proofs and Memory-Safety Certificates into the snn-mlir MLIR Lowering Pipeline

1. Problem Statement

Neuromorphic Spiking Neural Networks (SNNs) offer energy-efficient temporal computation suitable for edge medical devices, such as closed-loop neurostimulators for epilepsy. However, their deployment in safety-critical settings is currently blocked by a "toolchain gap." While existing frameworks like snnTorch and compilers like snn-mlir can generate valid C11 code from trained models, they fail to produce machine-checkable evidence that the compiled inference functions satisfy Worst-Case Execution Time (WCET) bounds or the documentation requirements of IEC 62304 Class B certification.

Current SNN compilers do not integrate formal verification methods (such as the Implicit Path Enumeration Technique, or IPET) to prove that code meets strict latency constraints required for implantable hardware. Without these proofs, SNNs cannot be certified for medical use under standards like IEC 62304, which mandates traceability from requirements to verified implementation.

2. Methodology

The authors propose a post-processing analysis pass that operates on the Multi-Level Intermediate Representation (MLIR) emitted by the snn-mlir compiler. The pipeline consists of the following stages:

Model Training and Export: A three-layer feedforward Leaky Integrate-and-Fire (LIF) SNN was trained using snnTorch on the CHB-MIT scalp EEG dataset (patients chb01 and chb02) for seizure detection. The model was exported to the Neuromorphic Intermediate Representation (NIR) format.
Compilation: The NIR graph was lowered to C11 code using snn-mlir (commit 89b65e0). The code was compiled with GCC at optimization level -O0 to ensure a stable, unoptimized correspondence between source structure and emitted instructions, which is necessary for accurate control-flow graph (CFG) extraction.
Formal WCET Analysis (IPET): A Python post-processing pass (certify.py) extracts the CFG of each compiled LIF layer. It formulates an Implicit Path Enumeration Technique (IPET) Integer Linear Program (ILP) parameterized by the instruction timing of the ARM Cortex-M4F microcontroller. The ILP maximizes the flow of cycles subject to flow-conservation constraints and loop-back bounds.
Annotation and Certification: The pass annotates the resulting C11 code with @wcet_bound comments and generates Lean4 proof-obligation stubs. These stubs formally state the WCET bounds as proof obligations, linking the compiler output to a proof assistant.
IEC 62304 Mapping: The generated artifacts (CFG documentation, annotated source, test logs) are mapped to specific clauses of IEC 62304 Class B (Software Development Process) to demonstrate compliance with documentation and traceability requirements.

3. Key Contributions

The paper claims four primary contributions:

Formulation of WCET for SNNs: The authors formulate WCET analysis for snn-mlir-compiled LIF inference functions as an IPET ILP parameterized by ARM Cortex-M4F instruction timing.
Automated Post-Processing Pass: Implementation of a Python pass that automates CFG extraction, ILP solving, WCET annotation, and Lean4 stub generation without requiring modifications to the underlying C++ compiler codebase.
End-to-End Validation: Validation of the pipeline on a clinically relevant seizure detection task, demonstrating that the compiled C11 inference matches the reference Python model while adhering to static analysis constraints.
IEC 62304 Artifact Bundle: Provision of a mapped artifact bundle covering IEC 62304 Class B documentation categories, representing a pathway from a trained model to regulatory-compliant documentation.

4. Results

Model Performance: The trained SNN achieved a 78.8% balanced accuracy (95% CI: 74.5–83.2%) on the held-out test set, exceeding the 75% credibility threshold. Sensitivity was 68.6% and specificity was 89.1%.
Compilation Correctness: The compiled C11 inference function showed negligible divergence from the snnTorch Python reference (max divergence $\approx 1 \times 10^{-5}$ ), attributed to floating-point precision differences rather than systematic bias.
WCET Bounds:
- The IPET analysis yielded a uniform per-layer bound of 5,634 cycles.
- The certified network bound for the three-layer network is 16,902 cycles (100.6 µs at 168 MHz).
- This bound provides a 497× margin below the 50 ms hard real-time deadline for neurostimulation.
- The measured execution time was 8,627 cycles (51.4 µs), well within the certified bound.
Artifact Coverage: The generated bundle fully covers five of the eight IEC 62304 §5.x software development process categories and partially covers two others, resulting in a score of 6.0/8.0 for the development process. It fully covers configuration management (§8.0) but notes a lack of formal software risk management analysis (§7.1).

5. Significance and Claims

The authors position this work as the first publicly documented pathway from a trained snnTorch model to an IEC 62304 Class B documentation bundle for an SNN inference function.

Novelty: The work bridges the gap between neuromorphic compiler outputs and formal verification standards, specifically applying IPET to SNNs and generating Lean4 proof obligations.
Modesty and Limitations: The authors explicitly state that the Lean4 stubs are specifications, not verified proofs; discharging these proofs is left to future collaborators. The WCET bounds are derived from unoptimized (-O0) builds and applied as a cross-architecture approximation (x86_64 host with ARM timing models) rather than through native ARM cross-compilation. The risk management analysis (§7.1) was not performed, and the study is limited to two patients from the CHB-MIT dataset.
Conclusion: The pipeline establishes a reproducible baseline for future work toward fully verified neuromorphic edge deployment, demonstrating that SNNs can be compiled into C11 code with machine-checkable latency bounds suitable for safety-critical medical device certification.