Browse Prior Art Database

METHOD FOR PRECISE SYNCHRONIZATION OF STIMULI ACROSS MULTIPLE INTERFACES IN A LOGIC VERIFICATION ENVIRONMENT

IP.com Disclosure Number: IPCOM000009407D
Original Publication Date: 1999-Jun-01
Included in the Prior Art Database: 2002-Aug-21
Document File: 3 page(s) / 191K

Publishing Venue

Motorola

Related People

Paul R. Salazar: AUTHOR

Abstract

This report addresses the challenges of synchro- nizing stimuli in a logic verification environment, and proposes a specific software methodology, the Unit-Sim SyncManager, embedded within the logic simulation control system to allow simulation sce- narios to achieve cycle accurate synchronization of stimuli. The Unit-Sim SyncManager is a set of C++ classes that, when used in conjunction with the Motorola Somerset Unit-Sim simulation environ- ment, provides a mechanism for accurately synchro- nizing interface transactions across any number of interfaces based on a set of defined transaction dependencies.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 33% of the total text.

Page 1 of 3

Developments Technical 0 M M-LA

METHOD FOR PRECISE SYNCHRONIZATION OF SdIMULI ACROSS MULTIPLE INTERFACES IN A LOGIC VERIFICATION :ENVlRONMENT

by Paul I?. Salazar

  This report addresses the challenges of synchro- nizing stimuli in a logic verification environment, and proposes a specific software methodology, the Unit-Sim SyncManager, embedded within the logic simulation control system to allow simulation sce- narios to achieve cycle accurate synchronization of stimuli. The Unit-Sim SyncManager is a set of C++ classes that, when used in conjunction with the Motorola Somerset Unit-Sim simulation environ- ment, provides a mechanism for accurately synchro- nizing interface transactions across any number of interfaces based on a set of defined transaction dependencies.

   The types of transaction dependencies used for synchronization include event, time delay, transac- tion order, and transaction co-dependency. The pur- pose of the multiple dependency types is to allow complex lists of transactions to occur during the simulation in a highly organized order. In addition, this synchronization method allows for the cycle accurate execution of transactions.

  The SyncManager consists of three C++ classes, SyncMan, SyncCmd, and SyncEvent. The SyncManager is instantiated during the initialization phase of the simulation, but prior to transaction parsing done by the Unit-Sim environment. The transactions processed during a Unit-Sim simulation are called UVP commands (transactions) and are generated using a testcase generation tool. Each UVP command contains parameters that are specific to an interface and are used to hold the values issued onto the interface fields. A SyncCmd object will be instantiated for each UVP command containing UVP "sync" parameters. These "sync" parameters tell the SyncManager the specific dependencies that exist for the transaction.

  A set of rules inside the SyncMan class is used to calculate the dependencies that exist for a transac- tion. In the Unit-Sim environment, an lrritator

processes transactions. The processing involves communicating with the SyncManager (through its API), and sourcing stimuli onto an interface. The ultimate purpose of the SyncManager is to deter- mine when a particular transaction has all synchro- nization dependencies met. When this happens, the transaction is said to be "Ready" which allows the Initator to then process it by stimulating the inter- face under its control.

   The SyncManager maintains a data object for each "synchronized" command. Included in these objects is a Command State. The Command State has an associated simulation time-stamp, informing the SyncManager of when each particular command entered the current state. Synchronization dependen- cies are calculated using the Command State, the time-stamp value and then values of all the synchro- nization parameters. The command synchronization states are described below:

  l Inactive - The state a "synced" command is placed in after inst...