1. Requirements for the Next Version of SCE-API

2. 2 5/14/2015 11:32 PM Overview l Basic Requirements meet SCE-MI 1.0 requirements backwards compatibility l Extracted Requirements zaiq mentor cadence axis l Ease of Modeling Requirements l Control and Debug Requirements

3. 3 5/14/2015 11:32 PM Satisfy SCE-MI 1.0 requirements l Performance in emulation and simulation implies a transaction based interface implies loose coupling of HDL engine and HVL engine. l support for multiple HDL execution engine types emulation simulation cycle event l support for multiple truly independent channels for reuse l support for multiple HVL test bench environments support for arbitrary threading systems in native mode. support for a single threaded model. semantics can be syntactically bound into arbitrary HVLs. l Automated infrastructure generation l Support synchronization of asynchronous message passing l Support zero-time-sequential-operations

4. 4 5/14/2015 11:32 PM Backwards Compatibility to SCE-MI 1.0 l SCE-MI 1.0 models must work in the new environment. l New and old models must coexist without penalty.

5. 5 5/14/2015 11:32 PM Relation to Other Accelera Standards l SystemVerilog also defines an HDL-C interface called DPI. Based on foreign function calls C-Calls-HDL (function export) HDL-Calls-C (function import) Proposed DPI task import / export could provide the necessary performance. There is some desire in Accelera to rationalize ITC and SV- CC work. l PLI, VHPI, VPI... no requirement for PLI support because it conflicts with the performance requirement.

6. 6 5/14/2015 11:32 PM Relationship to non-Accelera Standards l Emerging System C TLM standard l Current System C channels Is a C++ to C++ interface. Ideas could be borrowed.

7. 7 5/14/2015 11:32 PM Coexistence With Thread Systems l Transaction interface must coexist with application defined threading systems System C / SCV Verisity Verilog / System Verilog VHDL Vera POSIX p_threads quickthreads CoWare customer written custom environments l Customers will drive choice of thread system.

8. 8 5/14/2015 11:32 PM Extracted Requirements

9. 9 5/14/2015 11:32 PM Extracted Requirements (Zaiq) l General Goals Many SCE-MI 1.0 Requirements simulation and emulation support threading on the non-HVL side. multiple HVL support. Transaction level modeling Ease simulation to emulation transition. Ease and standardize construction of BFM / Transactors standardize control so complete tests work unchanged. l Specific support variable size transactions eliminate uncontrolled clock through encapsulation / abstraction. l Approach to Satisfy Requirements Define a transactor application layer built on top of SCE-MI to standardize transactor functionality. add a single standardized threading system. add control and debug functions.

10. 10 5/14/2015 11:32 PM Extracted Requirements (Mentor) l General Goals Satisfy SCE-MI 1.0 requirements Strong backwards compatibility with SCE-MI 1.0 improve ease of modeling for the HDL designer. Make better use of multithreaded systems on the HVL side. Coexist and support standard definitions of transactor functionality at the application layer. l Specific eliminate uncontrolled clock continue to support zero time sequential operations. support synchronization on message arrival. enforce repeatability l Approach build on top of SCE-MI add more abstract transaction layer, encapsulating clock control. make HDL interface more acceptable to HDL designers make use of user specified thread systems

11. 11 5/14/2015 11:32 PM Extracted Requirements (Cadence) l General Goals Many SCE-MI 1.0 Requirements simulation and emulation, cycle and event based engines support threading on the non-HVL side. multiple HVL support. Transaction level modeling create standard structure for construction of BFM / Transactors l Specific support variable size transactions eliminate uncontrolled clock l Approach to Satisfy Requirements use SCE-MI 1.0 as transport layer remain with macro based message passing paradigm, but replace macros. Force all transactors to conform to certain rules (standard definition of transaction) Remove automation around macros? Remove clock generation as well as clock control? Do not add control features

12. 12 5/14/2015 11:32 PM Extracted Requirements (Axis) l General Goals Many SCE-MI 1.0 Requirements simulation and emulation, cycle and event based engines support threading on the non-HVL side. multiple HVL support. Transaction level modeling standardize control so complete tests work unchanged. l Specific support variable size transactions eliminate uncontrolled clock optional application layer to separate instruction and data channels? l Approach to Satisfy Requirements replace entire SCE-MI with transport API based xbVC terminals remain with macro based (structural) message passing paradigm, but replace macros with different ones. create application layer based on separate paired instruction and data channels and memory controller. Force all transactors to conform to certain rules (standard definition of transaction) in particular, force separate instruction and data channels and specific instructions. Force a single standardized threading system. Add control features. Add many miscellaneous features

13. 13 5/14/2015 11:32 PM Loosely Coupled Activity Areas l Basic transaction level modeling interface l Application layer for standard transaction functions. l Control and debug l Interaction with application layer thread systems