Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Wire Demo

The wire demo demonstrates the “wire” behavior of bittide: threading a path through an 8-node FPGA network, treating each link as a dedicated point-to-point connection. Rather than using calendars to do time multiplexing on every link, each link is connected to the PE through a single mux. This mux can either be set to serve the MU or the PE.

The host driver uses the UGNs to calculates a route through all nodes and programs each node’s mux and PE configuration accordingly. Each PE reads a value from one link, XORs it with its own FPGA DNA, and writes the result to another link — chaining all nodes together. The final node’s result should be the XOR of all device DNAs, which serves as verification that the path was correctly established.

Architecture

Diagram wireDemo page 1

Initialization sequence

  1. “Boot” CPU
    1. Gets programmed by the host
    2. Programs the clock boards
    3. Gets transceiver block out of reset (enabling the bittide domain / other CPUs)
    4. Activates each transceiver channel and waits until they’ve negotiated a link with their neighbors.
    5. Prints “all done” message to UART.
  2. Clock control CPU
    1. Gets programmed by the host
    2. Calibrates clocks
    3. Prints “all done” message to UART.
    4. (Keeps calibrating clocks.)
  3. Management unit CPU
    1. Gets programmed by the host
    2. Sets the channels to “user” mode. This makes the channels accept data from the outside world instead of their negotiation state machinery.
    3. Waits for hardware UGN to be captured
    4. Start auto-centering elastic buffers
    5. Waits for clocks to be considered stable
    6. Stops auto-centering the elastic buffers
    7. Prints UGNs captured by hardware component to UART.

Components:

  • Boot CPU (BOOT)
  • Transceivers
  • Domain difference counters
  • Clock control (CC)
  • Elastic buffers (one per incoming transceiver link)
  • Hardware UGN capture (for comparison)

Components:

  • Management unit (MU)
  • 7 transmit and receive ring buffers, one of each per link
  • Programmable mux
  • WireDemoPe, a processing element specific for this demo
  • WireDemoPeConfig, a bus accessible device with a writable configuration for the processing element

Management unit

Connected components:

  • Timer
  • UART (for debugging)
  • FPGA DNA register

The management unit has access to and is responsible for all transmit/receive ring buffers in the node. In this demo these are not used.

To change the binary run on this CPU, one may either:

  • Edit bittide-instances/src/bittide/Instances/Hitl/WireDemo/Driver.hs, line 215 (at time of writing) to use another binary instead of wire-demo-management-unit
  • Edit the source files in firmware-binaries/demos/wire-demo-management-unit/ to change the binary pre-selected by the driver function

Wire Demo processing element

PE (wireDemoPe)

Takes two configuration values (from “PE config”):

  • What link to read from
  • What link to write to

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 (wireDemoPeConfig)

Has 3 bus accessible registers:

  • read_link :: Maybe (Index 7)
  • write_link :: Maybe (Index 7)
  • written_data :: Maybe (BitVector 64)

The first 2 registers are used to configure the PE. The third register stores the data written by the PE over the configured link. This is used to verify the demo works. The data in the last PE Config should be the XOR of all DNAs.

  • UART arbiter
  • JTAG interconnect
  • Integrated logic analyzers
  • SYNC_IN/SYNC_OUT

Running tests

One may specifically run the software UGN demo test by making a .github/synthesis/debug.json with the following contents:

[
  {"top": "wireDemoTest",       "stage": "test", "cc_report": true}
]

At the time of writing, the clock control CPU stabilizes system. The driver running on the host (bittide-instances/src/bittide/Instances/Hitl/WireDemo/Driver.hs) then releases the reset of the management unit CPU. In turn, this CPU will center the elastic buffers and print out the UGNs captured using the hardware UGN capture component over UART.

The host driver then calculates a schedule to thread a path through all nodes and programs all PE Configs and programmable muxes. After waiting for a static time the host driver reads the written_data register in each PE Config device and verifies it is equal to the XOR of all device DNAs up to that node. The last node should therefore have stored the XOR of all device DNAs.

Tests are configured to run the following binaries on the system’s CPUs:

  • Boot CPU: wire-demo-boot (firmware-binaries/demos/wire-demo-boot)
  • Clock control CPU: clock-control (firmware-binaries/demos/clock-control)
  • Management unit: wire-demo-management-unit (firmware-binaries/demos/wire-demo-management-unit)

One may change this by either:

  1. Changing the driver function so that it loads different binaries onto the CPUs. This may be accomplished by changing which binary name is used with each of the initGdb function calls.
  2. Changing the source code for the binaries. The locations for them are listed above.