Provide example of tethered-config simulation with MultiHarnessBinders

[jerryz123]

This adds a BringupHostConfig to go alongside the ChipLikeRocketConfig. The BringupHostConfig is the FPGA design that can bring-up the ChipLikeRocketConfig.

This also adds the TetheredChipLikeRocketConfig, which uses the MultiChip/MultiHarnessBinder APIs to build ChipLikeRocketConfig as chiptop0, BringupHostConfig as chiptop1, connect their serial-tl ports, connect SimTSI to the BringupHostConfig's UART-TSI pot, and simulate the entire system. The entire system can be simulated in RTL simulation, and tested with the standard testchip_tsi plusarg/htif commands.

Ex:

make CONFIG=TetheredChipLikeRocketConfig EXTRA_SIM_FLAGS="+cflush=0x2010200" run-binary LOADMEM=1 BINARY=hello.riscv

This approach to simulation will be very slow, as it will simulate both the slow TSI-over-UART and serial-tilelink interfaces at accurate frequencies.

The procedure for those using Chipyard to tape-out should be to craft an equivalent ChipConfig and BringUpHostConfig specific to their design, connect them in a MultiChip harness configuration using the MultiHarnessBinder API to model the chip-to-FPGA link, and simulate the system entirely in RTL simulation before tapeout.

Added:

• MultiHarnessBinder - like HarnessBinders, but for chiptop-to-chiptop connections
• CanHavePeripheryUARTTSI - adds a UART port that transports TSI, which gets converted to a tilelink master. This should only ever be built as part of FPGA bringup platforms.
• OBUS - "OffchipBus" - devices which transport tilelink to an off-chip tilelink network (ex: FPGA bringup board) should hang off this. For a chip, the OBUS contains all the off-chip memory. For a bringup FPGA config, the OBUS contains the chip's on-chip memory.
• BringupHostConfig - a no-core config that just contains some buses to support the ChipConfig's off-chip memory, and bridging between UART-TSI and the test chip.

Changes:

• Clean up the run-tests CI script to dedup a lot of the commands
• Reorganize AbstractConfig default IOBinders to delineate between IOCell and punchthrough IOs
• SerialTL hangs off the OBUS instead of MBUS now (OBUS can hang off the MBUS).

Fixed:

• run-binary-debug BINARY=none should not attempt to objdump none

Related PRs / Issues:

Type of change:

• Bug fix
• New feature
• Other enhancement

Impact:

• RTL change
• Software change (RISC-V software)
• Build system change
• Other

Contributor Checklist:

• Did you set main as the base branch?
• Is this PR's title suitable for inclusion in the changelog and have you added a changelog:<topic> label?
• Did you state the type-of-change/impact?
• Did you delete any extraneous prints/debugging code?
• Did you mark the PR with a changelog: label?
• (If applicable) Did you update the conda .conda-lock.yml file if you updated the conda requirements file?
• (If applicable) Did you add documentation for the feature?
• (If applicable) Did you add a test demonstrating the PR?

• (If applicable) Did you mark the PR as Please Backport?

[abejgonzalez]

Does the OBUS hold things like a scratchpad on the chip? Am I interpreting that correctly?

[jerryz123]

Does the OBUS hold things like a scratchpad on the chip? Am I interpreting that correctly?

OBUS is the bus which connects to off-chip memory/devices. It is intended to abstract away the physical implementation of the interface (SerialTL, etc.) from the clock crossings to the the interface, from any address remapping that needs to be done before going over that interface.

[abejgonzalez]

LGTM