[bebop/rushb] Fix bugs in rushB mode to run E2E models

[daiyongyuan]

Summary

• initialize RushB BEMU workers with the topology of their selected Chip.pb endpoint
• derive ABI accelerator IDs from tile/local Core placement instead of flat Core indices
• support native x86 model runners and host-pointer DMA for both BEMU and Verilator
• keep default Pebble Verilator unchanged; select RushB RTL only when --rushB is passed
• restore toy RushB CI and add multi-tile endpoint coverage

Commit structure

1. fix(bemu): initialize per-worker topology for rushB
2. fix(rushb): derive ABI accelerator IDs from Chip.pb
3. test(rushb): restore toy CI and add multi-tile routing coverage

Dependency PRs

• fix(verilator): select RushB RTL through bbdev bbdev#14
• fix(rushb): align host backends with chip topology bebop#19
• feat(rushb): build Buckyball model runners natively buddy-compiler/buddy-examples#17

The submodule commits must be merged before updating the final gitlinks on the target branch.

Validation

• LeNet RushB BEMU: PASS, classification 8
• LeNet RushB Verilator: PASS, classification 8
• python3 -m unittest compiler.scripts.tests.test_pb_to_target_registry: PASS
• nix develop -c cargo test -p bebop-rushb: 2 passed
• repository pre-commit hooks: PASS

[shirohasuki]

This test is superfluous; there is no testing framework, and no one will maintain it in the future.

[shirohasuki]

Variables are prone to conflicts, so why not pass parameters to each function?

[shirohasuki]

what means ACCELERATOR_ID and CHIP_ID, what's the difference?

[daiyongyuan]

ACCELERATOR_ID identifies a RushB command endpoint and is encoded as (tile_id << 16) | local_accelerator_id. CHIP_ID identifies the top-level Chip/BBSimDRAM instance used for host staging DMA.
Verilator Harness
└── Chip/SoC ← CHIP_ID
├── Tile 0
│ ├── Accelerator 0 ← ACCELERATOR_ID
│ └── Accelerator 1
└── Tile 1
└── Accelerator 0

[shirohasuki]

CHIP_ID means toy=0/pebble=1/poly=2/goban=3? Have I got that right?

[daiyongyuan]

CHIP_ID identifies a chip instance in a multi-chip simulation. In a normal single-chip simulation, CHIP_ID is typically 0 regardless of the design. Multiple cores within one chip are distinguished separately.

[shirohasuki]

Haha, I think it's too early for buckyball to consider a multichip system. I reckon it will still take us a year to build a multi-core system that makes sense. So, I suggest removing them now~

[shirohasuki]

We use the commit message format from the LLVM community.