LAB / MULTI-DEVICE
ENGINEERING NOTEBOOK
4× AKD1500 on one Raspberry Pi
A deliberately cautious multi-device notebook: public evidence on one side, our Pi measurements on the other.
EXPERIMENTALIN PROGRESS4 × AKD1500
What is already supported by public evidence
AKD1500 is an Akida 1.0 target. The current runtime can enumerate multiple hardware devices. BrainChip also publishes a separate multi-device repository built around several Akida chips on one x86 host, where each device appears as its own PCIe endpoint.
Boundary: that multi-device x86 reference does not prove our Raspberry Pi topology. It only tells us that multi-device orchestration is a legitimate software/hardware pattern to investigate.
Our Pi questions
- Do all four endpoints enumerate reliably after cold boot?
- How does the active driver name and expose each device node?
- How much host memory/CMA is needed for our actual mapped models?
- Can we bind specific models/workloads to specific devices predictably?
- What does model switching cost in practice?
- How does the PCIe topology affect concurrency?
Baseline capture
uname -a lspci -nn lsmod | grep -i akida ls -l /dev/akida* /dev/akd1500_* 2>/dev/null || true python -c "import akida; print(akida.__version__); [print(i,d.desc,d.version) for i,d in enumerate(akida.devices())]"
Result log
| Test | Result | Status |
|---|---|---|
| 1 device enumeration | Awaiting captured Pi result | Open |
| 4 device cold boot | Awaiting captured Pi result | Open |
| Model mapping ×4 | Awaiting mapped model | Open |
| Concurrent inference | Test harness not yet fixed | Open |
Sources / official baselineAkida device discoveryBrainChip Symphony multi-device referenceOfficial PCIe driver