TKT-1212 Digitaalijärjestelmien toteutus

Transcription

1 TKT-1212 Digitaalijärjestelmien toteutus Lecture 8 Simulation engines Erno Salminen 2013 transmogrify. vhd Source codes Simulation engine Wave viewer

2 Contents Modeling dimensions 1. Temporal 2. Data abstraction 3. Functional 4. Structural Basic simulator types 1. Event-driven simulation engines 2. Cycle-based simulation engines Waveform viewers and summary

3 Introduction Simulation-based verification is the most common way ensure functional correctness The heart is the simulation engine Models the behavior of the design and its environment Original slides created by Ari Kulmala This presentation is based on the book Comprehensive Functional Verification: The Complete Industry Cycle by Bruce Wile, John Goss, and Wolfgang Roesner Some examples obtained from Mentor Modelsim manual 3

4 Modeling dimensions Model is a simplification of reality and every system is best approached through a small set of nearly independent models Booch & Rumbaugh 4

5 Modeling dimensions#1: Temporal 1. Temporal dimension -Behavior over time, i.e. when the state changes I/Os represent the state of the DUV Causality means that output events do notoccur before the inputs that caused them a) Continuous time (Analog) Fairly close to physical properties of electrical circuit b) Discrete event Digital, electrical properties abstracted, delta delay, events occur seemingly simultaneously Various resolutions: 1fs, 1ns, clock cycle, transaction c) Timeless No regard of time stamps, just causality 5 Slightly different categories than course book. Note that terminology about models of computation (MoC) is sometimes confusing. See also: [E.A. Lee, A.Sangiovanni-Vincentelli, A Framework for Comparing Models of Computation, IEEE TCAD, Dec ]

6 Modeling dimensions #2: Data 2. Data abstraction - Signal values a) Continuous range (analog) E.g. voltage measurement, arbitrarily accurate real numbers b) Discrete values Bits, strings, integers, states E.g. std_logic: 1, 0, u, x, z, H, L Abstract values, e.g. user defined enumeration states Main, read_io, write_io Structs combine several abstract values 6

7 Modeling dimensions #3: Function 3. Functional Dimension May just be Continuous mathematical functions (e.g. Spice simulator) Select level of abstraction Transistors -> switches -> Boolean Logic -> Algorithms (RTL) -> Abstract mathematical formula E.g.: a) Boolean (half) adder: z0 = x0 xor y0 C1 = x0 and y0 b) Algorithm + (automatic implementation or user defined) c) Abstract formula The whole functionality is specified with abstract implementation-independent notations x=(2+y)^z mod a 7

8 Modeling dimensions #4: Structure 4. Structural Dimension a) Flat (single black box) No structurality, just implementation, eg. FFT with abstract mathematical formula Input FFT Output b) Hierarchical Implementation is structural Many subblocks Many components that have subblocks E.g. FFT has subblocks for add and multiply Input + FFT + Output * * 8

9 VHDL support for modeling dimensions Temporal Data Continuous Gate Delay Clock Cycle Intruction Cycle Events Continuous Multivalue Bit Bit Abstract Value Struct Functional Continuous Switch Level Boolean Logic Algorithmic Abstract Mathematical Structural Single black box Functional blocks Detailed component hierarchy 9 Verilog s support

10 Modeling compromise: Speed vs. Accuracy More speed more abstract models more test cases executed in unit time, but less accuracy. Designers should start with high-level models Basic verification, something like this could work Gradually refine the models if needed Simulation runtime and memory requirements RTL Style Gate-level style Gate-level with detailed delays 10 Model details and accuracy

11 Basic HDL simulator block diagram Interactive user control GUI control check HDL model of DUV check stimulus HDL Testbench HDL Model Simulation engine Trace Files Interactive waveform viewer GUI Coverage Files Interactive coverage analysis GUI 11

12 Waveform Viewers Every simulator can produce a trace file At minimum, symbol name and signal value contained Unfortunately, EDA vendors all have own file formats Usual difference is the compression, because in large simulations, data amount is very high Waveform viewers share very common looking GUI GTK wave viewer is a free tool that supports many different formats Search capabilities are required for usability Certain transitions on a signal Specific values Useful to compare two wave traces (e.g. after bug fix) 12

13 Simulation engine types Evaluate HDL model over time and present its state Standardization: The HDL language reference manual (LRM) defines the behavior of the simulation engine. 1. Evaluate signals and blocks only at model times for which events are scheduled Event-driven simulation engines Majority of simulators are in this category, e.g. ModelSim and GHDL Evaluate only the active parts 2. Evaluate the model at every point of time along the finest granularity known to the simulation engine Cycle-based simulation engines Simpler simulator and hence faster Commonly evaluate the whole model regardless of activity 13

14 Event-driven simulation engines

15 Event-driven simulation Most popular approach, Used also in other areas since it is very general approach Channels or signals transfer data between blocks Blocks process data at its inputs which may initiate a new transfer. Essential properties: 1. Evaluate model behaviour only at those times when model events are scheduled 2. Evaluate behavior only for the blocks or signals for which events are scheduled Event = change in signal s value 15

16 Event-driven simulation (2) Evaluating time: Simulator keeps track of current time and when events are scheduled to happen The model objects need to notify the simulation engine about future changes scheduling engine may skip unused time intervals Scheduling is done in internal time intervals, if no delay is specified Zero-delay scheduling (delta delay), most usual in RTL Each scheduling step evaluation creates a resulting update to the next occuring step Parallel updates are handled sequentially by the engine, effectively randomly Signal changes propagate through the model as the scheduling progresses 16

17 Simulator example Simulating a top level having two blocks, which contain 3 sub-blocks, b1, b2, c1. i1 a1s1 i2 a2s2 B1 s3 s4 a3 a4 s7 s8 C1 a7 o1 Signal directions imply partial order for the evalutation. s5 B2 a5 s6 s9 a6 E.g. a3 after s3 and a4 after s4, but no relation between a3 and a4 o2 17 inputs model outputs

18 Sim. example: evaluation over time A change occurs in i1 Simulator starts to evaluate the model over time by steps (delta delay) i1 a1s1 i2 a2s2 B1 s5 s3 s4 B2 s6 a3 s7 a4 s8 a5 a6 C1 s9 a7 o1 o2 Signal update Block evaluation inputs model outputs Blocks might be evaluated twice (due to both inputs) s3 a3 s7 C1a7 o1 i1 a1 s1 B1 s4 B2 s6 a6 o2 time 18 Simulator engine s scheduling step (=delta)

19 Another example 1. s7 3. s9 s8 2. s10 s11 4. s12 s

20 Another example: Update sequence Note: C1 evaluated twice

21 Event-driven simulation and HDL VHDL and Verilog specifications include the assumption of underlying event-driven simulator Cyclic process 1. Update signals 2. Execute processes (concurrent statements are actually also processes) 3. Adavance global time Feedback loops may cause endless oscillation User or the engine must take action to interrupt uncontrolled oscillation Usually bad HDL design, e.g. combinatorial loop Modelsim complains something like Zero delay oscillation at 21

22 ModelSim general flow Source: Modelsim manual 22

23 Inside the event-driven simulator The three basic core data structures of the event-driven simulation engine 1. A list of all executable blocks present in the model network 2. Data structure that shows the connections between blocks via signals 3. A value table that holds all current signal values Activity and time progress controlled by so called time wheel At zero time, all executable blocks are scheduled In VHDL, all processes and concurrent assignments At 0 ns, there might be lots of warnings due to unknown signal values. Usually harmless but ugly Each time wheel entry has a to-do list Assignments scheduled to happen at that point 23

24 Example of how network view is constructed from VHDL user-defined signal name simulator s internal signal 24

25 Time wheel and to-do lists a xor b a and b New to-do lists may be added in between the existing ones c(0)<= Now +1ns Now +2ns 25

26 Signal assignment and drivers 1. concurrent - in an architectural body Signal activities control not top-down flow - their execution order 2. sequential - inside a process, top-down ordering The value on the right side will be scheduled for the left side Value is placed on the driver of the left-hand side signal Multiple concurrent assignments produce multiple drivers That is legal if the signal type defines resolution function which resolves a single value from multiple drivers Sequential body (i.e. process) may have multiple assignments but they produce only a single driver Note that this includes both sequential (synchronous) and combinatorial (asynchronous) processes The last assignment in HDL is kept Last assigned value (in time) is kept unless otherwise stated may require state-holding logic in synthesis (DFF or latch)

27 Events and transactions Signal assignment may have an associated delay An event occurs when a signal changes its value If the same value is assigned again, there is no event When a value is scheduled to be assigned to a target signal after a given time, a transaction has been placed on the driver A transaction may assign the same value again, but no event occur Transaction is represented with value-time tuple <new_value, time>

28 Events and transactions (2) target_signal <= v after d; t+ t+ t+ At time t, new value v is computed from the righthand side Assignment specifies also delay d transaction tr i = (v,d) is placed on the driver At time t+t 0, time component of the transaction tr i has decresed to d-t0 At time t+t 1, time component decreases further At time t+d, time component becomes 0 and transaction expires Target signal get the value v

29 Transaction example event expiration, but no event (0,05) (1,10) a b c

30 Events and sensitivity list Simulation engine considers events of only those signals that are included in sensitivity list Example1: combinatorial process comb_foo: process (a_in, b_in)... No need to simulate this when, e.g. clk changes However, it could be simulated but that would not change any value (since the needed inputs are stable) waste of simulation time b_in clk rst_n others a_in comb_foo... assigned signals (Avoid reading these outputs in the same process or putting any of them into sens.list! That may easily create a combinatorial loop, i.e. random oscillator and infinite loop in simulator.)

31 Events and sensitivity list (2) Example 2: synchronous process sync_bar: process (rst, clk) begin if(rst = '0')then s0 <= '0'; elsif(clk'event and clk='1') then... <statements> After reset, process will be simulated on every clock edge But statements inside elsif-branch executed only at rising clock edge One could include all signals that are read in statements their events do not occur at the same time with clk event waste of time a_in b_in clk rst_n others not needed in sens.list sync_bar (in simulator)... assigned signals (These will change just after the clk edge and these can be read inside sync_bar )

32 Events and sensitivity list (3) Synthesis tool does not care about sensitivity list! All necessary signals (those that are read) will go into the logic cloud! All signals assigned inside if-branch with x event and x= 1 create register whose clk input is connected to signal x Detecting edge on arbitrary control signal must be coded explicitly Compare values from two consecutive clk cycles: if (a_old_r /= a_in) Nested events won t produce any meaningful logic a_in sync_bar (synthesized HW) b_in comb logic... assigned signals clk rst_n others

33 Real vs. delta delays in VHDL 1. Real delays: inertial, reject-inertial transport See last lecture Model the gate and wire delays 2. Delta delays Simulator s concept to deal with seemingly concurrent events Multiple signals may need updating, statements that are sensitive to these signals must be executed, and any new events that result from these statements must then be queued and executed as well The steps taken to evaluate the design without advancing simulation time are referred to as "delta times" or just "deltas. An infinitesimal interval Waveform shows the same global time no matter how many delta delays elapses This mechanism may cause unexpected results

34 Delta delay example Event at upper input propagates through logic AND will be evaluated twice Firts, it rises and then falls again You ll notice a glitch in signal C at 20ns in wave window 20 Fig2. ModelSim s list view 25 Fig1. Conceptual timing Fig3. ModelSim s wave view

35 Delta delay may cause problems The execution order of components with zero delay is unclear, e.g. two processes Simulator assumes some order and may evaluate the same process multiple times The order may change between compilations This is bad problem, if signal value is momentarily out of range of its type Luckily, this is quite rare Just like the glitch in previous example. For example, integer range 0 to 10 goes to 11 and then returns to valid value

36 Example of delta delay problem clk2 <= clk; seq0: process (rst, clk) begin if(rst = '0')then s0 <= '0'; elsif(clk'event and clk='1') then s0 <= inp; end if; end process; Desired HW: this is what you would expect inp clk seq0 seq1: process (rst, clk2) begin if(rst = '0')then s1 <= '0'; elsif(clk2'event and clk2='1') then s1 <= s0; end if; end process; rst_n clk2 seq1 s0 s1

37 Delta delay problem in simulator clk2 <= clk; seq0: process (rst, clk) begin if(rst = '0')then s0 <= '0'; elsif(clk'event and clk='1') then s0 <= inp; end if; end process; In real HW, similar problem are caused by clock skew Wrong value! seq1: process (rst, clk2) begin if(rst = '0')then s1 <= '0'; elsif(clk2'event and clk2='1') then s1 <= s0; end if; end process; 1 These change first, 3 which create new event, Event-queue[t0] Inp= 1 Clk = 0 Inp=1 Clk = 1 Clk2 <=clk seq0: (clk) seq1: (clk2) Signal update queue [t0] (s0=0) clk2=1 s0=1 s1=1 In one simulation round 37 2 then signal updates 4 and last signal

38 Behavior of problematic example code In this example you have two synchronous processes, 1. one triggered with clk 2. one triggered with clk2 To your surprise, the signals change in the clk2 process on the same edge as they are set in the clk process! As a result, the value of inp appears at s0 and s1 in the same simulation cycle During simulation 1. An event on clk occurs (from the testbench). 2. From this event ModelSim performs the "clk2 <= clk" assignment and the process which is sensitive to clk 3. Before advancing the simulation time, ModelSim finds that the process sensitive to clk2 can also be run. In order to get the expected results, you must do one of the following: a) Make certain to use the same clock on both processes or use just one process b) Insert a delay at every output c) Insert a delta delay

39 Event-driven simulation performance Widely used optimization well understood Performance critical portions: Management of to-do lists The time wheel The data that represents model topology When event is evaluated traverse model topology to find signals and blocks to update find the corresponding slots in the time wheel put the corresponding event to the to-do list Model granularity compromise Activity rate affects fine-grained model more than coarse grained model 39

40 40 Granularity vs performance

41 Simulation Performance Simulation throughput Per time spent: Amount of verification, i.e. number of tests Number of cycles Number of distinct states visited and checked Improve throughput: Increase simulation engine performance Or increase the simulated model performance Run simulations in parallel Eliminate redundant simulations Hard to measure The target of the simulation engine: all-around, gate-level, RTlevel? Profiling: which parts of the model are most time consuming E.g. Vsim Tools Profile Performace, then simulate, and view the performance report 41

42 Improving performance Efficiency: time_spent_on_hdl vs. time_spent_on_scheduling Less events, more efficient Speed can be optimized by more abstract HDL: No gate-level structures Integers instead of bit-vectors Standard libraries Binary values over multivalued No delay statements Processes instead of concurrent assignments Process is a pre-scheduled atomic action for simulation engine Variaables are faster than signals Once again, correct functionality and understandability are usually more important 42

43 Example VHDLs Fastest Slowest 43

44 Event driven simulations- the future Significant research on parallel algorithms for simulation engine over the years No breakthrough Seems to be inherently hard to parallelize no commercially available parallel event-driven simulation engine Two alternatives to parallelize 1. Trivial parallelization: Simulation farm Pool of workstations, each running independent simulation 2. Running single model partiotioned and parallelized accross several workstations 44

45 Cycle-based simulation engines

46 Cycle-Based simulation engines Algorithm to evaluate time: Evaluate the model at every point of time along the finest granularity known to the simulation engine E.g. once per clok cycle Based on much simpler algorithms than event-driven sim Superior performance 10x to 20x speed, models 3-10 times smaller Optimized totally for synchronous hardware design style Downsides Severe constraints to HDL design style No delays Limited sequential structures Testbench features of the HDLs largely not supported Testbenches with other languages, APIs 46

47 Cycle-based simulation engines(2) Due to constraints, not commercially accepted (came to market in mid 90s) However, some features have been then integrated to the event-driven simulators Applicable portions of the code are automatically handled with cycle-based fashion, others with event-driven Hybrid simulators Synchronous design Timing verification and functional verification can be separated Modeling properties Zero-delay simulation No combinational feedback loops model must be a directed acyclic graph (DAG) No dynamic block scheduling, evalution times are known 47

48 48 Example model network

49 Cycle-based simulation engines CBSEs typically use an oblivious simulation algorithm Calculates all the combinational functions at every cycle Redundant work: evaluate also parts that do not change simplicity (time wheels and to-do lists removed) No multivalue bits Synchronous do not care about glitches and hazards Simulation model actually becomes a piece of executable code (a program) Each output has a mathematical function dependent of the inputs typical arithmetic optimizations can be used at the compile time (synthesis-like optimizations). e.g. constant propagation, removing redundant logic 49

50 CB model of 2b-adder 50 Compare with the one shown on slide #22 (fig 5.25). Note the absence of delays

51 CBSE extensions In order to be more usable, CBSE s have been extended at the expense of the simulation efficiency Multivalued bits E.g. Busses (three-state), bus driving errors In VHDL, std_logic has 9 different states lots more computation on boolean logic In verilog, there are 4 states for bit Performance degrades 3x-4x Should be selectable feature Multiple clock domains Overclock the simulation of the slower domain However, simulators can never be solely used to quarantee clock domain crossings! Hybrid simulators Events inside CBSE vs. CBSE inside event BSE 51

52 Multiclocking example Slower clock domain clocked with the rate of the faster. (overhead) 52

53 Summary 1. Event driven simulation engine: Most common Supports arbitrary delays Supports a large set of HDL features 2. Cycle-based simulation engine Mostly used to boost simulation within event driven simulation engine Does not support delays (fixed time steps only) Severely restricts usable HDL features Significantly faster than Event DSE Designer can affect simulation speed by design choices More abstract code -> more speed -> less accuracy Balance and compromise! 53

54 Extra

55 Other sources VHDL: Analysis and Modeling of Digital Systems Tekijät Zainalabedin Navabi Julkaisija McGraw-Hill Professional, 1998 ISBN , sivua ay/delay.pdf

56 Typical ED simulator flow 56 no no yes yes

57 Simulator example Simulator checks all projected signal traces Global time is advanced to the next transaction 1 ns, 10ns, 15 ns, 20 ns, 35 ns... S3 has value 10 during 15-20ns After that value is a function of 1 and 10 (not defined here) Projected signal values Fig: [ lect2.frm.pdf]

58 Debugging delta delay problems The best way to debug delta delay problems is observe your signals in the List window. There you can see how values change at each delta time. View -> List Select signal in Object window -> RightMouseButton+Add to List

59 Reminder: Simulator example Simulating a top level having two blocks, which contain 3 sub-blocks, b1, b2, c1. i1 a1s1 B1 s3 a3 s7 C1 a7 o1 i2 a2s2 s4 a4 a5 s8 s9 Signal directions imply partial order for the evalutation. s5 B2 s6 a6 o2 59 inputs model outputs

60 Waveform of Simulator example Initally i1 = 0 i2 = 1 Then i1 goes 1 at 25 ns All signals seem to be updated at once Compile using vcom novopt Otherwise some intermediate signals are optimized away

61 List view of Simulator example Shows the simulation order, i.e. delta delays between assignments What actually happens: Start of simulation, all values U Input values assigned First internal signals (a1, a2)get update Signals propagate... Block b1 sets s3 and s4 a3 and a4 updated, block b2 sets s6 Block c1 sets a7 and s9 Simulation time advances, i1 rises In this example at 0ns, blocks b1 and c1 at were executed once (0ns+3, 0ns+6). Block b2 executed twice: 0ns+4 and 0ns+9. The latter does not chnage the value of s6.

62 Annotated simulator example The annotated delta steps correspond to simulation time 0 ns i1 a1s1 s3 a3 s7 a7 B1 C1 i2 a2s2 s4 a4 s8 a5 s o1 Signal directions imply partial order for the evalutation. s5 B2 s6 a6 o2 62 inputs model outputs

63 Detecting Infinite Zero-Delay Loops If a large number of deltas occur without advancing time, it is usually a symptom of an infinite zero-delay loop in the design. In order to detect the presence of these loops, ModelSim defines a limit, the iteration limit", on the number of successive deltas that can occur. When ModelSim reaches the iteration limit, it issues a warning message. The iteration limit default value is If you receive an iteration limit warning, first increase the iteration limit and try to continue simulation. You can set the iteration limit from the Simulate > Runtime Options menu or by modifying the IterationLimit variable in the modelsim.ini. See Control Variables Located in INI Files for more information on modifying the modelsim.ini file. If the problem persists, look for zero-delay loops. Run the simulation and look at the source code when the error occurs. Use the step button to step through the code and see which signals or variables are continuously oscillating. Two common causes are a loop that has no exit, or a series of gates with zero delay where the outputs are connected back to the inputs.

64 Source: ModelSim SE Userís Manual, v6.2a, June 2006