1. General-purpose Specification Languages

2. - 1 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund System modeling & design Represent system functions while abstracting away unnecessary details  Software programming languages  Hardware description languages  Flow and state-based diagrams No golden solution  System heterogeneity

3. - 2 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Current trends Bridge gap between hw and sw design  Unified design style and methodology Need for:  Fast simulation of complex systems  Hardware synthesis support  Targeted software compilation  Hw/Sw trade-off and interface design

4. - 3 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Types of Languages Domain-specific (e.g. dataflow)  Practical for signal processing  Concurrency + buffered communication Hardware  Structural and procedural styles  Unbuffered “wire” communication  Discrete-event semantics Software  Procedural  Some concurrency  Memory Hybrid  Mixture of other ideas

5. - 4 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Outline of the class HDL-based design  HW design flow  Overview of VHDL System design with SystemC  Overview of SystemC  SystemC based (HW/SW) design

6. - 5 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund System Design Methodology System Specification (C) HW (HDL) SW (C) Testbench 0101011110100010 1110010100100111 1000011110101001 0001100110101011... Translate Refine Challenge: deal with billion transitor complexity!!

7. - 6 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Hardware versus software models Hardware:  Parallel execution  I/O ports, building blocks  Exact event timing is very important Software:  Sequential execution (usually)  Structural information less important  Exact event timing is not important

8. - 7 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Traditional HW Design Flow

9. - 8 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund In detail: synthesis flow HDL Logic Synthesis Floorplanning Placement Routing Tape-out Circuit Extraction Pre-Layout Simulation Post-Layout Simulation Structural Physical Behavioral Design Capture Design Iteration

10. - 9 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund In detail: HDL for synthesis Module FSM(xx,xx) Begin xxx … end HW inference HDL Specification Structural RTL (tech. Indep) Logic Synthesis & Optimization Technology library (eg UMC 0.18) Design constraints Gate netlist Physical DA

11. - 10 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Hardware Languages Goal: specify connected gates concisely Originally targeted at simulation Discrete event semantics skip idle portions Mixture of structural and procedural modeling

12. - 11 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Hardware Languages Verilog  Structural and procedural modeling  Four-valued vectors  Gate and transistor primitives  Less flexible  Succinct VHDL  Structural and procedural modeling  Few built-in types; powerful type system  Fewer built-in features for hardware modeling  More flexible  Verbose

13. - 12 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Hardware methodology Partition system into functional blocks FSMs, datapath, combinational logic Develop, test, and assemble Simulate to verify correctness Synthesize to generate netlist

14. - 13 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund VHDL HDL = hardware description language Textual HDLs replaced graphical HDLs in the 1980‘ies (better description of complex behavior). VHDL = VHSIC hardware description language VHSIC = very high speed integrated circuit 1980: Definition started by DoD in 1980 1984: first version of the language defined, based on ADA (which in turn is based on PASCAL) 1987: revised version became IEEE standard 1076 1992: revised IEEE standard more recently: VHDL-AMS: includes analog modeling

15. - 14 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Entities and architectures Each design unit is called an entity. Entities are comprised of entity declarations and one or several architectures. Each architecture includes a model of the entity. By default, the most recently analyzed architecture is used. The use of another architecture can be requested in a configuration.

16. - 15 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund The full adder as an example - Entity declaration - Entity declaration: entity full_adder is port(a, b, carry_in: in Bit; -- input ports sum,carry_out: out Bit); --output ports end full_adder;

17. - 16 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund The full adder as an example - Architectures - Architecture = Architecture header + architectural bodies architecture behavior of full_adder is begin sum <= (a xor b) xor carry_in after 10 Ns; carry_out <= (a and b) or (a and carry_in) or (b and carry_in) after 10 Ns; end behavior; Architectural bodies can be - behavioral bodies or - structural bodies. Bodies not referring to hardware components are called behavioral bodies.

18. - 17 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund The full adder as an example - Simulation results - Behavioral description different from the one shown (includes 5ns delays).

19. - 18 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Structural bodies architecture structure of full_adder is component half_adder port (in1,in2:in Bit; carry:out Bit; sum:out Bit); end component; component or_gate port (in1, in2:in Bit; o:out Bit); end component; signal x, y, z: Bit; -- local signals begin -- port map section i1: half_adder port map (a, b, x, y); i2: half_adder port map (y, carry_in, z, sum); i3: or_gate port map (x, z, carry_out); end structure;

20. - 19 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund VHDL processes Processes model parallelism in hardware. General syntax: label: --optional process declarations --optional begin statements --optional end process a <= b after 10 ns is equivalent to process begin a <= b after 10 ns end

21. - 20 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Wait-statements Four possible kinds of wait-statements: wait until signal list;  wait until signal changes;  Example: wait until a; wait until condition;  wait until condition is met;  Example: wait until c='1'; wait for duration;  wait for specified amount of time;  Example: wait for 10 ns; wait;  suspend indefinitely

22. - 21 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Sensivity lists Sensivity lists are a shorthand for a single wait on-statement at the end of the process body: process (x, y) begin prod <= x and y ; end process; is equivalent to process begin prod <= x and y ; wait on x,y; end process;

23. - 22 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund VHDL semantics: global control According to the original standards document: The execution of a model consists of an initialization phase followed by the repetitive execution of process statements in the description of that model. Initialization phase executes each process once.

24. - 23 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund VHDL semantics: initialization At the beginning of initialization, current time, T c is 0 ns.  The driving value and the effective value of each explicitly declared signal are computed, and the current value of the signal is set to the effective value. …  Each... process … is executed until it suspends.  The time of the next simulation cycle (… in this case … the 1st cycle), T n is calculated according to the rules of step f of the simulation cycle, below.

25. - 24 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund VHDL semantics: The simulation cycle (1) Each simulation cycle starts with setting T c to T n. T n was either computed during the initialization or during the last execution of the simulation cycle. Simulation terminates when the current time reaches its maximum, TIME'HIGH. According to the standard, the simulation cycle is as follows: a)The current time, T c is set to T n. Stop if T n = TIME'HIGH and not  active drivers or process resumptions at T n. ?

26. - 25 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund VHDL semantics: The simulation cycle (2) Each active explicit signal in the model is updated. (Events may occur as a result.) Previously computed entries in the queue are now assigned if their time corresponds to the current time T c. New values of signals are not assigned before the next simulation cycle, at the earliest. Signal value changes result in events  enable the execution of processes that are sensitive to that signal...

27. - 26 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund VHDL semantics: The simulation cycle (3) d e e  P sensitive to s: if event on s in current cycle: P resumes. Each... process that has resumed in the current simulation cycle is executed until it suspends*. * Generates future values for signal drivers.

28. - 27 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund VHDL semantics: The simulation cycle (4) Time T n of the next simulation cycle = earliest of 1.TIME'HIGH (end of simulation time). 2.The next time at which a driver becomes active 3.The next time at which a process resumes (determined by WAIT ON statements). Next simulation cycle (if any) will be a delta cycle if T n = T c. f

29. - 28 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund  -simulation cycles … Next simulation cycle (if any) will be a delta cycle if T n = T c. Delta cycles are generated for delay-less models. There is an arbitrary number of  cycles between any 2 physical time instants: In fact, simulation of delay-less hardware loops will never terminate. 01

30. - 29 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund  -simulation cycles Simulation of an RS-Flipflop architecture one of RS_Flipflop is begin process: (R,S,Q,nQ) begin Q <= R nor nQ; nQ <= S nor Q; end process; end one; 0ns 0ns+  0ns+2  R 1 1 1 S 0 0 0 Q 1 0 0 nQ 0 0 1 0ns 0ns+  0ns+2  R 1 1 1 S 0 0 0 Q 1 0 0 nQ 0 0 1 0001 1100 0000 0111 1st  2nd   cycles reflect the fact that no real gate comes with zero delay.  should delay-less signal assignments be allowed at all?  cycles reflect the fact that no real gate comes with zero delay.  should delay-less signal assignments be allowed at all?

31. - 30 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund  -simulation cycles and deterministic simulation semantics Semantics of a <= b; b <= a; ? Separation into 2 simulation phases results in deterministic semantics

32. - 31 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund VHDL: Evaluation Behavioral hierarchy (procedures and functions), Structural hierarchy: through structural architectures, but no nested processes, No specification of non-functional properties, No object-orientation, Static number of processes, Complicated simulation semantics, Too low level for initial specification, Good as an intermediate “Esperanto“ or ”assembly” language for hardware generation.

33. - 32 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Verilog and VHDL Compared VerilogVHDL Structurell Hierarchyll Separate interfacesl Concurrencyll Switch-level modelinglm Gate-level modelinglm Dataflow modelingll Procedural modelingll Type systeml Event accessl Local variablesl Shared memorylm Wiresll Resolution functionsl

34. - 33 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Outline of the class HDL-based design  HW design flow  Overview of VHDL System design with SystemC  Overview of SystemC  SystemC based (HW/SW) design

35. - 34 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund System Design Methodology System Specification (C) HW (HDL) SW (C) Testbench 0101011110100010 1110010100100111 1000011110101001 0001100110101011... Translate Refine

36. - 35 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Software Languages Goal: specify machine code concisely Sequential semantics:  Perform this operation  Change system state Raising abstraction: symbols, expressions, control-flow, functions, objects, templates, garbage collection

37. - 36 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Software Languages C  Adds types, expressions, control, functions C++  Adds classes, inheritance, namespaces, templates, exceptions Java  Adds automatic garbage collection, threads  Removes bare pointers, multiple inheritance Real-Time Operating Systems  Add concurrency, timing control

38. - 37 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Software methodology C  Divide into (recursive) functions C++  Divide into objects (data and methods) Java  Divide into objects, threads RTOS  Divide into processes, assign priorities

39. - 38 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund SystemC Objectives:  Model Hw with Sw programming language  Achieve fast simulation  Provide support for hw/sw system design Requirement:  Give hw semantics to sw models Supported by a large consortium of semiconductor and EDA companies

40. - 39 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund SystemC C++ class library and modeling methodology  Hw semantics defined through the class library Object-oriented style  Components and encapsulation No language restriction or addition Some hw synthesis support

41. - 40 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund SystemC features Enable C++ without extending the language (syntax) - use classes Concurrency Notion of Time Communication Reactive Behavior Hardware Data Types bit vectors, arbitrary precision signed and unsigned integers, fixed-point numbers Signals, protocols Clocks Watching Processes

42. - 41 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Model Structure

43. - 42 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund SC_MODULE SystemC Classes Modules and Ports Modules ( sc_module )  Fundamental structural entity  Contain processes  Contain other modules (creating hierarchy) Ports( sc_in<>,sc_out<>,sc_inout<> )  Modules have ports  Ports have types  A process can be made sensitive to ports/signals in1 clk in2 out1 out2

44. - 43 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund SC_MODULE in1 clk in2 out1 out2 SystemC Classes - Processes Processes  Functionality is described in a process  Processes run concurrently  Code inside a process executes sequentially  SystemC has three different types of processes SC_METHOD SC_THREAD SC_CTHREAD PROCESS

45. - 44 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Process types sc_method: method process  sensitive to a set of signals  executed until it returns sc_thread: thread process  sensitive to a set of signals  executed until a wait() sc_cthread: clocked thread process  sensitive only to one edge of clock  execute until a wait() or a wait_until()  watching(reset) restarts from top of process body (reset evaluated on active edge) RTL style Architectural style Testbench

46. - 45 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Execution of processes Not hierarchical, communicate through signals Execution and signal updates  request-update semantics 1. execute all processes that can be executed 2. update the signals written by the processes 3.  other processes to be executed module ex port aport b internal signal sig process

47. - 46 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Channels Primitive Hierarchical

48. - 47 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Communication semantics Interface Method Calls (IMC)  Process calls an interface method of a channel  The collection of a fixed set of communication Methods is called an Interface (virtual object without data)  Channels implement one or more Interfaces  Modules can be connected via their Ports to those Channels

49. - 48 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Specification model PE*-assembly model Bus-arbitration model Time-accurate communication model Cycle-accurate computation model Implementation model Model types TLM * Processing elements

50. - 49 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund PE-assembly & Bus-arbitration Models Processing elements (PEs) Message-passing channels Abstract bus channels Bus arbiter arbitrates bus conflict

51. - 50 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Time-accurate Communication model Time/cycle accurate communication (time constraint) Approximate timed computation Protocol channel provides functions for all abstraction bus transaction

52. - 51 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Cycle-accurate computation model Modeled at register-transfer level PE are pin accurate and execute cycle-accurately Wrappers convert data transfer from higher level of abstraction to lower level abstraction

53. - 52 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Successive refinements

54. - 53 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund SystemC Design Vision SystemC as a single design language System Specification (SystemC) HW (SystemC) SW (SystemC) Testbench 0101011110100010 1110010100100111 1000011110101001 0001100110101011... Refine

55. - 54 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Pure SystemC Flow

56. - 55 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund SystemC HDL Flow

57. - 56 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Benefits of a C/C++ Design Flow  Productivity aspect Specification between architect and implementer is executable High speed and high level simulation and prototyping Refinement, no translation into hardware  System level aspect Tomorrow’s systems designers will be designing mostly software and less hardware ! Co-design, co-simulation, co-verification, co-debugging,...  Re-use aspect Optimum re-use support by object-oriented techniques Efficient testbench re-use Especially C/C++ is widespread and commonly used !

58. - 57 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Drawbacks of a C/C++ Design Flow  C/C++ is not created to design hardware !  C/C++ does not support Hardware style communication - Signals, protocols Notion of time - Clocks, time sequenced operations Concurrency - Hardware is inherently concurrent, operates in parallel Reactivity - Hardware is inherently reactive, responds to stimuli, interacts with its environment (requires handling of exceptions) Hardware data types - Bit type, bit-vector type, multi-valued logic types, signed and unsigned integer types, fixed-point types  Missing links to hardware during debugging

59. - 58 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund The missing link: SystemC Synthesis SystemC is not “born” to be a language for HW implementation (like Verilog & VHDL) Someone does not think so (and it would be nice if they were right)  Basic idea: define synthesizable SystemC subset  Make it another refinement step But will it succeed? Long story… [Celoxica 2005]

60. - 59 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Open Community Licensing How to get SystemC ?

61. - 60 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund SystemC Design Methodology

62. - 61 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Bottom-up alternatve: System Verilog Extensions to Verilog HDL  Modeling: Transaction-level modeling –Higher abstraction level Direct Programming interface –Enables calls to C/C++/SystemC –Co-simulation Verilog/SystemC Interface modeling with encapsulation –Support bus-intensive design –IP protection by nesting modules  Verification: Procedural assertions –Built into the language –Avoid recoding errors, increase test accuracy Is it only syntactic sugar? Long story…

63. - 62 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund SystemC contrasted with other design languages

64. Levels of abstraction

65. - 64 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund System level  The term system level is not clearly defined.  It is used here to denote the entire embedded system and the system into which information processing is embedded, and possibly also the environment.  Such models may include mechanical as well as information processing aspects, and may be difficult to find appropriate simulators. Solutions include VHDL- AMS, SystemC or MATLAB. MATLAB and VHDL-AMS support modeling partial differential equations.  Challenge to model information processing parts of the system in such a way that the simulation model can also be used for the synthesis of the embedded system.

66. - 65 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Algorithmic level  Simulating the algorithms that we intend to use within the embedded system.  No reference is made to processors or instruction sets.  Data types may still allow a higher precision than the final implementation.  If data types have been selected such that every bit corresponds to exactly one bit in the final implementation, the model is said to be bit-true. Translating non-bit-true into bit-true models should be done with tool support.  May consist of single processes or of sets of cooperating processes.  Simulating the algorithms that we intend to use within the embedded system.  No reference is made to processors or instruction sets.  Data types may still allow a higher precision than the final implementation.  If data types have been selected such that every bit corresponds to exactly one bit in the final implementation, the model is said to be bit-true. Translating non-bit-true into bit-true models should be done with tool support.  May consist of single processes or of sets of cooperating processes.

67. - 66 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Algorithmic level: Example: -MPEG-4 full motion search - for (z=0; z<20; z++) for (x=0; x<36; x++) {x1=4*x; for (y=0; y<49; y++) {y1=4*y; for (k=0; k<9; k++) {x2=x1+k-4; for (l=0; l<9; ) {y2=y1+l-4; for (i=0; i<4; i++) {x3=x1+i; x4=x2+i; for (j=0; j<4;j++) {y3=y1+j; y4=y2+j; if (x3<0 || 35<x3||y3<0||48<y3) then_block_1; else else_block_1; if (x4<0|| 35<x4||y4<0||48<y4) then_block_2; else else_block_2; }}}}}}

68. - 67 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Instruction level Algorithms have already been compiled for the instruction set of the processor(s) to be used. Simulations at this level allow counting the executed number of instructions. Variations:  Simulation only the effect of instructions  Transaction-level modeling: each read/write is one transaction, instead of a set of signal assignments  Cycle-true simulations: exact number of cycles  Bit-true simulations: simulations using exactly the correct number of bits

69. - 68 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Instruction level: example Assembler (MIPS)Simulated semantics and $1,$2,$3 Reg[1]:=Reg[2]  Reg[3] or $1,$2,$3 Reg[1]:=Reg[2]  Reg[3] andi $1,$2,100 Reg[1]:=Reg[2]  100 sll $1,$2,10Reg[1]:=Reg[2] << 10 srl $1,$2,10Reg[1]:=Reg[2] >> 10

70. - 69 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Register transfer level (RTL) At this level, we model all the components at the register- transfer level, including - arithmetic/logic units (ALUs), - registers, - memories, - muxes and - decoders. Models at this level are always cycle-true. Automatic synthesis from such models is not a major challenge.

71. - 70 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Register transfer level: example (MIPS) Controller B PC Instruction register IR Memory Speicher alu_ control T sign_ extend <<2 4 * ALU Reg 0 0 0 0 0 0 1 1 1 1 1 1 2 2 3 § 31:26 25:21 20:16 25:0 15:0 15:11 i2 a2 a1 i3 a3 a2 a1 o2 o1 PCSource TargetWrite ALUOp ALUSelA ALUSelB RegWriteRegDest MemToReg IRWrite MemRead MemWrite PCWrite PCWriteC IorD * § 31: 28 "00“

72. - 71 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Gate-level models  Models contain gates as the basic components.  Provide accurate information about signal transition probabilities and can therefore also be used for power estimations.  Delay calculations can be more precise than for the RTL. Typically no information about the length of wires (still estimates).  Term sometimes also employed to denote Boolean functions (No physical gates; only considering the behavior of the gates). Such models should be called “Boolean function models”.

73. - 72 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Gate-level models: Example source: http://geda. seul.org/ screenshots/ screenshot- schem2.png

74. - 73 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Switch-level models  Switch level models use switches (transistors) as their basic components.  Switch level models use digital values models.  In contrast to gate-level models, switch level models are capable of reflecting bidirectional transfer of information.

75. - 74 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Switch level model: example Source: http://vada1.skku.ac.kr/ClassInfo/ic/vlsicad/chap-10.pdf

76. - 75 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Circuit level models: Example  Models Circuit theory and its components (current and voltage sources, resistors, capacitances, inductances and possibly macro-models of semiconductors) form the basis of simulations at this level. Simulations involve partial differential equations. Linear if and only if the behavior of semiconductors is linearized. Ideal MOSFET Tran- sistor model

77. - 76 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Circuit level models: SPICE The most frequently used simulator at this level is SPICE [Vladimirescu, 1987] and its variants. Example:

78. - 77 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Circuit level models: sample simulation results

79. - 78 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Device level Simulation of a single device (such as a transistor). Example (SPICE- simulation [IMEC]): Measured and simulated currents

80. - 79 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Layout models  Reflect the actual circuit layout,  include geometric information,  cannot be simulated directly: behavior can be deduced by correlating the layout model with a behavioral description at a higher level or by extracting circuits from the layout.  Length of wires and capacitances frequently extracted from the layout, back-annotated to descriptions at higher levels (more precision for delay and power estimations).

81. - 80 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Layout models: Example din powlo powhi dout © Mosis (http://www. mosis.org/Technical/ Designsupport/ polyflowC.html); Tool: Cadence

82. - 81 -  P.Marwedel, U. Dortmund, Informatik 12, 2006 Universität Dortmund Process models Model of fabrication process; Example [IMEC]: Doping as a function of the distance from the surface Simulated Measured