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

2. 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

3. MLWG – Problem Statement3
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.

4. MLWG – Motivations/Goals4
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.

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

6. MLWG – Use-cases Considered6
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.

7. 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

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

9. 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.

10. 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

11. 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

12. 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)

13. 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

14. 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

15. 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.

16. MLWG – Proposed WG Structure

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

18. 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 ( )
Implementation/realization of standardized UVM/ML-API
Develop some metrics to measure success
For example: UVM API alignment