End-to-end validation of Phases 0-2 on an actual CPU. The real Z80 (examples/intel/z80.c) and a 32K EPROM (z80-boot-rom.c, a rom-32k variant holding JP 0x0006 / HALT) are wired chip-to-chip over a shared address + data bus with no board. RD drives the ROM's OE; CE is left enabled. Booting exercises all three phases at once: the Z80 drives the address -> the ROM reacts on the shared net key (Phase 0); asserts RD -> the ROM tri-state-drives the data bus while the Z80 released it (Phase 1); and reads the data bus in the SAME tickTimers step, getting the settled byte (Phase 2 settle-before-read). The Z80 fetches C3,06,00, jumps to 0x0006, fetches 76, and HALTs -> drives HALT low, which the test observes. z80.wasm is compiled from the committed examples/intel/z80.c; the boot ROM source + chip.json live in test_custom_chips/sdk/examples. All 36 chipbus tests pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| fixtures | ||
| scripts | ||
| sdk | ||
| sketches | ||
| src | ||
| test | ||
| .gitignore | ||
| README.md | ||
| package-lock.json | ||
| package.json | ||
| vitest.config.js | ||
README.md
test_custom_chips
Sandbox aislado para validar el sistema de custom chips de Velxio antes de integrarlo al frontend. Cero dependencia de Wokwi.
Objetivos
- Probar que se puede cargar un
.wasm(chip compilado a partir de C) y enrutarlo al simulador. - Probar que un sketch de Arduino real (
.hexcompilado conarduino-cli) puede comunicarse con el chip vía GPIO e I2C. - Mantener fidelidad 1:1 con la infraestructura de Velxio (
PinManager,I2CBusManager,AVRSimulator) para que el código que se valide acá sea trivial de portar.
Estructura
test_custom_chips/
├── package.json
├── README.md
├── vitest.config.js
├── sdk/
│ ├── include/
│ │ └── velxio-chip.h ← API que ven los chips
│ └── examples/
│ ├── inverter.c
│ ├── inverter.chip.json
│ ├── eeprom-24c01.c
│ └── eeprom-24c01.chip.json
├── scripts/
│ ├── compile-chip.sh ← clang invocation Linux/macOS
│ ├── compile-chip.ps1 ← clang invocation Windows
│ ├── compile-all.sh ← compila todos los ejemplos
│ └── setup-wasi-sdk.md ← cómo instalar wasi-sdk
├── src/ ← runtime y mirrors de Velxio
│ ├── ChipRuntime.js ← loader WASM + host imports
│ ├── WasiShim.js ← WASI mínimo (fd_write, proc_exit)
│ ├── PinManager.js ← espejo de Velxio
│ ├── I2CBus.js ← espejo del I2CBusManager
│ ├── AVRHarness.js ← avr8js wrapper Velxio-fiel
│ ├── intelHex.js ← parser
│ └── index.js
├── fixtures/ ← .wasm compilados + .hex sketches
└── test/
├── js/ ← tests que NO requieren clang
│ ├── 01_pin_manager.test.js
│ ├── 02_i2c_bus.test.js
│ ├── 03_avr_harness.test.js
│ └── 04_runtime_imports.test.js
└── e2e/ ← tests que requieren .wasm compilado
├── 05_chip_inverter.test.js
└── 06_chip_eeprom_24c01.test.js
Quickstart
# 1. Instalar deps
cd test/test_custom_chips
npm install
# 2. (Solo para tests E2E) instalar wasi-sdk siguiendo scripts/setup-wasi-sdk.md
# 3. (Solo para tests E2E) compilar los ejemplos
npm run compile:examples
# 4. Correr tests
npm test # todo
npm run test:js # solo tests JS-only (no requieren wasi-sdk)
npm run test:e2e # solo E2E con WASM
Los tests e2e/ se hacen it.skip automáticamente si el .wasm correspondiente no
está en fixtures/. Eso permite correr la suite parcialmente sin tener wasi-sdk instalado.
Por qué un sandbox separado
Igual que test_circuit/ validó el solver SPICE antes de integrarlo, este sandbox valida
el runtime de chips antes de tocar el frontend de Velxio. Cuando los tests pasen end-to-end,
los archivos de src/ se portan al frontend (con tipado TS) e integran con el editor.
Estado actual
Ver ../autosearch/04_findings.md para el log corrido de qué funciona y qué falta.