Skip to content

Tagma decoder execution path verification: ev as an independent channel #46

Description

@metasmile

Goal

Verify the Tagma 3-axis decoder execution path with the ev constraint engine as an independent channel, complementing the syntagma hardware track (syntagma issue #48), which verifies the decoder through Verilator simulation, golden anchors from the Rust tagma_core reference, gate-level simulation, and formal equivalence. ev would add a fifth, structurally different channel: the decoder contract expressed as a VerificationSpec, exhaustively enumerated and evaluated by ev's own engine.

Background

The Tagma decoder (syntagma/hw/rtl/tagma_decoder.v) maps a 16-bit Hangul code point to three structural axes:

code in [0xAC00, 0xD7A3]  (11,172 valid syllables)
offset = code - 0xAC00
i = offset / 588           (initial, 0..18)
m = (offset % 588) / 28    (medial, 0..20)
f = offset % 28            (final, 0..27)

Whitepaper: https://doi.org/10.5281/zenodo.21302508. The hardware verification artifacts live in syntagma/hw/ (branch 48-hw-verification, PR #50).

Scope

  1. Model the decoder contract as a VerificationSpec:
    • field code over all 2^16 values
    • constraint: valid range [0xAC00, 0xD7A3]
    • axis decomposition (i, m, f) as projections of the offset
  2. Add the projector capability the contract needs. ev currently ships sum, identity, parity; the decoder requires integer division and modulo by constants (588, 28, 21, 7) or a dedicated decode projector. This is the main engine extension.
  3. Exhaustively verify the execution path: all 11,172 valid code points produce the expected axes, and invalid inputs are rejected by the range constraint.
  4. Cross-check the ev results against the syntagma golden anchors (syntagma/hw/rtl/golden_anchors.hex, generated by tagma_core), following the golden-anchor pattern of issues Cross-verification harness: ev as reference for SSCCS standard experiment golden anchors #25 and SSCCS standard workspace golden anchor CI integration #28.
  5. Optional follow-up: raw RTL design input for ev synth (ev synth --design tagma_decoder.v --top tagma_decoder), so the decoder's generic synthesis report comes from ev's YosysBackend instead of the mirrored script in syntagma/hw/synth/yosys/synth_generic.ys. The RunSynthesis trait already accepts arbitrary RTL; only the CLI path (currently VerificationSpec::from_yaml required) needs a design-only mode.

Acceptance criteria

  • ev verify on the Tagma spec passes all 11,172 valid code points and rejects the invalid domain.
  • The axis projections match the golden anchors for every valid code point.
  • (Optional) ev synth --design produces the same SynthesisMetrics as the syntagma generic flow (478 cells, 0 registers, ev-compatible stat -json schema).

References

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions