Extreme Makeover for EDA Industry Daniel D. Gajski Center for Embedded Computer Systems University of California, Irvine www.cecs.uci.edu/~gajski Introduction With complexities of Systems-on-Chip rising almost daily, the design community has been searching for new methodology that can handle given complexities with increased productivity and decreased times-to-market. The obvious solution that comes to mind is increasing levels of abstraction, or in other words, increasing the size of the basic building blocks. However, it is not clear what these basic blocks should be beyond the obvious processors and memories. Furthermore, if a design consists of SW and HW the modeling language should be based on C since standard processors come only with C compilers. Unfortunately, C language was developed for describing software and not hardware. It is missing basic constructs for expressing hardware concurrency and communication among components. Therefore, we need a language that can be compiled with standard compilers and that is capable of modeling hardware and software on different levels of abstraction including cycle-level accuracy.

Past, Present and Future

Simulation based methodology Simuletable but not synthesizable or verifiable

Arithmetic Algebra < objects, operations> Arithmetic algebra allows creation of expressions and equations

Model Algebra <objects, compositions> Model algebra allows creation of models and model equivalences

Specify-Explore-Refine Methodology Design decisions Model refinement Replacement or re-composition

Each designer decision Several transformations Refinement Each designer decision Several transformations Model refinement

Verification Transformations New model Verify equivalence

Synthesis Estimate metric Evaluate options Design decision

Simulation

System Design Environment

Y-Chart

Finite-State-Machine with Data (Processor-level behavioral model: FSM +DFG)

Processor Architecture (Processor-level structural model: RTL components) Data memory Control inputs Control signals IR Selector Register Cache RF Bus1 Next- state logic or Address generator State register or PC Bus2 Output logic or Program memory ALU    Latch Bus3 SR Signal status Register Datapath Controller Control outputs Datapath outputs

Processor Semantics Objects: Objects: - RTL Components - States • Alus • Multipliers • Registers • RF - Connections • Buses • Wires Composition: - Netlist Objects: - States Transitions Statements Composition: - Statements • Sequential • Parallel - Transitions • Conditional • Unconditional Processor

Processor Synthesis Variable binding Operation Binding Rescheduling Bus Binding Allocation FSM Synthesis Processor RTL Processor D Q Control inputs Next- state logic or Address generator Output Program memory State register PC outputs signals Bus1 Bus2 Selector Register Datapath ALU    Bus3 Signal status Controller Memory RF SR IR Latch Data Op1 Op2 S1 S2 S3 Op2 Op3 Op4 Op6 Op1 Op5 Op1 Op2 Op3 FSMD model

Program-State Machine (System-level behavioral model: UML + C)

(System-level structural model: system components) System Architecture (System-level structural model: system components)

System (Transaction-Level) Semantics Objects: - Behaviors - Channels Composition: - Hierarchy - Order • Sequential • Parallel • Piped • States - Transitions • TI • TOC, TOS, ... - Synchronization Objects: - Behaviors - Channels Composition: - Hierarchy - Order • Sequential • Parallel • Piped • States - Transitions • TI • TOC, TOS, ... - Synchronization Objects: - Components • Proc • IP • Memories • IF - Connections • Buses • Wires Composition: (same as in Behavior Model) System

System Synthesis Scheduling Behavior Binding Channel Binding Allocation IF Synthesis Profiling Refinement System Memory µProcessor Interface Comp. IP Bus Custom HW System architecture PSM model Proc

SCE2 3.3 Synthesis Engine Decision User Interface (DUI) Validation User Interface (VUI) Capture Profiling Specification model Profiling data Sys. Comp IPs Arch. synthesis Design decisions Arch. refinement Select Partition Estimation Architecture model Compile Map Check Estimation results Schedule Simulate Buses Protocols Comm. synthesis Insert Verify Design decisions Comm. refinement 3.3 Synthesis Engine The synthesis engine includes synthesis tools for architecture, communication and implementation. All or any number of synthesis tools can be included. For example, if the architecture is fixed, such as in a platform design, the architecture synthesis tool can be omitted. Similarly, if only a standard bus is used, the communication synthesis is not required. Furthermore, if no custom hardware is needed, the implementation synthesis can be substantially simplified. Assemble Estimation Communication model Estimation results RTL Comp. RTOS CA synthesis Design decisions CA refinement Estimation results Estimation Implementation model Comm. Libraries Commercial Tools

Source: J. Peng, PHD Thesis Some Results Experiment on GSM Vocoder design (10K lines of code) Conclusion Productivity gain >2,000X for industrial strength designs Compare 9-12 months (manual refinement) vs. 50+4 minutes (user decisions + automatic refinement) Enables extensive design exploration (60/day) CommImpl Automated User / Refine Manual Modified lines SpecArch ArchComm 3,275 914 30 mins / <2 mins 5~6 mons 5 mins/ <0.5 min 3~4 mons. 6,146 15 mins / <1 min 1~2 mons. Refinement Effort Total 50 mins / <4 mins 9~12 mons 10,355 Results for the different vocoder models are shown here, from system specification model to implementation model. The tables list the time needed for the simulation, the number of lines of code for each model and the refinement effort. To validate the models, we performed simulations at all levels. The simulation performance at different levels for the vocoder are shown in the graph. As we move down in the level of abstraction, more timing information is added, increasing the accuracy of the simulation results. However, simulation time increases exponentially with lower levels of abstraction. As the results show, moving to higher levels of abstraction enables more rapid design space exploration. Through the intermediate models, valuable feedback about critical computation synthesis aspects can be obtained early and quickly. As the number of lines of code for different models suggests, more lines of code are added to the model with lower level of abstraction. Reflecting the additional complexity needed to model the implementation detail introduced with each step. The refinement effort table demonstrates that by using the automated system level refinement process, large productivity gains of 2000x or more can be achieved for the vocoder project. Source: J. Peng, PHD Thesis

Source: J. Peng, PHD Thesis Some Results Simulation Speed & Code size Refinement Effort Results for the JPEG encoder models in SpecC are shown here from system specification model to implementation model. The graphs shows the time needed for the simulation and the number of lines of code for each model for encoding of a 116x96 black-and-white image. To validate the models, we performed simulations at all levels. As we move down in the level of abstraction, more timing information is added, increasing the accuracy of the simulation results. However, simulation time increases exponentially with lower levels of abstraction. As the results show, moving to higher levels of abstraction enables more rapid design space exploration. Through the intermediate multiprocessing model, valuable feedback about critical computation synthesis aspects can be obtained early and quickly. As the number of lines of code suggests, refinement between models is minimal and is limited to the additional complexity needed to model the implementation detail introduced with each step. The refinement effort table shows that automated system level refinement process can achieve 2000 times productivity gains comparing manual refinement process in JPEG project. CommImpl Automated User / Refine Manual Modified lines SpecArch ArchComm 751 492 20 mins / <1 mins 3~4 mons 3 mins/ <0.5 min 1~2 mons. 1,278 5 mins / <0.5 min ~1 mons. Refinement Effort Total 28 mins <2mins 5~7 mons 2,521 Compare 5-7months (manual refinement) vs. 28 minutes (user decisions) + 2 minutes (automatic refinement) Source: J. Peng, PHD Thesis

Conclusions Extreme makeover is necessary for a new paradigm, where SW = HW = SOC = Embedded Systems Simulation based chaos is not acceptable Design methodology is based on scientific principles Model algebra is enabling technology for System design System modeling and simulation System verification System synthesis Formalism introduces simplicity that allows Automatic model generation (No need for languages) Exploration and synthesis (Simplifies design algorithms) Equivalence verification (Guarantees equivalence) 4 Conclusions In conclusion, the SpecC language with the supporting SpecC methodology is a necessary step in the new era of system design in which there is no difference between HW and SW, or between Systems-on-Chip (SoCs) and embedded systems in any electronic product. The SpecC methodology enables e-design since parts of the specification and implementation can be outsourced and transmitted electronically to any place in the world. The models in the databases and the exploration engine are needed for IP trading. Also, the SpecC methodology allows SW/HW co-design in which software is converted to HW, and vice versa, in matter of days instead of months. Product derivatives or mass customization (product-on-demand, POD) are possible with simple changes in the specification or iteration on design decisions. Without the SpecC methodology, the designers will remain the prisoners of the past, while adaptation of SpecC methodology will free designers from mundane tasks, like model writing and debugging, and turn them into creators of new exciting systems and products. References [1] D. Gajski, J. Zhu, R. Dömer, A. Gerstlauer, S. Zhao, SpecC: Specification Language and Methodology, Kluwer Academic Publishers, Boston, MA, ISBN 0-7923-7822-9, March 2000.