220 likes | 331 Views
This document addresses the complexities of using multiple SystemC and HDL descriptions for the same design in hardware/software co-validation. It discusses the importance of reusing testbench efforts, correlating different behavior descriptions, and designing a transactional testbench interface. Key topics include abstraction levels, transaction analysis, and debugging techniques. The innovative approach facilitates integration across various abstraction layers, enhances reusability of the test environment, and streamlines transaction monitoring throughout the design cycle, ultimately leading to significant verification time savings.
E N D
Simplifying the Behavior of SystemC Descriptions for Hardware/Software Covalidation Hervé Alexanian, Sonics, Inc. Gerald Bolden, Summit Design, Inc. Zvika Amir, Summit Design, Inc.
Problem Formulation/Statement • The Coexistence of Different SystemC/ HDL Descriptions of the same Design • Reuse of the Testbench Effort • Correlate the Descriptions with Common Stimulus
Agenda • Definitions of Abstraction Level Terminology • Designing the Transactional Testbench Interface • Correlating the Behavior Descriptions • Transaction Analysis and Debugging • Complete architecture analysis for various tradeoffs
OCP-IP Abstraction Level Terminology • TL0: SystemC Representation of Signals • Can be mapped to HDL wires • bool, sc_bv<N>, sc_lv<N> • TL1: Protocol Phase Accurate Model • Analogous to Bus Cycle Accurate • TL2: Transaction Level • Analogous to Programmer’s View with Timing Annotation
Designing the Transactional Testbench Interface • Efficiently isolate the test program from the simulation environment • Different abstractions have incompatible interfaces • Choose a universal data structure to represent transactions • Decouple the test from DUV using transactors • Testbench becomes reusable (untimed) component
Designing the Transactional Testbench Interface • Transactors isolate test from DUV’s abstraction layer • Provide standard test interface • Adapt to lower abstraction layer • Test becomes a shell, which is: • Only responsible for generating transactions • Reusable
Transactors • Test interface uses only SystemC ports and methods • Specific to DUV abstraction • Based on standard protocol components • Less effort than testbench
Simplified Transactor Behavior • Transactor reads from request FIFO port and sends as channel requests
Transactional Test • Generates requests/ responses into FIFOs • SCV constrained random generation • Good use of sc_export for FIFO interfaces • Simplifies the binding to transactors
Correlating SystemC Behavior Descriptions • Validate Functionality • SystemC TL2 / SystemC TL1 / RTL • Validate Timing • More difficult since models may have inherent inaccuracies
Correlating SystemC Behavior Descriptions • End to End Checking • Correlates behavior • Write/readback • Data checking • Transaction Monitors • Included within testbench • Can have trace dump for post process • Post process comparison can measure timing correlation
What is Transactional Debugging, Anyhow? • Defined as unified, parameterized, element which will represent a set of signals/data • Transaction information fully compatible w/ the corresponding signal information in the same environment
Transactional Debugging • Traditional waveform viewer, such that thousands of signals must be checked to ensure proper integration. • Each signal represents one line in the waveform viewer • Trace function calls rather than signals; trace the calling sequence of these methods • When they’re called and when they’re returned, incl their argument values(e.g., read, add, data, and control) and timestamps (cf. delta cycles)
Transactional Debugging • Manual analysis limited to defining the basic system architecture; and, using known parameters of contention • Simulation tools required to perform complete traffic analysis and architecture tradeoffs regardless of timing implementation.
OCP-IP TL2 / TL1 Master Slave Example Design example: TL2_TL1_Slave_Adapter Testbench: driver TL2 Master: master1 TL2 Channel: channel1 Tl2_Tl1_Adapter: slave_adapter TL1 Channel: channel0 TL1 Slave: slave1
Transactor Ports & Channels • Slave Adapter - Basic Design Structure Module Hierarchical Channel (TL1) Ports (binds channel) Hierarchical Channel (TL2)
Monitoring OCP TL1/TL2 Protocol • Transaction Sequence Viewer (TSV) • View Detailed Interface Methods sequence Read Input TL2 Request Respond Expand aggregate to TL1 phase level Request TL1 Respond
Monitoring OCP TL1/TL2 Protocol Basic TL2 + Test input Detailed TL2 + TL1 + Input TL2 + basic TL1 • Filtering Data as much as required Input TL2 TL1
The Key Takeaways • Innovative design of the testbench transactor interface simplifies the task of correlating the behavior descriptions of the same design • The transactor establishes and assures the correct integration between components of different abstraction levels • And, allows a progressively refined model to be easily integrated into a platform throughout the design cycle • Reuse of the test environment and code/scenarios for various design descriptions – results in actual verification time savings • An integrated platform will facilitate and analysis and debugging w/ recording and analysis of transactions while still managing traditional signals in a waveform/transaction viewer.
Thank You. www.sonicsinc.com www.sd.com