ELEC 516 VLSI System Design and Design Automation

ELEC 516 VLSI System Design and Design Automation Spring 2010 Lecture 2 Hardware Modeling Note: some of the figures in this slide set are adapted from the slide set of “ Modern VLSI Design” by Wolf, Copyright Pentice Hall 2002 1

Why do we need HDLs? z A specification is an engineering contract that includes not only functionality but also performance. z Top-down design: Partition the project into modules with well-defined specifications and interfaces, so that partition of tasks can be performed effectively. z A Behavioral model serves as a description of all the specifications of the project and document the function of all individual blocks and their interfaces. z In large digital designs: We need to talk about what hardware is required without actually designing the hardware itself: We need a Hardware Description Language HDL. z If we are able to Synthesize the hardware from the behavioral model, the target will be met. 2 ELEC 516/10 Lecture 2

Hardware description languages z Textual languages for describing hardware: y. Behavior xthe functional interpretation of a particular system. ystructure; z Most people today use textual languages rather than schematics for most digital design. y. Schematics make poor use of screen space. z Two major HDLs designed for simulation: y. VHDL; y. Verilog. y. Similar capabilities but somewhat different language philosophies. z EDIF - a standard netlist format 3 ELEC 516/10 Lecture 2

HDL - Simulation Oriented z Difference between HDL and conventional software programming language: y. Notion of simulation y. Simulation tags computations with times. x. Must know when signals change to properly simulate hardware. y. Simulation is parallel. x. Many statements can execute at the same (simulation) time. x. Just like hardware. 4 ELEC 516/10 Lecture 2

Advantages for Digital Design z Portability z Modeling capability (several levels) z Technology and foundry independence z Reusability z Early verification/simulation of functionality 5 ELEC 516/10 Lecture 2

Behavioral Hardware Modeling Behavioral modeling z Combinational logic circuits can be described by a set of ports (inputs/outputs) and a set of equations that relate variables to logic expressions z describes the functional relationship between inputs and outputs. y. Similar to programming but values are events. z The circuit can be seen as an interconnection of operators, each operator evaluates a logic function. z These models differ from structural models in that there is not a one-to-one correspondence between expressions and logic gates, because for some expressions there may not exist a single gate implementing it. 6 ELEC 516/10 Lecture 2

Behavioral Hardware Modeling A half-adder circuit example architecture BEHAVIOR of HALF_ADDER is process begin carry <= (a and b); sum <= (a xor b); end process; end BEHAVIOR; 7 ELEC 516/10 Lecture 2

Simple Example 8 ELEC 516/10 Lecture 2

Structural Hardware Languages z Describe an interconnection of components. z Expressive power is similar to that of circuit schematics. z Hierarchy is often used to make the description modular and compact. z The basic features of structural languages place them close to the declarative class, even though some structural languages have also procedural features. 9 ELEC 516/10 Lecture 2

Example 1: half-adder in VHDL architecture STRUCTURE of HALF_ADDER is component AND 2 port (x, y: in bit; o: out bit); component EXOR 2 port (x, y: in bit; o: out bit); begin G 1: AND 2 b port map (a, b, carry); G 2: EXOR 2 port map (a, b, sum); 10 x y a b o x o y sum carry ELEC 516/10 Lecture 2

Example 2: A Language for Describing netlists z describe a digital system by its netlist; z specifies primitive gate types and their rise and fall delay CCT full_adder(a, b, c, s, co) a b c g 1 g 2 g 3 g 4 11 w 1 g 5 s w 2 w 3 w 4 g 6 co XOR(Rise=16, Fall=12) g 1(w 1, a, b), g 5(s, w 1, c); AND(Rise=12, Fall=10) g 2(w 2, c, b), g 3(w 3, c, a), g 4(w 4, b, a); OR(Rise=12, Fall=10) g 6(co, w 2, w 3, w 4); INPUT a, b, c; WIRE w 1, w 2, w 3, w 4; OUTPUT s, co ENDCIRCUIT full_adder ELEC 516/10 Lecture 2

3 rd Example: SPICE netlist * net 1 = vdd! z * net 0 = gnd! z * net 2 = /p 6 z * net 3 = /g 4 z * net 4 = /Y<0> z * net 5 = /A<10> z * net 6 = /p 7 z * net 7 = /g 5 z * net 8 = /Sum<1> z * net 9 = /X<4> z * net 10 = /g 6 z * net 11 = /p 8 z * net 12 = /A<7> z * net 13 = /p 9 12 . model 4 nmos level=3 vto=0. 7459 +nsub=4. 547 e+16 kp=0. 00011169 lambda= +vmax=190000 xj=1. 7 e-07 ld=4. 157 e-08 +cgbo=3. 8876 e-10 cgdo=3. 9 e-10 cgso=3. +cj=0. 00026613 cjsw=5. 3766 e-10 mj=1. 0 +rsh=14. 19 delta=0. 8197 kappa=0. 07784 * nmos_hp 08(0) = /I 81/N 3 m 0 82 103 0 0 model 4 w=11. 2 u l=0. 8 u * nmos_hp 08(1) = /I 81/N 2 m 1 103 21 0 0 model 4 w=8. 4 u l=0. 8 u. model 5 pmos level=3 vto=-0. 874 +nsub=2. 659 e+16 kp=3. 0474 e-05 lambda= +vmax=212900 xj=2 e-07 ld=9. 903 e-10 th +cgdo=3. 9 e-10 cgso=3. 9 e-10 tox=1. 77 e+cjsw=1. 7481 e-10 mj=0. 5159 mjsw=0. 258 +delta=0. 8062 kappa=0. 01 eta=0. 02551 * pmos_hp 08(2) = /I 81/P 1 m 2 1 103 82 1 model 5 w=20. 4 u l=0. 8 u * pmos_hp 08(3) = /I 81/P 0 m 3 1 21 103 1 model 5 w=8. 4 u l=0. 8 u ELEC 516/10 Lecture 2

Testbench z A testbench is a model used to exercise a simulation. y. Provides stimulus. y. Checks outputs. z Testbenches help automate design verification. y. Rerun edited module against testbench. y. Run models at behavioral, RTL levels against the same testbench. 13 ELEC 516/10 Lecture 2

Example of using test bench z Test bench - top level entity to test the other entity. z The test bench must contain the circuit under test and should have sources for providing data to its input Entity TEST_BENCH begin is end TEST_BENCH; L 1: ONES_CNTA use WORK. all; port map(A, C); architecture ONES_CNT 1 of process TEST_BENCH is signal A: BIT_VECTOR(2 downto begin 0); A<= “ 000” after signal C: BIT_VECTOR(1 “ 001” after downto 0); “ 010” after component ONES_CNTA “ 011” after port(A: in BIT_VECTOR(2 “ 100” after downto 0); “ 101” after C: out NIT_VECTOR(1 “ 110” after downto 0)); “ 111” after end component; for L 1: ONES_CNTA use entity wait; end process; ONES_CNT(ALG) 14 1 ns, 1 ns, 1 ns; end ONES_CNT 1; ELEC 516/10 Lecture 2

Synthesizable code vs. simulatable code z VHDL and Verilog were designed for simulation. z A synthesis subset is: ysynthesizable; yproduces consistent simulation results. z Different tools may use different synthesis subsets. z Register-Transfer synthesis y. Most common type of synthesis. y. Synthesizes gates from abstract RT model. x. Registers are explicit. x. Some tools will infer storage elements---be careful. y. Optimized for performance, area, power. 15 ELEC 516/10 Lecture 2

Abstract Models z represent different circuit views at the logic and architectural levels so that it can be manipulated inside the computer. Structural Models z Model as a netlist: A netlist enumerates all nets of a given module (module-oriented netlist) or all modules of a given net (net-oriented netlist) n 1 p 4 m 1 p 6 16 p 2 p 3 n 2 n 3 m 2 p 5 p 7 m 1: n 1, n 2, n 3 m 2: n 1, n 2 m 3: n 2, n 3 m 3 ELEC 516/10 Lecture 2

State Diagrams z Sequential circuits at the logic level can be described by a finite-state machine transition diagrams which has y. A set of primary input patterns X y. A set of primary output patterns Y, y. A set of states S, y. A state transition function d: X*S->S, y An output function l: X*S->Y for Mealy models or l: X->S for Moore models y. An initial state. z The state transition diagram is a labeled directed multigraph Gt(V, E) where the vertex set V is in one-to-one correspondence with the state set S and the directed edge set E is in one-to-one correspondence with the transitions specified by d. 17 ELEC 516/10 Lecture 2

An example of a state transition diagram a’b’+r/0 S 0 r/0 a’b’r/0 S 1 r/0 a’br’/0 abr’/1 r/0 S 2 a’r’/0 b’r’/0 ar’/1 br’/1 S 3 r’/1 18 ELEC 516/10 Lecture 2

Data Flow Graph z Abstract models of behavior at the architectural level are in terms of operations and their dependencies. z Several different Dependencies ydata dependency y serialization constraints in the specification. A task may have to follow a second one. Example: loading data on a bus and then raising a flag. ydependency due to resource conflict: two tasks share the same resource (operator) z Data flow graphs represent operations and data dependencies. Let the number of operations be nops. A data flow graph Gd(V, E) is a directed graph whose vertex set V = {vi; i = 1, 2, . . . , nops} is a one-to-one correspondence with the set of tasks. 19 ELEC 516/10 Lecture 2

Examples of a dataflow graph xl = x + dx; ul = u - (3*x *u *dx) - (3 * y * dx); yl = y + u * dx; c = xl < a; 20 ELEC 516/10 Lecture 2

VHDL register transfer level modeling z VHDL - usable for design documentation, high-level design, simulation, synthesis and testing of hardware, as well as a driver for a physical design tool z Combines a general-purpose programming language and an HDL. y. Modeled on Ada programming language. z VHDL is a rich language: yconcurrent language yhierarchical ymodules; yabstract data types. 21 ELEC 516/10 Lecture 2

System Level Modeling z Modern So. C well contains y. Multiple processor cores, MCUs or DSPs or specialized media processors y. On-chip memory y. Accelerating hardware units for dedicated functions y. Peripheral control devices y. Complex on-chip communication networks and protocol y. Software components on the processor core and protocol, hardware components for accelerator. z Need modeling language beyond RT level abstraction used with the old HDLs. y. To specify, design, and implement complex system , incorporating functionality implemented in both hardware and software forms. 22 ELEC 516/10 Lecture 2

Requirement of system modeling language z Specification and design at various levels of abstraction z Incorporation of embedded software portion of a complex system, both models and implementation-level code z Creation of executable specification of design intent z Creation of executable platform models z Fast simulation speed z Constructs allowing separation of system function from system communications, in order to allow flexible adaptation and reuse of both model and implementation 23 ELEC 516/10 Lecture 2

System. C – a system modeling and design language z Object-oriented language base allow for modeling flexibility and facilitate reuse z To facilitate reuse, the following are incorporated in System. C y. Functionality and interface definition are separated y. Abstract and concrete data-types and ports y. Interface attributes y. A transaction/messaging concept 24 ELEC 516/10 Lecture 2

System. C language architecture 25 ELEC 516/10 Lecture 2