with the MASIC Methodology
Abhijit Kumar Deb
Doctoral Thesis
Stockholm, Sweden 2004
Johnny Öberg An Adaptable Environment for Improved High-level Synthesis, 1996.
Bengt Oelmann Design and Performance Evaluation of Asynchrounus Micropipline Circuits for Digital Radio, 1996.
Henrik Olson ASIC Implementable Synchronization and Detection Methods for Direct Sequence Spread Spectrum Wideband Radio Receivers, 1997.
Mattias O'Nils Hardware/Software Partitioning of Embedded Computer Systems,1996.
Daniel Kerek Design of A Wideband Direct Sequence Spread Spectrum Radio Transceiver ASIC, 1999.
Bengt Svantesson Dynamic Process Management in SDL to VHDL Synthesis, 2000.
Johnny Holmberg On Design and Analysis of LDI and LDD Lattice Filters, 2000.
Bingxin Li Design of Sigma Delta Modulators for Digital Wireless Communications, 2001.
Chuansu Chen Reusable Macro Based Synthesis for Digital ASIC Design, 2002.
Li Li Noise Analysis of Mixers for RF Receivers, 2002.
Tomas Bengtsson Boolean Decomposition in Combinational Logic Synthesis, 2003.
Meigen Shen Chip and Package Co-Design for Mixed-Signal Systems: SoC versus SoP, 2004.
Jimson Mathew Design and Evaluation of Fault Tolerant VLSI Architectures, 2004.
Petra Färm Advanced Algorithms for Logic Synthesis, 2004.
René Krenz Graph Dominators in Logic Synthesis and Verification, 2004.
Andrés Martinelli Advanced Algorithms for Boolean Decomposition, 2004.
Tarvo Raudvere Verification of Local Design Refinements in a System Design Methodology, 2004.
Doctoral Theses:
Tawfik Lazraq Design Techniques and Structures for ATM Switches, 1995.
Bengt Jonsson Switched-Current Circuits: from Building Blocks to Mixed Analog-Digital Systems, 1999.
Johnny Öberg ProGram: A Grammar-Based Method for Specification and Hardware Synthesis of Communication Protocols, 1999.
Mattias O'Nils Specification, Synthesis and Validation of Hardware/Software Interfaces, 1999.
Peeter Ellervee High-Level Synthesis of Control and Memory Intensive Applications, 2000.
Henrik Olson Algorithm-to-Architecture Refinement for Digital Baseband Radio Receivers, 2000.
Bengt Oelmann Asynchronous and Mixed Synchronous/Asynchronous Design Techniques for Low Power, 2000.
Yonghong Gao Architecture and Implementation of Comb Filters and Digital Modulators for Oversupplying A/D and D/A Converters, 2001.
Lirong Zheng Design, Analysis and Integration of Mixed-Signal Systems for Signal and Power Integrity, 2001.
Per Bjuréus High-Level Modeling and Evaluation of Embedded Real-Time Systems, 2002.
Imed Ben Dhaou Low Power Design Techniques for Deep Submicron Technology with Application to Wireless Transceiver Design, 2002.
Ingo Sander System Modeling and Design Refinement in ForSyDe, 2003.
Andreas Göthenberg Modeling and Analysis of Wideband Sigma-Delta Noise Shapers, 2003.
Dinesh Pamunuwa Modeling and Analysis of Interconnects for Deep Submicron Systems-on-Chip, 2003.
Bingxin Li Design of Multi-bit Sigma-Delta Modulators for Digital Wi reless Communications, 2003.
Li Li Modeling, Analysis and Design of RF Mixed-Signal Mixer for Wireless Communication, 2004
with the MASIC Methodology
Abhijit Kumar Deb
Stockholm 2004
Laboratory of Electronics and Computer Systems Department of Microelectronics and Information Technology
Royal Institute of Technology, Stockholm, Sweden
Thesis submitted to the Royal Institute of Technology in partial fulfillment
of the requirements for the degree of Doctor of Technology
ii TRITA-IMIT-LECS AVH 04:10
ISSN 1651-4076
ISRN KTH/IMIT/LECS/AVH-04/10--SE
Copyright © Abhijit K. Deb, September 2004
Royal Institute of Technology
Department of Microelectronics and Information Technology Laboratory of Electronics and Computer Systems
Isafjordsgatan 39
S-164 40 Kista, Stockholm, Sweden
iii
The difficulties of system design are persistently increasing due to the integration of more functionality on a system, time-to-market pressure, productivity gap, and performance requirements. To address the system design problems, design methodologies build system models at higher abstraction level. However, the design task to map an abstract functional model on a system architecture is nontrivial because the architecture contains a wide variety of system components and interconnection topology, and a given functionality can be realized in various ways depending on cost-performance tradeoffs. Therefore, a system design methodology must provide adequate design steps to map the abstract functionality on a detailed architecture.
MASIC—Maths to ASIC—is a system design methodology targeting DSP applications. In MASIC, we begin with a functional model of the system. Next, the architectural decisions are captured to map the functionality on the system architecture. We present a systematic approach to classify the architectural decisions in two categories: system level decisions (SLDs) and implementation level decisions (ILDs). As a result of this categorization, we only need to consider a subset of the decisions at once. To capture these decisions in an abstract way, we present three transaction level models (TLMs) in the context of DSP systems.
These TLMs capture the design decisions using abstract transactions where timing is modeled only to describe the major synchronization events. As a result the functionality can be mapped to the system architecture without meticulous details.
Also, the artifacts of the design decisions in terms of delay can be simulated quickly. Thus the MASIC approach saves both modeling and simulation time. It also facilitates the reuse of predesigned hardware and software components.
To capture and inject the architectural decisions efficiently, we present the grammar based language of MASIC. This language effectively helps us to implement the steps pertaining to the methodology. A Petri net based simulation technique is developed, which avoids the need to compile the MASIC description to VHDL for the sake of simulation. We also present a divide and conquer based approach to verify the MASIC model of a system.
Keywords: System design methodology, Signal processing systems, Design
decision, Communication, Computation, Model development, Transaction level
model, System design language, Grammar, MASIC.
v
vii
I would like to take the opportunity to express my sincere gratitude to my academic advisors, Dr. Johnny Öberg and Prof. Axel Jantsch for their support and encouragement over the last couple of years. I always felt myself lucky to have them as my academic advisors.
Dr. J. Öberg has been deeply involved with this PhD project since its commencement, and helped me in many different ways. His ingenious ideas toward the improvement of the project, invaluable suggestions with the grammar based language used in this project, and moral support have been the constant source of motivation throughout my PhD studies.
Prof. A. Jantsch has played the important part in introducing and explaining to me the role of different models of computation for modeling concurrency and time in a system model. No research project can keep pace with the rapidly evolving technology without meticulous study of contemporary research activities. He has always inspired me to read more and more research papers, and instigated me to work more by setting a high target.
I am especially thankful to Prof. Hannu Tenhunen who gave me the opportunity to start with this PhD project. Without him I would not even be at KTH and my work and contributions, whatever they are worth, would be very different, most likely less interesting. I am also very much thankful to Dr. A. Hemani for his genuine support and supervision during the early phase of this project. He made it possible for me to make a quick start with the project.
My colleagues and fellow PhD students have helped me through many mind-boggling discussions and numerous acts of friendship. In particular, I am thankful to Ingo Sander for many priceless discussions on how to write a technical paper; to Steffen Albrecht for being a real friend; to Dinesh Pamunuwa for joining and equally “giving-miss” to too many coffee breaks; to Andreas Göthenberg for all the fuzzy discussions; and to Wim Michielsen for all his “creative sketches” on my white board.
During the course of this work, many others in this lab have extended their helping
hand. In particular, I would like to acknowledge the sincere support in many
different ways that I have got from Dr. Elena Dubrova and Dr. Li-Rong Zheng.
viii
Margreth Hellberg, who helped me in various ways – starting from getting an accommodation in Stockholm, to several administrative helps.
This work has been funded by the Swedish Foundation for Strategic Research – SSF, Intelect, DOCCS, and KTH.
PhD studies cannot go on without special sacrifices of the family members, and this is no exception. Finally, I would like to acknowledge my biggest debt to my dear parents for their constant support and encouragement, and to my caring wife for her love and affection. I deprived her of many weekends and evenings while chasing for different paper submission deadlines.
Stockholm, September 2004
Abhijit K. Deb
ix
Abstract ……….………….……… .. iii
Acknowledgements ……….. vii
1. Introduction... 1
1.1 Thesis Background... 1
1.1.1 Historical Perspective... 1
1.1.2 Barriers to Moore’s Law ... 3
1.1.3 Systems and Models... 4
1.1.4 System Level Design... 6
1.2 Motivation ... 8
1.3 Key Concepts of the MASIC Methodology ... 11
1.3.1 Language Support and Validation Technique... 12
1.4 Publications ... 13
1.5 Author’s Contribution ... 15
1.6 Organization of the Thesis... 17
2. System Design for Signal Processing Applications ... 19
2.1 Introduction ... 19
2.2 Modeling ... 21
2.2.1 System Specification ... 21
2.2.2 Concurrency and Communication in Dataflow... 22
2.2.3 Models of Computation ... 25
A. Kahn Process Network... 25
B. Dataflow Process Network... 26
C. Synchronous Data Flow ... 27
D. Cyclo-static dataflow ... 28
E. Dynamic dataflow and Boolean dataflow ... 28
2.2.4 Heterogeneous Modeling Style... 29
2.2.5 Languages... 31
2.3 Design ... 33
2.3.1 System Partitioning ... 33
2.3.2 Reuse Methodology... 37
2.3.3 Scheduling ... 39
A. Dynamic Scheduling... 40
x
2.3.4 Communication Refinement and Interface Adaptation... 43
2.4 Analysis ... 45
2.4.1 Simulation ... 45
2.4.2 Performance Estimation... 47
2.4.3 Power Estimation... 48
2.5 Conclusion ... 48
3. MASIC Methodology... 49
3.1 Introduction... 49
3.1.1 Prevailing Design Methodology... 51
3.1.2 Problems with Prevailing Design Methodology... 52
3.2 Separation of Functionality and Architectural Decisions ... 53
3.2.1 Functionality... 55
3.2.2 Architectural Decisions... 56
3.2.3 The Abstract Model ... 58
3.3 Categorization of Architectural Decisions ... 59
3.3.1 System Level Decisions (SLDs)... 61
3.3.2 Implementation Level Decisions (ILDs)... 64
3.4 Levels of Abstraction... 66
3.4.1 Comparison of Different System Models... 68
3.4.2 Functional Model (FM)... 68
3.4.3 Process Transaction Model (PTM)... 69
3.4.4 System Transaction Model (STM) ... 72
3.4.5 Bus Transaction Model (BTM) ... 73
3.4.6 Implementation Model (IM)... 76
3.4.7 Design Flow through Different TLMs ... 78
3.5 Conclusion ... 80
4. Modeling with MASIC ... 83
4.1 Introduction... 83
4.1.1 Communication Modeling in MASIC... 84
4.1.2 Grammar Based Hardware Specification... 87
4.2 Grammars for Language Parsing ... 88
4.2.1 Pattern Recognition... 89
4.2.2 Language Parsing ... 90
4.2.3 Building a Compiler... 92
4.3 The MASIC Language... 93
4.3.1 MASIC Grammar Rules... 95
xi
B. Import Section ... 99
C. Interface Section... 99
D. Storage Section... 99
4.4 Case Studies... 99
4.4.1 Modeling at the FM level ... 101
4.4.2 Modeling at the PTM level ... 103
4.4.3 Modeling at the STM level ... 106
4.4.4 Modeling at the BTM level... 106
4.4.5 Modeling at the IM level ... 111
4.5 Limitations of Grammar Based Specifications ... 113
4.6 Conclusion... 114
5. System Validation... 117
5.1 Introduction ... 117
5.2 The Divide and Conquer Verification Strategy ... 118
5.2.1 GLOCCT and Its Verification ... 119
A. Start up sequence and configuration... 119
B. Interface to the surrounding functionality... 119
C. Internal Resource management ... 120
D. Movement of Data ... 120
5.2.2 Justification... 121
5.2.3 Benefits of the Divide and Conquer Approach ... 122
5.2.4 Experiments and Results ... 122
5.3 Petri Net Based Simulation... 124
5.3.1 Petri Net... 124
5.3.2 Building the Petri Net Model... 125
5.3.3 An Example: A Network of FSMs... 127
5.3.4 Simulating and Analyzing the Net ... 128
5.3.5 Experiments and Results ... 130
5.4 Conclusion... 133
6. Conclusion ... 135
6.1 Summary and Conclusion... 135
6.2 Limitations and Future Work... 138
7. References ... 141
xii
AHB Advanced High-performance Bus
AMBA Advanced Microcontroller Bus Architecture
APB Advanced Peripheral Bus
ASB Advanced System Bus
ASIC Application Specific Integrated Circuit
BFM Bus Functional Model
BNF Backus-Naur Form
BTM Bus Transaction Model
CFSM Codesign Finite State Machine
CAD Computer Aided Design
CSP Communicating Sequential Process
DAG Directed Acyclic Graph
DDF Dynamic Data Flow
DFG Data Flow Graph
DSP Digital Signal Processing EDA Electronic Design Automation FIFO First In First Out
FIR Finite Impulse Response
FM Functional Model
FPGA Field Programmable Gate Array
FSM Finite State Machine
FSMD Finite State Machine with Datapath
GLOCCT GLObal Control, Configuration, and Timing HDL Hardware Description Language
I/O Input/Output
IC Integrated Circuit
ILD Implementation Level Decision
IP Intellectual Property
IM Implementation Model
ITRS International Technology Roadmap for Semiconductors
KPN Kahn Process Network
MASIC Maths to ASIC
MPSOC Multiprocessor System-on-Chip
NOC Network-on-Chip
NRE Non-recurring Engineering
PTM Process Transaction Model
xiii
RTOS Real Time Operating System
SDF Synchronous Data Flow
SFG Signal Flow Graph
SLD System Level Decision
SOC System-on-Chip
STM System Transaction Model
TLM Transaction Level Model
VC Virtual Component
VHDL VHSIC Hardware Description Language
VHSIC Very High Speed Integrated Circuit
VLIW Very Large Instruction Word
VLSI Very Large Scale Integration
YACC Yet Another Compiler Compiler
1111....
This chapter provides an introduction to this dissertation. We start with a short background of the work. Next, we describe the motivation behind the development of the MASIC methodology, and describe the methodology in brief. Finally, we point out the contribution of the author in the development of the methodology followed by a short description on the organization of this dissertation.
1.1 Thesis Background
Almost all aspects of our way of life have been heavily influenced by the continued proliferation of electronic systems. The design task of these electronic systems encompasses a wide area of knowledge and research activities. This chapter begins with a look on the backdrop of the work presented in this dissertation so that the reader can put it in the right context within the vast field of electronic systems design.
1.1.1 Historical Perspective
As far back as 1965, Gordon Moore
1made the classical observation that the number of transistors per integrated circuit was exponentially increasing with time, and predicted that this trend would continue [104]. His insightful empirical law, which became known as Moore's law, still holds true and the exponential growth is expected to continue at least through the end of this decade.
1
He was the director of R&D of Fairchild Semiconductor—the company that he co-
founded—during the time he wrote his legendary paper, and joined Intel Corporation
afterwards. In his paper, he predicted that the exponential growth of semiconductor circuits
would continue at least for the next ten years, and most likely to continue beyond that time.
It is the relentless efforts of researchers and engineers that have made it possible to sustain such an exponential growth over the last four decades. As a result we have experienced that the number of devices that could be economically fabricated on a single chip has been exponentially increasing at a rate of 50% per year and hence quadrupling every 3.5 years. The delay of a simple gate has been decreasing by 13% per year, halving every 5 years [34]. While the minimum feature size is decreasing, the chip size is increasing. The million-transistor/chip barrier was crossed in the late 1980s. The clock frequency doubles every three years [112]. A graph of the enormous pace of the growth of integration density of microprocessors and memories is shown in Figure 1.
ITRS’99
1970 1974 1978 1982 1986 1990 1994 1998 2002 2006 2010 Years
109 108 107 106 105 104 103 102
Devices per chip
DRAM Memories Microprocessors
φ75mm φ100mm
φ125mm φ150mm
φ200mm
φ300mm
1k
Desk calculator4004 4k
64k 16k
256k 1M 4M
16M
64M
256M 1G 4G
8080 Z80
80488086/8088 6800
80286 32032
80386
68020
80486 PentiumPro Pentium II Xeon Celeron
Pentium IIIPentium 4 2.5G Hz
3.5GHz6G Hz
70nm
100nm 50nm
10G
130nm 180nm 250nm 350nm 500nm 800nm 1.2µm 2.0µm
1.2µm 3.0µm
5.0µm 8.0µm
LSI VLSI
SSI
MSI ULSI GSI
Figure 1. Evolution of microelectronics (after [136])
The increase in the size, speed and functionality of VLSI circuits in turn increased
the complexities of designing and fabricating such circuits. To manage the
complexities, it became customary to decouple the design engineer from requiring
to understand the intricacies of the fabrication process. Therefore, a set of design
rules was defined that acts as the interface or even the contract between the design
engineer and the process engineer [112]. Design engineers generally want tighter
and smaller designs, which lead to higher performance. The process engineers, on
the other hand, want a reproducible and high-yield process. Consequently, the
design rules are a compromise that attempts to satisfy both sides. The design rules
provide a set of guidelines for constructing the various masks needed in the
patterning process. They consist of minimum-width and minimum-spacing constraints, and the requirements between objects on the same or different layers.
1.1.2 Barriers to Moore’s Law
The exponentially growing availability of transistors makes it plausible to build larger systems, which integrate more functionality on a single die. The inevitable consequence of this enormous scale of integration increases the complexity of the system, and makes it more challenging to cost-effectively design and verify them.
Figure 2. The increasing design productivity gap (after [136])
Over the years we have observed a discrepancy between the pace at which the design technology and the process technology advances. The International Technology Roadmap for Semiconductors (ITRS) has documented a design productivity gap in which the number of available transistors grows faster than the ability to meaningfully design them. Figure 2 shows the increasingly widening gap between the manufacturing capability and the design productivity that we are experiencing over time.
The main message in the 2003 ITRS roadmap is that the cost of design is the greatest threat to the continuation of the semiconductor industry’s phenomenal growth [4]. Manufacturing non-recurring engineering (NRE) costs are in the order
Transistors / chip
Year
of one million dollars (mask set and probe card), whereas design NRE costs routinely reach tens of millions of dollars. When manufacturing cycle times are measured in weeks, with low uncertainty; the design and verification cycle times are measured in months or years, with high uncertainty [12]. However, investment in process technology has far outstripped the investment in design technology [49]. Nonetheless, progresses in the design technology are evolving. The work presented in this dissertation focuses on one aspect of design technology—system level design—with the aim to increase the design productivity.
1.1.3 Systems and Models
Arguably, almost everyone has a different definition of what a system is. In this context, a nice discussion can be found in [76], “What is meant by a system always depends on the context of discourse. What is a system in one context may be a tiny component in another context and the environment in a third.” For instance, an Application Specific Integrated Circuit (ASIC) is a very complex system to ASIC designers, but it is only one out of many electronic components that goes into an airplane, which in turn is only one element in the air traffic organization of a country. In this thesis, by “system” we mean electronic systems, such as those built into mobile phones, base-stations, digital set-top boxes, digital cameras, personal digital assistants, cars, planes, toys, robots, and so on. Signal processing remains at the heart of most of these products. Often, these products include an embedded microprocessor, if not more, to implement functionalities in software, and they are commonly referred to as embedded systems
2.
A modern car is known to contain up to 70 separate embedded controllers [127].
The March 2004 edition of IEEE Spectrum features a cover story on “Top 10 Tech Cars” [130]. This article describes the latest developments of automobile electronic systems like roll stability control, active steering system, lane keeping assistant system, etc. These systems acquire data from steering, braking, and vehicle sensors that monitor speed, body roll, yaw, wheel angle, etc. Then they perform a lot of signal processing on the sensor data and images from windshield mounted camera, and finally controls the brake torque at specific wheels, the front wheel angle, the engine power, the air bags, etc. According to Daimler-Chrysler sources, more than 90% of the innovation (and hence the value added) in a modern car is in electronics [118]. According to BMW, electronic components comprise more than 30% of a car’s manufacturing cost. Considering these data, the author
2
An embedded system is defined as a system, which uses a computer to perform a specific
function, but is neither used nor perceived as a computer [50].
has very reasonably put forward the question: “Will the electronic components be the car and the mechanical components an accessory?”
Although microprocessors has been in use for over two decades, microprocessor based systems have almost exclusively been board-level systems. By the 1990s, microprocessor based systems became an important design discipline for integrated circuit (IC) designers [134]. As a result, designers opted for realizing the whole microprocessor based system within a System-on-Chip (SOC). Since then, even multiprocessor System-on-Chip (MPSOC) has started to enter the marketplace, and are expected to be available in even greater variety over the next few years [135]. MPSOC solutions make most sense in high volume markets that have strict performance, power, and cost requirements. Communications, multimedia, and networking are the market segments that meet these requirements.
As a result, we see the emergence of different MPSOC designs, like the Philips Nexperia for digital set-top boxes and digital TV systems, the ST Nomadik for mobile multimedia applications, the TI OMAP for wireless applications, and the Intel IXP2850 for network processing [135].
Current electronic systems are far more complex than those of a decade ago.
While personal digital assistants contain a large 32-bit CPU, the high-end cameras, digital set-top boxes and laser printers contain multiple processors [134]. Philips Nexperia architecture contains two processors–a 32-bit MIPS CPU and a TriMedia Very Large Instruction Word (VLIW), plus three buses and a number of other units to implement special purpose functions [46]. It decrypts, decodes, converts, and displays multiple media streams having different data formats. The system typically handles live video, audio, and various other stream types in compressed and uncompressed formats. The set top box designed at STMicroelectronics contains a proprietary 64-bit processor and some general purpose blocks, along with dedicated functions specifically designed by STMicroelectronics [113]. Chip complexity is in the range of 8 million gates, 3 Mbits of embedded static RAM, integration of analog IP’s
3, and 400 signal pads. The main clock frequency is 200 MHz and circuits are organized around an internal proprietary bus.
The scale of system integration in turn increases the design complexity. As a result, it becomes indispensable to devise some technique to manage the design complexity. There are two major ways of managing complexities as shown in Figure 3. Partitioning divides the complexities into smaller chunks, without reducing them. The concept of abstraction, on the other hand, reduces the
3
In this text, we shall use the term IP to mean Intellectual Property. To avoid potential
confusion with the more popular use of the term IP as Internet Protocol, some people refer
to them as Virtual Components (VCs).
complexities by hiding details. Abstraction is the measure of absence of details. To be able to design and verify complex systems with ease, it has become customary to construct abstract models of them. A model is a simplification of another entity, which can be a physical thing or another model [76]. The model contains exactly those characteristics and properties of the modeled entity that are relevant for a given task.
Figure 3. Two ways of managing design complexities
The higher the level of abstraction is, the less detailed the model is. Electronic Design Automation (EDA) techniques and tools are often classified by the level of abstraction they deal with, where system level design remains at the top of the hierarchy. This dissertation presents a particular way of modeling signal processing systems at higher levels of abstraction, and presents a system level design methodology.
1.1.4 System Level Design
As we build system models at higher levels of abstraction, the modeling and verification tasks become easier. This is because the abstract model relieves the designer to think about the rigorous implementation details at the beginning, and gives the freedom to explore the design space with different alternatives per se.
Then, the next question is how to realize a detailed implementation of the abstract model. The act of design adds more details to the abstract model and yields an
design space horizontal
solution partitioning
abstraction level
vertical solution abstraction complexity
implementation model, most likely through a number of intermediate levels of abstraction, as depicted in Figure 4.
Figure 4. Design process from higher abstraction level to implementation level
System level design deals with realizing the system functionality on a system architecture. The system functionality is captured using different abstract formalisms, which we shall discuss in chapter 2. The overall system architecture includes the integration of different system components like general purpose processor cores
4, digital signal processing (DSP) cores, and VLIW cores to achieve flexibility and programmability; custom hardware blocks to implement performance critical portions; predesigned hardware blocks to save design time;
and memory subsystems for the embedded processors. Moreover, to provide application specific reconfigurability, it will also be required to have uncommitted Field Programmable Gate Array (FPGA) circuitry in the system. To connect these system components we need some kind of communication architecture, either bus based or network based. In addition, the SOC architecture would also contain I/Os, data converters, and mixed analog/digital designs. In this dissertation we focus on the digital part of the SOC architecture, targeting signal processing applications, and present a design methodology that facilitate the designer to map an abstract functional model to a system architecture.
4
An integrated circuit core is a predesigned, preverified silicon circuit block, usually containing at least 5000 gates that can be used in building a larger or more complex application on a semiconductor chip [64]. A core may be soft, firm, or hard. A soft core consists of a synthesizable HDL description that can be integrated to different
semiconductor processes. A firm core contains more structure, commonly a gate-level netlist that is ready for placement and routing. A hard core includes layout and technology dependent timing information, and is ready to be dropped into a system.
design space
abstract specification model
abstraction level
intermediate models
detailed implementation model design activities
1.2 Motivation
The pursuit to integrate more functionality and gain flexibility to support multiple standards, typical systems embrace heterogeneous architectures. The architecture is often comprised of a handful of programmable processor cores, different hardware blocks, few different segments of buses using different data transfer protocols, and bridges among these different bus protocols. The enormous scale of integration increases the system design complexity. On top of the scale of system integration, the designers face strict performance requirements, which in turn add up to the design challenges. To make the scenario even worse, the increasing time- to-market pressure demands these complex systems to be designed and verified in less amount of time. However, the established design methodologies in industry use the register transfer (RT) level description, which fail to cope with the design complexities due to a number of reasons:
• RT level is too detailed to be effective enough to explore the design space with different design alternatives.
• The system functionality often gets mixed up with the implementation details, which makes the design task more complex, and hinders design reuse and design for reuse.
• The hardware/software co-verification tools come into play at a later stage when the design team has already made much of the
commitments to an implementation.
• There is no smooth path from the functional modeling phase to the implementation level. Often the architectural decisions are captured in plain natural language at higher levels of abstraction, and the results of the functional modeling phase is not effectively reused at the RT level.
To tackle these design challenges, we believe that there is a clear need to adopt a
higher level of abstraction to model complex systems. The abstract system model
needs to be free of rigorous implementation details and pave the way to implement
it in various different ways. Mapping an abstract functional model on a system
architecture is a nontrivial task because the architecture contains a wide variety of
system components and interconnection topology, and a given functionality can be
realized in various ways depending on cost-performance tradeoffs. Therefore, a
system design methodology must provide adequate design steps, possibly through
a number of levels of abstraction, to map the functionality on a system
architecture. Along the way, the methodology must support the reuse of
predesigned hardware and software components, and provide us with as accurate performance estimates as possible.
MASIC—Maths to ASIC—is a system design methodology targeting DSP applications that tackles the system design challenges. The methodology has been introduced in [35][70][72]. The basic essence of the design flow in MASIC is the clean separation between the two major aspects of a system:
• Functionality: The functionality is the abstract behavior of the system that tells us what the system is supposed to do.
• Architectural decisions: These decisions tell us how the functionality is implemented, that is how the individual functional blocks perform their computation, and how these blocks communicate with each other and with the environment.
Figure 5. The basis of the system design flow with the MASIC methodology
The basis of the system design flow with MASIC is shown in Figure 5. In this design flow, the functionality is modeled separately without any concern of the implementation architecture. The architectural decisions capture the information about the implementation of the functionality. Finally, they are mapped together to validate that the given functionality runs well on the chosen architecture, and meets the performance requirements. The separation of the two design aspects splits the system design task into smaller and more manageable problems.
In the context of the separation of these design aspects, MASIC has a similar approach to the interface based design methodologies, which separate the system behavior from the implementation architecture [96][114][116]. Other contemporary methodologies, like the YAPI for signal processing system design
simulation model
functionality
mapping architectural
decisions
developed by Vissers et al. [44][84][131], the function architecture codesign developed by Sangiovanni-Vincentelli et al.[122], and the platform based design methodology developed by Keutzer et al. [83][102], also advocate the separation between the functionality and the architectural decisions.
To model a system using the design flow shown in Figure 5, a system designer typically studies the functionality, takes the system specification, makes a few initial calculations, and then proposes an architecture to implement the functionality. Next, the system performance is evaluated, for instance by simulation [84][131], and architectural decisions are iteratively altered to meet the performance goals. Although the concept of the separation of the functionality and the architectural decisions is of great value for any system design methodology per se, it brings three more issues that call for special treatment:
• There exists a huge number of architectural alternatives to implement both the computation and the communication aspects of a system.
Exploring all the architectural decisions is an inefficient approach.
Hence there is a need to categorize the set of architectural decisions in a systematic way, such that only a subset of the decisions needs to be considered at any particular instance in the design flow.
• There is a top-down iteration in the design flow shown in Figure 5. As a result, if a given set of architectural decisions does not yield
satisfactory performance then the design cycle needs to be iterated for another set of decisions. Such a long top-down iteration hinders the design productivity and there is a clear need of creating intermediate abstraction levels such that the top-down iteration is broken into smaller loops.
• Exploring the design space with different architectural decisions becomes difficult if the decisions are captured at a lower abstraction level where the data transactions among the modules are described elaborately. Therefore, we need to map the functionality to the system architecture at higher abstraction level such that the system models can be created quickly, and simulated with faster speed. In addition, we also need the abstract models to yield as accurate performance estimates as possible.
The MASIC methodology addresses all the preceding issues. In the following
section, we briefly discuss the key concepts of the system design flow in MASIC
and the tool support.
1.3 Key Concepts of the MASIC Methodology
We present a systematic approach to classify the architectural decisions in two categories: system level decisions (SLDs) and implementation level decisions (ILDs) [41]. As a result of this categorization, we only need to consider a subset of the decisions at once. Figure 6 illustrates the conceptual design flow after categorizing the architectural decisions. We add the SLDs to the functional model to create an abstract intermediate model. Next, the ILDs are added to the intermediate model to build a more detailed model. Figure 6 clearly shows that the creation of the intermediate abstraction level breaks the top-down iteration of the initial design flow of Figure 5 into two smaller loops. Next, we capture the SLDs and ILDs in an abstract way.
Figure 6. System design flow after categorization of architectural decisions
Typically, the functional model (FM) of a DSP system is built at the most abstract level where both communication and computation takes place in zero-time. In the implementation model (IM), however, both communication and computation are cycle accurate. Between the FM and IM of a system, we have created three transaction level models (TLMs) in the context of signal processing systems [42].
These TLMs are the process transaction model (PTM), the system transaction model (STM), and the bus transaction model (BTM). These TLMs capture the design decisions using abstract transactions where timing is modeled only to describe the major synchronization events. As a result the functionality can be mapped to the system architecture without meticulous details. Also, the artifacts of
implementation level decision
system level decision functionality
mapping
intermediate model
mapping
detailed model
the design decisions in terms of delay can be simulated quickly so that fast and reasonably accurate performance estimates can be obtained. Thus the MASIC approach saves both modeling and simulation time, and effectively helps the designer to explore the design space with alternative design decisions.
Figure 7. Coordinates of different system models in the system modeling graph
Gajski et al. have presented the system modeling graph where computation and communication are shown on two axes [28]. Each axis has three degrees of time accuracy: untimed, estimated, and cycle accurate. The coordinates of our different system models are shown in Figure 7. The thick arrow in gray shows the design flow in MASIC. Throughout the design flow, design decisions are added to an abstract model to create a less abstract model.
1.3.1 Language Support and Validation Technique
To successfully exploit the advantages offered by the MASIC methodology there is a need to have adequate tool support to build and simulate the system models. In our design flow, from the functional model through the transaction level models (TLMs) to the final implementation, the functionality remains the same. It is only the protocol of data transaction that evolves from abstract FIFO channels to bus protocols and component interfaces, like the bus functional models (BFMs) of embedded cores, etc. To build the system models at different abstraction levels, we need a suitable language to express the communication protocol. Grammars provide a natural way of describing communication protocol. Therefore, we have developed a grammar based language, which is built upon the principles of the
A. Functional model (FM)
B. Process transaction model (PTM) C. System transaction model (STM) D. Bus transaction model (BTM) E. Implementation model (IM) cycle
accurate
communication
estimated
cycle accurate estimated
computation zero
delay zero delay
A B
C
D E
ProGram [140] language. Abstract communication modeling has become a part of different system modeling languages like SystemC [59] and SpecC [48]. However, we argue that grammars provide a more intuitive and natural way of describing protocols than the C++ or C language.
The grammar based language of MASIC provides a unique way of capturing the architectural decisions. It creates the system interface, the interfaces of the individual functional blocks, the data channels among the blocks and the data transactions within the channels. Signal processing algorithms are typically developed in a C or MATLAB-like environment. The MASIC compiler imports these C functions, and generates a high level description of the system model in VHDL. The foreign language interface (FLI) of VHDL is used to perform co-simulation between VHDL and C.
It is not possible to simulate the grammar descriptions of the system models, unless they are compiled to another language, for example VHDL. Therefore, to be able to simulate the grammar descriptions, we have developed a Petri net representation of the models. As a result, the MASIC models can be simulated without having to compile them to another language. The Petri net representation of the system model also paves the way to apply different Petri net based analysis techniques, like deadlock or reachability analyses, on the model.
Verification of complex systems is a difficult problem because many DSP blocks placed on a system require a complicated global control logic for their proper interaction. Verifying the DSP blocks together with the global control results in a complex validation problem. We propose a divide and conquer approach that takes advantage of the clean separation between the functionality and the architectural decisions in the MASIC model of a system, and speeds up the verification process substantially.
1.4 Publications
This dissertation is based on the following publications by the author. All the papers listed here are peer-reviewed:
[paper-i] Abhijit K. Deb, A. Jantsch, and J. Öberg, “System Design for DSP
Applications in Transaction Level Modeling Paradigm,” in Proc. IEEE/ACM Design Automation Conf. (DAC), pp. 466-471, San Diego, CA, Jun. 2004.
[paper-ii] Abhijit K. Deb, A. Jantsch, and J. Öberg, “System Design for DSP
Applications Using the MASIC Methodology,” in Proc. IEEE Design,
Automation and Test in Europe (DATE) Conf., vol. 1, pp. 630-635, Paris, France, Feb. 2004. (Nominated for best paper award in its category) [paper-iii] Abhijit K. Deb, J. Öberg, and A. Jantsch, “Simulation and Analysis of
Embedded DSP Systems using Petri Nets,” in Proc. 14th IEEE Int. Workshop on Rapid System Prototyping (RSP), pp. 64-70, San Diego, California, Jun. 2003.
[paper-iv] Abhijit K. Deb, J. Öberg, and A. Jantsch, “Simulation and Analysis of Embedded DSP Systems Using MASIC Methodology,” in Proc. IEEE Design, Automation and Test in Europe (DATE) Conf., pp. 1100-1101, Munich, Germany, Mar. 2003.
[paper-v] Abhijit K. Deb, A. Hemani, J. Öberg, A. Postula, and D. Lindqvist,
“Hardware Software Codesign of DSP Systems using Grammar Based Approach,” in Proc. 14th IEEE Int. Conf. on VLSI Design , pp. 42-47, Bangalore, India, Jan. 2001.
[paper-vi] Abhijit K. Deb, A. Hemani, and J. Öberg, “Grammar Based Design and Verification of an LPC Speech Codec: A Case Study,” in Proc. 11th Int.
Conf. on Signal Processing Applications and Technology (ICSPAT'2000), Dallas, USA, Oct. 2000.
[paper-vii] A. Hemani, Abhijit K. Deb, J. Öberg, A. Postula, D. Lindqvist and B.
Fjellborg, “System Level Virtual Prototyping of DSP SOCs Using Grammar Based Approach,” Kluwer Journal on Design Automation for Embedded Systems, vol. 5, no. 3/4, pp. 295-311, Aug. 2000.
[paper-viii] Abhijit K. Deb, A. Hemani, and J. Öberg, “A Heterogeneous Modeling Environment of DSP Systems Using Grammar Based Approach,” in Proc.
3rd Int. Forum on Design Languages (FDL), pp. 365-370, Tubingen, Germany, Sep. 2000.
[paper-ix] Abhijit K. Deb, A. Hemani, A. Postula and L.S. Nagurney, “The Virtual Prototyping of an AM Chip Using Grammar Based Approach,” in Proc. 17th IEEE NORCHIP Conf., pp. 283-290, Oslo, Norway, Nov. 1999.
[paper-x] A. Hemani, A. Postula, Abhijit K. Deb, D. Lindqvist and B. Fjellborg, “A Divide and Conquer Approach to System Level Verification of DSP ASICs,”
in Proc. IEEE Int. High Level Design Validation and Test Workshop (HLDVT), pp. 87-92, San Diego, California, Nov. 1999.
[paper-xi] A. Hemani, J. Öberg, Abhijit K. Deb, D. Lindqvist and B. Fjellborg, “System Level Virtual Prototyping of DSP ASICs Using Grammar Based Approach,”
in Proc. 10th IEEE Int. Workshop on Rapid System Prototyping (RSP), pp.
166-171, Clearwater, Florida, Jun. 1999.
1.5 Author’s Contribution
The author of this thesis started working with the MASIC project during the early 1999. That was roughly the time when the project was formulated by Dr. A.
Hemani and Dr. J. Öberg. After Dr. A. Hemani had left the Royal Institute of Technology (KTH) for an industrial career, Prof. A. Jantsch became involved with the project. Since the commencement of the project the author remains the only Ph.D. student involved in this project and played the key role in the development of the methodology. Next, the contribution of the author is pointed out more specifically:
Separation of functionality and architectural decisions: The basic essence of the initial work on MASIC is the separation between the system functionality and the implementation architecture, and the creation of the grammar based language to build system models [paper-vii, ix, xi]. The former was mostly conceived by Dr. A. Hemani and Dr. J. Öberg, while the latter was mostly developed by the author of this thesis. The author is the only student involved in those papers, and he conducts most of the experimental works.
Modeling mixed hardware/software system modeling: The MASIC project—as the name suggests—was targeted to ASIC implementation of signal processing systems. To model a mixed hardware/software system, the methodology was extended to be able to deal with embedded cores [paper-v].
In MASIC, an embedded core is viewed at two different layers. The outer layer contains the bus functional model (BFM) of the core, and the inner layer contains the DSP function in C language. The author rendered the main contribution to develop the mixed hardware/software system design methodology and conducted the experiments.
Categorization of architectural decisions: The concept of the categorization of
architectural decisions, which helps the designer to consider only a smaller
subset of decisions at the beginning, was exclusively envisioned by the author
[paper-ii]. The systematic categorization of architectural decisions made it
possible to create intermediate abstraction levels in the design flow, which
helps to tackle design challenges in small incremental steps. Prof. A. Jantsch
played an important part in introducing and explaining to the author the role of
different models of computation for modeling concurrency and time in a
system model. The author developed the abstract models of the system, the
detailed model of the AMBA on-chip bus architecture, and the BFM of the
MIPS core to conduct the experiments presented in [paper-ii].
Mapping the functionality on a system architecture through a number of levels of abstraction: After the systematic categorization of the architectural decisions, the next obvious issue was to capture these decisions in an abstract way, and still being able to obtain as accurate performance estimates as possible. The concept of capturing the architectural decisions using abstract transactions through a number of transaction level models was solely developed by the author of this thesis [paper-i]. Prof. A. Jantsch and Dr. J.
Öberg acted as mentors throughout the course of the work. The author conducted all the experiments presented in [paper-i].
MASIC Language: The creation of the ProGram
5language [140] initiated the grammar based language development activity in the then Electronic System Design lab (ESD lab) at KTH. ProGram is targeted towards data communication protocols and control dominated systems. The MASIC compiler was built upon the principles of the ProGram compiler. The MASIC language is tailored towards high level modeling of signal processing systems.
Except a couple of syntactical details, the major improvement of the MASIC over the ProGram is the ability to link to the C functions from the grammar description, such that a DSP function written in C can be fired to perform the computation. The author, with valuable feedback from Dr. J. Öberg, has developed the syntax and the semantics of the MASIC language, and the compiler to generate a high level simulation model in VHDL [paper-viii].
Petri net based simulation approach: This work was presented in [paper-iii, iv].
The author was the prime contributor of the work, and he received valuable feedback from Dr. J. Öberg and Prof. A. Jantsch. This work has made it possible to simulate the grammar descriptions without having to compile them to another language.
System verification through divide and conquer approach: Verifying individual DSP blocks together with the global control results in a complex validation problem. Taking advantage of the clean separation between the functionality and the architectural decisions of the MASIC model, this verification technique is developed to ease the verification task. This work was presented in [paper-vi, x], where Dr. A. Hemani and Dr. A. Postula made the prime contribution by formulating the idea. The author applied the idea in the context of the MASIC methodology.
5
ProGram stands for Protocol Grammar, which was developed by Dr. J. Öberg
1.6 Organization of the Thesis
This thesis is organized as follows:
In the second chapter we discusses some of the pioneering works in the area of system design, which is needed to position the current work in the right context.
To study the huge volume of works conducted in this area, we categorize the works in three broad areas: modeling, design and analysis, and compare/contrast our approach with the others.
Next, in chapter three, we present the MASIC methodology in details. The three cornerstones of the methodology are the clean separation of the functionality from the architectural decisions, the systematic categorization of architectural decisions, and the stepwise capturing of the architectural decisions through a number of abstraction levels. In this chapter, we elaborately discuss all these aspects of the methodology and point out the benefits of our approach.
Chapter four applies the MASIC modeling technique on several examples. We also present the grammar based language of MASIC that helps to capture and inject the architectural decisions efficiently. The modeling concepts are illustrated by realistic examples, which are implemented using the AMBA on-chip bus architecture. Our results show that the abstract TLMs can be built and simulated much faster than the implementation model at the expense of a reasonable amount of simulation accuracy.
Chapter five presents the system validation approach with MASIC. First, we discuss the divide and conquer approach to system verification, and discuss its benefits. Next, we present the Petri net based simulation technique of the MASIC description of a system model.
Finally, in chapter six, we conclude the current work and point out the direction
towards future improvements.
2222....
This chapter discusses some of the key activities conducted in the area of system design methodology, briefly tells how different researchers have tackled different issues, and along the way compares and contrasts the MASIC methodology.
2.1 Introduction
This chapter provides a review of some of the pioneering works in the area of system design methodology. Design methodology refers to the sequence of steps by which a design process will reliably produce a design “as close as possible” to the design target while maintaining feasibility with respect to constraints [3].
Methodologies create the need of different design tools, and the success of a design methodology largely depends on adequate tool support. Design tools are developed to perform the design steps with ease. The tools are built on the basis of different computational models, scheduling techniques, etc. These underlying models do not allow us to build any arbitrary type of tools. Hence, at times we also see that methodologies are being developed taking the available tool support into account.
To study the huge volume of works conducted in the area of system design methodology it is necessary to put the works in the right context of the design activities, rather than discussing them in isolation. It is, however, quite difficult to categorize these works because lot of the activities are tightly interwoven.
Nonetheless, we classify them into three broad categories: modeling, design, and
analysis, and briefly discuss how different researchers have put emphasis on
different aspects.
The task of modeling is to describe complex systems in a simpler way. A model is a said to be the simplification of another entity, which can be a physical thing or another model [76]. The model contains exactly those characteristics and properties of the modeled entity that are relevant for a given task. It is customary to build a number of models of a complex system at different levels of abstraction.
At higher abstraction level, systems are typically modeled as a set of concurrent processes interacting with each other in an abstract way. The lower the level of abstraction is, the more detail the description is. The semantics of modeling tells us how different processes of a model cooperate with each other, how they communicate, and how they compute.
Figure 8. Different activities within design methodologies
It is the act of design that adds more details into a model and brings it to a lower level of abstraction. Figure 8 shows the conceptual framework of design methodologies where the design works successively bring a model from a higher abstraction level to a lower abstraction level.
Different models at different levels of abstractions are analyzed to validate their functionality, and to check their performance against the constraints. If the model does not meet its requirements then the modeling and the design work need to be performed again. Figure 8 shows the design analysis task using the arrows on the right side of the figure.
lower level of abstraction higher level of
abstraction model - 1
model - 2
analysis
model - n design work
design work analysis
The design methodology tells us how all these different steps can be performed with ease so that an abstract model can be brought down to a detailed model.
2.2 Modeling
2.2.1 System Specification
A typical design methodology starts with the system specification model, and describes a design flow that leads to an implementation, as shown in Figure 9.
Quite naturally, what is an implementation at a higher level of abstraction, is too far away for being termed as implementation at a lower level of abstraction. For example, a digital filter developed in MATLAB is an implementation for an application engineer but it is not an implementation for a system designer.
Figure 9. Design process
The specification model of a system typically contains two major parts [132]:
• A functional specification, which captures the input-output relation of a system without any implementation detail.
• A set of constraints, which contains non-functional information like, performance, power, size, design and manufacturing cost, etc.
It is unanimously accepted that the functionality of a system should be captured at the highest level of abstraction, without considering hardware/software partitioning or any implementation details. Thus the functional model relieves the designer to think about all the implementation details at the beginning, and gives the necessary freedom to explore the design space with different design decision, probably through a number of intermediate levels of abstraction, as shown in Figure 4, in chapter 1.
specification design
process implementation
