Event driven simulator

1,905 views

Published on

event driven simulator

Published in: Education, Technology, Design
  • Be the first to comment

  • Be the first to like this

Event driven simulator

  1. 1. EVENT DRIVEN SIMULATION WHY? WHAT? HOW? 1
  2. 2. WHY HDL I THINK “ WE “ are the reason behind the invention of this language. 2 Needs are small Circuit are small Leads to increase in Circuit complexity to Draw Schemetic of more than 600 gates is not possible for us Leads to the development of EDA TOOLS Can be drawn by using boolean algebra , k map etc Now man wants more features in their devices Requirement of a automation tool is required Use to design circuits comprises of millions of transistors Example Synopsys, Cadence Design Systems ,Chrysalis
  3. 3. Hardware Description Languages Special-purpose languages special constructs for hardware description timing, concurrency, bit vectors, etc. can usually include structural description examples  Verilog  VHDL Standard programming languages add data types and objects for hardware description examples  C  C++  Matlab
  4. 4. 4  Simulation is the process of conducting experiments on a model of a system for the purpose of understanding or verifying the operation of the actual system.  In simple words it means 1. Take the input 2. Process the input 3. Output  Simulation in the VHDL/PLD methodology:  Functional verification verifies the functional operation of a description.  Post-synthesis simulation verifies that the synthesizer accurately translated the description to logic.  Timing simulation verifies that the synthesized logic, when mapped to the target PLD, will meet the system’s requirements.
  5. 5. Types of simulations: 1. Behavioral: use the system as black box. 2.Functional: checks the functionality and ignores timing and just include unit delay. 3.Timing : system is partitioned into asic and timing analysis is done. This is called static timing analysis because outputs and inputs values are placed and then timing is done. 4. Logic / gate level: logic cell is taken and its timing and performance is done. 5. Switch level: models transistor as switches. 6.Transistor level: it requires models of transistor describing their nonlinear voltage and current characteristics(varitions).
  6. 6. Classification of Simulators Logic Simulators Emulator-based Schematic-basedHDL-based Event-driven Cycle-based Gate System
  7. 7. Classification of Simulators HDL-basedHDL-based: Design and testbench described using HDL Event-driven Cycle-based Schematic-basedSchematic-based: Design is entered graphically using a schematic editor EmulatorsEmulators: Design is mapped into FPGA hardware for prototype simulation. Used to perform hardware/software co-simulation.
  8. 8. 8  VHDL is an event-driven language.  A VHDL simulator must provide data structures and algorithms that allow it to efficiently simulate the execution of concurrent statements in a VHDL program.  Simulator's sequential execution must be able to provide the illusion of concurrency.  Changes in input and output signals occur in simulation time: the time value maintained by the simulator, as opposed to real time.  There are three common kinds of simulators:  time driven  event driven  cycle based (for simulation of sequental systems)
  9. 9. 9
  10. 10. HOW Simulation Algorithms Compiled simulation  logic equations compiled to code  execute code - fast  works well with zero and unit delay models  difficult with general timing models  no use of latency, multi-rate behavior Event-driven simulation  input changes cause evaluation of model, scheduling of output change event  use timing models to determine new event times  output change evaluated at scheduled time  advantage  real circuits have 10-30% activity  dormant parts of circuit are not evaluated
  11. 11. Event-driven Simulation Event: change in logic value at a node, at a certain instant of time → (V,T) Event-driven: only considers active nodes Efficient Performs both timing and functional verification All nodes are visible Glitches are detected Most heavily used and well-suited for all types of designs
  12. 12. Event-Driven Logic Simulation Evaluate gate when inputs change use logic model to compute new output value use timing model to compute when output will change Schedule an output change event store the event on a time-sorted event queue Process events from the queue output change evaluated at scheduled time causes new events to be scheduled 5 5 7 5 5 5 0 0 0 1->0 (0) 0 1 1 1 0->1 (5) 1->0 (12) 1->0 (10)
  13. 13. Event-Driven Logic Simulation 1. t=X: Schedule PI:1->0 at t=0 2. t=0: PI changes 1->0 Evaluate A, schedule A:0->1 at t=5 4. t=5: A changes 0->1 Evaluate B, schedule B:1->0 at t=10 Evaluate C, schedule C:1->0 at t=12 5. t=10: B changes 1->0, output 6. t=12: C changes 1->0, output 5 5 7 5 5 5 0 0 0 1->0 (0) 0 1 1 1 0->1 (5) 1->0 (12) 1->0 (10) A B C
  14. 14. An event-driven VHDL example process (count) begin my_count <= count; trigger <= not trigger; end process; process (trigger) begin if (count<=15) then count <= count + 1 after 1ns; else count <= 0 after 1ns; end if; end process; Block 1 Block 2 Each process: - loops forever - waits for change in signal from other process
  15. 15. A more hardware-oriented example s(0) <= a(0) xor b(0) after 2ns; c(0) <= a(0) and b(0) after 1ns; s(1) <= a(1) xor b(1) xor c(0) after 2ns; c(1) <= (a(1) and b(1)) or (b(1) and c(0)) or (c(0) and a(1)) after 1ns; sum_out(1 to 0) <= s(1 to 0); carry_out <= c(1); and a b and xor s(0) c(0) xor xor => s(1) sum_out(1) and and or or => => sum_out(0) carry_out
  16. 16. A more hardware-oriented example s(0) <= a(0) xor b(0) after 2ns; c(0) <= a(0) and b(0) after 1ns; s(1) <= a(1) xor b(1) xor c(0) after 2ns; c(1) <= (a(1) and b(1)) or (b(1) and c(0)) or (c(0) and a(1)) after 1ns; sum_out(1 to 0) <= s(1 to 0); carry_out <= c(1); and a b and xor s(0) c(0) xor xor => s(1) sum_out(1) and and or or => => sum_out(0) carry_out Let's simulate: a=11 b=01 Time = 0ns (step1) Red Boxes : evaluate in current step 1 1 1 0
  17. 17. A more hardware-oriented example s(0) <= a(0) xor b(0) after 2ns; c(0) <= a(0) and b(0) after 1ns; s(1) <= a(1) xor b(1) xor c(0) after 2ns; c(1) <= (a(1) and b(1)) or (b(1) and c(0)) or (c(0) and a(1)) after 1ns; sum_out(1 to 0) <= s(1 to 0); carry_out <= c(1); and a b and xor s(0) c(0) xor xor => s(1) sum_out(1) and and or or => => sum_out(0) carry_out Let's simulate: a=11 b=01 Time = 0ns (step2) 1 1 1 0 1
  18. 18. A more hardware-oriented example s(0) <= a(0) xor b(0) after 2ns; c(0) <= a(0) and b(0) after 1ns; s(1) <= a(1) xor b(1) xor c(0) after 2ns; c(1) <= (a(1) and b(1)) or (b(1) and c(0)) or (c(0) and a(1)) after 1ns; sum_out(1 to 0) <= s(1 to 0); carry_out <= c(1); and a b and xor s(0) c(0) xor xor => s(1) sum_out(1) and and or or => => sum_out(0) carry_out Let's simulate: a=11 b=01 Time = 0ns (step3) 1 1 1 0 1 1
  19. 19. A more hardware-oriented example s(0) <= a(0) xor b(0) after 2ns; c(0) <= a(0) and b(0) after 1ns; s(1) <= a(1) xor b(1) xor c(0) after 2ns; c(1) <= (a(1) and b(1)) or (b(1) and c(0)) or (c(0) and a(1)) after 1ns; sum_out(1 to 0) <= s(1 to 0); carry_out <= c(1); and a b and xor s(0) c(0) xor xor => s(1) sum_out(1) and and or or => => sum_out(0) carry_out Let's simulate: a=11 b=01 Time = 0ns (step4) 1 1 1 0 1 1 1
  20. 20. A more hardware-oriented example s(0) <= a(0) xor b(0) after 2ns; c(0) <= a(0) and b(0) after 1ns; s(1) <= a(1) xor b(1) xor c(0) after 2ns; c(1) <= (a(1) and b(1)) or (b(1) and c(0)) or (c(0) and a(1)) after 1ns; sum_out(1 to 0) <= s(1 to 0); carry_out <= c(1); and a b and xor s(0) c(0) xor xor => s(1) sum_out(1) and and or or => => sum_out(0) carry_out Let's simulate: a=11 b=01 Time = 1ns (step1) 1 1 1 0 1 1 1 1 1 1 1
  21. 21. A more hardware-oriented example s(0) <= a(0) xor b(0) after 2ns; c(0) <= a(0) and b(0) after 1ns; s(1) <= a(1) xor b(1) xor c(0) after 2ns; c(1) <= (a(1) and b(1)) or (b(1) and c(0)) or (c(0) and a(1)) after 1ns; sum_out(1 to 0) <= s(1 to 0); carry_out <= c(1); and a b and xor s(0) c(0) xor xor => s(1) sum_out(1) and and or or => => sum_out(0) carry_out Let's simulate: a=11 b=01 Time = 1ns (step2) 1 1 1 0 1 0 1 1 1 1 1 1
  22. 22. A more hardware-oriented example s(0) <= a(0) xor b(0) after 2ns; c(0) <= a(0) and b(0) after 1ns; s(1) <= a(1) xor b(1) xor c(0) after 2ns; c(1) <= (a(1) and b(1)) or (b(1) and c(0)) or (c(0) and a(1)) after 1ns; sum_out(1 to 0) <= s(1 to 0); carry_out <= c(1); and a b and xor s(0) c(0) xor xor => s(1) sum_out(1) and and or or => => sum_out(0) carry_out Let's simulate: a=11 b=01 Time = 1ns (step3) 1 1 1 0 1 0 0 1 1 1 1 1 1
  23. 23. A more hardware-oriented example s(0) <= a(0) xor b(0) after 2ns; c(0) <= a(0) and b(0) after 1ns; s(1) <= a(1) xor b(1) xor c(0) after 2ns; c(1) <= (a(1) and b(1)) or (b(1) and c(0)) or (c(0) and a(1)) after 1ns; sum_out(1 to 0) <= s(1 to 0); carry_out <= c(1); and a b and xor s(0) c(0) xor xor => s(1) sum_out(1) and and or or => => sum_out(0) carry_out Let's simulate: a=11 b=01 Time = 1ns (step4) 1 1 1 1 0 1 0 0 1 1 1 1 1 1
  24. 24. A more hardware-oriented example s(0) <= a(0) xor b(0) after 2ns; c(0) <= a(0) and b(0) after 1ns; s(1) <= a(1) xor b(1) xor c(0) after 2ns; c(1) <= (a(1) and b(1)) or (b(1) and c(0)) or (c(0) and a(1)) after 1ns; sum_out(1 to 0) <= s(1 to 0); carry_out <= c(1); Let's simulate: a=11 b=01 Time = 1ns (step5) and a b and xor s(0) c(0) xor xor => s(1) sum_out(1) and and or or => => sum_out(0) carry_out 1 1 1 1 0 1 0 0 1 1 1 1 1 1 1
  25. 25. A more hardware-oriented example s(0) <= a(0) xor b(0) after 2ns; c(0) <= a(0) and b(0) after 1ns; s(1) <= a(1) xor b(1) xor c(0) after 2ns; c(1) <= (a(1) and b(1)) or (b(1) and c(0)) or (c(0) and a(1)) after 1ns; sum_out(1 to 0) <= s(1 to 0); carry_out <= c(1); and a b and xor s(0) c(0) xor xor => c(1) carry_out and and or or => => sum_out(0) carry_out Let's simulate: a=11 b=01 Time = 1ns (step5) 1 1 1 1 0 1 0 0 1 1 1 1 1 1 1 That's enough - you get the point The statement-(process-) dependencies define a network. Changes are dynamically propagated through the network
  26. 26. Simulation Algorithm while (HaveEvents()) event = NextEvent(); /* time-sorted order */ currenttime = event->time; /* update global time */ event->gate->output = event->output/* change gate output */ print output if it is primary output; for (all gates g in event->gate fan-out list) newoutput = EvalGate(g); /* new gate output */ newtime = currenttime + g->delay; /* when it changes */ ScheduleEvent(g, newoutput, newtime);
  27. 27. Event Queue Implementation Events must be processed in time order  event queue must sort by time Must be able to delete events  cancel obsolete events on a gate Implementations  priority queue  O(logN) time to insert/delete for N-item queue  many implementations - AVL tree, heap, etc.  problem: N is often large  bucket queue - time wheel  divide time into time quanta Q, e.g. 1ps  circular buffer of N entries 1 quantum in size  can store events Q*N into future  events beyond buffer go into unsorted far list  O(1) time to insert, nearly so for delete
  28. 28. Event-driven Simulation Uses a timewheel to manage the relationship between components TimewheelTimewheel = list of all events not processed yet, sorted in time (complete ordering) When event is generated, it is put in the appropriate point in the timewheel to ensure causality
  29. 29. Event-driven Simulation b(1)=1 d(5)=1 D=1 1 0 1 0 1 D=2 a b c d(5)=1 d 5 0 1 e 0 1 3 c(3)=0 d(5)=1 0 1 4 d(5)=1 e(4)=0 6 e(6)=1
  30. 30. Time Wheel 0 1 i-1 i i+1 999 event event curtime curtime+999ps curtime+1ps time wheel of time quantums all events scheduled for a given time quantum Wheel only needs to be big enough to hold most variation in gate delays
  31. 31. Time Wheel Operation Insertion if (eventtime - curtime >= WHEELLENGTH*quantum) insert event into far list else insert at wheel[eventtime % (WHEELLENGTH*quantum)] Deletion i = curtime % (WHEELLENGTH*quantum) while (wheel[i] == NULL) if (i == WHEELLENGTH-1) i = 0; timebase += (WHEELLENGTH*quantum); for all events in far list if (eventtime - timebase < WHEELLENGTH*quantum) insert event into wheel else i++ remove first event from wheel[i] list and return it
  32. 32. 32 The LRM (Language Reference Manual) defines how an event-driven simulator must execute the VHDL. Simulator vendors implement this concepts. An event-driven simulator performs three steps to accomplish a simulation: 1) elaboration 2) initialization 3) repeated execution of simulation cycles
  33. 33. 33 Elaboration Elaboration is the creation of a simulation model for a design entity from its VHDL description. This simulation model consists of a net of simulation processes. During elaboration, all concurrent statements are converted to equivalent simulation processes.
  34. 34. VHDL semantics: initialization At the beginning of initialization, the current time, Tc is 0 ns.  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), Tn is calculated according to the rules of step f of the simulation cycle, below.
  35. 35. VHDL semantics: The simulation cycle (1) According to the standard, the simulation cycle is as follows: a) Stop if Tn= time‘high and “nothing else is to be done” at Tn. The current time, Tc is set to Tn. ?
  36. 36. VHDL semantics: The simulation cycle (2) b) 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 Tc. 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. c) ..
  37. 37. VHDL semantics: The simulation cycle (3) d e e δ) ∀ P sensitive to s: if event on s in current cycle: P resumes. e) Each ... process that has resumed in the current simulation cycle is executed until it suspends*. *Generates future values for signal drivers.
  38. 38. VHDL semantics: The simulation cycle (4) f) Time Tn 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 for statements).  Next simulation cycle (if any) will be a delta cycle if Tn = Tc. f
  39. 39. δ-simulation cycles … Next simulation cycle (if any) will be a delta cycle if Tn = Tc. Delta cycles are generated for delay-less models. There is an arbitrary number of δ cycles between any 2 physical time instants:
  40. 40. Cycle-based Simulation Take advantage of the fact that most digital designs are largely synchronous • Synchronous circuit: state elements change value on active edge of clock • Only boundary nodes are evaluated Internal Node Boundary Node L a t c h e s L a t c h e s
  41. 41. Cycle-based Simulation Compute steady-state response of the circuit at each clock cycle at each boundary node L a t c h e s L a t c h e s Internal Node
  42. 42. (Some) EDA Tools and Vendors Formal Verification Formality → Synopsys FormalCheck → Cadence Design Systems DesignVerifyer → Chrysalis Static Timing Analysis PrimeTime → Synopsys (gate-level) PathMill → Synopsys (transistor-level) Pearl → Cadence Design Systems

×