This talk is about constructing systems that are inherently heterogeneous in terms of timing conditions as digital networks (called `hets' from "heterogeneously timed nets") in which computational elements interact through (fully or partially) asynchronous communication mechanisms (ACMs).
Practical examples of systems with heterogeneous timing and power-saving requirements are embedded real-time control and decision-making systems, used in aerospace, automotive, telecomm and other applications. Although the idea of building such systems as hets does not itself stipulate that such systems are necessarily implemented in hardware, our perception is that this approach may be particularly effective in building the new generation of VLSI systems, or systems-on-chip (SOCs), where demands for higher speed, global asynchronisation and power savings come into one complex interplay.
The talk centers around the notion of ACMs as being the key to constructing hets. We analyse the evolution of the concept of timing in digital systems, from those centrally clocked, to systems with distributed clocking and/or self-timing (e.g., using handshakes), and finally to those which can be fully asynchronous. The price to be paid for such a complete temporal decoupling between components, which still need to communicate data across the interfaces, is that of potential partial loss of the transmitted information because of overwriting, by the source process, the data that has not been read by the destination process.
We present a classification of ACMs, in relation to particular types of data being communicated in hets, which is based on the propeties of over-writing with new data and re-reading the old data, essential to maintain full asynchrony in systems. We demonstrate the feasibility of building hets in hardware by presenting examples of the main types of ACMs, Pool, Signal and Message, together with their clock-free circuit implementations. Pool is an ACM that can be used to interface two time-driven sub-systems, with independent clocking regimes, whereas Signal, and its `mirror' Message, can help interfacing a time-driven (`busy') environment with a data-driven (`lazy') processing system where energy costs may be of concern.