LEGO: Empowering Chip-Level Functionality Plug-and-Play for Next-Generation IoT Devices

Adding a new sensor to a deployed IoT device means rewiring it, rewriting its embedded firmware, and often making a new circuit board, because the microcontroller on board has to know each chip intimately — LEGO (UESTC and Shanghai Jiao Tong) removes the microcontroller entirely, moves every chip-specific decision to a shared gateway, and leaves the device as a fixed circuit that turns received instructions into pin signals, so that plugging in a chip the gateway has a description file for is all the customisation there is.

Why this problem is worth solving

The difficulty is not that chips are complicated but that they are all differently complicated.

Chips are state machines, so timing is part of the interface.

What people did before, and where it broke

• Make embedded development faster. Tools that simplify hardware design, generate a recommended component list from user code, or lift low-level programming onto general-purpose platforms. Where it broke. A professional still has to write and debug an embedded program that makes a particular chip and a particular processor work together, before anything can be deployed.
• Reprogram devices over the air. Wireless reprogramming means a firmware change does not require physically visiting every deployed device. Where it broke. It changes how the program is delivered, not that it must be written, tested and made stable first. The development workload is untouched.
• Wrap each chip in a standardised plug-and-play module. The approach behind a published sensor standard and a body of modular device designs: hide the heterogeneity behind a uniform package with a uniform interface. Where it broke. Building such a module means adding a controller and supporting components and doing both hardware and software design, taking weeks to months per chip — harder than adapting the raw chip. The standard has existed since 2001 and is still not widely used.
• Design a modular end device with a fixed catalogue of modules. Platforms supporting dozens of interchangeable modules do exist and work well within their catalogue. Where it broke. Every module must be uniformly designed in advance, so the flexibility stops exactly at the edge of what the platform vendor built.
• The gap. All of these assume the chip is driven by a processor sitting next to it, which is where the coupling lives. Whether the firmware is easy to write, delivered wirelessly, or hidden inside a module, something local still has to know what this particular chip expects — so a new chip always means new local work.

How an end device stops running programs

The idea

The device stops executing a program and starts replaying a signal sequence someone else computed. This is the move that makes everything else possible, and it is more radical than it first appears: there is no microcontroller on the board at all. What remains is a fixed circuit — under 40 thousand logic gates, drawing 231 microwatts at one megahertz — that configures its pins as instructed, converts incoming instructions into the electrical signals a chip expects, and packages whatever comes back. Because that circuit is the same for every chip and every application, plugging in a different sensor changes nothing about it. The awkwardness of the old arrangement was never the chip and never the processor but the requirement that they be introduced to each other by hand, once per pairing; removing the processor removes the introduction. Replacing a general-purpose runtime on an endpoint with a tiny engine that replays a recording produced by a larger machine is precisely the trade the phone graphics stack work covered elsewhere on this site makes when it captures what 48 megabytes of vendor runtime does at its narrowest interface and replays it from 50 kilobytes.

All that heterogeneity turns out to be four verbs. The claim underneath the design is that however different two chips look, driving either one decomposes into writing data, reading data, asserting or clearing a control line, and checking a status line — with a delay attached to each, because a chip is a state machine that discards anything arriving in the wrong state. Two further keywords handle pin configuration and the formula converting raw bytes into units, and that is the entire language. The evidence offered is coverage: 105 commercial chips across 19 sensing types and eight bus protocols, each described in a file averaging 429 bytes. The pleasing part is what it does to where effort lands. A description is written once for a chip and is valid for every application and every device, whereas firmware is written per chip, per processor and per application; the measured effect is 78 percent less development time than C++ and 87 percent less preparation than a microcontroller platform. Finding that an apparently unbounded variety collapses onto a small set of primitives once the incidental differences are stripped away is the same discovery the compiler synthesis work covered elsewhere on this site makes about instruction sets, where 3,557 instructions become 397 operations — derived mechanically there, argued by inspection here.

Centralising control costs bandwidth, so the design is mostly about not sending things twice. Once every decision lives on the gateway, the naive consequence is a network round trip for every pin transition, which for a sensor sampled at 200 hertz is absurd. The structure that avoids it splits instructions into three levels — chip, function, meta-operation — and mirrors it with registers on the device, one register per function. Plugging a chip in transmits the complete conversation once, averaging 0.53 kilobits, and 86 of the 105 chips need under 800 bits. After that a task is a 36-bit command naming a device, a slot, a function, a rate, a duration and a priority, and the device replays the stored sequence locally with the datasheet delays intact. The scheduler refuses to interrupt a function partway, which is what keeps a half-finished conversation from corrupting a chip. Deciding which end of a link should hold the state, and paying in one currency to save in another, is the same negotiation the disaggregated memory work covered elsewhere on this site conducts in the opposite direction, stripping bookkeeping out of a shared box and pushing it onto the clients.

Following one accelerometer from the packet to the reading

Measured at about 7 seconds for the dialling and 9 for connecting wires, with a whole chip plugged in at 15.5 seconds on average by unskilled volunteers. This is the step that keeps the arrangement short of true auto-detection.

Why it works

• The coupling lives in the pairing, not in either half. A chip is only hard to use because a nearby processor must be taught its particular conversation, and that teaching happens once per chip and per application → so removing the processor removes the teaching → and what is left on the device is one fixed circuit that never changes, whatever is plugged into it.
• Chip conversations really do decompose. Pin layouts, command bytes and bus protocols differ endlessly, but the operations themselves are writing data, reading data, driving a control line and checking a status line → so six keywords suffice to describe a chip completely, provided each operation carries its required delay → which covered 105 commercial chips across eight bus protocols in files averaging 429 bytes.
• A description is portable in a way firmware is not. Firmware is written for a specific chip against a specific processor for a specific application, so none of it transfers → whereas a description names only properties of the chip itself, taken from its datasheet → so one file serves every device and every application, and the library grows once rather than repeatedly.
• Buffering turns a chatty architecture into a quiet one. Centralising control implies a round trip per pin transition, which no sampling rate could tolerate → so the full conversation is written into device registers once at 0.53 kilobits on average, and thereafter a task is a 36-bit command → letting a chip be sampled at hundreds of hertz with no further network traffic.
• Dropping the processor drops most of the power. A microcontroller runs an instruction stream continuously whatever the workload → whereas a fixed conversion circuit clocked at one megahertz does only signal translation → so computation power falls from 3.756 milliwatts to 0.583 at the highest sampling rate tested, more than paying for the extra communication the architecture requires.

What it costs (trade-offs and scope)

• The chip identifier is dialled in by hand. Plug-and-play here means automatic configuration, not automatic detection: the user looks up a 16-bit identifier and sets it on hexadecimal switches before inserting the chip, which the paper measures at about 7 seconds and describes as an example mechanism. Nothing reads the chip to find out what it is.
• A chip absent from the library is not plug-and-play at all. The 105 descriptions were written by 16 student volunteers. The manual work is moved out of the device and amortised across everyone who uses that chip, which is a real gain, but it is not eliminated.
• No parallel chip operations. The device schedules chips sequentially and the language has no way to express simultaneity, which the paper states plainly rules out driving several high-speed chips at once.
• Interrupts cannot be handled locally. The language has no interrupt description and the device has no interrupt circuit, so an interrupt travels to the gateway and the response travels back, which the paper acknowledges affects real-time behaviour.
• The device has no autonomy. Every chip-specific decision is remote, so a device can only continue running functions already buffered. The paper discusses eavesdropping and malicious chips, and proposes ciphers small enough to fit, but none of that is implemented or measured, and the dependence on a reachable gateway is not examined.
• Electrical coverage has hard edges. The level shifter is single-direction and CMOS-output, so it cannot preserve the configured pin type and cannot produce negative voltages — ruling out protocols such as RS232 — and its 10 milliamp limit caps attached chips at 180 milliwatts. Analogue chips are reached through 8-bit conversion in each direction, which is coarse.
• The favourable power comparison is narrow, and one component moves the wrong way. Against two microcontroller boards on an analogue sampling task, total power is roughly half — but communication power is consistently higher, which is the architecture’s own cost, and the win comes entirely from having no processor to run. The task is also the one most favourable to a fixed circuit.
• The size and cost claims are projections. The board is 36 by 45 millimetres, larger than both comparison boards. The 15 by 20 millimetre footprint and three-dollar cost are what an integrated implementation could achieve, and no such implementation exists.
• The user studies are demonstrations, not controlled experiments. Twenty-seven unskilled and sixteen skilled student volunteers; the language being compared against C++ and Python was designed by the authors, and the same participants wrote in all three.
• The response time depends on the gateway. The 0.13 second figure is at four cores and one gigahertz, and rises as either falls, because the cost is parsing rather than transmission.
• Communication is cheap only for pre-buffered functions. Anything not expressible as a stored function, or any change to one, needs the gateway again — and interrupt handling, being remote, is exactly such a case.

The evaluation

Check yourself

Sources

The paper is “LEGO: Empowering Chip-Level Functionality Plug-and-Play for Next-Generation IoT Devices” by Chong Zhang, Songfan Li, Yihang Song, Qianhe Meng, Minghua Chen, Yanxu Bai, Li Lu and Hongzi Zhu, published at ASPLOS 2023, pages 404-418, DOI 10.1145/3582016.3582050. The authors are at the University of Electronic Science and Technology of China and Shanghai Jiao Tong University.

This explainer is written from the full 15-page text. Everything above comes from the paper’s own sections: the analysis of why chip customisation is coupled to both hardware and software and why the two existing lines of work — faster embedded development with over-the-air updating, and standardised plug-and-play modules — leave that coupling in place; the system model of gateway, devices and commercial chips with its three design goals; the description language, covering the six keywords, the pin configuration syntax with its connection types, the four control primitives with their per-operation delays and the state-machine argument for why the delays are necessary, the data format keyword with its conversion expressions, and the structure of a description file split into a configuration part executed once and function parts that are buffered; the library design with its hash-based identifier assignment, its 105 chips across eight protocols and its average file size; the gateway, covering the parsing of statements into binary instructions with the twelve-bit coefficient-and-base timing encoding, and the three-layer orchestration across chip, function and meta-operation levels; the device, covering the register-based buffer framework with its scheduler, timing control, instruction counter and priority rules, the pin configuration unit with its five enable signals and four connection types, the input signal converting unit, and the output encoding unit; the implementation details of the FPGA mainboard, gate count, buffer size, board dimensions, analogue converters and level shifters, and the three field deployments; and the evaluation covering response time against data rate and gateway processor settings, the per-chip instruction transmission distribution, the power and size comparison against two microcontroller boards, the end-user and developer studies, and the preparation-time comparison against two embedded platforms, followed by the stated limitations on parallel operation, interrupt handling, voltage fitting and security.