architecture SoC Modeling

Ming-Hwa Wang, Ph.D. hardware model software COEN 207 SoC (System-on-Chip) Verification

Department of Computer Engineering

Santa Clara University validation

• Topics provides a consistent/uniform environment for modeling/simulation • advantages of modeling efforts • • what is modeling TLM modeling can ease verification • • cost of modeling do pre-silicon validation before chip is back • languages for modeling productivity • model creation and verification What Is Modeling • simulation technology • SoC modeling execution Who Are the Customers? • internal customers Advantages Of Modeling • hardware design - served as a golden model • hardware verification • Why Modeling? software driver testing/integration • • time to market software applications • • conventional iterative serial design process: validation • L0 validation for JTAG (model not needed) • architecture →→→ hardware →→→ software →→→ system integration • L1 tests on U-boot like environment without socket • parallel/concurrent design process: • L2/L3 flow testing on Linux like environment with socket (need hardware drivers) architecture system integration • external customers software • functional model to run applications

• a golden model for both hardware and software designs • cycle accurate model to debug applications

• software development can start much earlier in the design cycle, reduce time to market Models for Different Levels

• fast turn around time for changes than RTL • architecture

• performance is the key as complexity grows exponentially • performance modeling model 20-1000 mips • architecture exploration and trade-off FPGA 20-200M cps • throughput, delay, congestion, buffer size, etc. hardware accelerator 1M cps • hardware/software partitioning C executables translated from RTL 1-10K cps • software RTL 20-100 cps • algorithmic model - functional/behavior Gate 1 cps • transaction level modeling (TLM) • very high reusability across projects • programmer's view (PV) model - register-based, bus generic, • infrastructure untimed • methodologies • programmer's view model with timing (PV/T) - bus architecture • models with protocol, timing approximate • tools • cycle-accurate model • use simulation, debugging, verification, co-simulation, etc. to help • hardware ensure the SoC works with 1st time success (no re-spin or reduce • RTL: cycle-, bit-, and pin-accurate model number of re-spins to very minimum) • served as bridges among architecture, HW design/verification, SW Transaction Level Modeling (TLM) development, and validation • bus function model (BFM) • traditional verification uses testbench to generate test vector and • difficult to do co-simulation and difficult to attach validation devices then test against the golden model • CoWare • using a BFM provides an efficient means of including bus • automatic SystemC wrapper generation for RTL blocks or RTL transactions in simulation instead of test vectors or stimuli wrapper generation for SystemC blocks • TLM • drag and drop blocks and connected by adding wires using GUI • a transaction is a quantum of activity that occurs in a system • hierarchical composition for the design • TLM shifts upward in modeling abstraction w/o accompanied by a • automatic makefile generation to build the whole design corresponding, automated path back down to the lower level • run-time speed is fast • models communication mechanism (buses, FIFOs) are channels, by • support both functional models and cycle accurate models calling interface functions of these channel models, which • support co-simulation encapsulate low-level details (pins) of the information exchange • not good in convert existing design into the flow • transactions typically have a specific starting time and ending time • Synopsys Innovator • use of multiple inheritance to provide the flexibility, reuse, and • VaST protection • ARM • TLM vs. RTL summary • maybe the best environment, but ARM processor only • faster to write, faster to simulate, less code, pure software - because a higher level of abstraction is used to describe the system Example Modeling Comparisons • however - TLM means "giving up timing detail/accuracy" and is generally non-synthesizable PV model PVT model emulation C co- • solution: integrated TLM + RTL flow executable simulation RTL- no no yes yes yes RTL-Dependent Modeling dependent • emulation and h/w accelerator customers yes yes no no no • easy to attach validation devices by using speed bridges want • run time ok speed very fast fast ok slow slow • need modify RTL – synthesizable RTL only model need but need no need no need no need • one user at a time, need both hw and sw engineers work together verification difficult • not intended for interactive debugging attach no and no yes no no • single point of failure, expensive (cost vs. performance) device difficult • h/w accelerator is parallel processing, good for small design and interactive easy easy waste easy difficult speedup limited by the testbench (Amdahl’s law) debug • emulation is FPGA based, and good for big design model functional both cycle cycle cycle • C executable translated from RTL – Carbon VSP or Tenison (now ARC) accuracy accurate accurate accurate • easier to do, minimum model verification required transactors no need need no need need need • cycle accurate resource high high low low low • need modify RTL – synthesizable RTL only requirement • run time is slow model type post- Post- pre- pre-silicon pre-silicon • co-simulation silicon silicon silicon • very accurate model sequential concurrent concurrent sequential sequential sequential • need process support package (PSP), need modify RTL or • difficult to debug concurrent • run time is slow even with back door memory access hw/sw coop no no yes no no RTL-Independent Modeling debug • Virtutech tool low depends high high high • post-silicon model, functional model, no transactor needed maturity • run-time speed is very fast single point no no yes no no • not yet productive/mature for model development by users of failure • extensive verification is required (match specs? match RTL?) cost expensive expensive expensive reasonable reasonable Electronic/Executable System-Level Languages (ESL) Cost Of Modeling • can use open source SystemC kernel (http://www.systemc.org) and gcc instead of licensed hardware simulator • Modeling Is Expensive executable specifications: SystemC with master/slave and TLM libraries • • cost/benefit trade-off single language for both model and HDL: based on high level language • benefits of modeling is directly proportional to the availability and C++, grows downward by adding clocks, parallel execution scheduler quality of the model - simulation is only as good as its models and sensitivity list to mimic the hardware simulation • • efforts needed – similar to RTL design, only more productive multi-level description languages (though low-levels not recommended) • • fully understand the specs untimed/timed functional level • • code the model bus cycle accurate (BCA) level • • profiling and tuning cycle accurate (CA) level • • test/verify correctness register transition level (RTL) • • modeling need expert domain knowledge from architecture and coding gate level • skill to build the model served as a glue mechanism for integrating different models • • difficult to find people good in both areas code/class documentation can be automatically generated via doxygen • • cooperating efforts needed most commercial synthesis tools support SystemC (though not • productivity tools can help speed up development recommended) • language and compiler techniques • multi-domain simulation environment with GUI Verification Description Languages (VDL) • VDL • SystemVerilog – based on Verilog and grows upward to support Languages For Modeling Productivity system leverl modeling, emphasis on verification • SystemC Verification (SCV) Languages • Vera – design verification language • high-level languages • Specman – coverage-driven verification • hardware description languages (HDL) • Features • electronic/executable system-level languages (ESL) • constrained/biased random test generation • verification description languages (VDL) • function coverage and coverage-driven verification • architecture description languages (ADL) • line coverage, block coverage, or segment coverage • model description languages (MDL) • branch coverage • expression coverage: if all possible legal Boolean values of the High-Level Languages expression is reached • high-level languages (C/C++) • toggle coverage: which bits in RTL are toggled – for power • scripting languages (Perl, Python, etc.) analysis • for functional/behavior model only, no timing/clock • FSM coverage: if all states and possible transitions are reached • assertion language/aspect Hardware Description Languages (HDL) • HDL - Verilog, VHDL Architecture Description Languages (ADL) • multi-level description languages • ADL for application-specific processors • behavior/functional - for high-level modeling and testbenches • Lisatech from CoWare • register transition level (RTL) - for logic design • nML from Target • gate level • processor architecture description and exploration • switch level - for circuit design • automatically generate templates and manually insert implementation • synthesis flow in ASIC: translate RTL into gate/switch design by compiler code or automatically generate implementation code technology • tool generation from ADL • custom design flow - for high performance design • assembler • need both logic design and circuit design • ISS • need equivalence checking (beware of exponential explosion) • linker/loader • debugger • compiler • RTL Model Verification • model checking Model Description Languages (MDL) • theorem proving • MDL • static/dynamic property checking • compiled code - Virtutech DML • pre-/post-condition • graphics/spreadsheet - Escalate • assertion • flowchart - Synopsys Innovator • automatically provide counter examples for debugging • block diagrams and templates – Ptolemy • simulation technology • hierarchical drag and drop - CoWare • software simulation • math formula/equation - Matlab • hardware simulation • automatically translate MDL into model • hardware-assisted acceleration (e.g., Palladium - expensive) • more productive • FPGA (need partitioning, limited visibility, slow setups/compiling, • encapsulated/standalone or environment-independent models synthesizable RTL, little support) • symbolic simulation Model Creation And Verification • co-simulation • equivalence checking • Model Creation cycle by cycle simulation and comparison • • manually coding formal verification • generated by DML • converted from other model Simulation Technology • composition from other models • manually coding the interconnections Models of Computation and Simulation Technologies • connection template automatically generated • communicating sequential processes (CSP) • drag and drop using GUI tools with wrappers • continuous time (CT) • mix and match models with different levels and formats • discrete event (DE) * • hierarchical composition and viewing • distributed discrete event (DDE) • easy to understand the design and debugging • discrete time (DT) • finite state machine (FSM), hierarchical FSM * Model Conversion • process network (PN) • compiler technology - translate from high-level models to lower level • synchronous date flow (SDF) * models • dynamic data flow (DDF) * • synthesis - translate from RTL to gate/switch, e.g., Design Compiler • synchronous reactive (SR) * • behavior synthesis - translate from functional/behavior model into • rendezvous models (RM) * RTL • timed multitasking (TM) • Synopsys Behavior Compiler (BC) • genetic or automatic programming • SystemC to RTL compiler from Forte, Synfora, etc., provides signal environment from architecture modeling to synthesis, Simulation Environment good for algorithmic design only • modeling frame work • translator technology - translate one model to a different model with • user interfaces or GUIs same level • kernel: event scheduling • gain execution speed (w/ or w/o optimization) and easy to integrate • kernel functionalities - debug, sim control, check • Carbon VSP Compiler • custom/std-based modeling languages • Tenison • libraries (components, math) • productivity tools: translate mixture of models into HDL • glue/compilation/sim/regression automation • Vperl: translates mixture of Verilog and Perl into pure Verilog • expression parser (e.g., tcl, custom) • dis-compiler technology - translate from lower level model to higher • result/data display level • architectural models, carbonized models, VIPs or peripheral BFM, 3rd • reverse engineering?? party block/device/peripheral models • dynamic change combinations of high/low level block models for Separation of Simulation Environment and Models speed/accuracy requirements and configure/build whole SoC • simulation environment can get from commercial tools or open source • accommodate different format models by using wrappers or transctors • models can get from vendors independent of environment or be • good for unit test (on block level) and system test (on SoC level) developed in-house • using co-simulation to verify model and SoC for consistency • preferred order: IP vendor's models, other vendor's models, in- house Example Mix and Match Models • separation of simulation environment and models to ship to customers • software model: e.g., all high-level models • models and IPs • buy from or contract to vendors - more robust • developed in-house high -level block model 1 high -level block model 2 • advantages of separation • model portable across different tools high -level block model 3 high -leve l block model 4 • higher bargain power with vendors • disadvantages • compatibility issues and tools specific features/performance • hybrid model: e.g., replace one block model by RTL

Co-Simulation • two simulators: hardware simulator and software simulator high -level block model 1 high -level block model 2 • communication between HW & SW simulators - socket, rpc, PLI, VPI, DPI/DKI RTL block 3 high -level block model 4 • transactors between high-level arguments and pin connections with timing • use verification IP (VIPs) • pin- and cycle-accurate: high level parameters vs. low level pins SoC Modeling Execution

Scheduling • criteria definition (budget, goals/values, resource/time, domain input DUT output expertise) transactor transactor • specs collection and analysis for a project • top level model type determination • methodology evaluation and prototyping • automatic simulation environment generation parameters pins pins parameters • vendor model evaluation/validation - on-going • in-house model development/verification clock clock • integration with SW platform • bit-accuracy is necessary (or use approximation) • phased development and deployment • performance improvement • minimum feasible subset • backdoor memory access model • internal and then external customers • commercial co-simulation tools • Cadence - ncsim Execution plan • Synopsys - vcs • basic framework • Mentor Graphics - Questa + Seamless • ISS, cache, and memory • system bus modeling A mix and Match Environment • models developed and tested independent of the project • mix of high-level and low-level models with different formats • iterative integration and testing • most block models are high-level, few models in low-level for accuracy • integration and testing without sacrifice much speed • modeling integration • SW integration • validation and instrument attachment co-simulation yes no yes yes yes yes support UML XML SML XML Top Level Model Type modeling • requirements source code yes yes yes yes no yes • easy to ship to internal/external customers gen • user friendly and easy to use/debug cost 800K 376K free free 760K 800K • can support mix and match environment maturity/years 8 13 20 25 10 12 • embedded Linux OS • ability to integrate into customer's environment Automated Simulation Environment and Model Generation • language choice for top level model - SystemC/C++/C • mix and match may need different simulation environments for different • simulation control and scripting environment applications • an environment to control interaction and simulation control • build system to support automatic configuration and build of simulation • control and scripting language choice - Tcl/Python combinations • deliverables Methodology and Simulation Environment • an environment for SoC modeling and simulation • commercial tools - Virtutech, VaST, Synopsys, CoWare, Arm, Target, • ability to deliver SoC model to be used in customer environments etc. • free-domain open source tools - Giotto/Ptolemy/Metropolis, Esterel Simulation Platform • OSCI • use evaluation board and connect SoC model using socket • use ISS to replace evaluation board, connect to GDB Need to Have Features Instruction Set Simulator (ISS) Synopsys Virtutech Giotto Esterel VaST CoWare • requirements or • speed Ptolemy • dual-/multi-core and cache coherency ISS Arm PPC, Arm Arm PPC, • external memory synchronization Arm • cycle approximate or cycle accurate IPs Standalone proprietary sub sub From • open source - IBM PEK, MAME, Qemu, PearPC, etc. blocks blocks blocks 3rd party Memory Coherency model yes model, no yes yes XML yes • memory models creation GUI • inside ISS, or external memory models w/ GUI • memory map partitioning speed fast Very fast fast fast fast fast • backdoor memory access for efficiency debugger yes GDB GDB GDB yes yes • cache/memory interactions boot yes TinyOS • memory management Linux OS • cache coherency between the cores accuracy PV/PVT PV PV/PVT PV/PVT PV/PVT PV/PVT support yes yes open open yes yes Bus Models source source • abstract or high-level bus model • preferred - more efficient Nice to Have Features • connect low-level models to the bus with transactors • pin-/cycle-accurate or low-level bus model Synopsys Virtutech Giotto or Esterel VaST CoWare • Carbon VHM model Ptolemy • connect high-level models to the bus with transactors/VIPs SystemC or yes no Mirablilis* yes yes Carbon Block/Device/Peripheral Models • integration each block/device/peripheral may have multiple models with different levels/formats • behavior/functional models in C/C++/SystemC • TLM models (PV, PV/T, cycle accurate) in SystemC/SystemVerilog • RTL models in Verilog/VHDL, or Carbonized VHM • transactor/VIP for each block/device/peripheral • high-level models connect to pin-/cycle-accurate bus model • low-level models connect to abstract bus model • models procured form vendors independent of the environment are preferred • models to be developed in-house only if not available

Uniform Model Verification Environment • an uniform model verification environment for unit (block/IP) and system (SoC) tests • write directed tests based on compliance test suites • wrap functional model with pin-/cycle-accurate transactors to test against proven VIPs - Denali used the same approach • co-simulation to validate against RTL • regression with automated test self-checking - Dejagnu • short or release regression • daily regression • weekly or full/long regression

Debugger and GUI • support GDB • support other vendor's debuggers • multi-core debugging support • SoC peripheral debugging support • integrate the debugger to Eclipse programming environment

Instrument Attachment • need instruments support commands and vector file generation • most well-known instrument companies (e.g., Agilent, Rhodes & Shwartz, etc.) support these, small instrument companies may not have these support

Environment

testbench output

DUT capturing stimulus generation

command file command file