The Elastic Silicon Interconnect dialect
Long ago, software function calling conventions were ad-hoc. This led to issues, particularly with register clobbering and stack corruption. This is – in large part – the state of FPGA/ASIC design today: wire signaling protocols are often ad-hoc, which also leads to major issues. Though there are efforts to standardize the signaling protocols there are many minor and major variants, both of which lead to confusion which can cause real problems when one is listening to and twiddling the wires manually. ESI solves this by providing a simple, intuitive, common, and standardized interface to developers then figures out the signaling details and conversions between then.
While the ABI/signaling problem is slowly being partially solved, it does not speak to the types of data on the wires – the software analogy being memory and registers. In the software world, data types were added. More and more complex type systems began to evolve – to great successes in some cases as strong typing can help developers avoid bugs and assist in debugging. In the FPGA/ASIC world, RTL-level languages are starting to get basic types but across interconnects it is still common for the data types to be informally specified in a data sheet. This indicates a total failure of the basic type system which RTL supports.
The Elastic Silicon Interconnect (ESI) project raises the bar on both fronts. On the data type front, it (will) define a rich, hardware-centric type system to allow more formal data type definitions and strong static type safety. On the ABI/signaling front, it can build simple, latency-insensitive interfaces and abstract away the signaling protocol. Essentially, the intent is to cleanly separate/abstract the physical signaling layer from the message layer. This enables many tasks to be automated including – but not limited to – the following:
- Inter-language communication
- Type checking to reduce bugs at interface boundaries
- Correct-by-construction building of communication fabric (including clock domain crossings)
- Decision making about the physical signaling between modules
- Software API generation which bridges over PCIe, network, or simulation
- Pipelining based on floor planning between modules to reduce timing closure pressure
- Compatibility between modules with different bandwidths (automatic gearboxing)
- Type and signal aware debuggers/monitors in communication fabric
- Common interface for board support packages
- Extensible services to support global resources (e.g. telemetry)
The ESI project is in its infancy – it is not complete by any means. We are always looking for people to experiment with it and contribute!