The same architectural rigor that flew on the Space Shuttle — now an automated gate in your repository. Zero-allocation compliance, strict struct geometry, cache-line discipline, and software-level resilience against memory corruption (SIHFT) — enforced at compile time and in CI.
A common misconception when skimming this repository is that it is an academic space shuttle simulator, a retro-computing exercise, or an enthusiast project focused on arbitrary 256 KB memory limitations.
It is none of those.
ap101 implements pragmatic Software-Implemented Hardware Fault Tolerance
(SIHFT) concepts for production applications. It was forged as the core
internal testing discipline for the Clarus PACS medical imaging server
(repository link follows when the project goes public). DICOM ingestion
dealing with gigabytes of multi-frame CT/MRI data cannot tolerate heap churn,
fragmentation, or silent data corruption caused by unstable hardware.
Medians of 7 clean runs, produced by the public harness ab_test.py; full methodology, per-run tables and limitations: benchmark.md.
| Phase | Clarus+bridge | Orthanc 1.12.11 | Ratio |
|---|---|---|---|
| C-MOVE read (like for like) | 34.9 s (29.7 MB/s) | 103.3 s (10.0 MB/s) | 3.0x |
| Ingest end to end (HOP1+HOP2) | 58.8 s (17.6 MB/s) | 76.9 s (13.5 MB/s) | 1.3x |
| +- HOP1: C-STORE into outbox (accept only) | 23.3 s (44.4 MB/s) | 76.9 s (13.5 MB/s) | 3.3x |
| +- HOP2: outbox drain -> Clarus STOW | 36.5 s (28.4 MB/s) | - (single hop) | - |
Conditions: same VMware VM (3 vCPU, 32 GB RAM, HDD-backed virtual disks), loopback, 1035.1 MB corpus (1063 instances, 3 studies), documented Defender exclusions. n = 7 clean runs per condition (Clarus+bridge), Orthanc n = 9/10. Hop model: Orthanc does everything in ONE synchronous hop (its C-STORE phase is its full ingest). The bridge is TWO hops: HOP1 = asynchronous DIMSE acceptance into the outbox, HOP2 = drain into Clarus; the honest like-for-like number is HOP1+HOP2. The HOP1 row exists so nobody can sell the 3.3x acceptance rate as a 3.3x ingest. Without the exclusions Defender eats 54% of ingest and Clarus+bridge is ~17% slower than Orthanc - the exclusions are operational, not cosmetic.
- Zero-Heap Reinforcement: Slashed run-time allocations from 128 000 to exactly 0 per computed tomography (CT) study ingestion.
- Cache-line surgery on live structs: the
cache_line_fields!gate found a SHA-256 digest field crossing a 64-byte cache line in the study-instance record — fixed before false sharing could tax the indexing hot path. - Query hot path, zero-heap by construction: QIDO CBOR→JSON streaming removed one allocation per response → ≈8.6M heap allocations/day avoided — estimate at 100 QIDO/s (100 × 86 400), computed, not measured.
- The gate audits itself: the Clarus audit exposed a flaw in
TestAllocatoritself — shared counters polluted by parallel test threads. The enforcer now measures per-thread; a gate that lies is worse than none. - Numbers, not adjectives: the ingestion parse path benchmarks at ~309 ns against a 5 µs CI budget (full numbers and findings journal below).
- Target hardware profile: designed for cheap ARM single-board computers and repurposed x86 workstations in regional clinics. The discipline scales in both directions: keeps budget hardware alive, keeps big hardware fast.
The IBM AP-101B was the core avionics computer of the Space Shuttle. The aerospace industry proved that when building on imperfect hardware, the software must maintain total architectural discipline down to the assembly level.
We brought this philosophy to modern Rust. ap101 does not run code in
space; it introduces automated guardrails into your CI suite to ensure
that your data structures, memory access boundaries, and low-level code
invariants do not degrade during rapid production refactoring.
Full Shuttle history: ferrite-to-CMOS transition, STS-37/STS-40 →
The framework provides four distinct, high-utility tools for your test suite:
-
Zero-Heap Enforcer (
TestAllocator): A global allocator interceptor. If a hot-path parsing function leaks a hidden allocation (String,Vec,Box), the CI pipeline fails immediately. -
Structural Integrity (
assert_no_padding!): A compile-time layout assertion checking for hidden alignment gaps (padding bytes) in your data structures. Prevents hidden data serialization leaks and stack bloating. -
Fault Injection Engine (
FerriteCell<T>): A test-runner mechanism designed to simulate physical single-event upsets (SEUs) and transient bit-flips. Validates how your software detects, flags, and gracefully handles physical memory corruption. -
Cache-Line Audit (
cache_line_fields!/FieldSpan): Compile-time per-field cache-line spans viaoffset_of!. Flags fields straddling a 64-byte line boundary (two line fills per access) and groups fields that false-share one line across threads.
Add to Cargo.toml:
[dependencies]
ferrite-core = { git = "https://github.com/clicker71/ap101", subdir = "codebase/ferrite-core" }
[dev-dependencies]
ferrite-testkit = { git = "https://github.com/clicker71/ap101", subdir = "codebase/ferrite-testkit" }Run the navigation example test suite:
cargo test -p ap101b-coreExpected output:
╔════════════════════════════════════════════════════════════════╗
║ IBM AP-101B FERRITE CORE DISCIPLINE SUITE v3.0 ║
║ TARGET: NAVIGATION SYSTEM v1.0 ║
╚════════════════════════════════════════════════════════════════╝
[ COMPLIANT ] AP101B-CORE-01 | Struct Geometry & Alignment | Size: 32B...
[ COMPLIANT ] AP101B-CORE-02 | Zero Hidden Padding | ...
[ COMPLIANT ] AP101B-CORE-04 | Deterministic Computation (±4 ULP) | ...
[ COMPLIANT ] AP101B-CORE-05 | Cosmic Ray SEU Resilience | ...
╔════════════════════════════════════════════════════════════════╗
║ MISSION STATUS: GO FOR LAUNCH. ║
╚════════════════════════════════════════════════════════════════╝
DEVELOPER_GUIDE.md — full guide: writing tests, CI setup, understanding failures, common pitfalls, reference projects.
Every claim below is a real finding from the Clarus DICOMweb server, caught by the gates before it reached a user. Each entry carries a file/line or commit reference inside the Clarus repository; public links are added when it opens.
The brand-new cache-line gate caught a real defect on its first run:
InstanceRecord.sha256, a 32-byte hash, straddled a 64-byte cache-line
boundary — every read touched two lines instead of one.
- Fix:
#[repr(C)]with the two 32-byte hashes first (blake3at 0..32,sha256at 32..64). Fields are accessed by name and the manifest is CBOR-serialized, so the reorder is wire-safe. - The field is a legacy-tier address scheduled for removal; the fix is cheap and temporary, and the gate will re-verify the layout after the field goes.
- Measured effect on the development bench: none. The dev machine is disk-bound; this defect class is only visible on memory-bound target hardware. The gate caught what the benchmarks could not measure.
The zero-alloc gates themselves run under real CI load. They caught a flake in their own allocator: foreign harness threads were polluting the global allocation counters, causing rare false failures. The counters moved to per-thread storage — a measuring thread now sees only its own allocations. The tool that audits the product was audited by the product.
One streaming path (multipart body buffering) legitimately allocates — copying 500 MB parts would be worse. The test does not pretend otherwise: it declares the non-zero path with file/line and verifies what is actually guaranteed (correctness across torn read boundaries) instead of painting green over the exception.
| Finding | What the gate did |
|---|---|
| CBOR codec designed zero-alloc | confirmed the design contract, no retrofit |
hidden String clone in the auth hot-path lookup |
found, fixed to a borrow |
journal ring counters wrapped modulo → giant len() → infinite loop |
caught at the full-buffer boundary |
write!/format! on the QIDO response |
replaced with a manual &mut [u8] sink: −1 allocation per response |
| bitap fuzzymatch | masks on the stack, zero heap in the search path |
| HTTP request line, 15 headers, route match, chunked body | zero allocations per request; header parse ≈309 ns |
| streaming multipart buffer | honest non-zero path, documented with file:line |
parse_bench: ~309 ns for a ~200-byte request head (gate: <5 µs).- QIDO: −1 allocation per response → ≈8.6M heap allocations/day avoided — estimate at 100 QIDO/s (100 × 86 400), computed, not measured.
All key numbers already exist in the Clarus benchmark suites (cas / qido / stow / wado / index / concurrency). The roadmap item is to export them here with links to runs — not to generate new ones.
| Without ap101 | With ap101 |
|---|---|
hidden String clone in the auth lookup |
borrow returned, zero allocations |
write!/format! per QIDO response |
manual sink, zero allocations per response |
| fuzzy patient-name search on a managed runtime: hidden allocations and GC pauses on the query hot path | Bitap (Shift-Or) one-edit match from stack-only masks, TestAllocator-gated zero heap; candidates narrowed by the n-gram .idx accelerator with zero-heap intersect |
| ring counters wrapped → infinite loop at full buffer | boundary test drives the full buffer |
| padding leaks extra bytes into the cache | assert_no_padding! pins the layout |
| unknown behavior on a flipped bit | single-bit flips and 2–8-bit bursts detected (CRC-32) |
use ferrite_core::assert_no_padding;
use ferrite_testkit::heap::TestAllocator;
#[repr(C)]
struct HotRecord {
hash: [u8; 32],
size: u64,
}
// Compile-time: no hidden padding in the hot record.
assert_no_padding!(HotRecord, hash: [u8; 32], size: u64);
#[global_allocator]
static ALLOC: TestAllocator = TestAllocator::new();
#[test]
fn hot_record_path_is_zero_alloc() {
let before = ALLOC.snapshot();
let _ = core::mem::size_of::<HotRecord>(); // your hot path here
let after = ALLOC.snapshot();
assert_eq!(before, after, "hot path allocated");
}Modern software engineering has grown lazy. High-level languages and frameworks have created a dangerous illusion: that resources are infinite and abstractions are free.
They are not.
When a Python developer writes print("Hello World"), or a web developer
instantiates a nested JSON object, they see one line of code. But underneath,
the physical hardware sees a disaster: the runtime fires an avalanche of
Assembly instructions just to initialize a heap context. The OS memory manager
searches the global heap, locks threads, and carves out virtual memory. Cache
lines are instantly dirtied, forcing the CPU to stall for hundreds of cycles
fetching pointers from slow system RAM.
In a world of infinite cloud budgets, this laziness is hidden by corporate credit cards. In critical systems, this laziness kills.
ap101 exists to bring Assembly-level thinking back to modern Rust
codebases. It is an automated gatekeeper that forces your code to respect
the physical silicon.
This test harness is not a retro-computing physics simulator. It is an architectural quality contract for production software. It treats 256 KB not as a physical limitation, but as a disciplinary boundary to enforce four non-negotiable rules of high-performance engineering:
Your 64 GB of DDR5 RAM is a lie. Your CPU's ultra-fast L1 and L2 Data Caches are still tiny (32 KB – 512 KB).
The Trap: If your hot-path scatters data across the heap using dynamic
pointers (String, Vec, Box), you hit the Cache Wall. The CPU drops
to zero velocity, waiting for the memory bus.
The Discipline: ferrite-core forces zero-allocation and continuous,
tight memory layouts (zero padding). Your entire hot-path working set
resides entirely inside L1/L2 cache lines. The code runs at the absolute
physical speed limit of the silicon.
In aerospace, automotive, and medical devices, an unhandled Out-Of-Memory (OOM) error means catastrophic failure.
The Trap: A single temporary buffer allocation inside an interrupt handler or telemetry loop under peak load panics the kernel.
The Discipline: This harness acts as a brutal CI gate. It intercepts runtime allocations and unaligned structures, preventing junior developers from accidentally introducing heap mutations into hard real-time systems.
On modern edge nodes and high-frequency backend services, heap churn is the silent killer of performance.
The Trap: Millions of allocations per second cause heap fragmentation and force aggressive Garbage Collection or thread-locking allocation waits.
The Discipline: Forcing critical components to use stack-only, linear, predictable structures drops CPU system overhead to zero. It translates directly to fewer cloud instances and massive operational cost reductions.
The Space Shuttle's AP-101B (1981–1990) used magnetic ferrite core memory — naturally immune to cosmic rays at the physics level. The AP-101S (1991–2011) was the first Shuttle computer to use semiconductor memory (CMOS SRAM/DRAM), and with it came the first registered SEU on STS-37. The era of software-level fault tolerance began.
Today, at 3nm and below, the problem is exponentially worse. A single atmospheric neutron can flip bits in server RAM, automotive controllers, and medical equipment — on Earth, at sea level. The smaller the transistor, the lower the critical charge, the higher the SEU cross-section.
The Trap: Shrinking process nodes make silent data corruption a statistical certainty for any sufficiently large deployment. Standard compilers offer zero protection.
The Discipline: The SEU simulation in this harness forces you to write and test software-level fault-tolerant algorithms (CRC-32, XorFold, ECC) to guarantee data integrity when the physical silicon fails — exactly as the aerospace industry learned the hard way in 1991.
ferrite-core is a no_std Rust library providing:
FerriteCell<T>— controlled-access memory cell with explicit safety contract. Safe read for machine-word Copy types. Unsafe write with volatile semantics. Cosmic ray injection for SEU testing.- Structural audit — compile-time geometry checks (
size_of,align_of, zero hidden padding) viaassert_no_padding!macro and runtimeGeometryReport. - Cache-line audit —
cache_line_fields!macro +FieldSpanspans (crosses_line(),shares_line_with()), computed at compile time viaoffset_of!. Detects cross-cache-line field splits and false-sharing groups. - Checksums —
Checksumtrait withCrc16,Crc32,XorFoldimplementations. Stack-only. Zero allocations. - IBM PASS CRT telemetry —
IbmCrtdecorator with historicalAP101B-CORE-message IDs. (Named after the Shuttle's Integrated Display Processor / PASS CRT, not the ground-based IBM 3270 office terminal.)
ferrite-testkit (requires std) provides:
TestAllocator— global allocator wrapper to verify zero heap allocations in code under test.- SEU strategies — proptest generators for single-event upset simulation.
Cross-project audit of Clarus PACS production structs — the same code that had 128 000 allocations per CT study. The harness verifies geometry, padding, and SEU resilience of real-world medical data structures:
cargo test -p clarus-audit -- --nocaptureB-Model audit:
╔════════════════════════════════════════════════════════════════╗
║ IBM AP-101B FERRITE CORE DISCIPLINE SUITE v3.0 ║
║ TARGET: CLARUS CORE v0.3.0-alpha ║
╚════════════════════════════════════════════════════════════════╝
[ COMPLIANT ] AP101B-CORE-01 | ChunkRecord Geometry | Expected 40B, got 40B
[ COMPLIANT ] AP101B-CORE-02 | DicomElement Geometry | Expected 12B, got 12B | vr: [u8;2] — ZERO HEAP
[ COMPLIANT ] AP101B-CORE-03 | InstanceMeta Geometry | Expected 212B, got 212B
[ COMPLIANT ] AP101B-CORE-04 | InstanceMeta SEU (1000 flips) | All bit-flips detected
[ COMPLIANT ] AP101B-CORE-05 | Zero Hidden Padding | Verified at compile time via assert_no_padding!
╔════════════════════════════════════════════════════════════════╗
║ MISSION STATUS: GO FOR LAUNCH. ║
╚════════════════════════════════════════════════════════════════╝
S-Model audit — adds multi-bit SEU burst detection:
╔════════════════════════════════════════════════════════════════╗
║ IBM AP-101S CMOS FERRITE DISCIPLINE SUITE v3.0 ║
║ TARGET: CLARUS CORE v0.3.0-alpha (CMOS) ║
╚════════════════════════════════════════════════════════════════╝
[ COMPLIANT ] AP101S-CMOS-01 | ChunkRecord Geometry | Expected 40B, got 40B
[ COMPLIANT ] AP101S-CMOS-02 | DicomElement Geometry | Expected 12B, got 12B | vr: [u8;2] — ZERO HEAP
[ COMPLIANT ] AP101S-CMOS-03 | InstanceMeta Geometry | Expected 212B, got 212B
[ COMPLIANT ] AP101S-CMOS-04 | Multi-Bit SEU (1000 bursts, 2-8 bit) | All bursts detected by CRC-32
[ COMPLIANT ] AP101S-CMOS-05 | InstanceMeta SEU (1000 flips) | All bit-flips detected
[ COMPLIANT ] AP101S-CMOS-06 | Zero Hidden Padding | Verified at compile time via assert_no_padding!
╔════════════════════════════════════════════════════════════════╗
║ MISSION STATUS: GO FOR LAUNCH. ║
╚════════════════════════════════════════════════════════════════╝
The discipline is applied as an integration test inside the Clarus PACS repository itself. This is not a curated model example — it is a direct audit of production code: domain models, storage layer, CJK charset detection, and JPEG2000 transfer syntax constants.
Run from the Clarus repo:
cargo test -p clarus-testing --test ap101_audit -- --nocaptureDomain models — honest violations (expected for DTOs):
[ANOMALY DET] AP101B-CORE-10 | Patient Geometry | 112B
[ANOMALY DET] AP101B-CORE-11 | Study Geometry | 368B
[ANOMALY DET] AP101B-CORE-12 | Series Geometry | 168B
[ANOMALY DET] AP101B-CORE-13 | Instance Geometry | 184B
[ANOMALY DET] AP101B-CORE-14 | WorkItem Geometry | 376B
MISSION STATUS: ABORT. VIOLATION DETECTED.
Domain models use String/Option<String> for DICOM attributes. Hidden heap
pointers and padding are unavoidable for data transfer objects. The test
correctly flags them — structural discipline is not required for DTOs, only
for the hot path.
Hot path — all clear:
[ COMPLIANT ] AP101B-CORE-20 | ChunkHash [u8; 32] | ZERO HEAP
[ COMPLIANT ] AP101B-CORE-30 | Charset Chinese/Japanese/Korean/Georgian | Pure compute
[ COMPLIANT ] AP101B-CORE-40 | JPEG2000 Transfer Syntax UIDs | Constants
MISSION STATUS: GO FOR LAUNCH.
The storage layer ([u8; 32] chunk hash), charset detection (pure functions,
no allocation), and JPEG2000 codec constants (compile-time strings) are all
ferrite-compliant. This is the code that processes gigabytes of multi-frame
DICOM pixel data — and it runs with zero heap churn.
The test was deliberately not "fudged" to hide the domain model violations. It reports them honestly, demonstrating that the discipline distinguishes between what must be ferrite-compliant (hot path) and what cannot be (DTOs with variable-length DICOM attributes).
The discipline auditing itself (meta-circular verification).
Every assert_no_padding! macro, every CRC-32 checksum, every SEU injection
that ferrite-core provides is verified by the same discipline:
B-Model self-test (cargo test -p ap101b-core):
╔════════════════════════════════════════════════════════════════╗
║ IBM AP-101B FERRITE CORE ║
║ TARGET: NAVIGATION SYSTEM v1.0 ║
╚════════════════════════════════════════════════════════════════╝
[ COMPLIANT ] AP101B-CORE-01 | Struct Geometry & Alignment | Size: 32B (max 32B), Align: 8B (min 4B)
[ COMPLIANT ] AP101B-CORE-02 | Zero Hidden Padding | Expected 32B, got 32B
[ COMPLIANT ] AP101B-CORE-03 | Deterministic Computation (±4 ULP) | diff: 0.00e0 ≤ 4.77e-6
[ COMPLIANT ] AP101B-CORE-04 | Cosmic Ray SEU Resilience | All bit-flips detected
╔════════════════════════════════════════════════════════════════╗
║ MISSION STATUS: GO FOR LAUNCH. ║
╚════════════════════════════════════════════════════════════════╝
S-Model self-test (cargo test -p ap101s-cmos):
╔════════════════════════════════════════════════════════════════╗
║ IBM AP-101S CMOS ║
║ TARGET: NAVIGATION SYSTEM v1.0 (CMOS) ║
╚════════════════════════════════════════════════════════════════╝
[ COMPLIANT ] AP101S-CMOS-01 | Struct Geometry & Alignment | Size: 40B (max 40B), Align: 8B (min 4B)
[ COMPLIANT ] AP101S-CMOS-02 | Zero Hidden Padding | Expected 40B, got 40B
[ COMPLIANT ] AP101S-CMOS-03 | ECC Syndrome Check | ECC detects field change
[ COMPLIANT ] AP101S-CMOS-04 | Multi-Bit SEU Detection (2-8 bit) | All bursts detected
[ COMPLIANT ] AP101S-CMOS-05 | Battery Retention | 0x5A=OK, 0x00=LOST
[ COMPLIANT ] AP101S-CMOS-06 | Deterministic Computation (±4 ULP) | diff: 0.00e0 ≤ 4.77e-6
╔════════════════════════════════════════════════════════════════╗
║ MISSION STATUS: GO FOR LAUNCH. ║
╚════════════════════════════════════════════════════════════════╝
All four audit targets — B-model self, S-model self, Clarus Core B-model, Clarus Core S-model — return GO FOR LAUNCH. The discipline holds.
This project values architectural rigor over blind abstraction. For a transparent breakdown of our engineering assumptions, blind spots, and architectural constraints, read DECISIONS.md.
- [ ] V0.1.1 EXPORT CLARUS BENCHMARKS INTO README WITH LINKS TO RUNS (NS/OP, LATENCY TAILS)
- [x] V0.1.1 CACHE-LINE ANALYSIS IN GEOMETRYREPORT (FALSE SHARING DETECTION)
- [ ] V0.2.0 #[DERIVE(FERRITEDISCIPLINE)] — ONE ANNOTATION: GEOMETRY + PADDING + CRC
- [ ] V0.2.0 HFT/GAMEDEV FEATURE PROFILES (FEATURES = ["HFT"])
- [ ] V0.2.0 CARGO-AP101 CI PLUGIN — FAILS BUILD ON STRING IN HOT FUNCTION
- [ ] V0.2.0 SPATIAL BURST SEU (2-4 ADJACENT CELLS, S-MODEL)
- [ ] V0.2.0 ASYNC RUNTIME ISOLATION — ALLOC MICROSCOPE (TOKIO-AWARE)
- [ ] V0.2.0 CROSS-PLATFORM TARGET ALIGNMENT CONTRACT (ARM/X86_64)
- [ ] V0.2.0 STACK DEPTH ANALYSIS — CARGO-CALL-STACK INTEGRATION
- [ ] V0.2.0 FERRITECELL SAFETY CONTRACTS + UNSAFE AUDIT (MCDC)
- [ ] V0.3.0 QEMU ON-TARGET SEU TESTING (ARM/RISC-V)
- [ ] V0.3.0 CONST FN CRC-32 (NIGHTLY)
- [ ] V0.3.0 ARTICLE — 128 000 ALLOCS REMOVED WITH 1981 SHUTTLE DISCIPLINE
ap101/
├── README.md
├── codebase/ # Cargo workspace
│ ├── ferrite-core/ # no_std primitive library (shared)
│ │ ├── src/
│ │ │ ├── cell.rs # FerriteCell with unsafe contract
│ │ │ ├── audit.rs # Structural geometry audit
│ │ │ ├── checksum.rs # Checksum trait
│ │ │ └── telemetry.rs # IBM PASS CRT telemetry
│ │ └── Cargo.toml
│ ├── ferrite-testkit/ # std testing library (shared)
│ │ ├── src/
│ │ │ ├── heap.rs # Deterministic alloc detector
│ │ │ └── strategy.rs # Proptest SEU strategies
│ │ └── Cargo.toml
│ ├── examples/
│ │ ├── ap101b-core/ # AP-101B: Ferrite core memory
│ │ │ ├── src/lib.rs # NavigationState (B-model)
│ │ │ └── tests/discipline.rs
│ │ ├── ap101s-cmos/ # AP-101S: CMOS SRAM + DRAM/ECC
│ │ │ ├── src/lib.rs # NavigationState (S-model)
│ │ │ └── tests/discipline.rs
│ │ └── clarus-audit/ # Cross-project: Clarus Core audit
│ │ ├── src/lib.rs # ChunkRecord, DicomElement, InstanceMeta
│ │ └── tests/
│ │ ├── b_model.rs # B-model audit of Clarus
│ │ └── s_model.rs # S-model audit (multi-bit SEU)
│ └── Cargo.toml
└── .gitignore
ID PREFIX AP101B-CORE- AP101S-CMOS-
MODEL IBM AP-101B IBM AP-101S
MEMORY TECH FERRITE CORE (CORE STORAGE MODULE) CMOS SRAM (BATT-BACKED) + DRAM/ECC
WORD SIZE 32-BIT 32-BIT
CAPACITY ~416 KB PHYS, ~256 KB USABLE 256K WORDS (1 MB)
ERA 1981-1990. LAST FLIGHT: STS-40 1991-2011. FIRST FLIGHT: STS-37.
(1991) SEU FIRST DETECTED HERE.
cargo test -p ap101b-core # AP-101B ferrite core tests only
cargo test -p ap101s-cmos # AP-101S CMOS tests only
cargo test --workspace # ALL tests (B + S + core + testkit)
# CI-grade SEU verification (10 000 cases each):
PROPTEST_CASES=10000 cargo test -p ap101b-core prop_seu_detection
PROPTEST_CASES=10000 cargo test -p ap101s-cmos prop_burst_seu_detectionThe ferrite-core and ferrite-testkit libraries are model-agnostic.
Adding a new Shuttle computer variant requires only a new example crate:
STEP EFFORT WHAT TO DO
1. NEW EXAMPLE 5 MIN cargo new examples/ap101s-cmos
2. DEFINE STRUCT 15 MIN Ap101sState — SAME PATTERN, DIFFERENT EXPECTED_SIZE
3. DISCIPLINE TEST 20 MIN COPY ap101b() -> ap101s(). ADJUST: MULTI-BIT SEU, ECC, BATTERY
4. FILTER 0 MIN cargo test ap101s — WORKS IMMEDIATELY
B-model vs S-model differences in tests:
ASPECT AP-101B (FERRITE CORE) AP-101S (CMOS)
MEMORY CONSTRAINT 256 KB USABLE 1 MB
SEU MODEL SINGLE-BIT FLIP. FERRITE IS MULTI-BIT BURST (DRAM ROW UPSET).
NATURALLY IMMUNE. CMOS IS VULNERABLE. FIRST SEU
DETECTED: STS-37.
ERROR DETECTION CRC-32 CHECKSUM CRC-32 + ECC SYNDROME CHECK
POWER LOSS TOTAL LOSS. FERRITE IS NON- SRAM BATTERY RETENTION TEST
VOLATILE BUT UNPOWERED READ
= DESTRUCTIVE.
STRUCT SIZE 28-40 BYTES (COMPACT STRUCTS) UP TO 128 BYTES (ECC OVERHEAD)
Note on the S-model: The AP-101S used semiconductor memory (CMOS SRAM/DRAM), not ferrite cores. It has its own discipline —
ap101s-cmos— with checks specific to CMOS: ECC syndrome verification, multi-bit SEU bursts, and SRAM battery retention. Both models shareferrite-coreprimitives (CRC-32, structural audit,assert_no_padding!); the S-model adds ECC on top. Both models are tested; they simply protect against different physics.
MIT — see LICENSE.
"256 KB and not one byte more." — Flight software constraint, IBM AP-101B, ca. 1981.