1 / 12

Cadence Proposed Transaction Level Interface Enhancements for SCE-MI

Cadence Proposed Transaction Level Interface Enhancements for SCE-MI. SEPTEMBER 11, 2003. Agenda. End-user goals Transaction level requirements Proposed SCE-MI enhancements. End-User Goal: Verification Performance. Verify Large, Complex systems efficiently

manning
Télécharger la présentation

Cadence Proposed Transaction Level Interface Enhancements for SCE-MI

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. Cadence ProposedTransaction Level Interface Enhancements for SCE-MI SEPTEMBER 11, 2003

  2. Agenda • End-user goals • Transaction level requirements • Proposed SCE-MI enhancements

  3. End-User Goal: Verification Performance • Verify Large, Complex systems efficiently • Hardware assisted boosts verification performance for • large sub-systems • long-run tests (e.g. regression suite) • Transaction-based Interfaces improve performance by • infrequent transactions that reduces communications between hardware and software • allowing message level communication with smart transactors that interpret these messages in the HW

  4. But Software Simulation is still Required • Using abstract verification and design components • Rich functional capability • Comprehensive debug capabilities • Acceleration Hardware is usually less efficient • at small sub-system verification • with interactive debug sessions • Conclusion – Users are expected to start with SW simulation before moving to accelerated simulation. • Verification reuse from block/ sub-system to system is important • Maintaining congruent configurations using the same testbench is important

  5. SW-based Verification Flow Abstracted Testbench Abstracted DUT (TLM) Phase 1 (High Level Design) Abstracted Testbench Transactors DUT (HDL) Phase 2 (SW-based Verification) • Componentized SW based design and verification flow contains • Abstracted Testbench – Transaction level tests and response checkers • Abstracted DUT – Abstracted Transaction Level Model (TLM) • DUT – RTL model of the Device Under Test • Transactors – Bus functional models that refine communication between abstracted testbench and DUT

  6. Abstracted Testbench Abstracted DUT Phase 1 (High Level Design) Abstracted Testbench Transactors (Mix C/C++/HDL) DUT (HDL) Phase 2 (SW-based Verification) Transport Abstracted Testbench Accel DUT (HDL) Phase 3 (HW-assisted Verification) C/ C++ HDL Accelerated Verification Flow

  7. End-user Goal: Reusability Abstracted Testbench Abstracted DUT Phase 1 (High Level Design) Abstracted Testbench Transactors (Mix C/C++/HDL) DUT (HDL) Phase 2 (SW-based Verification) Transport Abstracted Testbench Accel DUT (HDL) Phase 3 (HW-assisted Verification) C/ C++ HDL

  8. Reusability can be accomplished by TLI Abstracted Testbench DUT (HDL) C/ C++ Phase 2 (SW-based Verification) HDL • Common Transaction Level Interface (TLI) that enables reuse • Same exposable TLI interfaces in SW-based and HW-assisted verification • Reusable abstracted testbench components and transactors • Congruent configurations in SW-based simulation and Emulation/Acceleration • Allows the user to switch among verification engines seamlessly Abstracted Testbench Accel DUT (HDL) C/ C++ Phase 3 (HW-assisted Verification) HDL TLI

  9. Transaction Level Requirements • Transaction definition • Generic, arbitrarily-sized hierarchical transaction payload • Common transaction-level interface definition • Basic input/output transaction interface • Signal-level definition for HDL part of the transactors • Corresponding C/C++ interface for the abstracted part of the transactors communicating with the corresponding HDL part • TLI must be independent of verification engine technology. • The HDL part of the transactors can be implemented using a simple FSM • The abstracted part of the transactors can use any HLL that can interface with a simple C/C++ API

  10. TLI Abstracted Testbench DUT (HDL) C/ C++ Phase 2 SW (event-based) HDL SCE-MI 1.0 Phase 3 Accel (SCE-MI) Abstracted Testbench Accel DUT (HDL) C/ C++ HDL TLI Abstracted Testbench Accel DUT (HDL) Phase 3 Accel (TLI) C/ C++ HDL SCE-MI 1.0 Key Drawbacks • Variable-Length Transaction handling must be (re-)coded for all ‘hardware side’ components • Precludes transactor re-use between event-based and cycle-based engines by • exposing ‘uncontrolled clock’ to end-user • assuming underlying cycle-based emulation/simulation technology

  11. TLI Proposal will • provide a complete Transaction-Level Interface for robust, variable length transaction processing • decouple the HDL API from the underlying cycle-based simulation/emulation system architecture • Remove the uncontrolled clock mechanism from the public interface of the API • provide a low-level engine independent transactional transport API in C/C++ • Facilitates transaction-level integration of emulation with diverse high level software engines (Pure C/C++, SystemC, System Verilog, PLi, etc.) TLI HLL HDL C/C++ Signals Transactor

More Related