tpt-fab

Rust

Rust toolkit for fab equipment integration (SECS/GEM) and process simulation, with pluggable lithography backends and privacy-preserving outcome aggregation.

0 stars0 forks0 watchersApache License 2.0

Languages

Rust100.0%
README

tpt-fab

Wafer-fabrication SECS/GEM control & process-simulation stack, plus the bidirectional Manufacturing Outcome file exchange shared with the RFC-001 PCB track.

Status: proposed/under construction — source of truth is spec.txt (RFC-002), build progress in TODO.md.

What this is

tpt-fab covers two things neither tpt-silicon (RTL→GDSII) nor RFC-001 (PCB/system co-design) addresses:

  1. The wafer-fabrication layer — the SECS/GEM-speaking (SEMI E4/E5/E30/E37/E39/E40/E90/E116, the GEM300 suite), lithography-technology-agnostic equipment-control and process-simulation software that sits between a finished layout and an actual wafer.
  2. A bidirectional manufacturing feedback loop — a formal, privacy-respecting, file-based return channel that lets any fab (wafer or PCB) send real outcome data back, so the tools' simulators and yield models can be calibrated against ground truth — without tpt-solutions ever owning fab hardware, and without any network egress in this codebase at all.

Positioning

This is not aimed at ASML, Applied Materials, or the other tier-one toolmakers, whose control software is safety-certified and IP-locked around hardware we will never get API access to. It is aimed at the tier below — NIL vendors and domestic litho programs still building their software stack from scratch, and the long tail of mature-node, analog, power, and specialty fabs who currently have nothing between "nothing" and enterprise EDA/MES licensing. The goal is to be good enough to matter to them, not to match a $10M TCAD license.

Crates

Each crate has its own README (usage, module map, design notes), CHANGELOG, and runnable examples under examples/.

CrateRole
tpt-fabCore: HSMS/SECS-II/GEM300 message stack, recipe versioning + drift detection, lot tracking, equipment-simulator harness, opt-in vendor adapter seam
tpt-fab-lithoPluggable PatterningBackend trait: DUV multi-patterning, EUV, nanoimprint (J-FIL-style), e-beam
tpt-fab-processExplicitly best-effort OPC suggestions + coarse etch/deposition/thermal simulation; sky130 MPW shuttle-run ingestion path
tpt-fab-aggregateThe Manufacturing Outcome file exchange: schema, consent, client-side aggregation, minimum-cohort + differential-privacy protection. Zero dependencies, zero network code — auditable by construction.
tpt-fab-intakeReceiver-side semi-automated intake queue: signature verify, schema check, consent enforce, anomaly screen → accepted/flagged/rejected, with a persistent decision ledger. Local files only

Quick tours without real hardware:

cargo run -p tpt-fab --example full_session          # a complete SECS/GEM recipe cycle
cargo run -p tpt-fab-litho --example plan_layer      # one layer planned by all four backends
cargo run -p tpt-fab-aggregate --example pcb_track   # the PCB track against the shared schema
cargo run -p tpt-fab-process --example sky130_ingest # shuttle results through the cohort gate
cargo run -p tpt-fab-intake --example intake_api    # the receiver-side intake queue

The outcome file exchange is a file exchange, not a service

Nothing here opens a network connection to send outcome data anywhere, on any schedule, under any configuration. OutcomeFileWriter writes to a local path and returns. What happens next — email, portal upload, USB drive, or nothing — is entirely the fab's decision, made after the file exists and its contents are already known to them. Every file that reaches tpt-solutions reached it because a human at the fab decided to send it. There is no "offline mode" to enable, because there is no online mode to begin with.

License

Dual-licensed, matching tpt-telos / tpt-protocol: MIT OR Apache-2.0.