Virtual Prototypes and Plaorms A Primer Eyck Jentzsch, MINRES Technologies GmbH Rocco Jonack, MINRES Technologies GmbH Josef Eckmüller, Intel Deutschland GmbH © Accellera Systems Initiative 1 FOUNDATIONS OF VP © Accellera Systems Initiative 2 What are not virtual prototypes & plaorms • These are not virtualizaon soluKons or virtual machines like VirtualBox or VMWare – A virtual machine (VM) is an emulaon of a computer system (...) and provides funcKonality of a physical computer (Wikipedia) – A VM or virtual machine was originally defined by Popek and Goldberg as "an efficient, isolated duplicate of a real computer machine." • Although some concepts and mechanisms are also used in VPs © Accellera Systems Initiative 3 What is a virtual prototype or plaorm • Virtual plaorm is a hardware simulator execuKng embedded soUware (eSW) • Usually built on top of an instrucKon set simulator (ISS) of the processor(s) connected via buses to memory and peripherals such as Kmers, general I/O, communicaon interface, etc. • While the VP is mostly implemented in SystemC the ISS may be implemented in some other general purpose language. © Accellera Systems Initiative 4 Differences between virtual prototype and plaorm • Virtual prototype – Is in development and does not have final structure and parKKoning. – Possibility to quickly change this – Comprehensive analysis means – Used to opKmize SoC design wrt. power, area, speed, throughput, and/or latency • Virtual plaorm – Represents a SoC in its final shape, – Aims at simulaon speed as well as funcKonal accuracy and completeness, – Used for (e)SW development © Accellera Systems Initiative 5 Alternaves to VPs • Emulaon – high accuracy and speed – needs Register-Transfer-Level (RTL) descripKon, expensive to scale • FPGA – high accuracy and speed – needs RTL implementaon to do synthesis, place and route è long implement- compile-debug loops • Hardware in the loop (HIL) – very high accuracy and speed (real-Kme) – comes late in the design process, scalability challenge © Accellera Systems Initiative 6 VP standards • Focus on standards for VP development - SW and FW running on VP may have different requirements/standards • Usage of C++ - Performance requirements - Compliance with exisKng models - Most tools provide APIs - Linking of scripKng environments for dynamic control e.g. Python, TCL, Lua • Standards are important for IP exchange - Internal implementaon might be different - Standards oUen imply standard interfaces/APIs - Standards typically allow easier tool deployment • Tools can blur the line between standard and proprietary implementaon - AddiKonal funcKonality provided that is vendor specific - Model libraries may incur tool specific funcKonality © Accellera Systems Initiative 7 Modeling techniques • Several modeling approaches are used to implement a VP and its components – Behavioral/unKmed – FuncKonal/loosely med – Cycle-accurate/approximately Kmed – Register-transfer-level • A parKcular VP usually is a mix-and-match of these techniques © Accellera Systems Initiative 8 Behavioral/unKmed • The unKmed model is a funcKonal IF descripKon having no noKon of Kme • A set of algorithmic blocks F1 communicang using funcKon calls or message pipes • Keeps the causality and order of invocaon F2 © Accellera Systems Initiative 9 FuncKonal/loosely Kmed (LT) • The loosely Kmed model is a structural and behavioral refinement of the OS+SW (IF, F2) funcKonal model. ACCEL • Mapping of funcKonal blocks to HW and CPU (F1) SW components and communicaon interfaces in-between based on a chosen architecture • Subsystems can execute ‘ahead-of-Kme’ • TransacKons at communicaon MEM I/O interfaces correspond to a complete read or write across a bus or network in physical hardware and provide Kming at the level of the individual transacKon © Accellera Systems Initiative 10 Cycle-accurate/approximately Kmed (AT) • Approximated Kming on bus OS+SW communicaon and on hardware (IF, F2) ACCEL resource access CPU (F1) – Interface communicaon Kme – Average processing Kme in hardware IP • TransacKons are broken down into a MEM I/O number of phases corresponding much more closely to the phasing of parKcular hardware protocols © Accellera Systems Initiative 11 Register-transfer level (RTL) • Models a block or SoC in terms of the flow of data between hardware registers, and the logical operaons performed on this data • StarKng point for physical implementaon by synthesis, place, and route © Accellera Systems Initiative 12 C++ class libraries for modeling • SystemC is a class library on top of C++ SCML - Structural descripKon elements - Data types TLM2 - Event driven simulaon kernel • TLM2 modeling allows for interoperability SystemC - Reuse of exisKng components whether 3rd party or inhouse C++ - Tool environments support TLM2 - InteracKon with more cycle-accurate models is well defined – Even bridging into RTL simulators is well defined and supported by (commercial) tools • ProducKvity libraries enable faster modeling of common components - Registers, memories, infrastructure tasks - Examples of libraries - Propriatary: Synopsys SCML, Intel ISCTLM, ASTC Genesis - Open Source: Greensocs Greenlib, MINRES SC Components © Accellera Systems Initiative 13 TLM2 based modeling • TLM2 ports are the interfaces between IA TLM2 ports modules - Retain connecKon to architectural view of SoC - Allows for reuse of components Subsystems, for instance Audio, - Focus on interfaces, not on funcKonality Graphics, Modem etc. • Provides infrastructure for modeling efficiency - LT modeling allows opKmizaon of events IniKator Slave - Direct-memory-interface (DMI) calls can nb_transport_bw b_transport invalidate_direct_mem_ptr nb_transport_fw provide very high memory-access efficiency get_direct_mem_ptr transport_dbg - Temporal decoupling allows models to delay synchronizaon with other components © Accellera Systems Initiative 14 Modeling efficiency with TLM2 LT • LT specifies different transport mechanisms IA ISS RAM - b_transport() as blocking access per transacKon - DMI calls to request memory access by pointer • Design goals Subsystems, for instance Audio, - Minimizing synchronizaon with environment Graphics, Modem etc. - Localizing workload - Allows for registraon of callback funcKons • Works well in conjuncKon with temporal decoupling - Avoid synchronizaon in blocking calls if possible - Processor models can decide when to synchronize © Accellera Systems Initiative 15 ProducKvity Libraries • Common elements should be modeled on top IA of common classes • Registers, Memories, etc. • Efficient for stubs or preliminary implementaons Subsystems, for instance Audio, • Common infrastructure tasks should be Graphics, modeled on top of common classes Modem etc. – Logging – Parametrizaon – Domain handling (Clock, reset, power) • SCML, ISCTLM, and Genesis are examples of (proprietary) producKvity libraries – Concepts and implementaons might serve as starKng point for standardizaon © Accellera Systems Initiative 16 Register modeling • Registers are one of the main interface between HW and SW • Registers mean different things to HW and SW groups registers control Write_start() - HW contains many registers, but only few are exposed to SW enable registers set Write_finished() - SW visible registers should be implemented, documented and reset tested src_addr Reset_values() dest_addr • Consider automated code generaon - Large amount of registers - changing requirements - Meta data formats like IPXACT, RDL, RAL • Having a model that allows consistent HW and SW access modeling is important - Access modes, reset and retenKon values - Efficient access through callback funcKons - ProducKvity layer provides register classes © Accellera Systems Initiative 17 Model meta data • SKtching models together is a recurring IA and error prone task • Using meta data is oUen useful – Data visualizaon Subsystems, for – Data exchange instance Audio, Graphics, • IPXACT is a XML based schema for Modem etc. interface descripKons – Some tools can provide or read IPXACT • XML parsing for simple tasks can be done using Open source libraries • Other examples for meta data representaons are RDL, RAL, sysML © Accellera Systems Initiative 18 Improvement of standards • TLM2 provides a generic transport mechanism and extension mechanisms – Specific protocols are not described • AMBA, PCI, MIPI are leU to implementer • ProducKvity libraries are not standardized • More support for common infrastructure tasks – Tracing – Profiling – Parallelizaon © Accellera Systems Initiative 19 Using IP for Virtual Plaorms • VP represents hardware – SoC design typically contains a significant number of 3rd IP components – Ideally all IP should come from same source (RTL, architecture, verificaon, VP models) • Availability of IP for VP is improving, but sKll limited – Availability of models oUen defines the usage – Consider Co-simulaon • Processor-based models that execute SW – User of VP is exposed to those models • Peripheral models – Execute funcKonality autonomously, but under control of SW • Interconnect models – ConnecKng different elements based on addresses © Accellera Systems Initiative 20 Modeling processors SW/FW • Core funcKonality of VP IA ISS • Need support for high speed, good debug interface, profiling, etc. Subsystems, for • Most embedded processor providers instance Audio, Graphics, also provide ISS models Modem etc. – Speed versus Kming accuracy • Dynamically configurable to run in performance mode or accuracy mode – Links to debug environment and other SW tools should be consistent with user expectaon © Accellera Systems Initiative