Pekka Alho
email: pekka.alho@tut.fi

Jouni Mattila
email: jouni.mattila@tut.fi

Real-Time Service-Oriented Architectures: a Data-Centric Implementation for Distributed & Heterogeneous Robotic System

Keywords: real-time, distributed, SOA, data-centric, middleware, robotics

Cyber-physical systems like networked robots have benefited from improvements in hardware processing power, and can facilitate modern component and service-based architectures that promote software reuse and bring higher-level functionality, improved integration capabilities, scalability and ease of development to the devices. However, these systems also have very specific requirements such as reliability, safety, and strict timeliness requirements set by the physical world, that must be addressed in the architecture.

This paper proposes a real-time capable service-oriented architecture, based on data-centric middleware and an open real-time operating system. A prototype implementation for a robotic remote handling scenario is used to test the approach. The architecture is evaluated on the basis of how well it fulfils the expectations given for the service-orientation, including: reusability, evolvability, interoperability and real-time performance. In one sentence, the goal is to evaluate the benefits of a data-centric approach to service-orientation in a performance-critical and distributed system.

Introduction

Developing software for cyber-physical embedded systems such as networked robots is a demanding task, due to complex functionality that has to be realised in a distributed and heterogeneous computing environment which typically has requirements for real-time performance and fault tolerance. Many of the challenges in these systems are related to interoperability and growing scale. Typically a distributed control system will consist of several subsystems running on different platforms that produce and consume increasing amounts of data.

On a higher abstraction level, business processes are also becoming strongly networked to improve efficiency by automatically transferring data, task requests etc. between systems. This means that robotic systems must be integrated to operations management systems, open for external connections, and able to connect and cooperate with other machines. These requirements and challenges are not unique to robotics -other domains like industrial automation, mobile machines and telecommunication have very similar issues.

Service-oriented software engineering has evolved from component frameworks and object orientation to meet the demands of more open and networked environments. It promotes reuse by decomposing business processes into reusable core services. The main benefits of service-oriented architecture (SOA) include high level of decoupling -provided by the service model -and interoperability which enables service providers and consumers to exist on different platforms. Two major downsides typically associated with SOA are complexity of developing such a system and increased overhead caused by communication mechanisms [START_REF] Machado | Guidelines for performance evaluation of web services[END_REF]. The latter is also related to the lack of performance guarantees, and presents a major challenge especially for embedded systems. An SOA implementation for robotic system therefore needs to place heavy emphasis on solving this problem, which is one of the key design goals for the architecture presented in this paper.

Application of SOA design principles to real-time systems (RTSOA) is a research topic that has come up in the last decade, with research including experimental implementations [START_REF] Cucinotta | A Real-Time Service-Oriented Architecture for Industrial Automation[END_REF], [START_REF] Panahi | A Framework for real-time service-oriented architecture[END_REF], [START_REF] Garces-Erice | Building an Enterprise Service Bus for Real-Time SOA: A Messaging Middleware Stack[END_REF] and related key features like service composition [START_REF] Tsai | RTSOA: Real-Time Service-Oriented Architecture[END_REF], [START_REF] Moussa | Toward effective service composition for real-time SOA-based systems[END_REF]. However, most of the current RTSOA approaches are based on the existing messagebased Web Service standards. Web services face challenges when used in embedded systems, as messages need to be serialized in real-time [START_REF] Tsai | RTSOA: Real-Time Service-Oriented Architecture[END_REF], and quality of service (QoS) must be managed at the transport layer. Other challenges include complexity of networking with HTTP, XML, and SOAP; constraints imposed by embedded system architecture; and verbosity of HTTP and XML.

We believe that the service-oriented approach may be beneficial for the development of cyber-physical systems, but there is a need to test out different implementation solutions that fulfil the specific limitations and requirements of the target domain, including reliable communications, limited resources, and deterministic behaviour. In this paper we present a data-centric approach to RTSOA and evaluate it by implementing the proposed reference architecture for a robotic remote handling scenario. Remote handling involves human operators remotely controlling robots that perform tasks like maintenance or construction in dangerous environments, so reliability and performance of the system are vital for successful task completion.

2

Real-Time Service Orientation for Robotic Systems

Design Goals

We see the following as the main design goals for the real-time service-oriented architecture:

Promote software reuse by producing reusable and decoupled software modules.

Enable composing a working system out of reusable and existing services.

Improve interoperability of heterogeneous systems (platform & programming language independence).

Ensure evolvability [START_REF] Pei-Breivold | A systematic review of software architecture evolution research[END_REF] in the future; the architecture should support changing requirements and operating environments during the system lifecycle. Deterministic real-time performance, despite dynamically changing environment. Dependable and fault tolerant operation.

Improve cost-efficiency & ease of development; the implementation should be able to use off-the-shelf solutions for tools, software and hardware, instead of purpose-built applications and devices.

Reference Architecture

The reference architecture, introduced in [START_REF] Hahto | Service-oriented architecture for embedded machine control[END_REF], is a general proof-of-concept control system platform for machine automation as an alternative to proprietary and specialized solutions. The platform is based on the ideas of real-time service orientation, introduced previously in this section, and emphasizes integrability, interoperability, maintainability and heterogeneity. Service orientation allows software components to be published and located locally or over a network. In section 3 we will describe the actual implementation of the reference architecture for a remote handling scenario. A high-level layered view of the reference architecture is shown in Fig. 1. Key concepts of the architecture are services, communication & information sharing mechanisms, composition, and fault-tolerance. These are described next.

Concurrency Model & Real-Time Performance

The choice of a concurrency model for the architecture directly affects decoupling of the modules and management of real-time constraints. Options for the concurrency model include processes, threads or call-back functions [START_REF] Calisi | Design choices for modular and flexible robotic software development: the OpenRDK viewpoint[END_REF]. Each solution has its own pros and cons for ease of development and inter-process communication. For a service-based architecture, the process-based model (services as processes) makes most sense, as it is the most decoupled alternative. This decoupling provided by processes has benefits, including the possibility to more easily manage services at runtime and improved robustness.

A service can be defined as an independently developed, deployed, managed, and maintained software implementation that directly represents business tasks or devices.

A service can be defined by a verb which describes the function it implements, e.g. "generate a trajectory". Our implementation of services uses object orientation: service is an interface (virtual class) that has methods for starting, stopping, restarting etc. the service, which the service developer must implement. Services can use native applications and services provided by the operating system (e.g. APIs for communication).

Communication & Information Sharing

In order to communicate, components need some form of visibility or references between the communicating parties. However, this can lead to a tightly coupled system design that scales poorly. Examples of communication methods that impose coupling include sockets, remote method invocation and client-server model in general. A more decoupled solution is to use middleware based on the asynchronous publish/subscribe communication paradigm, which can be implemented as message-based like Java Message Service (JMS), or data-centric like Data Distribution Service (DDS) 1 .

Another communication problem in distributed real-time systems is that networking can add unpredictable delays and unreliability to connections. Therefore we need to be able to set and monitor quality of service (QoS) parameters like reliability and how long the data is valid for each topic, so that the system can react appropriately if the QoS is compromised. QoS can be used to define if we want reliable sending (e.g. for commands) or just the most recent value as fast as possible (e.g. sensor measurements). The data-centric middleware can be used as a data bus between the services, as shown in Fig. 2: this is similar to the use of enterprise service bus (ESB) in enterprise SOAs. Another benefit of using a distributed middleware is a global data space where all data can be accessed; there is no central broker/repository that could act as a bottleneck or a single point of failure.

In an ideal situation we would have total location transparency for the services (no difference between accessing local and distributed services), but in order to achieve optimal real-time performance, the architecture uses separate communication methods for local and networked communications, termed local service bus and global service bus. The reference architecture itself is not committed to any specific communication standard, but the implementation uses DDS middleware and the communication mechanisms provided by the real-time operating system (RTOS) Xenomai 2 .

Local connection of services as components and the use of DDS as a data-bus for distributed communications combine the strengths of component and service approaches, and provides optimal real-time performance in both cases. DDS can be used on low-end embedded systems to read and send sensor information, whereas XMLbased solutions would be too heavy, and would necessitate a separate solution.

Global service bus: DDS was chosen since it implements asynchronous datacentric publish/subscribe model and provides QoS management, making it suitable for cyber-physical systems, which place a heavy emphasis on sending and receiving data.

Local service bus: services can use RTOS message queues (an asynchronous "mailbox") or shared memory for local real-time communication between two services. The queue-based local communication is similar to the component wiring approach used in component-based software engineering.

Composition

In complex systems, the number of internal components can easily grow to the range of hundreds or even thousands. Management of this many components or services can be complex and laborious if the framework-implementation of the architecture does not provide tools for this. Engineering of new applications from reusable components is supported by a repository of available components, configuration services to select and combine components, and run-time mechanisms that allow components to be dynamically changed. In the service-oriented architecture, higher level functionality can be implemented by creating composite services of the existing services, as shown in Fig. 3. Different means of implementing composition include programmatic, publish/subscribe, events and orchestration engine. Since our reference architecture is based on the pub-lish/subscribe model, this is a natural match for the composition mechanism, and enables flexible implementation of composite services. Services can be chained locally and globally to form new composite services. A single service can be part of multiple composite services and used by multiple other services, which can reduce the level of unnecessary redundancy in the system.

A repository provides a way to document and list available services or components. For SOAs this can be done by writing an interface description and saving it in the repository. Service registries, on the other hand, provide runtime information for finding and binding services. In our proposed data-centric approach, based on the use of a data bus, the middleware can handle registration of new publishers, and match subscribers to the provided data topics.

Service composition and management at runtime is handled dynamically through a local service manager, which controls spawning of new services. This makes it possible to modify a service and restart it on-the-fly, enabling faster deployment process by updating only related services, instead of having to recompile the whole system after every reconfiguration or update.

Fault Tolerance

Fault tolerance is a key requirement for the architecture, as many cyber-physical systems perform safety-critical tasks. A fault in the control system may endanger human lives (either directly or indirectly), cause operational downtime or damage the environment or equipment. Service-orientation can support error confinement with the modular architecture, based on the decoupling provided by the service model, although the system still needs to implement error detection and recovery.

Because of the decoupled design, developers cannot make the presumption that other services are always available, and must take the situation into account in their application code so that the service will react if a dependency goes down, e.g. because of failure or manual shutdown. The error handling approach based on decoupling is similar to the one used in the Erlang programming language, which can be summarized as "let it crash" [START_REF] Armstrong | Making reliable distributed systems in the presence of software errors[END_REF]. In the event of an error, the process is terminated, presuming it is not an exception that can be handled. This forces other services to react and do error recovery, including entering their safe state. The architecture can still be prone to error propagation, so the services should be made fail-silent if possible, making it easier to detect faults.

In order to implement error detection, the system can use a service manager to detect crashed services based on heartbeat signals or monitoring the use of resources like CPU and memory. Unresponsive behaviour or unexpected increase in CPU usage for a service can indicate a fault in the service, and may endanger real-time performance of other services and cause unexpected and potentially dangerous behaviour. The service manager restarts the unresponsive service, which will put the system temporarily into a safe state by forcing other services to do error handling, according to the "let it fail" approach. Key principle is writing loosely coupled services, by forcing the developer to consider situations where the dependency services are not available or timing constraints are violated.

Implementation for a Remote Handling System

In order to test the proposed data-centric real-time approach to service-orientation, we implemented a remote handling control system (RHCS) for automated teleoperation of an industrial robot Comau SMART NM45-2.0, based on the reference architecture described in the previous section. A basic remote handling scenario consists of an operator using the web-server based Operation Management System (OMS) to send movement commands to the equipment controller. Virtual reality software (IHA3D) is used to visualize the position and movements of the robot.

Services deployed on the equipment controller for the remote handling system implementation are shown in Fig. 4. Service descriptions, real-time task priorities and execution periods are listed in Table 1.

Trajectory-Generator

Generate a trajectory profile that the manipulator can follow from one point to another.

50 2

C4G

Interact with the low level control system of the manipulator. 91 2

C4GJoint-DataPub

Publish manipulator joint position data. 45 10

OmsCom

Read OMS commands and manipulator joint data; send commands to the trajectory generator to create new trajectories.

50

Measuring Measure task execution time and jitter. 20 0.1

Evaluation of the Experiment

This section presents an evaluation of the problems and benefits of the proposed approach that could be observed with the implemented experimental system. The system is evaluated with the following criteria: reusability, interoperability, evolvability, realtime performance, fault tolerance, and ease of development. Dynamic composition performance depends greatly on the algorithm design [START_REF] Tsai | RTSOA: Real-Time Service-Oriented Architecture[END_REF] and it is not evaluated in this paper. Instead, a static composition is used. Reused software includes TrajectoryGenerator service, C4G service and two subsystems (OMS and virtual reality). A service-based implementation avoids stovepipe system antipattern3 as services are loosely coupled (no direct references to other services) and do not interfere with each other's namespaces etc., simplifying future reuse of services. Interoperability of heterogeneous systems (machines and higher-level enterprise systems) is supported on any platform that has a compatible DDS implementation. DDS is available on several programming languages, therefore good programming language independence is provided. Interfaces to Web services, REST-based services and other communication platforms can be implemented with adapters.

Evolvability -the software must be able to accommodate new and changing requirements, including connections to unforeseen external sources. Ability to do this in the long term is especially important for industrial automation systems, because they have long expected lifetimes. This can be measured with evolvability, which describes the ability of software to accommodate future changes [START_REF] Pei-Breivold | A systematic review of software architecture evolution research[END_REF]. Performing a complete evolvability analysis is not reasonable in this context, so we focus on the changeability, extensibility and portability sub-characteristics: Changeability: Data typically has better consistency in the long run when compared to interfaces. However, if the data topics or queue configurations are changed or added, corresponding modifications must be implemented to both publishers and subscribers, but it is possible to provide extensions topics that provide the new or changed data, thus retaining compatibility with old implementations.

Extensibility: New topics or functionality in the form of services can be added on-the-fly, without shutting down and recompiling the whole system. The runtime composition can be managed with the service manager, which can also be used to lazily launch necessary services (service chains).

Portability is limited if RTOS-specific features like real-time queues are used.

Real-time performance -we analysed system performance by measuring cycle durations for a real-time task first unloaded and then running a full remote handling system with a script generating artificial CPU, network & disk loads. The real-time measuring task was executed 10000 times with 100 µs period on a 3.4 GHz Pentium 4 CPU. The measured latencies are shown in Fig. 5. Although standard deviation of cycle duration has increased from 172 ns to 410 ns in the heavily loaded system, graphs show highly deterministic behaviour in both cases. Performance of the DDS middleware in embedded real-time systems has been evaluated e.g. by Xiong et al. in [START_REF] Xiong | Evaluating the performance of publish/subscribe platforms for information management in distributed realtime and embedded systems[END_REF]. Fault tolerance -the service manager can detect if services use more system resources than reserved at start-up, and force a restart. Other services need to react according to the "let it crash" error handling approach. After the services have been restarted, normal operation can be resumed if the fault was transient. A leaky bucket counter or an escalating retry timer can be used to distinguish transient faults from permanent ones.

An example case of error handling: the TrajectoryGenerator service is killed in the middle of running a trajectory to the C4G service, which controls the robot. C4G service detects that there is no new data available, and stops the movement of the robot, by ramping down the power in a controlled and safe fashion. Normal operation can be resumed when the TrajectoryGenerator is restarted.

Cost-efficiency & ease of development: the service-model is an intuitive approach for developers, as services can be interfaces to devices or related to tasks that must be accomplished. Linux-based development offers a variety of tools & drivers, reducing need for self-developed or proprietary choices. Communication configurations (for local queues) are currently hardcoded, so managing a large number of local communications becomes cumbersome, although the service manager can be used to start services. The local service communications should be standardized and details moved to external configuration files that could also be managed with tools to simplify management and reduce local coupling between services.

Conclusions

A dynamic module system based on services or components is necessary to manage complexity of embedded and distributed control systems. The module system should abstract the communications between modules, and provide tools for managing and deploying the configurations in order to improve software reusability and simplify development process, maintenance, and integration of new devices to the system.

In this paper we have presented our design concept for a service-based software architecture. Our proposed approach adapts the SOA paradigm with data-centric design, based on topic-based publish/subscribe middleware and RTOS. The experimental implementation of the architecture demonstrates integration of heterogeneous subsystems with the service-based control system through a scalable middleware-based data bus. The control system is based on an open RTOS and has deterministic real-time capabilities. Although all composition features in the prototype are not fully implemented, it provides contribution by testing the data-centric approach to implementing RTSOA.

Fig. 1 .

 1 Fig. 1. Layered architectural view of the reference architecture

Fig. 2 .

 2 Fig. 2. Bus-based communication in SOA

Fig. 3 .

 3 Fig. 3. Composite service (Key: circle denotes a service, arrow shows direction of data flow)

Fig. 4 .

 4 Fig. 4. Service deployment view for the system (Key: UML)

Fig. 5 .

 5 Fig. 5. Cycle durations for single task vs. remote handling system with extra load

Table 1 .

 1 List of services used in the remote handling control system.

	Service name	Service description	Priority	Period
			[0 .. 99]	[ms]

A standard maintained by Object Management Group, http://portals.omg.org/dds/.

Real time Linux kernel extension and development framework, http://www.xenomai.org/.

http://sourcemaking.com/antipatterns/stovepipe-system


Jiaxing Zhang
email: jxzhang@ece.neu.edu

Gunar Schirner
email: schirner@ece.neu.edu

Joint Algorithm Developing and System-Level Design: Case Study on Video Encoding

System-Level Design Environments (SLDEs) are often utilized for tackling the design complexity of modern embedded systems. SLDEs typically start with a specification capturing core algorithms. Algorithm development itself largely occurs in Algorithm Design Environments (ADE) with little or no hardware concern. Currently, algorithm and system design environments are disjoint; system level specifications are manually implemented which leads to the specification gap. In this paper, we bridge algorithm and system design environments creating a unified design flow facilitating algorithm and system co-design. It enables algorithm realizations over heterogeneous platforms, while still tuning the algorithm according to platform needs. Our design flow starts with algorithm design in Simulink, out of which a System Level Design Language (SLDL)-based specification is synthesized. This specification then is used for design space exploration across heterogeneous target platforms and abstraction levels, and, after identifying a suitable platform, synthesized to HW/SW implementations. It realizes a unified development cycle across algorithm modeling and system-level design with quick responses to design decisions on algorithm-, specification-and system exploration level. It empowers the designer to combine analysis results across environments, apply cross layer optimizations, which will yield an overall optimized design through rapid design iterations. We demonstrate the benefits on a MJPEG video encoder case study, showing early computation/communication estimation and rapid prototyping from Simulink models. Results from Virtual Platform performance analysis enable the algorithm designer to improve model structure to better match the heterogeneous platform in an efficient and fast design cycle. Through applying our unified design flow, an improved HW/SW is found yielding 50% performance gain compared to a pure software solution.

Introduction

The increasing complexity of Multi-Processor System-On-Chip (MPSoC) designs has become a major challenge. Designers combine components with diverse and distinct architecture characteristics heterogeneously to achieve efficient and flexible platform solutions, which however, dramatically increases design complexity.

In order to tame the complexity, System-Level Design (SLD) has emerged with methodologies, tools and environments for a systematic design at higher levels of abstraction. System-Level Design Environments (SLDE), such as PeaCE [START_REF] Ha | PeaCE: A hardware-software codesign environment for multimedia embedded systems[END_REF] and SoC Environment (SCE) [START_REF] Dömer | System-on-Chip Environment: A SpecC-based Framework for Heterogeneous MPSoC Design[END_REF] operate on an input specification captured in an System-Level Design Language (SLDL), such as SystemC [START_REF]Functional Specification for SystemC 2[END_REF] and SpecC [START_REF] Gajski | SpecC: Specification Language and Design Methodology[END_REF]. Based on an input specification, SLDEs provide design space exploration through early performance estimation, automated refinement into Transaction Level Models (TLM), and detailed analysis capabilities. Designers can use their synthesis to generate target implementations. A typical SLD environment is shown at the lower half of Fig. 1.

System-Level Design Env. An Algorithm Design Environment (ADE), currently separated from the system-level design, is shown at the top half of Fig. 1. Algorithm development environments mainly concentrate on modeling algorithms. They simplify prototyping of algorithms by providing toolboxes of algorithm components, detailed (graphical) analysis and functional validation tools. Often, at this level of design, little or no hardware knowledge is concerned. ADE examples include TargetLink [START_REF] Misra | ac tl: Modelling style guidelines for the application of targetlink in the context of automatic code generation[END_REF], LabView [START_REF] Johnson | LabVIEW Graphical Programming: Practical Applications in Instrumentation and Control[END_REF] and Simulink [18]. These ADEs also offer some generation capabilities, however focus on homogeneous solutions and do not offer exploration facilities comparable to SLDEs. However, there is no direct connection between ADEs and SLDEs. Algorithms captured in environments like Simulink are abundantly available through various toolboxes (e.g. computer visions, signal processing), but they need to be converted manually into an SLDL specification for system designed exploration. The manual conversion is time-consuming, tedious and error-prone, which defines the Specification Gap (Fig. 1, middle). The specification gap lowers design productivity and hinders efficient co-design of algorithm and architecture.

Refinements

In this paper, we present a unified design flow that integrates both algorithm and system design environments by bridging the specification gap through Algo2Spec. In this paper, we focus on Simulink as an ADE, which offers modeling, simulating, debugging and analyzing multi-domain dynamic systems. We propose Algo2Spec to close the specification gap by synthesizing Simulink models into SLDL specifications. This enables rapid heterogeneous design space exploration, e.g. through automatically generated VPs at varying abstraction levels. Simultaneously, by extending an existing system design flow to the algorithm level, algorithm designers in Simulink are provided with rapid, dynamic and accurate feedback from heterogeneous VP analysis. Combining the environments creates a seamless unified design flow reaching from Simulink models, via specification, and VPs to target implementations. The unified flow simplifies model analysis and instant propagation up in the design flow, empowering designers to make strategic decisions for globally optimized designs.

We demonstrate the gained flexibility and efficiency of our unified flow using a video encoder design. We show multiple iterations of design decisions to highlight feedback across the environments. Within three design iterations, models with varying granularity are examined in heterogeneous platform explorations. Through applying the unified flow, a software/hardware co-design solution was identified that yields 50% performance gain compare to pure a software solution.

The remainder of this paper is structured as following: Section 2 introduces relevant related work. Section 3 overviews the design flow. Section 4 shows the cross-layer decisions. Section 5 demonstrates the flow benefits on the video encoder case study. Finally, section 6 concludes the paper.

Related work

Significant research effort has been invested into system-level design usually starting from functional specifications. Conversely, the challenge of how to obtain the specification has not gained much attention and consequently specifications are mostly written manually.

Using UML as part of SoC design methodologies has been intensively studied [START_REF] Martin | UML for SOC Design[END_REF][START_REF] Mellor | Executable UML: A Foundation for Model-Driven Architecture[END_REF][START_REF] Vanderperren | From UML/SysML to MATLAB/Simulink: current state and future perspectives[END_REF][START_REF] Riccobene | A SoC design methodology involving a UML 2.0 profile for SystemC[END_REF]. Several language conversions to translate UML models into SystemC are proposed [START_REF] Vanderperren | From UML/SysML to MATLAB/Simulink: current state and future perspectives[END_REF], [START_REF] Riccobene | A SoC design methodology involving a UML 2.0 profile for SystemC[END_REF]. Furthermore, a framework for co-simulation between MATLAB and UML under a co-design flow with application specific UML customizations is provided in [START_REF] Mueller | UML for ESL design: basic principles, tools, and applications[END_REF]. However, these approaches mostly focus on structural conversion and behavior translation (with exception of state machines) is less explored.

A top-down refinement flow from Simulink to SystemC TLM in presented in [START_REF] Jerraya | Programming models and HW-SW interfaces abstraction for multi-processor SoC[END_REF][START_REF] Popovici | Multilevel Programming Envrionment for Heterogeneous MPSoC Architectures[END_REF]. Refinement and component exploration in their work happens in Simulink, requiring direct annotation, rewriting and modifications of Simulink models. This can be seen as contrary to abstraction separation as the top level of abstraction should not involve hardware concerns [START_REF] Marwedel | Embedded Systems Design[END_REF]. Moreover, no system exploration tools or profiling facilities are instantly applied in their approach to SystemC models. On the implementation side, the Simulink conversion is realized as external tools (ie. yacc/lex), which cannot be integrated to Simulink directly while increasing the overall design tool complexity.

Meanwhile, a re-coding approach [START_REF] Chandraiah | Code and data structure partitioning for parallel and flexible MPSoC specification using designer-controlled recoding[END_REF] is proposed to transform flat C code into a structured SLDL specification. The effort similarly aims to close the specification gap, but directly targets C as an input language. Our approach, on the other hand, starts from a higher abstraction by using Simulink as input models.

Also some generation facilities are present within Simulink. The Simulink Embedded Coder (SEC) [START_REF]Simulink Embedded Coder Reference R2011b[END_REF] directly generates target-specific embedded C code, however does not enable heterogeneous exploration. A co-simulation solution [START_REF]Untimed SystemC/TLM Simulation[END_REF] is introduced between Simulink and generated SystemC TLM, however with the focus of being used as testbench rather than the design itself.

Unified Algorithm-System Design Flow

Our unified design flow combining both algorithm-and system-level design is shown in Fig. 2. The figure jointly represents three essential aspects (a) the design flow on the left, (b) model examples on the right and (c) decisions at varying levels. Algorithm Design Environment (ADE), Specification Generation Tool (SGT), namely our proposed Algo2Spec, as well as System-Level Design Environment (SLDE) compose a top-down design methodology with SGT connecting the other two major design environments. For the work in this paper, we select Simulink [18] as an ADE and the System-on-Chip Environment (SCE) [START_REF] Dömer | System-on-Chip Environment: A SpecC-based Framework for Heterogeneous MPSoC Design[END_REF] as an SLDE. The latter uses SpecC [START_REF] Gajski | SpecC: Specification Language and Design Methodology[END_REF] as an SLDL. The principles and concepts, however, apply to SystemC [START_REF]Functional Specification for SystemC 2[END_REF] equally. The unified design flow, as depicted in Fig. 2, starts with designer capturing in ADE the algorithm with desired functionalities and structure. Available algorithms from the algorithm block database simplify and accelerate the development. The designer tunes and refines the algorithms in ADE as a cycle of modeling, simulation, debugging, validation and evaluation. The result of ADE is the captured algorithm in Simulink as for example shown on top right Fig. 2. The example consists of the top-level blocks A1, A2, A5, and A8, were A2 and A5 execute parallel and contain further sub-blocks.

After finishing the initial algorithm specification, the designer transitions to Specification Generation Tool (SGT), namely Algo2Spec, shown in the middle of the Fig. 2. Algo2Spec synthesizes the Simulink model into a specification in SpecC SLDL, following the designer's specification design decision. Different SLDL specification can be generated based on decisions of granularity, scheduling and optimization configurations. An SLDL specification example is shown next to the SGT, were leaf blocks are converted to leaf behaviors and hierarchical blocks are represented through hierarchical behaviors preserving the original hierarchy. Simulink signals are captured as variable in this example.

The generated specification is then the basis for detailed design space exploration in the SLDE. The designer can explore platform decisions: Processing Elements (PE) allocation, behavior to PE mapping, scheduling and communication refinement. In SLDE, depicted in the bottom of Fig. 2, System Refinement then realizes these decisions in form of Transaction-level Models (TLM). The TLM of the example, illustrated below the specification, is generated based on a mapping decision of A1, A2 on CPU while A5 and A8 on a custom hardware: HW1. After optimizing algorithms and finalizing the platform decisions, the Back-end Synthesis can synthesize the overall design down to the selected hardware/software implementation.

Algo2Spec: Specification Generation Tool

To bridge the gap between ADE and SLDE, we propose Algo2Spec. Algo2Spec takes the Similink algorithm model as an input and synthesizes it to a SpecC SLDL specification representing the algorithm's functionality and original hierarchy. We construct Algo2Spec as a multi-stage process of the front-end synthesizer and the integrator. In the first the front-end synthesizer in turn conducts leaf synthesis (generating computation code for each leaf component), hierarchy synthesis (producing the overall SLDL skeleton) and signal synthesis (connecting behaviors). Afterwards, the integrator combines the output of front-end synthesizer to produce a specification. The following paragraphs outline each step.

Leaf Synthesis. As a first step in the generation process, the front-end synthesizer starts with the leaf synthesis. It works on the smallest unit in the model, which is an atomic block in Simulink (e.g computation, algebraic or logical) as the blocks A1, A3, A4, and A6-A8 in the example. Each leaf block in Simulink will be represented as a SLDL behavior, which is an atomic unit capturing computational load. As SpecC SLDL is an extension over ANSI-C, Ccode is needed for each behavior. To generate this, leaf synthesis iterates through the Simulink model and invokes Simulink Embedded Coder (SEC) as the backend C code generator for each leaf. The result is a set of C files for each Simulink block expressing the computation.

Hierarchy Synthesis. The hierarchy synthesis is responsible for generating an overall SLDL skeleton for the Simulink model, capturing its structural and behavioral hierarchy. For this it creates an empty behavior for each identified leaf, and also creates hierarchical behaviors to represent the Simulink model structure. In our example A2 and A5 are hierarchical behaviors containing the child behaviors A3, A4 and A6, A7, respectively. During this stage, syntactical correctness and model functional validity are both enforced. Single rate models appear as a sequential composition. Multiple single-rate islands are represented as parallel behaviors communicating through channels. However, hierarchy flattening is necessary for multi-rate models to partition blocks running at different rates to different rate control behaviors in the SLDL specification. Scheduling is an important part of hierarchy synthesis, please see Sec. 4.

Signal Synthesis. Simulink uses signals for communicating between blocks by defining that each signal has to have at one simulation time interval the same value at every of its point. Signal synthesis recreates the same connectivity in SLDL communication primitives ensuring communication across behaviors. It mainly generates variables mapped through ports and routed through hierarchical behavior to enable communication. Signal synthesis becomes in multi-rate models, were buffers are needed. Buffers are generally represented as queues in the SLDL.

Integrator. After front-end synthesis, the integrator combines the computation code generated by leaf synthesis and the SLDL skeleton containing hierarchy, communication and scheduling generated by hierarchy/signal synthesis to output the final specification. The integrator localizes global variables and creates clean and well-defined communication interface adhering to the communication structure in original Simulink models. In addition, the integrator also inserts all initialization and termination routines to maintain proper model execution.

In result, all computation related procedures are merged into SLDL behaviors by the integrator. A specification that captures the model hierarchy, execution semantics, signal properties and valid results is generated. The SLDL specification serves as the fundamental element for detailed design space exploration. The SGT eliminates the need for manually writing the specification, thus avoid coding errors and significantly shortens the time to exploration.

Scope. As Simulink offers a wide range of modeling domains (e.g. continues time and discrete) and in order to achieve a feasible solution. The subset supported by Algo2Spec has to be limited. Most importantly, continues time models are out of scope for Algo2Spec. Restricting the scope of considered Simulink semantics for synthesis purpose has been shown effective in earlier approaches [START_REF] Tripakis | Translating discrete-time simulink to lustre[END_REF], which demonstrated tremendous benefits while targeting only a safe subset. For this paper, we target the following components: blocks under discrete and fixed step solver and SEC; special blocks in toolboxes (partially supported depending on configurations); multi-rate systems with limited rate-transition schemes.

Cross-Layer Decisions

With the tight integration, the unified design flow realizes a feedback/decision loop (see Fig. 2) where feedback by the analysis tools in ADE, SGT and SLDE respectively is propagated to the designer on the left-hand side. In result, on the right side, the designer enters new decisions into the flow for optimization and system-level exploration to identify a suitable algorithm / platform combination. Assisted by the multi-level analysis feedback, the designer can identify and eliminate bottlenecks at an appropriate level. The next paragraphs outline the decisions at each level as well as overall decision opportunities.

Algorithm Decisions. The decisions at the first level mostly stem from within the ADE. Through its simulation analysis, the designer improves the algorithm for optimizing functional performance. Examples include algorithm exploration to find the most suitable algorithm for a given task, the configuration or tuning of an algorithm. Functional performance in this context could refer to the detection accuracy of a vision algorithm.

However, algorithm composition also affects the later design. As a structural example, an S-Function block cannot be further decomposed into smaller blocks. Thus, it hinders finer granularity explorations. Higher dimensions and width of signals used between blocks may cause higher traffic if these blocks are mapped to different PEs. An additional degree of freedom is the exposed amount and type of parallelism. Different types of PEs (such as processor, GPU, custom hardware) efficiently operate on different types of parallelism (task-level, datalevel, fine-grained, respectively). If the designer already has a PE type in mind, the algorithms with an appropriate parallelism can be chosen. Overall, algorithm decisions not only alter model functionality, but also impact the system-level explorability of the overall design and preferred PE-type mapping.

Specification Decisions. These decisions affect the generation of the specification in terms of granularity of SLDL blocks, scheduling of blocks and exposed parallelism. The granularity decision determines up to which level the Simulink's structure is exposed in SLDL, and conversely what is treated as a leaf component. At one extreme, the finest granularity exposes each atomic Simulink block as leaf in SLDL. This hinders Simulink to perform block fusion as all blocks are generated separately. Further, it may expose overly simplistic blocks, such as single stage combinatorial logic, to the SLDL. Overall, this may cause unnecessary communication overhead in the SLDL specification without offering impactful mapping alternatives. At the other extreme, the coarsest granularity treats the Simulink top model as one "big" leaf. It gives all cross-block optimization potential to Simulink, however, causes a loss of hierarchy which in turn removes the possibility of heterogeneous exploration. Algo2Spec therefore aims at at a granularity with a threshold balancing block fusion potential and exploration flexibility. In the current version, Algo2Spec relies on the designer to define the granularity (see Fig. 2). A heuristic and automatic decision making for deciding granularity is part of future work.

Simulink and the SLDL differ in execution semantics, which offers opportunities for scheduling exploration. One policy: faithful scheduling emulates the simulation semantics of Simulink. All Simulink blocks are statically scheduled in a sorted dependency list and executed sequentially. In result, all SLDL behaviors will be sequentially executed in the same order. A second scheduling policy: pipelined scheduling can be observed for example in the Simulink HDL Coder generated code. Blocks are executed in a pipeline fashion offering temporal parallelism. If selected, Simulink blocks are then synthesized into a pipelined SLDL model enabling parallelism exploring. For brevity and simplicity, this paper focuses on faithful scheduling.

It has to be noted that granularity and scheduling also affect the exposed parallelism. The desired parallelism depends on the targeted PE class as for example mapping to custom hardware component can benefit from much finer grained parallelism than a processor mapping.

System-Level Decisions. Once the specification is defined, a myriad of system-level decisions are required spanning architecture decisions (PE allocation and behavior mapping), scheduling decisions of behaviors within each PE (static, dynamic-priority, dynamic-FCFS), network decisions (interconnect and communication element allocation), and subsequent communication decisions (selecting interconnect specific communication and synchronization primitives). These decisions are for example discussed in [START_REF] Dömer | System-on-Chip Environment: A SpecC-based Framework for Heterogeneous MPSoC Design[END_REF]. The SLDE realizes these decisions by model refinement. It generates Transaction-Level Models (TLM) at varying levels of abstraction to implement these decisions. The generated TLMs are then used for performance/power/cost analysis driving new system-level design decisions.

Cross Layer Decisions. In addition to the decisions at each level, crosslayer decisions are needed. For example, we have observed in the past the need to change parallelism granularity and type depending on mapping decisions. Hence in result of system exploration, the algorithm definition needs to be changed. We also have experienced the necessity for platform specific algorithm tuning such as converting from floating to fixed point computation, or reducing memory bandwidth of a vision algorithm through parameter compression. Again, with automating the path from algorithm to specification and instant available performance feedback, the designer can easily try out various decision combinations that will yield better overall designs.

Case Study

We demonstrate the flexibility of the unified design flow by exploring a Motion JPEG (M-JPEG) video encoder. We have chosen this application for it is a real-life application that is not too complicated. M-JPEG is a video format that defines each frame of the video feed is compressed as a JPEG image separately, which is like MPEG [START_REF] Gall | MPEG: a video compression standard for multimedia applications[END_REF] but without inter-frame predictive coding. It is primarily used in video-capturing equipment, such as digital cameras and webcams. We start with a Simulink model out of the vision toolbox. The model contains 294 blocks, 28 S-functions, 35 subsystems, 86 inports and 69 outputs. The model contains blocks with up to 8 levels in depth (which we will later simply refer to as depth). For our experiments, the design encodes a 910-frame QVGA (320x240) video stream.

In this case study, the designer performs three exploration steps of granularity identification (algorithm decisions/specification decisions), early estimations and platform explorations (system-level decisions). Based on simulation feedback, a new design iteration starts with new higher-level design decisions. Overall, we show three design iterations.

All iterations draw from the same database of processing element (PE) types. For simplicity, we restrict the exploration to one CPU (ARM7TDMI at 100MHz) that is assisted by up to two custom hardware components (HW1, HW2 at 100MHz). All PEs are connected to one processor bus of type AMBA AHB.

Initial Design Iteration. In the first iteration, the designer selects a coarse granularity which only exposes a minimum decomposition. This may potentially facilitate optimization of the generated computation code, such as block fusion by Simulink Embedded Coder (SEC) and reduce the overall traffic due to fewer components. With the selected granularity, Algo2Spec generates the coarse-grained specification as shown in Fig. 3. It only contains three leaf behaviors, PreProc, BlkProc and MatCon in behavior Encoder_DUT (Design Under Test) together with Stimulus and Monitor consisting the testbench. After specification generation, the SLDE tools for early estimation can be used to identify allocation and mapping candidates. Due to the coarse granularity, not many blocks are available for PE mapping as they are all merged together into a few "super" blocks even though it has a fairly light overall traffic. BlkProc is the most computational and communicaexpensive block. Thus the design is most suitable for SW-only mapping and one with a custom HW component for the most computation intense block BlkProc. Tabl. 1 summarize these explorations. Fig. 5 plots the results of the platform explorations in terms of target execution time (in secs) and PE utilizations (in percentage). The leftmost bar indicates target execution time, while the right bars show PE utilizations. Expl1, the SWonly solution takes nearly 80s where Expl2, is faster with 60s. With dedicated HW for executing the most computational intensive behavior, both CPU and HW1 are load-balanced and the co-design solution offers some performance increase. However, the speedup is not too significant due to the coarse-grained model and limited parallelism. Hence, we start a new iteration for a finer-grained specification to increase mapping options.

Intermediate Design Iteration. A finer granularity with depth 3 (hierarchy levels) is chosen to generate a new specification. Fig. 6 illustrates the simplified fine-grained specification. The fine-grained specification decomposes all three levels of PreProc to 10 sub-behaviors; BlkProc to 4 sub-behaviors; MatCon to 1 sub-behavior (see Fig. 6). Two task-level parallelism within, Spl_Par and ImgP_Par are discovered while decomposing Pre_proc and scheduled in parallel in the generated SLDL specification. The estimation results in Fig. 7 omit two behaviors in ImgP_Par due to their low computation and communication demands. Also, it is inefficient to explore the task-level parallelism in Spl_Par, and ImgP_Par as these behaviors have low computation. Splitting BlkProc potentially introduces more traffic as InProc and OuProc have more data exchange with SubBlk within the original block. Consequently, Tabl. 2 shows selected explorations: Expl3, mapping SubBlk to HW1 and Expl4, mapping SubBlk and Chroma to HW1. The results in Fig. 8 (with Expl1 for reference) show that Expl3 yields a similar performance gain as Expl2 in the previous iteration. Unexpectedly, Expl4 downgrades performance by incurring more traffic. Even though this specification offers more mapping flexibility, it introduces too many oversimplified behaviors such as SplY, SplCb, SplCr and ImgP1/2/3. Hierarchy depth is imbalanced: BlkProc in Fig. 3 has depth of 8 while on the same level, PreProc and MatCon only have depths of 3 and 2. It is undesired to decompose computationally non-intense blocks unnecessarily while the computation heavy BlkProc is insufficiently split. Therefore, in the next iteration a custom granularity selectively splits BlkProc to an even finer granularity to expose potential parallelism without affecting other blocks with overheads.

Final Design Iteration. Fig. 9 shows the custom generated specification which has BlkProc with depths of 5, while PreProc and MatCon remains at level 1. BlkProc is decomposed now through 5 levels to Mot, along with three parallel behaviors: Tran1, Tran2 and Tran2. Fig. 11 shows that, mapping Tran2 does not boost the performance meaningfully as its low computation to communication ratio. Furthermore, Expl8, even though HW2 is load-balance, the overall performance still does not increase much due to additional traffic. Expl5 achieves best performance splitting the two computational heavy blocks PreProc and Mot onto CPU and HW1 without much traffic. Meanwhile, it keeps Tran1 running in parallel with Tran2 and Tran3. Subsequently, Expl5 is selected for final implementation, which is generated by the back-end synthesis. Due to limitation of space, the details of the implementation are not further examined.

Conclusion

In this paper, we presented a unified algorithm and system design flow. We introduced Algo2Spec which closes the specification gap by generating SLDL specifications out of Simulink algorithm models. Automating specification generation eliminates the error tedious manual implementation. Moreover, it enables algorithm designers to explore the platform implications of the chosen algorithms, and empowers a cross-layer decision process.

Fig. 1 .

 1 Fig. 1. Specification Gap

Fig. 2 .

 2 Fig. 2. Unified algorithm-system design flow with feedback/decision loop

Fig. 3 .

 3 Fig. 3. Initial Specification

Fig. 5

 5 shows the result of early estimations of both computation and communication demands on each generated leaf behavior in the specification. Computation expresses the number of C-level operations executed in each leaf behavior. Communication demand shows number of bytes are transferred overall in a leaf behavior.

Fig. 4 .Fig. 5 .

 45 Fig. 4. Initial Early Estimation

Fig. 6 .

 6 Fig. 6. Intermediate Specification

Fig. 7 .Fig. 8 .

 78 Fig. 7. Interm. Early Estimation

Fig. 9 .

 9 Fig. 9. Final Specification

Fig. 10

 10 Fig. 10 presents early estimation for behaviors with meaningful computation or communication. Tran1 has significant computation and low communication, making it a candidate for concurrent execution. This iteration now uses two custom hardware: HW1 and HW2. Tabl. 3 show the explorations. All four explorations have Tran1 mapped on a separated HW1, running concurrently with Tran2. The designer explores with Tran1, Tran2 and Tran3 to run in parallel by adding HW2 (Expl6, Expl7 and Expl8).

Fig. 10 .Fig. 11 .

 1011 Fig. 10. Final Early Estimation

Table 1 .

 1 Initial Explorations

		Expl1 Expl2
	CPU All All others
	HW1	BlkProc

Table 2 .

 2 Intermediate Explorations

	Expl3	Expl4
	CPU All others	All others
	HW1 SubBlk SubBlk, Chroma

Table 3 .

 3 Final Explorations

	Expl5 Expl6 Expl7	Expl8
	CPU All oth. All oth. All oth. All oth.
	HW1 PreProc PreProc PreProc PreProc
	Tran1 Tran1 Tran1	Tran1
	Mot	InProc
	HW2	Tran2 Tran2 Mot, Tran2

We demonstrated the unified flow using an MJPEG video encoder example and highlighted cross-layer design iterations. An improved HW/SW solution was identified yielding 50% performance gain compared to a pure software solution. All explorations are conducted in a few hours which yield a significant improvement on productivity and efficiency.

Acknowledgment: The work presented in this paper is in part supported by the National Science Foundation under Grant No. 1136027.


Frank Sill Torres
email: franksill@ufmg.br

Enhancement of System-Lifetime by Alternating Module Activation

Keywords: Robustness, Redundancy, Sleep Transistor, Modeling, BIST 1

Reliability and robustness have been always important parameters of integrated systems. However, with the emergence of nanotechnologies reliability concerns are arising with an alarming pace. The consequence is an increasing demand of techniques that improve yield as well as lifetime reliability of today's complex integrated systems. It is requested though, that the solutions result in only minimum penalties on power dissipation and system performance. The approach Alternating Module Activation (AMA) offers both extension of system lifetime and low increase of power and delay. The essential contribution of this work is an analysis to which extent this technique can be improved even more. Thereby, components that enable partial concurrent error detection as well as Built-in self-test functionality are included. Further, a flow for comparison of system's lifetime on cell-level is presented. Final results indicate an improvement of the system's lifetime of up to 58 % for designs in which the expected instance lifetime differs by factor 2.

INTRODUCTION

CMOS is still the predominating technology for digital designs with no identifiable concurrence in the near future. Driving forces of this leadership are the high miniaturization capability and the robustness of CMOS. The latter, though, is decreasing with an alarming pace against the background of technologies with sizes at the nanoscale. Such technologies, with device dimensions in the range of a few nanometers, suffer from an increased susceptibility to different kinds of failures during operation [START_REF] Srinivasan | The impact of technology scaling on lifetime reliability[END_REF]. In contrast to previous technology generations, solutions within the manufacturing process are not sufficient anymore to deal with these kinds of issues. Accordingly, reliability concerns are not only an issue of manufacturing anymore, but also have to be considered in all abstraction layers of the design process. Thereby, three main strategies can be identified: (I) design techniques that detect errors [START_REF] Bernardi | A new hybrid fault detection technique for Systems-on-a-Chip[END_REF], (II) techniques that detect and correct errors [START_REF] Mitra | Robust System Design with Built-In Soft-Error Resilience[END_REF] and (III) those techniques that try to avoid or at least prolongate errors [START_REF] Inukai | Variable threshold CMOS (VTCMOS) in series connected circuits[END_REF] [START_REF] Tschanz | Adaptive body bias for reducing impacts of die-to-die and within-die parameter variations on microprocessor frequency and leakage[END_REF]. As those techniques of strategy (I) require another mechanism to cope with the detected error, they do not increase the expected lifetime of the designs as aimed at in this work.

We proposed in previous works [START_REF] Torres | Reliability Enhancement via Sleep Transistors[END_REF] [START_REF] Cornelius | Power-Efficient Application of Sleep Transistors to Enhance the Reliability of Integrated Circuits[END_REF] a design technique that relates to strategy (III) and combines Sleep Transistors with the idea of modular redundancy to extend lifetime reliability of integrated circuits. In this work, we propose how this approach can be combined with techniques of strategy (II) to cope with errors as they can finally still occur.

The remainder of this contribution is organized as follows: section 2 summarizes the initial approach while section 3 presents the proposed extensions of the design technique. The subsequent section 4 introduces an extended flow on cell-level in order to compare lifetime reliability of integrated circuits. The following section 5 presents and discusses simulation results before section 6 concludes this work.

Alternating Module Activation

This section describes the fundamentals of the previously developed approach Alternating Module Activation as well as requirements for the necessary control logic.

Basic Idea

An essential characteristic of power gating with Sleep Transistors [START_REF] Powell | Gated-Vdd: A circuit technique to reduce leakage in deep-submicron cache memories[END_REF] is its ability to dynamically disconnect the power supply during the runtime of integrated systems. Hence, during the disconnected state the gated logic is ideally without any inherent currents and voltages, and thus electromagnetic fields. Furthermore, local temperatures are reduced as there is no switching activity present. It should be noted that these are key parameters for several lifetime decreasing effects, like electromigration [START_REF] Srinivasan | RAMP: A Model for Reliability Aware Microprocessor Design[END_REF], gate-oxide breakdown [START_REF] Stathis | Reliability limits for the gate insulator in cmos technology[END_REF], and negative bias temperature instability [START_REF] Maricau | NBTI model for analogue IC reliability simulation[END_REF], of integrated circuits. Thus, during an idle phase of a gated logic these effects are eliminated or at least strongly reduced. As a consequence, the mean time to failure (MTTF), which is the average time that a system operates until it fails, is prolonged approximately by the time that the design is in the idle phase. This relation is applied by the proposed approach Alternating Module Activation (AMA). Hereby, each gated module (i.e. each logic block) is implemented at least two times (see also Fig. 1). During the runtime though, only one of these instances is active while the others are disconnected from the power supply. Consequently, the resulting ideal mean time to failure MTTFʹ AMA of a module realized with the proposed approach can be expressed by:

= ⋅ AMA min MTTF' MTTF N (1)
where N is the number of redundant instances and MTTF min is the minimum MTTF over all module instances. Equation (3) refers to the ideal case where any additional logic is neglected and the gated modules are completely disconnected from the power supply.

It could be shown in previous works [START_REF] Cornelius | Power-Efficient Application of Sleep Transistors to Enhance the Reliability of Integrated Circuits[END_REF] that there is a moderate increase in dynamic power dissipation of ca. 6 %, while the leakage and area are roughly doubled.

Control circuitry

In order to properly work, additional logic is required to multiplex the results from the currently active instance to the subsequent module. This is implemented by multiplexers that are placed behind the redundant instances as depicted in Fig. 1. Here, a simple 2:1 multiplexer is shown to forward the correct signals from the redundant instances of the module A to the subsequent module B.

Commonly, power gated logic requires additional clock cycles before the logic can be fully operated again (i.e. wake-up time [START_REF] Powell | Gated-Vdd: A circuit technique to reduce leakage in deep-submicron cache memories[END_REF]). Hence, it is not feasible to connect the signals controlling the Sleep Transistors (here /Sleep1 and /Sleep2) also directly to the multiplexers. Instead, a control signal scheme as shown in Fig. 1 should be applied to ensure data consistency. Thereby, it has to be assured that before a transition of the multiplexed outputs both instances are active (/Sleep1 and /Sleep2 are logically '1').

( ) = ⋅ - ⋅ AMA , i i min MTTF'' 1 MTTF with: MTTF=MTTF trans i N p (2)
with p trans is the probability that the instance i is in the transition phase but its output is still not forwarded by the multiplexer.

For a comprehensive investigation, it has to be considered that the lifetime of the system also depends on the MTTF of the multiplexers. The multiplexers though are realized as transmission gates [START_REF] Torres | Reliability Enhancement via Sleep Transistors[END_REF], whereas only one path is active at a time. Thus, the impact of failure mechanisms, like gate-oxide breakdown or electromigration [START_REF]Failure Mechanisms and Models for Semiconductor Devices[END_REF], is also correspondingly smaller. Nevertheless, it is reasonable to apply special design strategies for the multiplexers as well, like transistors with thicker gate oxide and wider wires.

Enhanced Alternating Module Activation

This section proposes extensions of the AMA approach that increase the lifetime in case of faultiness of one of the instances. Beside this, error detection capability and Built-in self-test (BIST) functionality are added.

Partial Concurrent Error Detection

A missing function of the initial version of the Alternating Module Activation approach is error detection capability. Hence, it is proposed to add comparators to each multiplexer. Its function is the verification that all multiplexer's inputs have the same value, and thus, whether all instances of a module produce equal results (comparator C-M in Fig. 2). However, only during the transition phase, i.e. when one instance is disconnected from supply while another is connected (see Fig. 1), more than one instance is active at the same time. This presents a limitation as only during this phase concurrent error detection (CED) is possible. The intention of this partial CED though, is not the identification of transient faults [START_REF] Possamai Bastos | Novel transient-fault detection circuit featuring enhanced bulk built-in current sensor with low-power sleep-mode[END_REF]. In contrast, its purpose is the detection of permanent faults.

It is recommended to modify the transition phase in the way that all instances are connected for a limited time. Thus, the probability of detection of an error can be increased. Considering this change, the mean time to failure MTTFʹ EAMA of a module results to:

( ) = ⋅ - ⋅ EAMA min MTTF' 1 MTTF trans N p ( 3
)
where p trans denotes the probability that the instances are in transition phase and its outputs are not forwarded by the multiplexer. Consequently, the increase of p trans reduces the time between the occurrence of a permanent failure and its detections.

Selective Complete Deactivation Of Instances

One major drawback of the initial version of the AMA approach is the complete function loss if one of the instances fails. Thus, it is proposed to utilize the existence of at least two instances of each module. The basic idea is the complete deactivation of an instance in case of failure, i.e. the control algorithm stops to consider the defective instance. This deactivation can pushed so far that the single instance configuration is reached. Thus, the expected life time of the circuit can be increased by the difference of the mean time to failure of the instances of each module. Considering exclusively the MTTF of the instances of the module the resulting MTTF mod_EAMA can be estimated with:

( ) ( ) ( ) ( ) ( ) ( ) 1 2 1 EAMA N N-1 i i (i-1) 1 MTTF 1 MTTF -MTTF MTTF 1 ... MTTF -MTTF 1 MTTF with: MTTF MTTF trans N trans i N N p p = ⋅ + -⋅ +     = ⋅ - +     = - ⋅ > ∑ (4)
Hence, in case of different mean time to failures of the instances the increase ΔMTTF mod_EAMA results to:

( )

EAMA i i (i-1) 2 MTTF 1 MTTF with: MTTF MTTF . N trans i p = ∆ = - ⋅ > ∑ (5)
These differences of the MTTF result from variations of process parameters, aberrations of layout parameters, on-die temperature distribution, and effects through neighboring blocks.

Built-In Self-Test for Faulty Instance identification

Another missing function of the initial approach is the identification of a faulty instance. Hence, it is proposed to add a memory based Built-In Self-Test (BIST) mode. Therefore, test input and output vectors for each module have to be generated and stored in a memory block whose inputs are multiplexed to the module inputs. Further, the outputs of the memory and the module are connected to comparators (see Fig. 2). Thus, in case of detection of an error by the partial CED the proposed BIST structure can be applied for successive tests of each instance for identification of the faulty one.

3.4

Final Architecture and Control Scheme Fig. 2 shows the final architecture of the extended approach whereas the initial blocks are greyed out. For reasons of lifetime extension both kinds of comparators as well as the memory can be switched off by Sleep Transistors when it is not needed. Fig. 3 depicts the new control structure which is extended by two phases of error detection. As described in subsection 3.1 the partial CED is only active during the transition phase. Further, the design changes to the BIST mode only in case of the detection of an error. During that mode the system has to be halted as no correct functionality can be guaranteed. After detection of a faulty instance it is removed from the list of possible active instances and the system returns to normal operation.

Technique for MTTF Comparison on Cell-Level

This section proposes a new technique on cell-level for the comparison of mean time to failure of integrated designs.

Types of modeling of failure mechanisms

Several models for individual failure mechanisms within integrated circuits can be found in the literature [START_REF] Powell | Gated-Vdd: A circuit technique to reduce leakage in deep-submicron cache memories[END_REF][9] [START_REF]Failure Mechanisms and Models for Semiconductor Devices[END_REF], whereas SPICE simulations are reported as the most accurate approach used by circuit designers. However, the accuracy comes together with major computational efforts and simulation times, which limits the maximum number of elements within an investigation. In contrast, approaches on higher levels decrease drastically the effort in computation, allowing the analysis of considerably more complex design [START_REF] Lorenz | Aging analysis at gate and macro cell level[END_REF] [START_REF] Xiao | A Method of Gate-Level Circuit Reliability Estimation Based on Iterative PTM Model[END_REF]. However, this gain comes with the price of reduced accuracy.

Cell models for MTTF Comparison

The proposed approach for modeling of the meant time to failure of integrated designs is an extension of the in [START_REF] Torres | Reliability Enhancement via Sleep Transistors[END_REF] presented mixed-signal method. In contrast to the solution on SPICE level the new approach applies models on cell-level in which the function of the logic cells deteriorates over time. Thereby, the level of degradation is parameterized for each cell and bases on results from studies on SPICE level [START_REF] Torres | Reliability Enhancement via Sleep Transistors[END_REF]. Further, all cells receive an additional input that defines whether the cell is active or deactivated. This allows different level of degradation depending on the state of connected Sleep Transistors.

RESULTS OF THE SIMULATIONS

In this section, the setup of the test environment is presented before the obtained simulation results are discussed.

Setup of the test environment

The presented simulation results are based on designs from the ISCAS benchmark suite (c1355 and c3450) [START_REF] Xiao | A Method of Gate-Level Circuit Reliability Estimation Based on Iterative PTM Model[END_REF], the ITC99 benchmark suite (b05, b15 and b21) [START_REF] Basto | First results of ITC'99 benchmark circuits[END_REF], and two proprietary designs, i.e. a 32-bit multiplier (mult) and a simple 8-bit MIPSlike processor (MIPS). The applied library consists of 8 standard cells described as VERILOG modules with a hard degradation limit that takes the cell active time into consideration. The levels of cell degradation are based on simulation results obtained from the test environment presented in [START_REF] Cornelius | Power-Efficient Application of Sleep Transistors to Enhance the Reliability of Integrated Circuits[END_REF]. Thereby, all cells were realized in a predictive 16 nm technology [START_REF] Zhao | New generation of Predictive Technology Model for sub-45nm early design exploration[END_REF] and simulated with the same error models as in [START_REF] Cornelius | Power-Efficient Application of Sleep Transistors to Enhance the Reliability of Integrated Circuits[END_REF]. Next, all cells were simulated with different parameters for the error models, and with connected Sleep Transistors in on-and off-mode. Thereby, the values of the parameters were chosen in a manner that for each cell five different MTTF could be defined. The multiplexer are implemented as transmission gates with increased transistor dimensions that elevate the MTTF of these components.

In the current implementation the control circuitry is included in the test environment and not part of the analyzed designs. In future works several robust design strategies shall be analyzed for these block. The probability that an instance is in a transition phase without having its outputs forwarded, defined by frequency and length of a transition, was set to 1 %. Due to random values for degradation all simulations were executed 100 times. Further, the automated duplication of module instances as well as the insertion of Sleep Transistors, multiplexer and comparators is done by a tool specifically written for these tasks.

The number of redundant instances is limited to two as we consider solutions with higher numbers of instances as too costly in terms of area.

5.2

Results and discussion

In a first step it was verified whether the results of the initial AMA approach (see section 2) can be reproduced in the proposed test environment. Therefore, for each design the MTTF of the raw version without any redundant blocks was estimated. Subsequently, those designs were modified according to the AMA approach presented in section 2. Thus, each design was duplicated and complemented with the multiplexer, while the test environment was extended by the related control logic. Further, for both experiments the cell degradation models that lead to the longest MTTF were chosen. At these simulations, a design was considered as defective with the appearance of the first wrong result at the design outputs. The results presented in Fig. 4 show that the improvements of the initial approach could be reproduced whereas the MTTF could be increased by an average of factor 1.98. In the next step the proposed extension of the AMA approach (see section 3) was analyzed. Initially, the designs were simulated with each module realized as single instance and for all five degradation classes of the cells. Next, comparators and a memory based BIST were added while the control logic was extended by error verification. Then, each modified design was simulated five times whereas the cell degradation models of one instance of each module were varied.

The results of this analysis are depicted in Fig. 5. Here, the increase of the mean time to failure of the extended approach compared to the initial one is shown for varying relation between the MTTFs of the instances. The depicted curves show the minimum, average, and maximum improvement of the system's MTTF compared to the initial approach. It follows that for equal distributed MTTFs of the instances the proposed extension leads only to a negligible increase of expected system lifetime (average: 1 %). In contrast, already with one group of instances having a 25 % lower mean time to failure the system's MTTF can be increased in average by 8 %. If one group of the instances has a MTTF this is by factor 2 shorter the improvement increases up

Increase of System's MTTF

Improvement of MTTF through initial AMA approach compared to raw designs to 51 % (average: 50 %). Hence, it could be shown that the presented approach can considerably increase the system lifetime.

It should be noted that these simulations cannot classify the increase of robustness against errors that are not based on temporary degradation but abrupt failures, e.g. based on high temperature peaks, extreme overvoltage due to electro-static discharge, or infant mortality effects.

For this analysis we consider a comparison of the MTTF of raw designs with the extended version of the approach as not conclusive. This is due to fact that the choice for the cell degradation model for the raw versions would be only random.

CONCLUSION

Integrated circuits realized in nanometer technology are continuously more susceptible to severe failure mechanisms. This alarming development necessitates design techniques to improve the lifetime reliability. Hence, the presented work proposes an extension of an approach that combines the ideas of Sleep Transistors and modular redundancy in a beneficial way. Thereby, the approach aims at increased lifetime reliability while the impact on delay and power dissipation is kept to a minimum. Due to proposed extensions of this work it is possible to detect permanent errors. Furthermore, the modifications lead to extension of the expected system's lifetime as faulty instances can be identified and disconnected. In order to compare system lifetime, we also proposed a modeling technique on cell-level. Finally, simulation results show that the proposed improvements of the design approach can extend the system's Mean Time To Failure (MTTF) in average by 52 % if the instance's MTTF differ by factor 2.

Fig. 1 .

 1 Fig.1. The initial AMA approach with two redundant instances, whereas the results of the active instance are forwarded by the subsequent multiplexer, and related control signal scheme

Fig. 2 .

 2 Fig. 2. Structure of Enhanced AMA (blocks of the initial AMA are greyed out)

Fig. 3 .

 3 Fig. 3. Control flow for extended AMA approach, enhanced by an error detection phase during module transition and a BIST mode

Fig. 4 .

 4 Fig. 4. Increase of Mean Time To Failure (MTTF) of designs realized with the initial AMA approach (each module with two instances) compared to the raw versions

Fig. 5 .

 5 Fig. 5. Improvement of Mean Time To Failure (MTTF) of extended approach compared to the initial approach under variation of relation of instance's MTTFs (each module with 2 instances)

Acknowledgements. This work was supported by grants from CNPq, CNPq/DISSE, CAPES, FAPEMIG, and UFMG/PRPq.