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.
Every compiled and server-stored LUMP, identified by token. Click Open to inspect.
Loading registry…
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.
Three steps to run your first capability-secured program on real hardware.
1
Flash Your Wukong
Download the pre-built bitstream and program it onto your QMTECH Wukong Artix-7 FPGA board. The board will boot the Church Machine kernel automatically.
Waiting
2
Connect & Verify
Plug in your Wukong 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.
Programming and live trace use separate interfaces. Use the JTAG connection to load the FPGA, then use the USB-UART connection for the bridge and trace.
Do not use JTAG as the trace port
1
JTAG — programming
Testing uses .bit; release uses .mcs
For testing, download the .bit and load it over JTAG. For the official reset-resident release, download the .mcs and program the board’s SPI flash with the free AMD Vivado Hardware Manager. This connection programs the board; it does not carry the Church Machine trace stream.
Windows / Mac: the JTAG cable appears inside Vivado Hardware Manager.
Linux / Chromebook: openFPGALoader detects the JTAG cable; it is not the COM port selected by the trace bridge. AMD’s free Vivado ML Standard Edition includes Hardware Manager.
2
USB-UART — trace & commands
Bridge connection for trace, run/step, and upload
Run hardware/wukong_bridge.py against this serial port. It carries the live trace packets and the commands sent by the IDE at 57600 8N1.
Windows: often COM3, but the number is assigned by Windows — select the actual USB-UART port shown in Device Manager.
Linux: usually /dev/ttyUSB* or /dev/ttyACM*. ChromeOS: if the FT4232H picker shows four interfaces, choose the 3rd entry for USB-UART.
🧙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 contains the Verilog netlist, pin constraints, and the Vivado build script. If a pre-built bitstream is available you can download it directly from the card above — no synthesis needed.
Everything in one download: church_wukong_xc7a100t.v, the wukong_xc7a100t.xdc pin constraints, the wukong_xc7a100t.tcl Vivado build script, and the current wukong_bridge.py.
The ready-to-flash church_wukong_xc7a100t.bit is downloaded separately from the card in the Connect tab — the ZIP holds the source, constraints, and Vivado build script. (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 have the QMTECH Wukong XC7A100T (Artix-7) board.
⚡ Step 2 — Flash the Pre-built Bitstream ~3 min
Download the pre-built bitstream (church_wukong_xc7a100t.bit) from the card above, then program it with Vivado Hardware Manager.
Download the pre-built bitstream (church_wukong_xc7a100t.bit) from the card above, then program it with openFPGALoader.
checking…
Download church_wukong_xc7a100t.bit using the card at the top of this tab
Launch Vivado and open Hardware Manager (Flow → Open Hardware Manager)
Click Open target → Auto Connect — the Wukong appears as xc7a100t
Right-click the device → Program Device → select the downloaded .bit file
Click Program and wait for it to finish (~10 s)
Download church_wukong_xc7a100t.bit using the card at the top of this tab
Confirm the JTAG programmer is visible with openFPGALoader --detect (the JTAG interface is separate from the USB-UART trace port)
Flash the downloaded bitstream: openFPGALoader church_wukong_xc7a100t.bit openFPGALoader auto-detects the Artix-7 JTAG cable.
Wait for "Programming done" — a few seconds
LEDs right now:012Board is being programmed
⚡ Step 2 — Build & Program the Board ~35 min
Build the bitstream from the downloaded ZIP using AMD Vivado, then flash it to your board.
Part A — Build the bitstream (~30 min)
Download and install AMD Vivado (free ML Standard edition) from xilinx.com/support/download.html — required before any of the steps below.
Unzip the downloaded project into a working folder.
Open the Vivado Tcl Console (Start menu → Vivado → Vivado Tcl Shell), cd into the folder, and source the build script:
cd C:/path/to/church-wukong-package
source wukong_xc7a100t.tcl
The script creates the project, runs synthesis + implementation, and writes church_wukong_xc7a100t.bit
Download and install AMD Vivado (free ML Standard edition) from xilinx.com/support/download.html — required before any of the steps below.
Unzip the downloaded project into a working folder.
cd into the extracted folder and source the build script in Vivado batch mode:
cd ~/path/to/church-wukong-package
vivado -mode batch -source wukong_xc7a100t.tcl
The script creates the project, runs synthesis + implementation (~30 min), and writes church_wukong_xc7a100t.bit
Part B — Flash the board (~5 min)
LEDs right now:012Board is being programmed
In Vivado: open Hardware Manager → Open target → Auto Connect
Right-click the xc7a100t device → Program Device
Select church_wukong_xc7a100t.bit from your build folder
Click Program and wait for it to finish (~10 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: openFPGALoader church_wukong_xc7a100t.bit
Wait for "Programming done" — a few seconds
⚠ Common problems — Flash
Vivado Hardware Manager can't find the board — check the JTAG cable is fully seated, try a different USB port, confirm board power is connected.
"Unknown device" error — install or reinstall the FTDI/Digilent JTAG cable drivers.
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 ZIP (Verilog netlist + XDC + Vivado build script), then download the pre-built church_wukong_xc7a100t.bit from the Connect tab — no synthesis needed.
Flash — Program church_wukong_xc7a100t.bit onto the Wukong board with Vivado Hardware Manager (or openFPGALoader).
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.
WUKONG CONNECTION PROFILE
Configuration
Keep the programming link, trace bridge, and board settings together. Use these values when configuring the host machine or diagnosing a connection.
✅ Reference profile
💻 JTAG programming · Artix-7
Testing
Download .bit and load it over JTAG for temporary testing; reset or power-cycle clears it.
Official release
Download .mcs and program SPI flash for a reset-resident release image.
Free AMD tool
AMD Vivado ML Standard Edition includes Vivado Hardware Manager; openFPGALoader is also supported.
Trace data
Not carried over JTAG
📡 USB-UART bridge
Baud
57600 8N1
Linux
/dev/ttyUSB* or /dev/ttyACM*
Windows
Select the assigned COM port
🔧 Bridge service
Script
hardware/wukong_bridge.py
IDE port
8766
Responsibilities
Trace, commands, uploads, and acknowledgements
Attached reference images
IDE references plus physical cable, board, and host setup photos for matching the expected connection, status, and execution workflow.
11 references
Versions overviewConnect Wukong entryBoard controlsDashboard actionsPipeline healthConnection statusHardware traceExecution workspaceProgrammer cable pinoutCabled Wukong boardLaptop and Wukong IDE
ARTIX-7 FPGA UNIT UNDER TEST
QMTECH Wukong board
The physical FPGA unit used for Wukong programming, trace capture, command delivery, and boot verification.
XC7A100T-200T
Artix-7 XC7A100T-200T Wukong BoardPhysical unit under test
No build yet — click Build to synthesise RTL
Build Log
Ready.
Package Contents
No build yet.
Next Steps►
Build first to see instructions.
📜 Build History►
Loading…
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).
Selects the synthesis target for Download FPGA Package and Deploy to FPGA.
The Wukong XC7A100T uses Yosys + Vivado for P&R.
Identity
Your dot pet name is stamped into every compiled LUMP as the identity seal — petname.Abstraction#n is globally unique.
Notifications
Choose which alerts appear on screen.
Friends & Family
Every person gets a Golden Token — a device-managed capability identifier checked by the Church Machine. Current tokens are not cryptographically unforgeable.
Adults control which permissions children hold. No accounts, no passwords — just tokens on this device.
Invoke Method
Select a method, fill in arguments, then click Set Up Call. DR0 is set to the method selector automatically.
Create Namespace Entry
Reserve a slot in the namespace for your abstraction. This is where Mind meets the machine — every abstraction needs a home.
Save to Namespace
Choose any existing slot except Boot.NS (0) or Boot.Thread (1) to replace that LUMP with this release. Choose New Entry only when you want a separate copy. The binary T-ID and saved date/time identify each saved revision.
Format Lump Step 1 of 2
Output format
Header
Version History
Capabilities
Audit
Open File Catalog
Save File
Must start with simulator/ and end with .cloomc — the file is written to the workspace on the server.
Mum Tunnel Library
Share abstractions with learners worldwide
Loading shared abstractions...
Publish to Mum Tunnel Library
Open on Another Device
Copy this link and open it on your phone, tablet, or another computer:
Add LUMP — Choose Type
Import LUMP
Namespace DNA
Capability GT links between abstractions
Each node is a Namespace slot. Directed arrows represent declared GT capability links
from source to target. Hover a node or edge for details.
GT Inspector — Golden Tokens by Type
Every GT currently found in loaded c-lists and live CRs, grouped by type. Click any row to see where it appears.
