CADENCE CONFIDENTIAL Design Methodologies for the Nanotechnology Era Alberto...
-
Upload
phebe-sharp -
Category
Documents
-
view
223 -
download
4
Transcript of CADENCE CONFIDENTIAL Design Methodologies for the Nanotechnology Era Alberto...
CADENCE CONFIDENTIALCADENCE CONFIDENTIAL
Design Methodologies for the Nanotechnology EraAlberto Sangiovanni-Vincentelli
Outline
• Motivation
• Design Challenges
• Platform-based Design
• Communication-Based Design
• Implementation Platforms: Constructive Fabrics
• Analog Platforms
Disaggregation:Electronic Systems Design Chain
EDA
Manufacturing
Implementation
System Design
PlatformBasedDesign
IP
InterfacesFabrics
6,000
6,500
7,000
7,500
8,000
8,500
9,000
1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007
ASIC Design Trend
Source: IBS
-27%
Design Starts
Electronic Design: A Vision
• Embedded Software will be increasingly critical in the Electronic Industry
• Embedded Software Design must not be seen as a problem in isolation, it is an, albeit essential, aspect of EMBEDDED SYSTEM DESIGN
• Our vision is to change radically the way in which ESW is developed today by linking it:
– Upwards in the abstraction layers to system functionality
– Downwards in the programmable platforms that support it thus providing the means to verify whether the constraints posed on Embedded Systems are met.
• Programmable Platforms must be developed efficiently leveraging IP-reuse and Application Space knowledge
• The future of the industry is pinned on the success of this plan
Outline
• Motivation
• Design Challenges
• Platform-based Design
• Communication-Based Design
• Implementation Platforms: Constructive Fabrics
• Analog Platforms
A Discipline of Platform-Based Design (ASV, GSRC 2000)
Silicon Implementation PlatformSilicon Implementation Platform
Architectural PlatformArchitectural Platform
Manfacturing InterfaceManfacturing Interface
Silicon ImplementationSilicon Implementation
Basic device & interconnectstructures
Delay, variation,SPICE models
Microarchitecture(s)Microarchitecture(s)
Circuit Fabric(s)Circuit Fabric(s)
Functional Blocks,InterconnectCycle-speed, power, area
S SV V SG
SG
SSV
V
SS SSVV VV SSGG
ApplicationApplication
Architecture(s)Architecture(s)
Kernels/BenchmarksProgramming Model:Models/Estimators
The design process is meet-in-the-middle:•Top-down: map an instance of the top platform into an instance of the lower platform and propagate constraints•Bottom-up: build a platform by defining the “library” that characterizes it and a performance abstraction (e.g., number of literals for tech. Independent optimization, area and propagation delay for a cell in a standard cell library)
The library has elements and interconnects
ASV Platforms (2001)
For every platform, there is a view that is used to map the upper layers of abstraction into the platform and a view that is used to define the class of lower level abstractions implied by the platform.
For every platform, there is a view that is used to map the upper layers of abstraction into the platform and a view that is used to define the class of lower level abstractions implied by the platform.
Upper layer of abstraction
Lower layer of abstraction
Constraints Performance Annotation
In general, a platform is an abstraction layer that covers a number of possible refinements into a lower level.
Platform
Mapping Tools
Platform
Platform stack{
Specification
Analysis
After Sales Service
Calibration
Implementation
Dev
elo
pm
ent
Pro
cess
BusesBusesMatlab
CPUs Buses OperatingSystems
Software Components Virtual Architectural Components
C-Code IPs
ASCET
ECU-1ECU-1 ECU-2ECU-2
ECU-3ECU-3BusBus
f1f1 f2f2
f3f3
System Behavior System Platform
Mapping
Performance Simulation
Refinement
Evaluation ofArchitectural and Partitioning Alternatives
Design Methodology: Orthogonalize Concerns
Consequences
• There is no difference between HW and SW. Decision comes later.
• HW/SW implementation depend on choice of component at the architecture platform level.
• Function/Architecture co-design happens at all levels of abstractions
– Each platform is an “architecture” since it is a library of usable components and interconnects. It can be designed independently of a particular behavior.
– Usable components can be considered as “containers”, i.e., they can support a set of behaviors.
Outline
• Motivation
• Design Challenges
• Platform-based Design
• Communication-Based Design
• Analog Platforms
Picoradio Sensor Networks (BWRC)
Control Environmental parameters (temperature, humidity…)Control Environmental parameters (temperature, humidity…) Minimize Power consumptionMinimize Power consumption Cheap (<0.5$) and small ( < 1 cmCheap (<0.5$) and small ( < 1 cm33))
Large numbers of nodes Large numbers of nodes — — between 0.05 andbetween 0.05 and 1 nodes/m1 nodes/m22
Limited operation range of network Limited operation range of network —— maximum 50-100 m maximum 50-100 m Low data rates per node Low data rates per node —— 1-10 bits/sec average 1-10 bits/sec average Low mobility (at least 90% of the nodes stationary)Low mobility (at least 90% of the nodes stationary)
sensoractuator
controller
• Key challenges
– Satisfy tight performance and cost constraints (especially power consumption)
– Identify Layers of Abstraction (Protocol Stack)
– Develop distributed algorithms (e.g. locationing, routing) for ubiquitous computing applications
– Design Embedded System Platform to implement Protocol Stack efficiently
Embedded System Platform
Network Design Using Platforms
Application components Requirements
Components Adaptation
Communication Refinement (Protocol Stack + Gateways)
On-Chip Networks
Network Platforms
event trace:
es11, es12, es13 er11, er12
er21, er22, er23es21, es22
node
linkportI/O port
• Network Platform (NP): Library of communication resources (protocols, channels…)
• Network Platform Instance (NPI): selection of NP resources
– Structure: set of resources and topology
– Behavior: set of event traces (events model send or receive actions)
Communication Refinement
• Replace components in abstract NPI with set of resources or NPIs
• Select resources from NP library and compose them to create NP with new Communication Services
• NP resources
– Channels (C ): transfer messages
– Protocols (P): adapt Communication Services
– Gateways (G): interface NPs
• Check refined NPI satisfies constraints
NPP P
NP’
NP GNP2NP1
Design of a Platform Layer: Ulysses
• Protocol Synthesis from Scenario-based (UML) Specifications
– Avoid early partitioning into components
– Problems: optimality, scenario interactions
– Specify scenarios independently
– Compose scenarios
Ulysses
• Pattern-based Design
– Library of Protocol Patterns: framing, retransmissions
• Multiple levels of abstraction (and Models)
– UML Message Sequence Charts (MSCs)
– Petri Nets (PNs)
• PNs Synthesis from MSCs
• Protocol synthesis and optimization driven by PN algorithms
P1 P2U1 U2
read write
Embedded System Platform
Network Design Using Platforms
Application components Requirements
Components Adaptation
Communication Refinement (Protocol Stack + Gateways)
On-Chip Networks
Adaptation of Component Behavior: The essence of IP-reuse (GSRC)
• The components in the NP library must come with specified abstract interfaces
• The composition of components can either be direct, when the interfaces are compatible, or through an adaptor, if they can be made compatible
• We provide a formulation of the problem that can be used to both verify compatibility and to synthesize the adapter
Interface Compatibility
Protocol 1 Protocol 2
Are the two protocols compatible?Interface Theories [de Alfaro and Henzinger]
Interface Adaptability
Protocol 1 Protocol 2
Can the two protocols be made compatible?Interface Synthesis [Passerone, Rowson, ASV]
Adapter
Interface Synthesis
Protocol 1 Protocol 2
What does compatible really mean?[Passerone, de Alfaro, Henzinger, ASV]
Adapter
Specification
Communication Synthesis Platform
M 1
M 2
M 3
M 4
M 5
M 1
M 2
M 3
M 4
M 5
P2P Specification
Communication Implementation
CkSkewWiresBuffers
Processes +Shells l=1
l=1
Relay Stations
(x1,y1)(x2,y2)
(x3,y3) (x4,y4)
bw1+bw2bw3+bw4
Links
Comm. nodes
(bw1,d1)
(bw2,d2)
(bw3,d3)
(bw4,d4) (bw5,d5)
CommunicationSpecs
Communication Synthesis Platform StackCommunication Synthesis Platform Stack
Constraints
– System modules communicate by means of point-to-point unidirectional channels
– Each channel is characterized by a set of communication constraints (distance, minimum bandwidth)
– The specific functionality of each module is “abstracted away”
• Abstract Model
Library
cost
Length
b1
b2
clk
Relay Station Switches
Cr(b)
Cs(b)
Cs(b)
This is the basic library of Communication Components
Synthesis of Communication Architecture
Library of Pre-designedCommunicationComponents
Point-to-PointChannel Communication Constraints
CommunicationArchitecture Implementation
Synthesis
Communication Implementation
Lib
n r
l1
l2
Metropolis Framework
Infrastructure
• Metropolis meta-model
- language
- modeling mechanisms• Meta-model compiler
Meta-model Library
• Models of computation
Meta-model Library
• Architecture platforms
Tools
Simulator QSS PIG STARS SPIN …
Application-specific methodologies
Multi-media, wireless communication, mechanical controls, processors
Metropolis meta-model
• Computation : f : X Z
• Communication : state evaluation and manipulation
• Coordination : constraints over concurrent actions
- process : generates a sequence of events
- medium : defines states and methods
- quantity : annotation of each event (time, energy, memory, …)
- logic : relates events and quantities, defines axioms on quantities
- quantity-manager : algorithm to realize annotation subject to relational constraints
Concurrent specification with a formal execution semantics:
Key difference with respect to Ptolemy, UML, SystemC, …!!!
Concurrent specification with a formal execution semantics:
Meta-model : function netlist
process P{
port reader X;
port writer Y;
thread(){
while(true){
...
z = f(X.read());
Y.write(z);
}}}
medium M implements reader, writer{
int storage;
int n, space;
void write(int z){
await(space>0; writer ; writer)
n=1; space=0; storage=z;
}
word read(){ ... }
}
interface reader extends Port{
update int read();
eval int n();
}
interface writer extends Port{
update void write(int i);
eval int space();
}
MP1X Y P2X Y
Env1 Env2
MyFncNetlist
R
I
F A
M
Meta-model: execution semantics• Processes take actions.
– statements and some expressions, e.g.
y = z+port.f(), port.f(), i < 10, …
• An execution of a given netlist is a sequence of vectors of events.
– event : the beginning of an action, e.g. B(port.f()),
the end of an action, e.g. E(port.f()),
null (no-op) N
– the i-th component of a vector is an event of the i-th process
– synchronous trace-based semantics
– time and other quantities elapse and actions are executed in states
– no assumption on atomicity whatsoever (unless explicitly modeled)
• An execution is feasible if
– it satisfies all coordination constraints, and
– it is accepted by all action automata defining meta-model semantics
Meta-model: architecture componentsAn architecture component specifies services, i.e.
• what it can do
• how much it costs
: interfaces
: quantities, annotation, logic of constraints
medium Bus implements BusMasterService …{
port BusArbiterService Arb;
port MemService Mem; …
update void busRead(String dest, int size) {
if(dest== … ) Mem.memRead(size);
[[Arb.request(B(busRead));
GTime.request(B(memRead),
BUSCLKCYCLE +
GTime.annotation(B(busRead)));
]]
}
…
scheduler BusArbiter extends Quantity
implements BusArbiterService {
update void request(event e){ … }
update void resolve() { //schedule }
}
interface BusMasterService extends Port {
update void busRead(String dest, int size);
update void busWrite(String dest, int size);
}
interface BusArbiterService extends Port {
update void request(event e);
update void resolve();
}
BusArbiterBus
R
I
F A
M
Meta-model: architecture netlist
Bus
ArbiterBus
Mem
Cpu OsSched
MyArchNetlist
…
…
…
Master
CPU + OS
Slave
Mem
Arbiter
Architecture netlist specifies configurations of architecture components.
Each constructor
- instantiates arch. components,
- connects them,
- takes as input mapping processes.
R
I
F A
M
Meta-model: platforms
interface MyService extends Port { int myService(int d); }
medium AbsM implements MyService{ int myService(int d) { … }}
B(thisthread, AbsM.myService) <=> B(P1, M.read);
E(thisthread, AbsM.myService) <=> E(P2, M.write);refine(AbsM, MyMapNetlist);
MyArchNetlistMyFncNetlist MP1 P2
B(P1, M.write) <=> B(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, )B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf);
MyMapNetlist1
MyArchNetlistMyFncNetlist MP1 P2
B(P1, M.write) <=> B(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, )B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf);
MyMapNetlist1
B(…) <=> B(…);
E(…) <=> E(…);refine(AbsM, MyMapNetlist1)
MyArchNetlistMyFncNetlist
MP1 P2
B(P1, M.write) <=> B(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, )B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf);
MyMapNetlist2
M
B(…) <=> B(…);
E(…) <=> E(…);
refine(AbsM, MyMapNetlist2)
A set of mapping netlists, together with constraints on event mappings, constitutes a platform (constrained set of possible implementations) with a given interface.
R
I
F A
M
R
I
F A
M
Meta-model: recursive platforms
S
N N'
B(Q2, S.cdx) <=> B(Q2, mQ2.excCpu); E(Q2, M.cdx) <=> E(mQ2, mQ2.excCpu);
B(Q2, Q2.f) <=> B(mQ2, mQ2.mapf); E(Q2, P2.f) <=> E(mQ2, mQ2.mapf);
MyArchNetlistMyFncNetlist MP1 P2
B(P1, M.write) <=> B(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, )B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf);
RTOSNetlist
MyArchNetlist
MyFncNetlist
MP1 P2B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf);
M
RTOS
Outline
• Motivation
• Design Challenges
• Platform-based Design
• Communication-Based Design
• Analog Platforms
Motivation
Optimality?Exploration?
Focus
• Focus on System Level Design
– Enable effective design exploration
– Evaluate tradeoffs while proceeding top-down
– Allow integration of third-party components
– Move design optimization as high as possible
– Co-design with the digital part (BB+Protocol)
• Not HW/SW co-design, but HW/SW/Analog!
Analog Design Flow
System Specs
Behavioral models–Matlab, Excel, …–Define Block requirements
Circuit design–Size, Simulate and iterate
Layout design–Verify and iterate
Syst
em
Level
Exp
lora
tion
Cir
cuit
S
izin
g &
Syn
thesi
s
Analog Design Flow
System Specs Behavioral models
–Matlab, Excel, …–Define Block requirements
Circuit design–Size, Simulate and iterate
Layout design–Verify and iterate
Syst
em
Level
Exp
lora
tion
Cir
cuit
S
izin
g &
Syn
thesi
s
Analog Platform
Analog Platforms
• An Analog Platform is a library of analog components and interconnects that implements a set of functionalities
• An Analog Platform consists of:
– Behavioral models – provide an efficient way to simulate mapping effects at the current platform level
– Performance models – constrain the possible behaviors to the considered platforms
Analog Platforms
• Classic top-down approaches suffer for limited predictability of performances Introduce a new level of abstraction
• Platforms abstract underlying components providing:
– Estimation mechanisms (i.e. models) for platform level optimization
– Mapping mechanisms to propagate constraints to next level
• Platforms provide accurate exploration mechanisms by limiting the search space
• Platforms may encapsulate synthesis paths
Analog Platform Stacks
Filter
Diff. S.Ended
OpAmp Lib1 OA Lib2
Sw.Cap Cont.T.
Perf
orm
ance
Est
imat
ion
Map
ping
Too
ls
• APs allow efficient top-down flows for analog systems
Platform stacks allow the selection of optimal architectures and topologies for analog components
At each level of abstraction in the platform stack, performance models allow transforming requirements into satisfiable next-level constraints
Any platform instance is implementable by definition
OpAmp
Analog Platforms
• The Analog Platform (AP) concept applies at different levels of abstractions
– Custom circuits – APs can be derived by automatic characterizationof the circuit
– IPs – APs can be used to encapsulate and characterize Intellectual Properties (possibly customizable Synthesizable Cores)
– Programmable cores – Field Programmable Analog Arrays (FPAA) provide the first example of generic analog platform
Behavioral Models
• A behavioral model is a mathematical parameterized representation of a circuit/component
– still a functional model, no notion of architecture
• How to select rin, i2noise, g1, g2, g3, f-3dB, rout?
– Feasible (compatible) values depend on the real implementation of the platform optimization
2noisei 2
2 invg3
3 invginvg1 outrinr dBf 3
voutvingain
Behavioral ModelIdeal Model
Behavioral Models Hierarchy
• Behavioral models should be organized in form of trees, one for each functional block
– the root node represent the universal model for the functionality
– deeper nodes represent refined models, which already have some architectural assumption
– leaf nodes represent the most detailed behavioral models specific for implementation architectures
Model Representation
• Right now, continuous time prototypes in Matlab/Simulink
– easy to use and powerful prototyping environment
– integration with external code
– de facto standard among analog system designers
• However, HDL-A languages may represent a viable alternative
– more industrial environment
– tool integration
– Co-simulation/co-verification?
Performance Models
• Top-down flows need to estimate performances
– Constrain behavioral models parameters
– set of compatible {gain, noise, dist.,…} n-tuples
• Architectural constraints can be represented through mathematical relations
(Power, Gain, NF, IIP3, P-1dB, DR, …) = 1 {Power, Gain, NF,…} are feasible with the current Platform
• No need for considering actual design variables that achieve specific performances
– Abstract away unnecessary implementation details
Constraint Relations (I)
• Approximate off-line through sampling
• Build estimation methods bottom-up
• Let’s define:
is the set of n-tuples ( n) {W1, W2, …, L1, L2, …, IB1, …, VB1, ..}
is the set of m-tuples ( m){Power, Gain, NF, IIP3, P-1dB, DR,…}
• AP Evaluation defines a function f: n m
• f() can be evaluated in different ways
– analytical expressions
– simplified models/simulations
– Spice accurate simulations
Constraint Relations (II)
• Operatively
– define and (define architectural space)
– get = f()
– build a relation (x)=1 x
needs to sample the image of is a n-dimensional space
– Limit n by proper definition of
– Keep granularity as low as possible
– Trade-offs with composition modeling
– Design of Experiments
– Capture designer experience to prune
– Build a constraints graph for the circuit
W
L
G
NF
Generating f()
• Given the definitions of and , and a constraint graph, f () is randomly sampled
• Operatively, Ocean scripts templates are available to automate the process
• Sampling is computationally expensive but requires no man-power
– On the order of 1000 samples may be necessary depending on the accuracy and on the “size” of
Example
• Example:
– Original, 7 7
– Shown, projection in 3
Proposed Methodology
• Separate the design of single blocks from the system optimization
– Third party’s platforms
– Largest performance improvements come from new topologies
– Do not limit designer’s creativity
• Generate functional models
• Generate performance models
• Perform system optimization at the behavioral level
– use hierarchical models and refinement to select topology
Analog Design Flow
Mapping
Performance Eval/System Optimization
PLL
Behavioral Models
Int. APsExt. IP’s
Performance ModelsNew APs
BehaviorRefinement
Architecture Refinement
Constraints Interpolation
• Given a set of samples, build an approximation for
– because of the generality of the evaluation scheme, few properties can be leveraged
• Assume the evaluation to define a continuous function
– reasonable while exploring “working” circuits
• Assume to be a connected set
• Then, is a connected set in m
– given x1 and its nearest neighbor x1N, if they are “close enough” then all the points in the segment x1-x1N satisfy
• Therefore, approximate with the smallest connected set containing the sample points
Support Vector Machines
• Statistical learning machinery to infer from data
• SVM’s belong to the class of large margin classifiers
– pioneered by Vapnik and Chervonenkis in the Sixties
• Simple conceptual model: hyperplane classifiers
– Separate data into classes using hyperplanes
– Can manage complex models
– Still mathematically analyzable
– Good control on (over)fitting
Operations on Platforms
• Analog Platforms stacks require three operations to be defined:
• Abstraction – Given a detailed platform, generate constraints for an abstracted AP
• Composition – Given constraints for two connected APs, derive constraints for the composition
• Merge – Given different platforms for the same functionality, generate constraints considering the union of s
Abstraction
• Top-down flows and model hierarchies require to derive multiple abstraction for one block
• Use relations where some of the parameters are free
{Power, Gain, NF} = {Power, Gain, NF, , , }
{Power, Gain, NF} =1 IIP3*, P-1dB
*, DR*,… s.t. {Power, Gain, NF, IIP3*, P-1dB
*, DR*,…}=1
are obtained from by projection onto a smaller
• This happens when the model is more general than the implementation
Projection on SVMs
• Need an efficient way to compute
– maximize
with respect to x (x=[x x] m)
– global optimization of a nonlinear function
– simulated annealing
– ad hoc technique
– optimum in the neighborhood of some SV
– complexity o(nl)
– 2 orders of magnitude faster than SA
,1
2
nSV
i
xxii beybxf ixw
Composition
• Composability is a key requirements for building complex (hierarchical) models
• Behavioral models don’t have any intrinsic notion of loading effects
• Need to include interface characterization parameters in the relation
– include ancillary parameters in
– check compatibility of interfaces
– Dynamic Range, Bias point…
– automatic insertion of converters?
• Similar to Communication Based Design for the digital world
Composition
• Define:
– x = [x ], y=[y, ], z=[x y]
AB([x y]) = 1 s.t. A ([x ]) = B([y ]) = 1
• In terms of SVM’s
0
0 ..
1max
1
122
22
nSV
iB
Bi
nSV
iA
Ai
BiB
BiB
AiA
AiA
ee
eets
λλyy
λλxx
λ
Block A A(x)
Block B B(y)
Merge
• Merge is defined in terms of performance relations building a new relation:
= 1+ 2+… k
i are constraints for different Analog Platforms (e.g. for a single ended LNA, a differential LNA, cascoded and so on)
– ‘+’ is the logical OR function
• Architecture selection is achieved selecting platform instances in . The mapping process will then select i
Closure
• Closure is a composition that involves a transformation in the abstraction space
• Closure defines a new platform that is non-trivially related to the composing ones
– E.g., in a PLL, jitter of single components, non linearities and transfer functions get transformed into locking range, acquisition time, phase noise, …
• Closure is implemented through the same process used for AP generation on the first instance
LF
VCO
PLL
Top-down with APs
• Complex optimization strategies can be used at system level
– #params at top level is moderate to low
– behavioral models reasonably fast
• Optimize the system and refine the architectural blocks
• At the end, a set of specs is provided for each Platform Platform Instance
– Constraints achievable by construction
• Generate the actual circuits
– Designers, IP providers, Automatic tools …
• Proceed with appropriate bottom-up verification
Sensor Interface Example
MEMS Pressure Sensor
ADC Converter
Signal Conditioning
10 bit1 kSamples/s
Input range: 0.5-1.5VBandwidth: 500 Hz
FSO: 200 mVR: 1000-2300 R/T: 1800ppm
Bridge Linearization
TemperatureCompensation
Amplification DC Offset
Nyquist Filter
Comm. Adapter
Synthesize and Map on Proper Platform• Off-the-Shelf Components• Field Programmable Analog Arrays• Custom Solutions
Performance Representation
• Platform performance spaces are derived bottom-up by sampling platform instances
Performances can be represented using Support Vector Machines (SVMs)
Fundamental Question and the Role of Platform-Based Design
• Question:
– Will design and manufacturing become intertwined as in the past?
• Analysis:
– Productivity higher if clean separation among layers of abstraction
– Can we afford inefficiency in silicon?
– If yes, what is the price to pay?
• Platform-based design is a disciplined methodology based on clean separation of layers of abstraction but favoring communication among different groups to mitigate negative impacts
Concluding Remarks
• Change in technology and market conditions will force a major design style shift towards IP re-use and programmable solutions
• Platforms will dominate many applications
• ASIC’s design starts will decrease further due to mask and NREs costs
• Embedded software will be a major emphasis in design
• Communication on chip and off chip will be the dominant part of design
• Analog will continue to be a major worry!