Design for test & debug in hardware/software systems

System Architecture Architecture Refinement Hardware Synthesis Detailed System Architecture Synthesis Communication Synthesis Software Synthesis Hardware & Software Components Hardware/Software Integration System Implementation Figure 2.2 Hardware/software co-design flow 13 A concise description of the subsequent steps in the hardware/software co-design flow is presented next. A more detailed description will be provided in the sections 2.3. 1 through 2.3. 6. I. The first step is to gather the system requirements. Usually, the system requirements are described informally using natural language. The resulting requirements document states the requirements on the system behavior and the environment in which the system should operate. 2. During system specification, the functional behavior of the system is captured into a conceptual, formal model. Usually, a hierarchical model of the system is created in which the system's functional behavior is decomposed into a number of parallel, communicating processes. The system specification is described using a formal specification language. The system specification is validated and verified using simulation and formal verification techniques. In most literature on co-design is stated that the system specification should not contain an implicit or explicit architectural model. The system specification should model the functional system behavior, independent of the implementation architecture. However, the organization of the system specification often already implies an implicit architectural model, because the same organization is used in the system implementation. A priori knowledge on the physical system architecture, like distributed processing nodes using a specific communication architecture (e.g. a shared bus), or dictated hardware and software 14 2. Hardware/Software Co-Design components, should already be reflected in the organization (i.e. communication mechanisms and decomposition) of the system specification [vdPV97]. The transition from behavior specification to hardware/software architecture is facilitated if the organization of the specification corresponds directly to the organization of the system architecture: this allows one-to-one mapping of objects in the specification to hardware or software components. 3. In the architecture exploration phase, numerous alternative hardware/software architectures are explored to find a system architecture that satisfies constraints like performance and costs. Exploration of the design space is achieved by defining a number of system architectures. A system architecture is a set of hardware and software components, each component implementing a part of the functional specification. The physical constraints like power consumption, silicon area, memory size, and performance of the hardware and software components are specified. The quality of the alternative system architectures is estimated by considering these constraints. The optimal system architecture is selected and this selected architecture is detailed in the subsequent design steps. Architecture exploration is one of the key issues in the current research on hardware/software co-design. 4. During architecture refinement, the system architecture is refined by adding more details on the implementation of hardware components, software components, and communication interfaces. The refined architecture describes the system's processors, memories, and buses. Co-simulation is used to verify whether the refined description is equivalent to the initial system specification. The result of architecture refinement is a system-level description, providing high-level, behavioral descriptions of the hardware components, the software components, and their communication interfaces. 5. Synthesis consists of three parallel activities: hardware synthesis, software synthesis, and communication synthesis. The task of synthesis is to convert an abstract, behavioral description into a description containing detailed implementation information. Hardware synthesis of custom components like ASICs consists of high-level synthesis and logic synthesis. High-level synthesis converts a behavioral-level hardware description into a structure of components at the register-transfer level (RTL) like ALUs and registers. Logic synthesis converts the RTL components into gate-level descriptions. Software synthesis determines the scheduling of software processes and inclusion of a real-time kernel or an operating system. In general, software synthesis converts a behavioral description into a traditional software program compilable by traditional compilers. Communication synthesis generates the communication interfaces between hardware and software components. Hardware components, software components and their communication interfaces can be co-simulated at various levels of abstraction. When synthesis and co-simulation is completed, the physical hardware design is done. The gate-level descriptions of custom hardware components are converted into switch-level descriptions and layout data for FPGA or custom ASICs is generated using design tools for placement and routing. The automatic synthesis of hardware, software and communication interfaces is a key issue in the current research on hardware/software co-design. 6. During system integration, all the hardware and software components are integrated and the final system implementation or a prototype implementation is obtained. Testing is 2.3 Hardware/Software Co-Design 15 used to check whether the integrated system is a correct implementation of the system specification. The co-design flow is based upon the principle of stepwise refinement. Initially, a high-level behavioral model of the system is created. In each subsequent design step, more implementation details are added and a more refined description of the system is obtained. In each design phase, the designer focuses on a different abstraction level. During system specification, the designer concentrates on the completeness and correctness of the functional system behavior. When defining the hardware/software architecture, the designer focuses on system performance and communication protocols between hardware and software components. During synthesis, the designer proceeds from behavioral-level descriptions (behavioral-level VHDL, C code) to lower level descriptions (register-transfer level and gate-level VHDL, assembly code and object code). During physical hardware design, the designer concentrates on detailed timing and electrical characteristics. In the following sections, the six steps in hardware/software co-design are described in detail. 2.3. 1 System Requirements System requirements are requirements on the system's functional behavior, requirements on the environment in which the system has to operate, and non-functional system requirements. The system requirements are gathered and stated in the requirements document. Functional system requirements define the functional behavior of the system. Often the behavior is described as sequences of input stimuli and the subsequent responses of the system. Requirements on the system environment define the objects in the system environment that interact with the system. Non-functional requirements are general requirements or implementation requirements, like performance, reliability or a prescribed system architecture. The process of defining the system requirements is still a very amorphous and ad hoc process in most co-design methods. An exception is the SHE method [ vdPV97], which particularly emphasizes requirements capture and system specification. 2.3. 2 System Specification During system specification, the functional behavior of the system is defined. A conceptual model is created to capture the system's functional behavior. The conceptual model is a hierarchical model, using functional decomposition to handle complexity. Besides hierarchy, the conceptual model concentrates on essential characteristics of embedded, real-time systems like concurrency, communication, synchronization, states and state transitions. The system specification forms the basis for the subsequent design phases. A correct, complete and consistent specification is therefore a necessity. Unfortunately, system specification does not receive as much attention as subsequent implementation stages in the design flow. Consequently, many functional, conceptual errors are not detected until late in the design process or even during integration. However, design errors are far more difficult and more expensive to correct in the late stages of system design. System specification therefore should be one of the basic ingredients of 16 2. Hardware/Software Co-Design hardware/software co-design. The goal of the system specification is to unambiguously define the system's functional behavior, resulting in a formal description of the system that can be validated and verified. System specification consists of three tasks: selecting an appropriate modeling technique and description language, specifying the system using the modeling technique and description language, and finally validating and verifying the model. Usually the modeling and description, and the validation and verification tasks must be iterated several times before a complete, correct and consistent functional system specification is obtained. There are many modeling techniques to capture functional behavior. Most commonly used in current co-design projects are: • Finite-State Machine (FSM) model A system can be modeled as a hierarchical set of concurrent, communicating FSMs. In the basic model, the communication between FSMs is asynchronous communication, and the concurrent FSMs proceed synchronously in lock step. Various extensions to this basic FSM model have been proposed. The FSM model is very useful for modeling control-oriented systems that do not require complex data operations. • Communicating Sequential Processes (CSP)