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

CSP channels for CAN-bus connected embedded control systems

Closed loop control system typically contains multitude of sensors and actuators operated simultaneously. So they are parallel and distributed in its essence. But when mapping this parallelism to software, lot of obstacles concerning multithreading communication and synchronization issues arise. To overcome this problem, the CT kernel/library based on CSP algebra has been developed. This project (TES.5410) is about developing communication extension to the CT library to make it applicable in distributed systems. Since the library is tailored for control systems, properties and requirements of control systems are taken into special consideration. Applicability of existing middleware solutions is examined. A comparison of applicable fieldbus protocols is done in order to determine most suitable ones and CAN fieldbus is chosen to be first fieldbus used. Brief overview of CSP and existing CSP based libraries is given. Middleware architecture is proposed along with few novel ideas

Fully automated urban traffic system

The replacement of the driver with an automatic system which could perform the functions of guiding and routing a vehicle with a human's capability of responding to changing traffic demands was discussed. The problem was divided into four technological areas; guidance, routing, computing, and communications. It was determined that the latter three areas being developed independent of any need for fully automated urban traffic. A guidance system that would meet system requirements was not being developed but was technically feasible

Timing Failure Detection with a Timely Computing Base

In a recent report we proposed an architectural construct to address the problem of dealing with timeliness specifications in a generic way. We called it the Timely Computing Base, TCB. The TCB defines a set of services available to applications, including timely execution, duration measurement and timing failure detection. We showed how these services could be used to build dependable and timely applications. In this paper we further extend the description of the TCB, namely by presenting a protocol for its Timing Failure Detection (TFD) service. We discuss the essential aspects of providing such a service under the TCB framework and make some considerations relative to the service interfac

System analysis and integration studies for a 15-micron horizon radiance measurement experiment

Systems analysis and integration studies for 15-micron horizon radiance measurement experimen

Distributed eventual leader election in the crash-recovery and general omission failure models.

102 p.Distributed applications are present in many aspects of everyday life. Banking, healthcare or transportation are examples of such applications. These applications are built on top of distributed systems. Roughly speaking, a distributed system is composed of a set of processes that collaborate among them to achieve a common goal. When building such systems, designers have to cope with several issues, such as different synchrony assumptions and failure occurrence. Distributed systems must ensure that the delivered service is trustworthy.Agreement problems compose a fundamental class of problems in distributed systems. All agreement problems follow the same pattern: all processes must agree on some common decision. Most of the agreement problems can be considered as a particular instance of the Consensus problem. Hence, they can be solved by reduction to consensus. However, a fundamental impossibility result, namely (FLP), states that in an asynchronous distributed system it is impossible to achieve consensus deterministically when at least one process may fail. A way to circumvent this obstacle is by using unreliable failure detectors. A failure detector allows to encapsulate synchrony assumptions of the system, providing (possibly incorrect) information about process failures. A particular failure detector, called Omega, has been shown to be the weakest failure detector for solving consensus with a majority of correct processes. Informally, Omega lies on providing an eventual leader election mechanism

An eventually perfect failure detector in a high-availability scenario

Modern-day distributed systems have been increasing in complexity and dynamism due to the heterogeneity of the system execution environment, different network technologies, online repairs, frequent updates and upgrades, and the addition or removal of system components. Such complexity has elevated the operational and maintenance costs and triggered efforts to reduce it while improving its reliability. Availability is the ratio of uptime to total time of a system. A High Available system, or systems with at least 99.999% of Availability, imposes a challenge to maintain such levels of uptime. Prior work shows that by using system state monitoring and fault management with failure detectors it is possible to increase system availability. The main objective of this work is to develop an Eventually Perfect Failure Detector to improve a database system Availability through fault-tolerance methods. Such a system was developed and tested in a proposed High-Availability database access infrastructure. Final results have shown that is possible to achieve performance and availability improvements by using, respectively, replication and a failure detector.Os Sistemas distribuídos modernos têm aumentando em dinamismo e complexidade devido à heterogeneidade do ambiente de execução, diferentes tecnologias de rede, manutenção online, atualizações frequentes e a adição ou remoção de componentes do sistema. Esta complexidade tem elevado os custos operacionais e de manutenção, incentivando o desenvolvimento de soluções para reduzir a manutenção dos sistemas enquanto melhora sua confiabilidade. Disponibilidade é a razão do tempo de atividade sobre um intervalo de tempo total. Sistemas de Alta Disponibilidade, ou seja, que possuem pelo menos 99.9999% de Disponibilidade, representam um grande desafio para manter tais níveis de operacionalidade. Trabalhos anteriores mostram que é possível melhorar a Disponibilidade do sistema utilizando o monitoramento de estados do sistema e o gerenciamento de falhas com detectores. O objetivo principal deste trabalho é desenvolver um Detector de Falhas Eventualmente Perfeito que pode melhorar a Disponibilidade de um sistema de base de dados através de uma arquitetura de Alta Disponibilidade. Os resultados finais mostram que é possível ter ganhos de desempenho e disponibilidade utilizando, respectivamente, métodos como replicação e detecção de falhas