Specifying Hardware Communication as Programs
2026-06-11 • Programming Languages
Programming LanguagesHardware Architecture
AI summaryⓘ
The authors propose a new programming language designed to describe how hardware components talk to each other. Typically, engineers write separate programs to send instructions to hardware and to watch what happens, which can be time-consuming and prone to mistakes. Their language lets users write one clear set of instructions that can both control and observe hardware interactions. They also created a tool that, given these instructions and recorded hardware signals, automatically figures out what happened during communication. The authors plan to test their approach on common hardware protocols.
hardware protocolsdrivermonitordomain-specific language (DSL)transaction-level modelingwaveformWishboneAXI-Streamsignal tracinghardware debugging
Authors
Ernest Ng, Nikil Shyamsunder, Francis Pham, Adrian Sampson, Kevin Laeufer
Abstract
To test and debug hardware modules, it is common to write two programs: a driver, which translates high-level transactions into interactions on the module's input and output signals, and a monitor, which analyzes a signal-level execution trace and recognizes a transaction. These two programs are commonly implemented separately for each hardware protocol, but this separation entails manual effort and risks inconsistencies. We advocate an alternative approach. We present a DSL in which users specify hardware communication protocols as succinct imperative programs. Crucially, the same specification can be used to both drive designs and monitor transactions. We present the design of a tool, which given a specification in our DSL and a waveform, automatically infers a transaction-level trace consistent with the waveform. We discuss plans to evaluate our DSL on real-world interconnects such as Wishbone and AXI-Stream.