Simplify switch demo

[martijnbastiaan]

Status quo

Back in April we added a switch demo to showcase that we could use the bittide mechanism to thread a path through an 8-node network, all statically scheduled. The hardware used to look like this. To simplify things, we programmed a static calendar and used a calculator to produce the exact clock cycles at which the PE should send and receive data. For more details, see this presentation.

Proposal

While talking to potential users of bittide we've found that they're not interested in this switching behavior (yet). Instead, they're more interested in the "wire" behavior of bittide and would simply like to be kept away from anything else. To showcase this, I propose the following hardware design:

The idea is still the same: thread a path through a bunch of nodes/FPGAs (in our case 8). The implementation is much simpler than the previous iteration though: instead of using calendars to do time multiplexing on every link, the links are connected to the PE through a single mux. This mux can either be set to serve the MU or the PE.

Hardware components

Management unit

Still responsible for buffer centering, getting links up and running, etc. It will program the mux and PE config.

Programmable mux

2 bus accessible registers:

• cycle_to_switch :: Unsigned 64: cycle to switch from MU to PE
• arm :: Bool: whether to actually look at the first register yet. Used to prevent atomicity issues.

Inputs:

• Links from the PE
• Links from the MU

Outputs:

• Reset to PE
• Links to elastic buffers

PE

Takes two configuration values (from "PE config"):

• What link to read from (:: Maybe (Index 7))
• What link to write to (:: Maybe (Index 7))

The PE is active for two cycles after reset:

• First cycle: read from link indicated by config (or source static "0").
• Second cycle: write value_read_in_first_cycle XOR fpga_dna_lsbs to link indicated by config (or do nothing)

PE Config

2 bus accessible registers:

• read_link :: Maybe (Index 7)
• write_link :: Maybe (Index 7)

Why this shows bittide

Because the PE only reads a single cycle and writes a single cycle, we need to be able to predict exactly when data packets will arrive on any given node from any given node.

Why this satisfies "seeing bittide as a wire"

The MU will take care of all reset logic and set everything up for the PE / business logic. The business logic does not have to care about this at all and just does a simple read, trusting that the data from its neighbor is presented on the relevant link. Vice versa for writing.

Things we will not do for this demo

We won't do in-band communication of UGNs. They are captured and read out by the host PC over a debug connection. The host PC will also calculate the schedule for each FPGA (programmable mux config, PE config). Doing this all in-band is planned, but we need to take one bite at a time.

Things left out of the diagram

• Clock control
• Transceiver IP
• Debug connections
• ʰᵃʳᵈʷᵃʳᵉ ᵘᵍⁿ ᶜᵒᵐᵖᵒⁿᵉⁿᵗˢ
• Peripherals (timers, uart, etc.)