MLWG - User Requirements ML User-companies WG Nov 6, 2012

MLWG – Agenda 2 Month day, 2012 Problem Statement Representation Motivations/Goals Representation Overview High-level Requirements Proposed Architecture Key Requirements Initialization and Configuration Synchronization Phasing Communication Implementation Recommendations Next Steps and Plan of Action

MLWG – Problem Statement 3 Month day, 2012 MLWG – Problem Statement There is no standardized or ubiquitous way to integrate both verification IP and other design or verification collateral in different frameworks/languages to create a simulation model. The scope of this problem includes simulation, emulation, and acceleration.

MLWG – Motivations/Goals 4 Month day, 2012 MLWG – Motivations/Goals Why a standard is required in this space The need to develop products that involve integrating IP from multiple providers is rapidly growing and requires standards to do this more efficiently. Existing standards require a path towards interoperability with newer standards. Accellera needs to align their own standards development. Initial Working Group Goal Collect the user-level requirements of a solution that can solve this problem and make a recommendation for the next steps, including organizational aspects, to address the ML challenge.

MLWG – Representation Chair: Warren Stapleton 5 Month day, 2012 MLWG – Representation Chair: Warren Stapleton There have been 20 weekly 2hr meetings + 2 cancelled time slots. Data extracted from minutes:

MLWG – Use-cases Considered 6 Month day, 2012 MLWG – Use-cases Considered The two main use-cases used for discussion: A transactor sitting in one framework/language being used in another framework/language to provide monitored transactions to a scoreboard. A behavioral model in one framework/language being used as a predictor of behavior for a scoreboard in another framework/language.

MLWG – High-level Requirements Portable Must provide vendor neutrality for user-level code (Stimulus, Transactors, Scoreboards) Easy to use User-level verification-IP code must not be made aware of the mixed-language solution Provide a natural use model for existing methodologies (UVM, SystemC, …) Leverage existing standards where possible Frameworks must be able to operate without the mixed-language solution if they are the only framework being used Useful Must enable the concept of reusable verification-IP Must allow for development of interoperable solutions with proprietary frameworks Must provide standard APIs for framework facilities like: Startup, Messaging, Configuration, Synchronization (timing and phasing), Communication, Shutdown Available Working group must deliver a prototype

MLWG – Proposed Architecture 8 Month day, 2012 MLWG – Proposed Architecture

MLWG – Requirements for Configuration Any framework should be able to participate in a logical hierarchy concept. Need to have top level logical hierarchies that can start in any framework. Provide persistency of configuration data beyond configured model usage, e.g. post processing. Provide access API for typed configuration data. API will provide capability to insert and retrieve configuration data, that will fail compilation if not type correct. Provide a performance/memory consumption optimized storage method of configuration data that is accessible across frameworks. Implementation detail is whether it is centralized or distributed. Provide override capability based on logical hierarchy to enable configuration based build. provide a scope/content/logical hierarchy based approach to configuration data identification. Provide capability to pass configuration data from the simulation command line. Accessing (storing/retrieving) configuration data should not be dependent on the existence of a specific framework. Configuration can be used for managing resource data in addition to configuration data. For simplicity we are naming this the configuration package but it is good for resources as well.

MLWG – Synchronization Requirements Enable key synchronization methods across frameworks Provide a uniform mechanism for synchronizing time Provide APIs for registering/connecting standard UVM Methodology synchronization primitive styles as a minimum foundation such as: Events Objections Barriers Time synchronization Provide a time notification service for adapters to schedule wakeups Multiple concurrent notifications at different intervals can be specified One or more adapters can register with one or more notifications Synchronize the view of a clock domain across multiple frameworks Synchronization Methods Notifications shall be with or without transmittable data

MLWG – Phasing Requirements Shall be only one master phase control mechanism provided Provide phase notifications for all phase related activity Enable framework phase responses to notifications Enable frameworks to post phase requests independent of notifications Default to UVM predefined phase schedule, if none provided Ability to map controller phase names to local framework phase names Pre-run, post-run synchronization across frameworks Minimal: Pre-run synchronization at end of elaboration(barrier/notification) Post-run synchronization at the point the run phase completes Support for either fine-grained or coarse-grained synchronization Notify if pre/post-run phase traversal is top-down or bottom-up Run time phase action notification for participating frameworks Support for registering any schedules and phases at least for runtime Ability for a framework to request a jump to any runtime phase

MLWG – Communication Requirements (1) Requirements Scope Within: Messaging amongst verification components in different frameworks such as transactions and events Outside: Generalizations for config access and phasing Outside: Time synchronization assumed part of synchronization requirements Foundation Shall enable all communication-specific TLM 2.x usage models Shall enable specific TLM 1.x capabilities such as analysis ports Enabling Requirements Shall enable discovery of components and other communication participants Shall enable messages to support all information necessary for routing Shall enable dynamic connectivity changes Shall enable TLM-specific timing synchronization (global quantum)

MLWG – Communication Requirements (2) Execution Requirements Shall enable communicating a single message container data type with serializable contents Shall enable correlation amongst components with maintained message-identity for life time of a message Shall enable one-to-one, one-to-many and many-to-one connectivity Shall enable uni-directional and bi-directional communication Shall enable blocking and non-blocking messaging

MLWG – Implementation requirements Reference implementation Implementation of backplane in C++ and C++ as the second language for the adapters Leverage available industry standards and implementations where possible Fully functional with all major vendor's simulators Examples Examples to demonstrate interoperability and/or interfacing with other languages standards and methodologies including C++, e, SystemC, UVM-SV, VHDL, SCE-MI Test functionality using the UVM-SV framework implementation, getting full coverage on the UVM side Regression suite / tests Set of compliancy tests to validate compatibility with the ML standard interface, functionality and performance

MLWG – Recommendation Restructure Accellera WGs to provide better standards alignment VIP-TSC was primarily purposed with aligning VMM, OVM and providing a System-Verilog solution Examples of poor alignment: UVM and SystemC (CCI) configuration are not aligned and not working together as far as the MLWG is aware of. UVM RAL, IP-XACT registers, and SystemRDL. Currently working on building interoperable solutions out of what exists as opposed to architecting a holistic solution. See initial proposal in next slide Committee to focus on the overall methodology along with sub-committees: VIP-SV library VIP-SC library VIP-Backplane With requirement to support frameworks other than UVM-SV or SystemC Charter of committee (Could be new charter of VIP-TSC) Define a unified methodology that can enable the deployment of UVM methodology in multiple frameworks and allow them to interoperate. Create a standardized VIP-API document.

MLWG – Proposed WG Structure

MLWG – Proposed Group Mapping 1717 Month day, 2012 MLWG – Proposed Group Mapping

MLWG – Next Steps and Plan of Action Phase 1 (2012) Complete the user requirements gathering About 75% done and should be completed before the VIP-TSC F2F Present to the WG Chairs and Solicit Feedback Propose aligned working group structure Phase 2 (2013) Expand and collect vendor requirements Resolve/consolidate user and vendor requirements Propose implementation approach/responsibilities Phase 3 (2013-2014) Implementation/realization of standardized UVM/ML-API Develop some metrics to measure success For example: UVM API alignment