Requirements for the Next Version of SCE-API

1. Requirements for the Next Version of SCE-API

2. Overview • Basic Requirements • meet SCE-MI 1.0 requirements • backwards compatibility • Extracted Requirements • zaiq • mentor • cadence • axis • Ease of Modeling Requirements • Control and Debug Requirements

3. Satisfy SCE-MI 1.0 requirements • Performance in emulation and simulation • implies a transaction based interface • implies loose coupling of HDL engine and HVL engine. • support for multiple HDL execution engine types • emulation • simulation • cycle • event • support for multiple truly independent channels for reuse • 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. • Automated infrastructure generation • Support synchronization of asynchronous message passing • Support zero-time-sequential-operations

4. Backwards Compatibility to SCE-MI 1.0 • SCE-MI 1.0 models must work in the new environment. • New and old models must coexist without penalty.

5. Relation to Other Accelera Standards • 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. • PLI, VHPI, VPI ... • no requirement for PLI support because it conflicts with the performance requirement.

6. Relationship to non-Accelera Standards • Emerging System C TLM standard • Current System C channels • Is a C++ to C++ interface. • Ideas could be borrowed.

7. Coexistence With Thread Systems • 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 • Customers will drive choice of thread system.

8. Extracted Requirements

9. Extracted Requirements (Zaiq) • 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. • Specific • support variable size transactions • eliminate uncontrolled clock through encapsulation / abstraction. • 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. Extracted Requirements (Mentor) • 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. • Specific • eliminate uncontrolled clock • continue to support zero time sequential operations. • support synchronization on message arrival. • enforce repeatability • 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. Extracted Requirements (Cadence) • 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 • Specific • support variable size transactions • eliminate uncontrolled clock • 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. Extracted Requirements (Axis) • 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. • Specific • support variable size transactions • eliminate uncontrolled clock • optional application layer to separate instruction and data channels? • 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. Loosely Coupled Activity Areas • Basic transaction level modeling interface • Application layer for standard transaction functions. • Control and debug • Interaction with application layer thread systems