Behavioral Design Outline –Design Specification –Behavioral Design –Behavioral Specification –Hardware Description Languages –Behavioral Simulation –Behavioral Verification –Behavior-Implementation Linkage Goal –Understand behavioral design –Overview HDLs –Overview simulation and verification

Design Specification Describe desired system –signal processing - frequency response –protocols - state diagrams, Petri nets –bus interface - timing diagram –processor - instruction set –be as precise as possible »avoid ambiguity »help clarify design goals Validation - are we building the right product? –rapid prototyping »quickly try out idea »let users play with it No real formal hardware design spec languages Problems very similar to those of software systems

Behavioral Design Map design spec to formal behavioral spec –algorithmic description of design –examples »low-pass filter => finite impulse response filter »CPU architecture => fetch-decode-execute cycle Approach –write behavioral hardware description language (HDL) »use off-the-shelf libraries –verify it has same function as design specification »usually through simulation –synthesize structural description –feedback to design spec, from structural spec X(i) = W(i-1)*X(i-1) + W(i-2)*X(i-2) +...

Hardware Description Languages Special-purpose languages –special constructs for hardware description –timing, concurrency, bit vectors, etc. –examples »ISP »Verilog - see Weste Sec 1.6.1, »VHDL Standard programming languages –support advantage –add data types and objects for hardware description –examples »C »C++ »Smalltalk »LISP »Simula - original OO language, CSP sim. support

Model Libraries Model - behavioral description of component Components –vendor-supplied chip »e.g behavioral description –module within a chip »e. g. LSI Logic microprocessor core Model suppliers –chip vendor –CAD tool vendor –model library company - e.g. Logic Automation Inc. Problem –more than one HDL –more than one behavioral simulator –solutions »multi-HDL simulator - e.g. Redwood VHDL-Verilog simulator »common data flow interchange language - benchmarks

Behavioral Simulation Methods of simulation –event-driven simulation »variable changes and signals are events –(compile and) execute program –observation »“debugger” »dump all variables and browse Simulation model uses –verify with design specification –develop manufacturing tests –develop software to execute on hardware »e.g. compiler for new CPU architecture

Behavioral Verification Verification - are we building the product right? Is description self-consistent? –static analysis - e.g. lint syntax, semantics –dynamic analysis - type checking, access violations, etc. Does behavioral function match design spec? –static analysis - same number of I/Os, instruction encodings –simulation - observe behavior and compare –primary limitation is vagueness of design spec –cannot exhaustively simulate –can miss design corners »page fault while taking interrupt after floating-point error

Behavioral Synthesis Map behavior to structure Optimize - like compiler –loop unrolling - pipelining –code motion - moving between clock cycles –strength reduction - multiply => add Map to structure - like code generation –assign “instructions” to RTL components »partitioning into chips »limited package bandwidth –assign to clock cycles in sequential design »meet timing constraints More complex than software compiler –more complicated constraints –more like compiling for heterogeneous parallel processor if (a == b) out = 1; else out = 0;

Behavior-Implementation Linkage Behavioral spec influences implementation –shows up in structural design –hard to completely eliminate behavioral spec biases –analogous to programming »compiling program for parallel vs. serial machine Structural design style known - no problem –e.g. CSP behavior => pipelined structure –1:1 behavior-structure mapping Remapping old behavior - could be hard –VAX behavior to superscalar implementation Feedback from structural, physical design –were design goals met during synthesis May have to modify behavior –to avoid influencing tools –to meet design goals

Hardware/Software Co-Design Most products are hardware + software –current practice »agree on hardware design specification »build hardware and software separately »integrate them –problems »potentially long feedback path »forces all HW/SW tradeoffs to hardware design spec »error-prone Solution: CAD tools synthesize HW and SW –in limited domains »controller - state diagram, control equations »DSP - transfer characteristic –new research area - see DAC, ICCAD proceedings Mem CPU I/O world SW HW