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