Translate security intent, then make the result prove itself

Security assertions describe behavior that a hardware design must always permit or prevent. Engineers can use them to express rules about privilege boundaries, control flow, memory protection and other processor behavior. The challenge is that an assertion written for one implementation rarely transfers directly to another. Two processors may share the RISC-V instruction set while using different internal signals, module boundaries, timing conventions and control logic.

A September 9 preprint introduces AutoTrans, a research pipeline for translating an existing assertion corpus to a different RISC-V processor. It combines a lightweight SystemVerilog parser, structured language-model prompts, compilation and formal property verification. The language model proposes the translation, but its output does not enter the accepted set merely because it looks plausible. It must compile and be proven non-vacuous against the target design.

That final condition is important. A vacuous assertion may appear to pass because its triggering condition can never occur. AutoTrans asks the formal tool to reject that empty success along with assertions contradicted by a counterexample. The design therefore treats generation as a source of candidates and formal verification as an acceptance gate. This is a stronger engineering boundary than trusting fluent code or measuring whether generated text resembles a reference answer.

Grounding starts with the target design

The first stage parses the target processor's register-transfer-level code. AutoTrans uses regular expressions to extract module ports, internal signals, parameters and referenced package types. It records those elements in structured JSON, detects conventional clock and reset names for sequential modules and selects either a clocked or combinational assertion template. The parser is narrower than a complete SystemVerilog compiler, but it supplies the model with names that actually exist in the chosen design.

Prompt assembly combines that inventory with the source security-property group, module metadata and a fixed template. The resulting prompt is saved so its exact contents can be audited. The authors used DeepSeek V4-Flash through NVIDIA NIM for the initial translation. When compilation or formal verification identified a failure, the pipeline could retry with V4-Pro, subject to a limit of three attempts per module.

This approach narrows one familiar failure mode in generated code: invented identifiers. In a controlled ablation on Ibex's physical memory protection module, the authors report that an ungrounded prompt produced 15 signal names absent from the target file and included a Markdown fence that stopped compilation. The grounded condition used eight valid signals, compiled and passed the formal gate. That is a single-module ablation, so it does not establish a universal prevention rate, but it shows why extracting the target interface before generation can be useful.

Two verification gates separate syntax from behavior

AutoTrans first compiles each generated bind file with QuestaSim. Compilation catches malformed syntax, undeclared signals and integration errors. Candidates that clear that stage move to JasperGold formal property verification. The pipeline analyzes the Ibex design, establishes clock and reset behavior, attempts to prove each assertion and checks for vacuity. Counterexamples and unreachable antecedents are routed back as structured failure information for another model attempt.

A successful proof has a precise but limited meaning. It establishes that the property holds for the modeled target RTL under the formal setup and that the antecedent is reachable. It does not establish that the assertion completely captures its intended security rule. It also does not prove that Ibex, another RISC-V processor or a fabricated chip contains no vulnerability. Missing properties, incorrect assumptions and behavior outside the verification model remain outside that result.

The paper calls its metric Translation Acceptance Rate. It counts source assertion groups that are both proven and non-vacuous after translation. This is more meaningful for this task than a text-similarity score because two syntactically different assertions can express the same property. Even so, acceptance depends on the supplied source corpus, target design, harness and interpretation of intent. A human still has to evaluate whether the property being proved is the property that matters.

The experiment covers one source and one target

The researchers translated 68 assertion groups from the NS31A corpus across nine security categories to the open-source lowRISC Ibex processor. Forty-six source groups included SystemVerilog examples. The remaining 22 contained natural-language property descriptions, requiring the pipeline to generate target assertions without source SVA code. The paper reports that all 68 groups produced at least one candidate property, but generation coverage was not counted as acceptance.

Twenty groups in two modules passed directly from the lower-cost Flash model. Six modules used Pro retries. After those automated attempts, the authors report an automatic acceptance rate of 78 percent, or 53 of 68 groups. Manual resolution of remaining structural problems then produced a reported final rate of 68 of 68. The changes addressed timing, antecedent reachability, port scope, signal substitution and target-specific logic. The claim that these edits preserved security intent comes from the authors and was not independently assessed.

The manuscript contains a numerical inconsistency worth resolving. Fifty-three accepted groups out of 68 leave 15 groups unresolved, but the accompanying prose says manual work was required for 16 groups across seven modules. The per-module table and the overall percentage do not explain the difference. This does not erase the documented automated passes, but it prevents the manual remainder from being reported as a settled count without clarification.

Reproducible inputs are not identical model outputs

AutoTrans makes signal extraction and prompt assembly deterministic. Given identical source files and configuration, those stages are intended to reproduce the same JSON and byte-identical prompt. The authors also fixed the model temperature and sampling seed. Those controls reduce avoidable variation, but they cannot freeze a remotely operated model whose weights or serving stack may change. A fixed prompt is an auditable input, not a guarantee of identical completion text.

The formal gate provides a practical response to that uncertainty. If changed output no longer compiles or proves, it is rejected rather than silently accepted. Still, a different output can pass the same properties, and the experiment does not measure repeated runs across provider updates. It also uses one hosted model family, one source corpus and one target commit retrieved in May 2026. No independent replication or cross-processor study establishes the reported rate elsewhere.

The cost claim also needs boundaries. The authors say the nine-module experiment fit within 1,000 free NVIDIA NIM developer credits and required no local GPU or fine-tuning. The full workflow nevertheless depends on hosted inference and the proprietary QuestaSim and JasperGold tools used in the experiment. Free promotional inference does not include commercial verification licenses, integration effort or expert time for failed translations.

AutoTrans points toward a productive role for language models in hardware engineering. They can propose mappings across designs whose internal structures differ, while deterministic tooling restricts the vocabulary and formal methods test the result. The progress is not autonomous security certification. It is a staged workflow that converts uncertain generation into reviewable candidates and refuses to count them until stronger tools accept them. Broader processors, repeated provider conditions and independent intent review are the next tests of whether that pattern generalizes.