A tuned chip-design model + an evaluation-native IDE. You type a natural-language hardware request; the system turns it into a structured spec, extracts the compute kernels, proposes hardware candidates, estimates how the workload runs on each, generates real RTL for the winner, verifies that RTL with Verilator, and writes an evidence-backed report. Measured tool results and estimated performance numbers are kept visually and verbally separate everywhere.

The project is two layers:

• Layer 1 — the core: a tuned model + a benchmark that proves it. Qwen2.5-Coder-7B-Instruct fine-tuned (QLoRA) for Verilog generation and tool-error repair, measured on a held-out benchmark as base vs. tuned vs. tuned+repair. This is the scientific claim of the project.
• Layer 2 — the demo: the evaluation-native IDE. A Streamlit app that drives the staged pipeline below and shows the tuned model working inside a verification-driven loop. The model proposes. The tools evaluate. The IDE explains.

Grounded in the literature: ChipNeMo (arXiv:2311.00176) shows generic LLMs are weak at chip design and that domain adaptation + grounded evaluation is what moves the needle; NL2GDS (arXiv:2603.05489) shows NL-to-chip should be a staged flow with tool feedback and iterative repair. Layer 1 is the first lesson, Layer 2 is the second.

The IDE runs end-to-end with no GPU and no network: every backend module ships a stub that returns cached demo data from generated/fixtures/, so the whole pipeline renders before the real model or EDA tools exist.

python -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate
pip install -r requirements.txt
streamlit run app.py

Then paste the canonical demo prompt:

"Design a low-power INT8 accelerator for transformer decoder inference. Batch size is 1, sequence length is 2048, hidden size is 1024, number of heads is 16. Optimize for tokens per second under 5W. Generate an RTL skeleton for the selected accelerator tile and provide an evaluation report."

You should see: a validated spec, a kernel table, three hardware candidates (A_low_power / B_balanced / C_high_performance), an evaluation with a [ESTIMATE] label on every performance number, generated RTL, a [MEASURED] Verilator lint result, and a downloadable report.

The two backends that touch the model and the EDA tools degrade gracefully: llm_client.generate(...) calls an OpenAI-compatible vLLM server at FAIRCHILD_LLM_URL (default http://localhost:8000/v1) and falls back to a canned RTL stub on any failure; verifier.run_lint(...) shells out to verilator --lint-only if it is installed, otherwise returns a stubbed PASS. So a missing GPU or missing Verilator never breaks the demo.

chips/
├── README.md  app.py  requirements.txt
├── configs/        train_lora.yaml  eval.yaml  model.yaml
├── data/           raw/  processed/  train.jsonl  val.jsonl  repair_train.jsonl
│                   benchmark_tasks.jsonl
├── models/adapters/        # tuned LoRA adapter (Layer 1 artifact)
├── backend/        schemas.py            # pydantic v2 data contract
│                   spec_compiler.py      # NL prompt  -> Spec
│                   workload_extractor.py # Spec       -> [Kernel]
│                   candidate_generator.py# Spec       -> [Candidate]
│                   performance_estimator.py # kernels x candidate -> EvalRow  [ESTIMATE]
│                   ranker.py             # rank candidates under constraints
│                   rtl_generator.py      # Candidate  -> .sv files (Jinja2 templates)
│                   verifier.py           # verilator --lint-only -> VerifyResult [MEASURED]
│                   repair_agent.py       # (RTL, tool error) -> explanation/fix
│                   report_generator.py   # everything -> Markdown report
│                   llm_client.py         # vLLM client w/ stub fallback
│                   serve_stub.py         # canned synthesizable RTL, offline
├── tuning/         train_lora.py  merge_or_load_adapter.py   # train + serve lane
│   └── data_gen/   SFT data generation: prepare_sft_data.py  inject_bugs.py
│                   run_verilator_for_repairs.py  build_repair_dataset.py
│                   diff_testbench.py  build_semantic_repair.py
│                   export_mg_verilog_seeds.py  decontaminate.py
├── benchmarks/     run_base_eval.py  run_tuned_eval.py  run_repair_eval.py
│                   evaluate_outputs.py  make_benchmark_table.py
├── templates/      mac_cell.sv.j2  systolic_array_tile.sv.j2  systolic_array_tb.sv.j2
├── generated/      fixtures/  rtl/  reports/  logs/  benchmark_results/
└── docs/           execution_plan.md  architecture.md  demo_script.md

The end-to-end data flow and the measured-vs-estimated boundary are documented in docs/architecture.md. The 3-minute demo walkthrough is in docs/demo_script.md. The full team build plan, module specs, and timeline are in docs/execution_plan.md.

The work is four parallel swimlanes; the interfaces are the pydantic schemas in backend/schemas.py, agreed up front so everyone builds against stubs from minute one.

Fine-tuning and serving Qwen2.5-Coder-7B happen on a separate A100 lane (see docs/execution_plan.md §9). That lane produces the Layer-1 benchmark table and the LoRA adapter. None of it is required to run the IDE locally: the UI runs entirely on CPU off the cached fixtures and the stub clients, and only upgrades to live generation when an FAIRCHILD_LLM_URL server is reachable. CPU EDA tools (Verilator, Icarus, Yosys) are likewise optional — without them the verifier returns a clearly labeled stub PASS. You can clone this repo on a laptop and demo the whole pipeline.

• Every performance number (tokens/s, energy/token, utilization, power) is an analytical [ESTIMATE] — kernel-level arithmetic, not silicon measurement.
• The Verilator lint result is the one [MEASURED] signal and is the credibility anchor of the demo.
• The benchmark evidence comes strictly from the tuned 7B model, not a prompt-wrapped base model.

These two categories are kept visually distinct in the UI and the report at all times.