Asynchronous techniques for system-on-chip design

SoC design will require asynchronous techniques as the large parameter variations across the chip will make it impossible to control delays in clock networks and other global signals efficiently. Initially, SoCs will be globally asynchronous and locally synchronous (GALS). But the complexity of the numerous asynchronous/synchronous interfaces required in a GALS will eventually lead to entirely asynchronous solutions. This paper introduces the main design principles, methods, and building blocks for asynchronous VLSI systems, with an emphasis on communication and synchronization. Asynchronous circuits with the only delay assumption of isochronic forks are called quasi-delay-insensitive (QDI). QDI is used in the paper as the basis for asynchronous logic. The paper discusses asynchronous handshake protocols for communication and the notion of validity/neutrality tests, and completion tree. Basic building blocks for sequencing, storage, function evaluation, and buses are described, and two alternative methods for the implementation of an arbitrary computation are explained. Issues of arbitration, and synchronization play an important role in complex distributed systems and especially in GALS. The two main asynchronous/synchronous interfaces needed in GALS-one based on synchronizer, the other on stoppable clock-are described and analyzed

Specifying the Caltech asynchronous microprocessor

The action systems framework for modelling parallel programs is used to formally specify a microprocessor. First the microprocessor is specified as a sequential program. The sequential specification is then decomposed and refined into a concurrent program using correctness-preserving program transformations. Previously this microprocessor has been specified at Caltech, where an asynchronous circuit for the microprocessor was derived from the specification. We propose a specification strategy that is based on the idea of spatial decomposition of the program variable space

Submicron Systems Architecture Project : Semiannual Technical Report

The Mosaic C is an experimental fine-grain multicomputer based on single-chip nodes. The Mosaic C chip includes 64KB of fast dynamic RAM, processor, packet interface, ROM for bootstrap and self-test, and a two-dimensional selftimed router. The chip architecture provides low-overhead and low-latency handling of message packets, and high memory and network bandwidth. Sixty-four Mosaic chips are packaged by tape-automated bonding (TAB) in an 8 x 8 array on circuit boards that can, in turn, be arrayed in two dimensions to build arbitrarily large machines. These 8 x 8 boards are now in prototype production under a subcontract with Hewlett-Packard. We are planning to construct a 16K-node Mosaic C system from 256 of these boards. The suite of Mosaic C hardware also includes host-interface boards and high-speed communication cables. The hardware developments and activities of the past eight months are described in section 2.1. The programming system that we are developing for the Mosaic C is based on the same message-passing, reactive-process, computational model that we have used with earlier multicomputers, but the model is implemented for the Mosaic in a way that supports finegrain concurrency. A process executes only in response to receiving a message, and may in execution send messages, create new processes, and modify its persistent variables before it either exits or becomes dormant in preparation for receiving another message. These computations are expressed in an object-oriented programming notation, a derivative of C++ called C+-. The computational model and the C+- programming notation are described in section 2.2. The Mosaic C runtime system, which is written in C+-, provides automatic process placement and highly distributed management of system resources. The Mosaic C runtime system is described in section 2.3

Submicron Systems Architecture Project: Semiannual Technical Report

No abstract available

The impact of asynchrony on computer architecture

The performance characteristics of asynchronous circuits are quite different from those of their synchronous counterparts. As a result, the best asynchronous design of a particular system does not necessarily correspond to the best synchronous design, even at the algorithmic level. The goal of this thesis is to examine certain aspects of computer architecture and design in the context of an asynchronous VLSI implementation. We present necessary and sufficient conditions under which the degree of pipelining of a component can be modified without affecting the correctness of an asynchronous computation. As an instance of the improvements possible using an asynchronous architecture, we present circuits to solve the prefix problem with average-case behavior better than that possible by any synchronous solution in the case when the prefix operator has a right zero. We show that our circuit implementations are area-optimal given their performance characteristics, and have the best possible average-case latency. At the level of processor design, we present a mechanism for the implementation of precise exceptions in asynchronous processors. The novel feature of this mechanism is that it permits the presence of a data-dependent number of instructions in the execution pipeline of the processor. Finally, at the level of processor architecture, we present the architecture of a processor with an independent instruction stream for branches. The instruction set permits loops and function calls to be executed with minimal control-flow overhead

Specification and validation of control intensive ICs in hopCP

technical reportControl intensive ICs pose a significant challenge to the users of formal methods in designing hardware. These ICs have to support a wide variety of requirements including synchronous and asynchronous operations polling and interrupt driven modes of operation multiple concurrent threads of execution non-trivial computational requirements and programmability. In this paper we illustrate the use of formal methods in the design of a control intensive IC called the "Intel 8251" Universal Synchronous / Asynchronous Receiver Transmitter (USART), using our hardware description language 'hopCP'. A feature of hopCP is that it supports communication via synchronous ports in addition to synchronous message passing Asynchronous ports are distributed shared variables writable by exactly one process We show the usefulness of this combination of communication constructs We outline algorithms to determine safe usages of asynchronous ports and also to discover other static properties of the specification We discuss a compiled code concurrent functional simulator called CFSIM, as well as the use of concurrent testers for driving CFSIM. The use of a semantically well specified and simple language and the associated analysis/simulation tools helps conquer the complexity of specifying and validating control intensive ICs

An asynchronous forth microprocessor.

Ping-Ki Tsang.Thesis (M.Phil.)--Chinese University of Hong Kong, 2000.Includes bibliographical references (leaves 87-95).Abstracts in English and Chinese.Abstract --- p.iAcknowledgments --- p.iiiChapter 1 --- Introduction --- p.1Chapter 1.1 --- Motivation and Aims --- p.1Chapter 1.2 --- Contributions --- p.3Chapter 1.3 --- Overview of the Thesis --- p.4Chapter 2 --- Asynchronous Logic g --- p.6Chapter 2.1 --- Motivation --- p.6Chapter 2.2 --- Timing Models --- p.9Chapter 2.2.1 --- Fundamental-Mode Model --- p.9Chapter 2.2.2 --- Delay-Insensitive Model --- p.10Chapter 2.2.3 --- QDI and Speed-Independent Models --- p.11Chapter 2.3 --- Asynchronous Signalling Protocols --- p.12Chapter 2.3.1 --- 2-phase Handshaking Protocol --- p.12Chapter 2.3.2 --- 4-phase Handshaking Protocol --- p.13Chapter 2.4 --- Data Representations --- p.14Chapter 2.4.1 --- Dual Rail Coded Data --- p.15Chapter 2.4.2 --- Bundled Data --- p.15Chapter 2.5 --- Previous Asynchronous Processors --- p.16Chapter 2.6 --- Summary --- p.20Chapter 3 --- The MSL16 Architecture --- p.21Chapter 3.1 --- RISC Machines --- p.21Chapter 3.2 --- Stack Machines --- p.23Chapter 3.3 --- Forth and its Applications --- p.24Chapter 3.4 --- MSL16 --- p.26Chapter 3.4.1 --- Architecture --- p.28Chapter 3.4.2 --- Instruction Set --- p.30Chapter 3.4.3 --- The Datapath --- p.32Chapter 3.4.4 --- Interrupts and Exceptions --- p.33Chapter 3.4.5 --- Implementing Forth primitives --- p.34Chapter 3.4.6 --- Code Density Estimation --- p.34Chapter 3.5 --- Summary --- p.35Chapter 4 --- Design Methodology --- p.37Chapter 4.1 --- Basic Notation --- p.38Chapter 4.2 --- Specification of MSL16A --- p.39Chapter 4.3 --- Decomposition into Concurrent Processes --- p.41Chapter 4.4 --- Separation of Control and Datapath --- p.45Chapter 4.5 --- Handshaking Expansion --- p.45Chapter 4.5.1 --- 4-Phase Handshaking Protocol --- p.46Chapter 4.6 --- Production-rule Expansion --- p.47Chapter 4.7 --- Summary --- p.48Chapter 5 --- Implementation --- p.49Chapter 5.1 --- C-element --- p.49Chapter 5.2 --- Mutual Exclusion Elements --- p.51Chapter 5.3 --- Caltech Asynchronous Synthesis Tools --- p.53Chapter 5.4 --- Stack Design --- p.54Chapter 5.4.1 --- Eager Stack Control --- p.55Chapter 5.4.2 --- Lazy Stack Control --- p.56Chapter 5.4.3 --- Eager/Lazy Stack Datapath --- p.53Chapter 5.4.4 --- Pointer Stack Control --- p.61Chapter 5.4.5 --- Pointer Stack Datapath --- p.62Chapter 5.5 --- ALU Design --- p.62Chapter 5.5.1 --- The Addition Operation --- p.63Chapter 5.5.2 --- Zero-Checker --- p.64Chapter 5.6 --- Memory Interface and Tri-state Buffers --- p.64Chapter 5.7 --- MSL16A --- p.65Chapter 5.8 --- Summary --- p.66Chapter 6 --- Results --- p.67Chapter 6.1 --- FPGA based implementation of MSL16 --- p.67Chapter 6.2 --- MSL16A --- p.69Chapter 6.2.1 --- A Comparison of 3 Stack Designs --- p.69Chapter 6.2.2 --- Evaluation of the ALU --- p.73Chapter 6.2.3 --- Evaluation of MSL16A --- p.74Chapter 6.3 --- Summary --- p.81Chapter 7 --- Conclusions --- p.83Chapter 7.1 --- Future Work --- p.85Bibliography --- p.87Publications --- p.9

Design Rules for Non-Atomic Implementations of PRS

Martin Synthesis yields quasi--delay-insensitive (QDI) circuits, expressed in production--rule-set (PRS) form. Under an atomic circuit evaluation model, these circuits are provably correct. However, not all physical circuit implementations provide the atomic transitions needed to satisfy the atomic circuit model. This can cause operational failures in real circuits, as we illustrate. Nonetheless, circuits with non-atomic transitions can faithfully implement the atomic circuit model when combined with a few simple slewtime constraints. To generalize this, we present a non-atomic circuit model, and we prove that any non-atomic circuit satisfying the slewtime constraints implements the atomic circuit model. To synthesize correct physical circuits, therefore, one can use Martin Synthesis assuming atomicity, and then physically implement the resulting circuit using the slewtime constraints as design rules