1 / 13

Requirements for the Next Version of SCE-API

Requirements for the Next Version of SCE-API. 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. Satisfy SCE-MI 1.0 requirements.

eljah
Download Presentation

Requirements for the Next Version of SCE-API

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related