Hardware/Software Co-Design Models And Reconfigurability Languages

3m ago
550.02 KB
30 Pages
Last View : 5d ago
Last Download : 3m ago
Upload by : Kelvin Chao

Hardware/Software Co-Design Reconfigurability FPGA Models and Architectures Models and Languages HDL Embedded Systems Design Handel C C UML System C Spec C SpecCharts Micaela Serra 0

What is Hardware / Software Co-Design? Cooperative design of hardware and software components high level system description Unification of separate hardware and software paths CODESIGN TOOLS SW HW 10011 0101 VHDL COMPILER Free movement of functionality between if (x 0) a 1; hardware and software during C code design exploration HW SYNTHESIS ASIC/ FPGA PROM µP Attempt to utilize the “synergy” between hardware and software Micaela Serra 1

What is an Embedded System? Any item including a programmable device, not intended to be general purpose, with many interface units to measure, control, manipulate the external environment FPGA/ ASIC A/D & D/A conversion SOFTWARE MEMORY CPU ACTUATORS SENSORS EXTERNAL ENVIRONMENT DIAGNOSTICS HUMAN INTERFACE Micaela Serra 2

Applications Very diverse applications Very diverse domains What are the common characteristics? Ferrari Testarossa Micaela Serra 3

Embedded (Mechatronics) Systems Example: car transmission Microprocessor observing and controlling a car’s automatic transmission ¾ observe engine rpm, manifold pressure ¾ control shifter, engine throttle real time & fault tolerance requirements in a closed-loop control interface with a larger mechanical system (“embedded”) software requirement Micaela Serra 4

Design issues Cost I/O capability many options Size small 8-bit often acceptable Power consumption Portable or not On-chip memory small RAM, large ROM Performance not critical (except video games) Software migrating to high level languages constrained by RAM size Development tools critical new wave? Reliability portability and remote use Robustness Micaela Serra 5

A block diagram of a microwave oven EMBEDDED PROCESSOR CHIP Processor RAM ROM Bus Input Interface Input keys Door open Output Interface Magnetron Fan Displays Light Speaker Micaela Serra 6

System Hardware/Software Co-Design Hardware Functionality System Specifications Hardware Architecture Integrated Modelling Software Requirements System Integration Software Design & Test incremental evaluation Micaela Serra 7

What are the Goals of Co-Design? Integrating the Software and Hardware processes Requirements Incremental evaluation of process Unified design environment Design Testing Micaela Serra 8

What are the Challenges in Co-Design? HW/SW split decided early, on ad hoc basis Ability to explore HW/SW trade-offs is restricted Different cultures hamper integration Cost increases and schedule over-runs Micaela Serra 9

What are the Co-Design Research Areas? (1) Co-specification How to model the system? (2) Partitioning What functions go in hardware versus software? (3) Co-synthesis Generate HW/SW components Create HW/SW communication (4) Co-simulation Simulate HW/SW components interacting in real time Micaela Serra 10

Modelling What is the best methodology for specifying HW/SW system? ¾ ¾ ¾ ¾ a high-level functional / algorithmic spec? HW-type language (VHDL, HW-C) or SW-type (C, C )? formal spec language? (provably correct) same/different methods for HW vs. SW specs? (avoid too early binding) Internal Representation (Co-modelling) Micaela Serra 11

Elevator Controller “If the elevator is stationary and the floor requested is equal to the current floor, then the elevator remains idle. If the elevator is stationary and the floor requested is less than the current floor, then lower the elevator to the requested floor. If the elevator is stationary and the floor requested is greater than the current floor, then raise the elevator to the requested floor” req floor curr floor loop if (req floor curr floor) then direction : idle; elseif (req floor curr floor) then direction : down; elseif (req floor curr floor) then direction : up; end if; end loop; req floor curr floor req floor curr floor down req floor curr floor req floor curr floor idle req floor curr floor req floor curr floor req floor curr floor up req floor curr floor Micaela Serra 12

Partitioning How to divide specified functions between HW & SW? ¾ based on functional spec constraints (timing, cost, size, power) ¾ primarily manual so far; want to automate ¾ generic specs, use heuristics or interactive guidance (with quick evaluation) to divide Approaches ¾ start with all HW, extract functions to move to SW, stop when performance constraints are violated ¾ start with all SW, extract performance critical portions Criteria ¾ For system tasks: Does task interact closely with the O.S? S/W Does task interact closely with external signals? H/W ¾ For remaining tasks: cost and speed. Efficiency of a system is directly related to how the functionality in H/W or S/W is allocated Micaela Serra 13

Co-synthesis and Co-simulation Generating the HW & SW components ¾ HW synthesis built on existing CAD tools ¾ generate HW / SW interprocess communication ¾ schedule SW processes to meet timing constraints (static vs. dynamic) H/W \ S/W Integration ¾ SW and HW operate as separate processes and communicate through suitable IPC (inter-process communication) mechanisms (e.g. Unix sockets) Co-simulation: evaluating the synthesized design ¾ simulate SW & HW components interacting in real time ¾ for design / constraint verification, performance estimation ¾ for feedback to partitioning step Micaela Serra 14

Hardware/Software Co-Design Process System Specification ¾ Feedback from cosimulation to partitioning System Partitioning ¾ Interface design As partition changes so must the interface between hardware and software Co-Synthesis Software Interface Hardware System Integration Co- Simulation ¾ Implicit in the process is a unified system representation that can move to a hardware, software, and interface representation Micaela Serra 15

What is the hardest task? Interface Development Interface Host System Application FPGA Operating System Software Interface Controller PCI Bus PCI Interface Device Driver Experiment Hardware Interface Controller Micaela Serra 16

Multidisciplinary Topic Marketing study market needs determine requirements common English language Software Engineer design the code Manufacturing Engineer dimensions of objects layout, location, etc Design Architect New specifications, behavior product Testing Engineer operating range develop test strategies environment checks specifications, architecture e.g., setup time CAD engineer develop tools Design Engineer Design Technician design of functional blocks select technology interconnection between blocks actual hardware realization e.g., schematic block implementation gate/transistor Micaela Serra 17

Some Observations on Embedded Systems Embedded system's behavior is defined by its interaction with its environment CPU is only a specialized part of the system The functionality provided is specific to the application One does not design an embedded computer Î one designs an embedded system Often there is dedicated software / OS (customizable) Often it replaces electromechanical component Possibly no keyboard Interdisciplinary design area Micaela Serra 18

System Types Data-dominated Control-dominated ¾ Transform input stream into output stream ¾ Reactive real-time stimulus/response ¾ Heavy digital signal processing ¾ Often modeled with state transition diagrams ÎAutomatic Teller Machine (ATM) ¾ Often modeled using dataflow diagrams Î Cell Phone But how do we describe these systems? Micaela Serra 19

Typical Characteristics of Embedded Systems - Functionalities State Transitions ¾ Intrinsically state-based ¾ Constant transitions from one mode/state to another Behavioral Hierarchy ¾ Functionality is more easily conceptualized as behavior Behavioral Completion ¾ Finite activities may not terminate solely by external events but continue until behavior completion ¾ May need to initiate a new activity at time of completion Concurrency ¾ Both Task-level and Statement-level concurrency Exceptions ¾ Certain events require an instantaneous response ¾ Interrupt handling is crucial Complex algorithms ¾ Usually with complex programming constructs Complex Users Interfaces ¾ Multiple menus & options (e.g. navigational maps for GPS) Micaela Serra 20

Typical Characteristics of Embedded Systems – Timing and Costs Real Time ¾ Correctness of computation depends on the time it is delivered ¾ Failure to meet deadlines might create safety issues or simply unhappy customers ¾ Mostly reactive computation – it executes as a response to external events Manufacturing Costs ¾ Crucial for marketing ¾ Microprocessor, flash memory, I/O, sensors Power ¾ Battery life! ¾ Heat dissipation! ¾ Peaks of use! Multirate ¾ Several real time activities at the same time (e.g. audio and video portions in multimedia) Micaela Serra 21

Typical Embedded Systems Functional Requirements Control laws (e.g. PID control, fuzzy control) Sequencing control (e.g. FSMs, mode changes, switching between control laws) Signal processing (e.g. voice, video) Fault response (e.g. detection, reconfiguration) Application-specific user interface device (e.g. buttons, bells, lights) Micaela Serra 22

Typical Embedded Systems Nonfunctional Requirements Performance Physical size and weight Cost Purpose Usability Power consumption Micaela Serra 23

Development and Debugging Target System 9cross-compilers 9testbench hardware 9testbench software Processor core Internal memory Serial I/O ports Parallel I/O ports Counter/Timer A-to-D conversion D-to-A conversion Host System Micaela Serra 24

Questions in Designs? How do we design for upgradeability? How much hardware do we really need? Does it really work? Limited observability and controllability Complex testing How do we meet deadlines? How do we minimize power consumption? Restricted development environment Micaela Serra 25

Models & Languages Pure Modelling Systems set of functional objects Pure Implementation Languages methods for composing objects compiled into machine code configuration files A model provides an abstract view of: its functionality its characteristics how the system works simulation for testing and verification Micaela Serra 26

Characteristics of Models Formal Comprehensible contains no ambiguity designers can understand it Flexible To be useful a model must be: easy to modify its functionality Complete describes the entire system Natural aids rather than impedes the design Micaela Serra 27

Model Taxonomy structure-oriented heterogeneous block diagram; schematic control/ dataflow graphs transition (Mealy) hierarchical concurrent finite state machines state (Moore) entity relationship program state machine activity-oriented state-oriented finite state machines data-oriented Petri nets dataflow graphs flow charts Micaela Serra 28

Acknowledgements “Computers as Components” by W. Wolf, Morgan Kaufmann Pub. “Specification and Design of Embedded Systems” by D. Gajski, F. Vahid, S. Narayan, J. Gong, Prentice Hall. “Embedded System Design: A Unified Hardware/Software Introduction” by F. Vahid and T. Givargis, John Wiley & Sons. “Embedded System Design Issues (the Rest of the Story)” by P. Koopman, CMU Micaela Serra 29

Hardware/Software Co-Design Process ¾Feedback from co-simulation to partitioning ¾Interface design As partition changes so must the interface between hardware and software ¾Implicit in the process is a unified system representation that can move to a hardware, software, and interface representation System Specification System Partitioning Co .

Related Documents:


Cisco MDS 9000 Family Hardware and NX-OS Release 5.x Supported Software 1-2 Cisco MDS 9000 Family Hardware and NX-OS Release 4.2x Supported Software 1-8 Cisco MDS 9000 Family Hardware and NX-OS Release 4.1x Supported Software 1-15 Cisco MDS 9000 Family Hardware

using different object models and document the component interfaces. A range of different models may be produced during an object-oriented design process. These include static models (class models, generalization models, association models) and dynamic models (sequence models, state machine models).

by software. Commodity hardware devices, such as Mel-lanox NICs and P4 Switches, support both putting a hardware counter to every flow and sampling the hardware traffic to software. The cost of using hardware counters for flow rate measurement is very high (more discussion in Section2). If sampling a portion of the hardware traffic to .

Hardware, of course, offers much greater speed than a software implementation, but one must consider the increase in development time inherent in creating a hardware design. Most software designers are familiar with C, but in order to develop a hardware system, one must either learn a hardware design language such

Quasi-poisson models Negative-binomial models 5 Excess zeros Zero-inflated models Hurdle models Example 6 Wrapup 2/74 Generalized linear models Generalized linear models We have used generalized linear models (glm()) in two contexts so far: Loglinear models the outcome variable is thevector of frequencies y in a table

Lecture 12 Nicholas Christian BIOST 2094 Spring 2011. GEE Mixed Models Frailty Models Outline 1.GEE Models 2.Mixed Models 3.Frailty Models 2 of 20. GEE Mixed Models Frailty Models Generalized Estimating Equations Population-average or marginal model, provides a regression approach for . Frailty models a

Introduction 1 Part I Ancient Greek Criticism 7 Classical Literary Criticism: Intellectual and Political Backgrounds 9 1 Plato (428–ca. 347 bc)19 2 Aristotle (384–322 bc)41 Part II The Traditions of Rhetoric 63 3 Greek Rhetoric 65 Protagoras, Gorgias, Antiphon, Lysias, Isocrates, Plato, Aristotle 4 The Hellenistic Period and Roman Rhetoric 80 Rhetorica, Cicero, Quintilian Part III Greek .