120 likes | 266 Views
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
E N D
Cadence ProposedTransaction 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 • 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
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
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
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
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
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
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
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
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