Alpona-1.0-27B

Alpona 1.0 · 27B

Specification in, synthesizable SystemVerilog out.

Alpona 1.0 · 27B is an RTL generation model with a built-in five-stage generate, check and repair pipeline. It drafts a module, derives a behavioural model of the specification, writes its own testbench, and repairs the design using real compiler and simulator feedback from Icarus Verilog.

Install

pip install -U "transformers>=5.14.1" torch accelerate
conda install -c conda-forge iverilog  # required by stages 3-5; any platform, no root
# alternatives: sudo apt-get install iverilog   |   brew install icarus-verilog

• Icarus Verilog must be on PATH, or passed as iverilog="/path/to/iverilog". Without it, stages 3–5 are skipped, the result reports outcome = "no_toolchain", and the module is returned without being checked. Icarus Verilog is GPL-2.0 and is not bundled with this repository.
• The BF16 weights need about 56 GB of GPU memory plus room for the KV cache, for example one 80 GB GPU or two 40 GB GPUs.

Run

from transformers import pipeline

rtl = pipeline("alpona-rtl", model="musatur/Alpona-1.0-27B",
               trust_remote_code=True, device_map="auto")

print(rtl("Design a 4-bit synchronous up-counter with active-high synchronous reset."))

module TopModule (
  input clk, input reset,
  output reg [3:0] q
);
  always @(posedge clk) begin
    if (reset) q <= 4'd0;
    else       q <= q + 4'd1;
  end
endmodule

Serve with vLLM

python serve_vllm.py --model musatur/Alpona-1.0-27B --tp 2 --port 8000

curl -s localhost:8000/rtl -d '{"spec": "Design an 8-bit register with synchronous reset."}'

serve_vllm.py imports alpona_stages.py, so run it from a local copy of this repository:

hf download musatur/Alpona-1.0-27B --local-dir Alpona-1.0-27B
cd Alpona-1.0-27B
python serve_vllm.py --model . --tp 2 --port 8000

The server listens on all network interfaces and has no authentication, so run it only on a trusted network.

Options

spec = "Design an 8-bit register with synchronous reset."
out = rtl(spec, rounds=3, tb_tries=2, return_details=True)

out["rtl"]                 # final module
out["draft_rtl"]           # first pass, before verification
out["behavioural_model"]   # derived truth / state / timing table
out["testbench"]           # the self-checking testbench it wrote
out["outcome"]             # tb_satisfied | rounds_exhausted | repair_produced_nothing
                           #   | no_usable_testbench | no_toolchain
out["stage_log"]           # one line per stage

Built on Qwen3.8-27B. Apache-2.0.

What this repository contains

• Weights: 18 BF16 safetensors shards (27.78B parameters), with the tokenizer, chat template and processor files.
• config.json: the model configuration with the alpona-rtl pipeline registration and the Alpona defaults (alpona_version: "1.0", alpona_rounds: 3, alpona_tb_tries: 2).
• Pipeline code: pipeline_alpona.py (the Hugging Face pipeline), alpona_stages.py (the five stages and their prompts), serve_vllm.py (a small HTTP server using vLLM) and requirements.txt.

Together they make pipeline("alpona-rtl", ...) a single call that drafts, checks and repairs a module.

How it works

1. Draft. One ordinary generation from the specification, kept as the control.
2. Derive. The model writes an explicit behavioural model of the specification (truth table or equations, state table, cycle-by-cycle timing, edge cases) before any test exists.
3. Pre-compile. Icarus Verilog elaborates the draft, and the model fixes any compile errors (up to rounds attempts).
4. Testbench. The model writes a self-checking testbench from the derived behavioural model rather than from the prose (up to tb_tries attempts).
5. Repair. The module is compiled and simulated against that testbench and repaired using the real compiler and simulator output (up to rounds attempts). If the testbench never passes, the pipeline returns the last module that compiled, not an untested edit.

The pipeline never sees a reference implementation or a benchmark testbench.

Intended use

• Generating synthesizable Verilog/SystemVerilog modules from written specifications, as an assistant to RTL designers, researchers and students.
• Research on LLM-based RTL generation and verification.

Every generated module should be reviewed and verified by an engineer (simulation against an independent testbench, linting, synthesis) before it is used in real hardware.

Out-of-scope use

• Use without human review in safety-critical hardware, for example medical, automotive or aerospace systems.
• Treating the pipeline's own testbench as sign-off verification. The same model writes the module and the test, so both can share one misreading of the specification.
• General chat, image or video tasks. Alpona was evaluated only on RTL generation.

Limitations

• The checking and repair stages depend on Icarus Verilog being installed. Without it, the module is returned unchecked.
• The self-generated testbench can be wrong. When it rejects every candidate, the pipeline returns the last module that compiled, which may still be functionally wrong.
• Evaluated on VerilogEval v2 and RTLLM v2, which mostly contain single-module designs. Performance on larger multi-module and bus/protocol designs has not been established.
• One request runs several generations (draft, derive, testbench, repairs), so it is slower and uses more compute than a single generation.
• Generated code may still contain functional bugs, non-synthesizable constructs or timing problems that the testbench does not catch.

License

Apache-2.0 (see LICENSE), following Qwen3.8-27B, on which this model is built. The Alpona pipeline code in this repository is also released under Apache-2.0. Icarus Verilog, which the pipeline calls at run time, is GPL-2.0 and is not included.

Acknowledgement

Developed under the project "LLM-Guided RTL Design and Verification" (EOI 122), funded by a BIRDI grant under SICIP.