printf("Hello, World\n");proves a Turing machine can write to stdout
Keystone.Hello()proves the CM can reach a named person, across any distance, through a capability stack
Why this matters
printf writes bytes to a file descriptor — it has no knowledge of who is on the other end.
Keystone.Hello() travels through a capability stack: every hop is authenticated by a Golden Token, so the CM can prove it reached a specific named person and not merely an open socket.
That guarantee — identity plus authority, enforced in hardware — is what separates capability-based computing from conventional I/O.
STEP 1 — ACTIVE
Scan QR & Connect
Scan Mum's QR code (or paste her identity string) to call Keystone.Connect() and fill c-list slot 1 with her E-GT.
STEP 2 — PENDING
Say Hello
Call Keystone.Hello() through the live Tunnel once Mum is connected in Step 1.
Mum's QR Code (served from this IDE — scan or paste)
QR not available — server may be starting up. Reload
Scan or Paste Identity String
Point camera at Mum's QR code…
Keystone NS[32] — C-list Slot 1 (Mum E-GT)
NULL GT — Connect() not yet called
Step 2: Say Hello (connect in Step 1 first)
Connect to Mum in Step 1 to enable the live Tunnel bridge.
Mum's canonical identity string (copy for paste above):
Loading…
⚠ Developer Tool
Rotates Mum's Ed25519 key pair and refreshes this page.
Memory — Word-Addressed Dump
Abstraction Catalog
Select an abstraction
Click any abstraction on the left to see its methods, permissions, and how it fits into the CR6/CR14 canonical form.
Click Source on any card to expand, Load → Editor to open in the editor.
Select Source Library to browse all example scaffolds.
LUMP Repository
Select a lump
Select a lump to see its public interface.
Select a lump to see its source.
Pick a lump above to see its methods, pet names, MTBF, deployment info, and capabilities.
Execution Trace0 rows
#
PC
Op
Cond
Dst
Src
Description
DR0
DR1
DR2
DR3
DR4
DR5
DR6
DR7
DR8
DR9
DR10
DR11
DR12
DR13
DR14
DR15
N
Z
C
V
STO
Get Started with the Church Machine
Three steps to run your first capability-secured program on real hardware.
1
Flash Your Ti60
Download the pre-built bitstream and program it onto your Ti60 F225 FPGA board. The board will boot the Church Machine kernel automatically.
Waiting
2
Connect & Verify
Plug in your Ti60 over USB and verify it calls home. The board will appear in your Devices list once registered.
Waiting
3
Write & Run a Program
Open Programs, write a CLOOMC assembly program, assemble it and run it in the simulator. Every instruction is capability-checked by the hardware.
🧙Startup WizardDEMONew here? We'll get your board running step by step ↓× Exit tour▾
Step 1 of 6
○Get
›
○Flash
›
○Power
›
○Connect
›
○Upload
›
○Running
How would you like to get started?
📦 Download the Project ~1 min
Download the full Church Machine project for your board. The ZIP already contains a pre-built bitstream (outflow/church_soc_cm.hex) — ready to flash, no synthesis needed. The Efinity project is also inside if you ever want to rebuild from source.
Everything in one download: the pre-built bitstream (outflow/church_soc_cm.hex), a Makefile with make flash, plus the full Efinity project for rebuilding.
The ready-to-flash programming file is already inside the ZIP at outflow/church_soc_cm.hex — go straight to the next step. (Rebuilding from source is optional and takes ~30 min.)
⚠ Common problems — Get Bitstream
Download link not loading — hard-refresh the page (Ctrl+Shift+R / Cmd+Shift+R).
No network access — copy the direct GitHub URL shown in the release badge and open it in a new tab.
Wrong board selected — verify you chose the Ti60 F225 / F225C variant.
⚡ Step 2 — Flash the Pre-built Bitstream ~3 min
The pre-built bitstream is already inside the ZIP at outflow/church_soc_cm.hex — no separate download. Just unzip and load it in Efinity Programmer.
The pre-built bitstream is already inside the ZIP at outflow/church_soc_cm.hex — no separate download. Just unzip and run make flash.
checking…
Unzip the project you downloaded in Step 1 into a working folder
Launch Efinity Programmer:
Open Efinity IDE, then go to Tool → Programmer (or run standalone: C:\Efinity\2025.2\bin\programmer.exe)
Cable dropdown: select Efinix USB2.0 Device
Mode: JTAG · Operation: Active Serial Programming (Active Serial writes to SPI flash — the board keeps it after power-off)
Click Open Bit File → select the bundled outflow/church_soc_cm.hex from the unzipped folder
Click Start and wait for "Programming Done" (~30 s)
Unzip the project and open a terminal in that folder
Confirm the JTAG cable is visible: ls /dev/ttyUSB* — expect /dev/ttyUSB0
Flash the bundled bitstream: make flash Runs openFPGALoader on the included outflow/church_soc_cm.hex — nothing else to download.
Wait for "Programming done" — about 30 seconds
LEDs right now:012Board is being programmed
⚡ Step 2 — Build & Program the Board ~35 min
Build the bitstream from the downloaded ZIP using Efinity IDE, then flash it to your board. The board stores it permanently — it keeps it even after you unplug it.
Unzip the downloaded project into a working folder.
Open the Efinity Terminal (Start menu → Efinity 2025.2 → Efinity Terminal) — this shell pre-sets Efinity's Python path. Then cd into the folder and run setup_ti60_peri.py. The script is inside the ZIP; do not type it as a bare system command:
cd C:\path\to\church_ti60_f225_project
python setup_ti60_peri.py
You should see "SUCCESS — church_ti60_f225.peri.xml written"
Enable SoC / UART — open church_ti60_f225.sdc in any text editor and switch from Phase A to Phase B by following the comments inside the file: Phase A = 25 MHz (safe default). Phase B = 50 MHz with SoC/UART enabled. The comments tell you exactly which lines to swap.
Launch Efinity IDE from the Start menu (Windows) or Applications (Mac)
File → Open Project → select church_soc_cm.xml
Run Synthesis → Place & Route → Generate Bitstream Takes ~30 min. When done, outflow/church_soc_cm.hex is the programming file.
Unzip the downloaded project into a working folder.
If you have an OSS CAD Suite or any other venv active, deactivate it first — then cd into the extracted folder and run setup_ti60_peri.py using Efinity's own Python. The script is inside the ZIP; it is not a system command, do not type it bare:
deactivate # skip if no venv is active
cd ~/path/to/church_ti60_f225_project
PYTHONPATH=$HOME/efinity/2025.2/lib:$HOME/efinity/2025.2/pt/bin \
EFXPT_HOME=$HOME/efinity/2025.2/pt \
$HOME/efinity/2025.2/bin/python3.11 setup_ti60_peri.py
You should see "SUCCESS — church_ti60_f225.peri.xml written"
Enable SoC / UART — open church_ti60_f225.sdc and switch Phase A → Phase B per the comments (Phase B = 50 MHz with SoC/UART):
nano church_ti60_f225.sdc
Comment out the Phase A line and uncomment Phase B exactly as the comments direct.
Run Synthesis → Place & Route → Generate Bitstream Takes ~30 min. When done, outflow/church_soc_cm.hex is the programming file.
Part B — Flash the board (~5 min)
LEDs right now:012Board is being programmed
In Efinity IDE: go to Tool → Programmer
Cable dropdown: select Efinix USB2.0 Device
Mode: JTAG · Operation: Active Serial Programming (Active Serial writes to SPI flash — the board keeps it after power-off)
Click Open Bit File → navigate to outflow/church_soc_cm.hex
Click Start and wait for "Programming Done" (~30 s)
Get OSS CAD Suite if you don't have it — download the latest Linux x64 .tgz from github.com/YosysHQ/oss-cad-suite-build/releases and extract it to your home folder so that ~/oss-cad-suite/environment exists.
Activate OSS CAD Suite in your terminal: source ~/oss-cad-suite/environment
Confirm the JTAG cable is visible: ls /dev/ttyUSB* — expect /dev/ttyUSB0
Flash the built bitstream to the board: make flash (equivalent to openFPGALoader -b titanium_ti60_f225 outflow/church_soc_cm.hex)
Wait for "Programming done" — about 30 seconds
⚠ Common problems — Flash
Efinity Programmer can't find the board — check the JTAG cable is fully seated, try a different USB port, confirm 12 V power is connected.
"Unknown device" error — install or reinstall the Efinix FT4232H JTAG driver from the Efinity installer.
Bit file rejected / wrong device — re-download the bit file and verify its SHA against the release notes; do not use a bit file built for a different board variant.
openFPGALoader: "No device detected" (Linux/Chromebook) — check the USB cable is a data cable, try openFPGALoader --detect, and confirm the cable is fully seated.
"Permission denied" on /dev/ttyUSB* (Linux/Chromebook) — run sudo usermod -aG dialout $USER then log out and back in (or sudo chmod 666 /dev/ttyUSB* for a quick fix).
openFPGALoader not found — run source ~/oss-cad-suite/environment first to activate the toolchain.
✅Board flashed! The Church Machine firmware is now on your board.
🔌 Step 3 — Restart the Board ~1 min
Unplug the USB cable, wait 2 seconds, then plug it back in. The LEDs show exactly what the board is doing — watch them light up in sequence.
Immediately012LED0 solid ON — board is powering up
After ~0.1 s012LED1 slow blink — Church Machine is healthy and waiting for the IDE to load its programs
After ~0.5 s012LED2 turns ON — board has said hello to the IDE (stays ON permanently)
⚠ If fault012LED1 goes OFF, LED2 stays ON — fault latched. Power-cycle to clear
⚠ Common problems — Power Cycle
LED0 is not solid amber after power-up — the board may not have been flashed successfully; go back and re-flash.
LED blink pattern is wrong — compare against the LED table in StartupCM.md; a different pattern usually means the wrong bit file was flashed.
Fault LED (LED2) lights immediately — check the UART cable is connected, then re-flash; if the fault persists, inspect the CALLHOME log for a fault_code.
No LEDs at all — power issue; confirm USB cable supports data+power, and check the USB port power rating (board needs ≥ 500 mA).
✅LED0 ON + LED1 blinking — board is healthy and waiting for the IDE.
🔗 Step 4 — Connect to the IDE < 1 min
Click the button below to open the serial connection menu, then pick your board from the list. The IDE will detect it and move on automatically.
LEDs now:012Waiting for IDE to connect
This step advances automatically when the board is detected.
⚠ Common problems — Connect
No board listed in the browser picker — this feature needs Chrome or Edge 89+; try a different USB cable; make sure the board driver is installed (FT4232H).
Connected but nothing happens — board may not be powered or the cable supports charging only; power-cycle the board and try again.
Port closes immediately — power-cycle the board and retry; another program (screen, minicom, Arduino IDE) may have the port open already.
ChromeOS / Crostini users — go to Settings → Linux → USB devices and turn off Linux sharing for the FT4232H; Chrome needs exclusive access.
✅Connected! Board detected — moving to upload.
📡 Step 5 — Sending Programs to Board ~10 s
The IDE is sending the boot programs (called LUMPs) to your board over the serial cable. Each small packet is confirmed before the next one is sent — usually done in about 10 seconds.
LEDs now:012LEDs stay the same during upload — normal
This step advances automatically once the upload finishes and the Church Machine starts.
⚠ Common problems — Upload
Upload starts then stalls mid-way — check USB cable quality (some charging cables drop data); power-cycle the board and click Try again.
Checksum errors in the log — close any other program using the same serial port, then reconnect and retry.
Upload finishes but Church Machine does not start — the firmware on the board may be out of date; try re-programming the board, then reconnect.
✅Upload complete! Programs loaded — Church Machine is starting.
🎉 Church Machine Running! 🎉 Done!
Your Church Machine is live! Three startup instructions ran automatically, and your board is now executing capability-secured code on real hardware.
CALL completes012boot_complete=1 — demo sequencer: LED0→1→2→3→off, 0.5 s each, repeating
Abstraction runs012LEDs driven by your abstraction via MMIO — Boot.Abstr cycles through patterns
✅ Your Church Machine is running capability-secured code on real hardware.
Watch the Live UART panel below to see every instruction as it executes.
🚀 What would you like to do next?
Write your first program — open the Code view and try one of the built-in example programs.
Learn step by step — open the Tutorials for guided lessons starting from the basics.
Explore example programs — use the Examples drop-down in the Code view to load ready-made programs and run them on your board.
Read the reference guide — open the Reference view to browse the full instruction set and capability model.
🔧 Something wrong?
Demo sequencer not cycling LEDs — all LEDs off is normal if your abstraction has taken over; check the NIA stream to confirm instructions are executing.
CALL faults immediately on boot — verify the namespace upload completed without errors; if in doubt, disconnect, re-flash the board, then reconnect and re-upload.
Need to reset — power-cycle the board; the IDE will re-upload the boot image automatically on the next CALLHOME.
MMIO LED debug — send a DWRITE 0x40000000 1 instruction to force LED0 on; use 0x40000004, 0x40000008, 0x4000000C for LED1–3.
Auto-advances in 3 s — or click to skip ahead
🎓 Tour Complete!
You've walked through all 6 setup steps. Here's a quick summary of what the real flow involves:
Download the Project — Grab the one ZIP, which already contains a pre-built bitstream (outflow/church_soc_cm.hex) plus a Makefile — no synthesis needed.
Flash — Unzip, then run make flash (or load the bundled hex in Efinity Programmer over JTAG) onto the Ti60 F225 board.
Power Cycle — Unplug and replug the board; the LED pattern confirms the Church Machine core is healthy and waiting.
Connect — Click "Connect" in the IDE; the board's CALLHOME greeting is automatically detected and the wizard advances.
Upload — The IDE sends the boot image over UART (~1 second); each frame is CRC-checked and ACK'd by the FPGA.
Running — Your capability-secured abstraction is live on real FPGA hardware, LEDs cycling as the demo sequencer runs.
Board reported boot OK — your first capability-secured program ran
—
🔗
Register
Board saved to your IDE — you'll see it in the Devices tab
—
✅
Release
Board is verified and production-ready
—
Advanced / Troubleshooting
📌 Port selection
The FT4232H exposes 4 ports — you want the 3rd one (SoC UART, interface 2):
Linux:/dev/ttyUSB2 — confirm with ls /dev/ttyUSB* (should show 0–3)
Windows: look for USB Serial Port (COM N) — the 3rd entry in Device Manager under FT4232H
Mac:/dev/cu.usbserial-<id>2
If nothing appears in the browser picker:
ChromeOS / Crostini: go to Settings → Linux → USB devices and turn off sharing for the FT4232H — Chrome needs exclusive access; once Linux claims the device, Chrome WebSerial can't see it.
Linux desktop: run sudo chmod a+rw /dev/ttyUSB2 then refresh.
Try a different USB cable or port, then power-cycle the board and refresh.
🌉 Via Bridge (Chromebook Crostini / headless)
If WebSerial still can't reach the board, run the bridge in your Linux terminal and connect via it instead:
Bridge command
cd ~/church_project/SoC/church-machine
python3 server/local_bridge.py /dev/ttyUSB2 57600 8766 --ide=https://lab.cloomc.org --insecure
The --ide= flag tells the bridge where to forward UART packets. The --insecure flag is needed on ChromeOS because the Linux container can't verify external certificates. First time only: open https://penguin.linux.test:8766/status in Chrome → Advanced → Proceed.
✅
Board is live — you can now write and run programs from the Code tab.
No build yet — click Build to synthesise RTL
Build Log
Ready.
Package Contents
No build yet.
Next Steps►
Build first to see instructions.
In 1843, Ada Lovelace wrote the first computer program — Note G, an algorithm for computing Bernoulli numbers. It was not just code. It was the first first-class program: it passed functions as arguments to other functions, not just values.
This is the vital distinction. Basic machine code (Turing) moves numbers between registers — ADD R0, R1, R2 adds two values, nothing more. CLOOMC is different. In CLOOMC, a variable can hold a function, pass it to another function, and return a function as a result. let double = \x -> x * 2 creates a function. let apply = \f x -> f(x) passes that function as an argument. Ada did this in 1843 — Alonzo Church formalised it in 1936 as the lambda calculus.
Type let x = 2 + 3 and you are writing what Ada wrote. To see her original algorithm as Church Machine code, click Create and select the Bernoulli example.
λ>
Challenge
Click "New Problem" to get a math challenge!
Tools
History
Abstractions & Methods
Hardware Instruction Set — 20 Instructions
M-bit rules — per-register inspection model
The M-bit is a 1-bit flag on every CR register, separate from its GT permissions.
It is set and cleared by hardware to control the M-window (inspection channel).