1 viewer

Circuit — Transparent Silicon

Hand the machine a program and it shows you the silicon: any CRE8VM language synthesizes in-process to Verilog and a render-ready circuit.scene.v1 netlist (per-cell class/rank, per-net driver→sinks, layered 3D layout). Every artifact is a content-addressed atom; every design is a durable vertex tied to the compile run's ir_hash.

Designs
0
Schema
circuit.scene.v1

Synthesize a circuit

The PIS soft core — a general machine

Every other design on this page is a compiled-once function: the program became the FSM, so a different program means different silicon. This one is a CPU. CRE8VM emits a synthesizable multi-cycle core for PIS, its provable register ISA — instruction ROM, data RAM, constant pool, frame-windowed register file, call stack. Bake a different program into IMEM and the same chip runs it. Synthesize it below and it becomes an ordinary design: same gate schematic, same Circuit.EmitScene into the world, same ASIC handoff.

It decodes 18 of the ISA's 24 opcodes. Recursion works — Call/Ret run on the frame-windowed file. Outside the set: Div, HostCall, FieldInv, MerkleVerify, FriLayerFold, FriCommitCheck. A program using one of those still synthesizes; the core comes back with zero-filled ROMs and the reason on the record, rather than an error.

HaltConstCopyAddSubMulDivEqLtAndOrXorNotJumpBranchCallRetLoadStoreHostCallFieldInvMerkleVerifyFriLayerFoldFriCommitCheck

Geometry and timing, quoted verbatim from the header the emitter writes into the file:

  • Generated by CRE8VM — PIS v1 soft core (multi-cycle microsequencer)
  • Semantics: src/proof/pis.rs Encoding: src/proof/pis_encode.rs
  • No program image baked in — ROMs are zero-filled.
  • 6 clock cycles per retired instruction; CALL is 6 + FRAME_WINDOW (= 22), MUL is 6 + WIDTH (= 70).
  • Frames: 16 × 16 registers = 16384 bits of register file; call depth 16 (deepest nesting 15).
  • Declared subset: a register index >= 16 or a CALL at depth 15 raises `trap`.
  • Boot clear: 1024 clocks after reset zero `regs` and `dmem` (block RAM has no reset port); `start` is captured while it runs.

What the schematic below will and won't show. The native netlist exporter lowers assigns and simple always blocks, and it is module-agnostic — it flattens the whole emitted file (pis_goldilocks_addsub, pis_goldilocks_mulstep, pis_alu, pis_cpu) into one netlist. Two consequences, both measured rather than assumed: the core's multi-cycle microsequencer case is not cell-visible, so the cell count is a fraction of the machine (most of its signals land in the scene's disconnected_signals stat); and the scene's port list is the first module header the flattener saw, not pis_cpu's interface. What is faithful is the net layer — the named nets are the core's own signals (frame_ptr, rstack_pc, imem, dec_op, regs…). Read the schematic as the datapath spine, not as a gate-level CPU.

Baking a program does not change the netlist hash — the image lives in initial blocks. That is the claim on this page made checkable: one machine, many programs. And Circuit.Simulate recompiles a design's source, which on a core design is the baked program, so it runs that program's own FSM rather than this CPU.

Synthesize the PIS soft core

No circuit designs yet — synthesize one above (the default: a javascript function becomes an FSM you can inspect gate by gate).