Erm Sequences 061205

5 Sequences: Constructing TestScenarios

This chapter describes a uniform and efficient way of implementing sequences in Specman. Specifically,this chapter introduces a new statement (the sequence statement), a new action (the do action), and awhole methodology for handling sequences.

Together with the evc_util package, Cadence ships three example packages called ex_atm, ex_c_bus,and ex_soc. These example packages demonstrate in detail the various sequence features.

Note You can only run these example packages on top of Specman version 4.1 or higher. See thePACKAGE_README.txt files of the example packages for a description of how to run them.

The sections of this chapter can be divided into the following four main parts:

Introduction • “Introduction to Sequences” on page 5-2

• “How to Use Sequences in Your Environment” on page 5-4

Basic Use • “Getting Started with Sequences” on page 5-5

• “Implementing Sequences” on page 5-11

• “Writing Tests Using Sequences” on page 5-18

• “Sequence File Organization” on page 5-23

e Reuse Methodology 5-1

© 2006 Cadence Design Systems, Inc. All rights reserved worldwide.

Sequences: Constructing Test ScenariosIntroduction to Sequences

5.1 Introduction to SequencesSequences let you define streams of data items sent to a DUT (or streams of actions performed on a DUTinterface). You can also use sequences to generate static lists of data items with no connection to a DUTinterface.

For defining sequences, it is also necessary to define standard interfacing entities between the sequenceand the DUT. Therefore, the sequence solution deals with three main entities:

Advanced Use • “Using Virtual Sequences” on page 5-23

• “Advanced Generation-Related Aspects of Sequences” on page 5-29

• “Implementing Complex Scenarios” on page 5-34

• “Miscellaneous Advanced Features” on page 5-48

• “Layering of Protocols” on page 5-55

• “Tracing and Debugging Sequences” on page 5-70

Reference • “Sequence-Related Methods” on page 5-98

• “Sequence-Related Pseudo-Routines” on page 5-108

• “Sequence Interface” on page 5-110

• “Predefined Sequence Kinds” on page 5-117

• “BFM-Driver-Sequence Flow Diagrams” on page 5-119

• “Sequence Deprecation” on page 5-124

• “Known Limitations” on page 5-127

Item A struct that represents the main input to the DUT (for example, packet,transaction, instruction). Typically, such items already exist in yourenvironment, and only very small modification is required to use them withsequences.

Sequence A struct that represents a stream of items signifying a high-level scenario ofstimuli. This is done by generating items one after the other, according tosome specific rules. The sequence struct has a set of predefined fields andmethods. The sequence struct can also be extended by the user.

5-2 e Reuse Methodology


Sequences: Constructing Test ScenariosIntroduction to Sequences

To complete the picture:

• A TCM does the actual driving of items into a specific DUT channel.

• The TCM resides in a BFM unit.

• For the purpose of driving data into the DUT, the sequence driver interacts only with the BFM.

The sequence driver and the BFM work as a pair, where the sequence driver serves as the interfaceupwards towards the sequences so that the sequences can always see a standard interface to the DUT.The BFM serves as the interface downwards to the DUT, letting you write sequences in any way youfind appropriate.

At first, it might seem unnecessary to separate the sequence driver and the BFM. The importance of thisseparation becomes clear when implementing virtual sequences (see “Using Virtual Sequences” on page5-23).

Figure 5-1 describes the general flow of data and control in sequences.

Sequence Driver A unit that serves as the mediator between the sequences and theverification environment. The generated items are passed from the sequenceto the sequence driver and the sequence driver acts upon them one by one,typically passing them to some kind of BFM (Bus Functional Model). Ofcourse, the sequence driver can be rather empty and, instead of driving itemsinto the DUT, simply place them on a list.



Sequences: Constructing Test ScenariosHow to Use Sequences in Your Environment

Figure 5-1 Flow of Control and Data in Sequences

The execution flow for generation of items and driving them into the DUT is as follows:

• The sequence driver launches the main TCM of a sequence (called body()), which in turn launchesthe main TCM of any subsequences. (See “Defining the Behavior of Sequences” on page 5-12.)

• Sequences generate items on the fly (as part of the execution of their body() TCM).

• Each generated item is passed to the sequence driver, which in turn passes it to the BFM.

Note All of the above actions are done automatically by the sequence mechanism. The subsequenceand item actions are encapsulated in the new do action. (See “Activating Items and Subsequences” onpage 5-13.)

5.2 How to Use Sequences in Your Environment

To use sequences in your environment:

1. Define the sequence item struct.

2. Define the sequence and its driver using the sequence statement.

3. Hook the sequence driver to the environment.

SequenceItem

Fields:idkind == TXbackpointer...

Sequence Driver

BFMMon

DUT

TX Agent

Config:...

Clock Event

seq

seq

seq

seq

seqSignal Map



Sequences: Constructing Test ScenariosGetting Started with Sequences

4. Create your sequence library by implementing various scenarios using the sequence struct.

5. Write tests based on the sequence library.

Note Throughout these sections, the examples used are from the eRM library.

See Also

• For more information on Step 1 through Step 3, see “Getting Started with Sequences” on page 5-5

• For more information on Step 4, see “Implementing Sequences” on page 5-11

• For more information on Step 5, see “Writing Tests Using Sequences” on page 5-18

5.3 Getting Started with SequencesThis section describes how to define sequences in your environment and hook them to your BFM.

This section includes:

• “Defining the Sequence Item” on page 5-5

• “Defining the Sequence and Its Driver Using the sequence Statement” on page 5-5

• “Hooking the Sequence Driver to the Environment” on page 5-9

5.3.1 Defining the Sequence ItemFor an item to be used with sequences it must have some common functionality. Therefore, define theitem struct like you always do but inherit from the predefined type any_sequence_item.

For example:

struct ex_atm_cell like any_sequence_item {kind: [A1, A2, A3, A4];color: ex_atm_color;..

};

Note If you have a pre-existing environment that does not use sequences, you must edit the basic itemto make it inherit as above.

5.3.2 Defining the Sequence and Its Driver Using thesequence Statement

Define the sequence struct and the sequence driver unit using the sequence statement.



Sequences: Constructing Test ScenariosDefining the Sequence and Its Driver Using the sequence Statement

Syntax

sequence sequence_name [using sequence_option,...];

Options

Example 1 Defining a BFM sequence for ATM cells

sequence ex_atm_sequence using item=ex_atm_cell;

This statement assumes that an ex_atm_cell struct already exists. It defines:

Example 2 Defining a virtual sequence for an SoC environment

sequence soc_sequence;

This statement defines the soc_sequence struct, the soc_sequence_kind type, and thesoc_sequence_driver unit.

item = item_type The item to be used in the sequence. This item must be alreadydefined and inherits from any_sequence_item. The item struct isextended by the sequence statement.

If the item option is not used, then this is assumed to be a virtualsequence (see “Using Virtual Sequences” on page 5-23).

created_kind = kind_name The name of the associated kind enumerated type to be created(default: sequence_name_kind).

created_driver = driver_name The name of the associated sequence driver to be created(default: sequence_name_driver).

sequence_type =base_sequence_name

The name of the sequence struct your sequence inherits from(default: any_sequence).

For more information, see “Creating a Common Base for YourSequences and Sequence Drivers” on page 5-49.

sequence_driver_type =base_sequence_driver_name

The name of the sequence driver unit your sequence driverinherits from (default: any_sequence_driver).

For more information, see “Creating a Common Base for YourSequences and Sequence Drivers” on page 5-49.

Struct ex_atm_sequence (inherits from any_sequence)

Type ex_atm_sequence_kind

Unit ex_atm_sequence_driver (inherits from any_sequence_driver)




For more information about virtual sequences, see “Creating a Virtual Sequence” on page 5-24.

The rest of this section describes the entities that the sequence statement creates or extends:

• “Sequence Struct” on page 5-7

• “Sequence Driver Unit” on page 5-7

• “Item Struct” on page 5-8

• “Sequence Kind Type” on page 5-8

5.3.2.1 Sequence Struct

The sequence statement creates a new sequence struct (ex_atm_sequence in “Example 1” on page 5-6),which inherits from the predefined any_sequence, which in turn inherits from any_sequence_item.

The main members of the created sequence struct are:

Note The only way to define sequences is via the sequence statement; however, you can define a basesequence by deriving it from any_sequence. For more information see “Creating a Common Base forYour Sequences” on page 5-49.

For the full list of the sequence struct members, see “any_sequence Interface” on page 5-111.

5.3.2.2 Sequence Driver Unit

The sequence statement creates a new sequence driver unit (ex_atm_sequence_driver in “Example 1” onpage 5-6), which inherits by default from any_sequence_driver.

The main members of the created driver unit are:

driver: driver_name; Reference to the sequence driver

kind: kind_name; For creating sequence subtypes with variousbehavior

body() @driver.clock is empty; Defines the sequence behavior to be implemented bythe user

parent_sequence: sequence_name; Backpointer to the creating sequence of thesequence. Assigned automatically in pre_generate()of the sequence if such a parent exists




Notes

• Some of the above methods apply only for BFM sequence drivers and not for virtual sequence drivers.For more information about virtual sequences, see “Using Virtual Sequences” on page 5-23.

• The only way to define sequence drivers is via the sequence statement; however, you can define abase sequence driver by deriving it from any_sequence_driver. For more information, see “Creatinga Common Base for Your Sequence Drivers” on page 5-50.

• For the full list of the sequence driver unit members, see “any_sequence_driver Interface” on page5-113.

5.3.2.3 Item Struct

The sequence statement does not create the item struct, but it extends it.

The main members that are added to the item struct are:

For the full list of the item struct members, see “any_sequence_item Interface” on page 5-111.

5.3.2.4 Sequence Kind Type

The sequence statement creates a new kind enumerated type called “sequence_name_kind”(ex_atm_sequence_kind in “Example 1” on page 5-6), which has the following predefined values:

sequence: MAIN sequence_name; The MAIN sequence, whose body is startedautomatically at the beginning of the run phase

event clock; Main clock for the sequences (to be implemented bythe user)

get_next_item(): item_name @clock Method used to get the next item to be created by thesequences

event item_done Event emitted to inform the sequence driver that theBFM is ready for the next item

driver: driver_name; Reference to the sequence driver that facilitates theactual driving to the DUT

parent_sequence: sequence_name; Backpointer to the creating sequence of the item.Assigned automatically in pre_generate() of theitem



Sequences: Constructing Test ScenariosHooking the Sequence Driver to the Environment

Note Cadence recommends that all enumerated values be stated in uppercase letters. In addition, alluser-defined sequence kinds should be defined as uppercase names. For example:

extend ex_atm_sequence_kind: [LEGAL_CELLS];extend LEGAL_CELLS ex_atm_sequence {

body() @driver.clock is only { ... };};extend MAIN ex_atm_sequence {

body() @driver.clock is only { ... };};

See Also

• “Predefined Sequence Kinds” on page 5-117

5.3.3 Hooking the Sequence Driver to the Environment

To hook the sequence driver into your environment:

1. Add a reference to the sequence driver in the BFM.

2. Instantiate the sequence driver in the environment.

3. Connect the sequence driver’s clock to the BFM’s clock.

4. Transfer the item from the driver to the BFM by adding a TCM that explicitly requests items fromthe driver and calls the appropriate BFM’s TCM.

5. (Optional) Add useful fields and methods to the base sequence type.

Hookup Example

Assume an ex_atm_cell item that is defined as follows:

struct ex_atm_cell like any_sequence_item {...

MAIN A sequence that loops n times creating the sequence field (randomly unlessconstrained). The driver contains an instance of the MAIN sequence, whichis started automatically upon run().

RANDOM Same as MAIN but used inside other sequences.

SIMPLE A sequence that contains a single item.



Sequences: Constructing Test ScenariosHooking the Sequence Driver to the Environment

};

Have a BFM that knows how to drive a cell into the DUT:

unit ex_atm_bfm {event a_clock is rise('atm_clk') @sim; // ATM main clockdrive_cell(cell: ex_atm_cell) @a_clock is { // drives cells to the DUT

...};

};

The BFM is instantiated in an ATM verification environment:

unit ex_atm_agent {bfm: ex_atm_bfm is instance;

};

Now define the ATM sequence and sequence driver, and hook the sequence driver into the BFM:

// Define ex_atm_sequence, ex_atm_sequence_kind, and ex_atm_driversequence ex_atm_sequence using item=ex_atm_cell,

created_driver=ex_atm_driver;

Then hook the sequence into the environment:

// 1. Add a reference to the sequence driver in the BFMextend ex_atm_bfm {

driver: ex_atm_driver;};

// 2. Instantiate the sequence driver in the ATM environmentextend ex_atm_agent {

driver: ex_atm_driver is instance;keep bfm.driver == driver;

};

// 3. Connect the (predefined) clock event to the BFM's clockextend ex_atm_bfm {

on a_clock {emit driver.clock;

};};

// 4. Pull item from driver, process it, then inform using item_doneextend ex_atm_bfm {

execute_items() @clock is {var seq_item: ex_atm_cell;while TRUE {

seq_item = driver.get_next_item();



Sequences: Constructing Test ScenariosImplementing Sequences

drive_cell(seq_item);emit driver.item_done;

};};

run() is also {start execute_items();

};};

Step 5 is optional:

// 5. Extend the base ex_atm_sequence typeextend ex_atm_sequence {

!cell: ex_atm_cell;};

At this point, your environment is already capable of generating (by default) random sequences.

• The sequence driver generates the MAIN sequence and starts its body() method upon run().

• The launched MAIN sequence creates count sequences of any kind, randomly selected from thecurrently loaded ATM sequences. (count is a field in the predefined MAIN sequence.) Initially, thisis only the SIMPLE sequence, so you will have a random stream of ATM cells. See also “MAINSequence” on page 5-118.

• The execute_items() TCM of the BFM pulls the items created by the sequences and drives them intothe DUT using the drive_cell() TCM.

• After each item is driven to the DUT, the event driver.item_done is emitted to let the sequencecomplete the do action and inform the driver that the item was processed.

Note If your verification environment contains several ex_atm_unit instances, each of them will havea sequence driver and hence a MAIN sequence and a random stream.

See Also

• “BFM-Driver Interaction Mode” on page 5-43

5.4 Implementing SequencesThis section describes how to implement various scenarios using the sequence struct and its relatedmethods and features. It then describes how to build your sequence library, which will be used later intests.




Sequences: Constructing Test ScenariosImplementing a Scenario Using the Sequence Struct

• “Implementing a Scenario Using the Sequence Struct” on page 5-12

• “Creating a Sequence Library” on page 5-17

5.4.1 Implementing a Scenario Using the Sequence StructA sequence can be defined by the set of items that it creates. These items can be created directly by thesequence or indirectly by creating subsequences (sequences within sequences) that in turn create items.Creation of items/subsequences is done in a dedicated predefined TCM named body(), using thededicated do action.


• “Defining the Behavior of Sequences” on page 5-12

• “Activating Items and Subsequences” on page 5-13

• “Using Sequences from a “first of” Block” on page 5-13

• “Parameterizing Sequences” on page 5-15

• “Enhancing the User Interface” on page 5-15

5.4.1.1 Defining the Behavior of Sequences

The body() TCM is a predefined TCM of any_sequence that is implemented to define the behavior ofthe sequence. The body() TCM of the MAIN sequence that is generated directly under the sequencedriver is launched automatically by the run() method of the sequence driver. The body() of anysubsequence is activated by the do action.

The body() TCM defines the life cycle of the sequence and, as such, defines the duration of thesequences. Before body() is initiated, the predefined event started occurs. When body() is finished, thepredefined event ended occurs.

You cannot call or start body() directly. Instead, use the following:

To call the body() TCM:

• Use the do action.

For example:

do sequence;

To start the body() TCM:

• Use the any_sequence predefined method start_sequence().




For example:

sequence.start_sequence();

Note The do action can be used only within a sequence TCM. For details about the additional effectsof the do action, see “Activating Items and Subsequences” on page 5-13.

Except for the aforementioned restriction, body() is just a normal TCM. You can use ordinaryprocedural code in it, and you can extend it using is first, is also, or is only.

When starting the body() TCM using the start_sequence(), there are two hooks, pre_body() andpost_body() TCMs, that can be used as follows:

Note The MAIN sequence is started automatically, using the start_sequence() method. For moreinformation about the start_sequence() method, see “start_sequence()” on page 5-99.

5.4.1.2 Activating Items and Subsequences

To activate an item or a subsequence from within a sequence:

• Use the do action.

See Also

• do on page 5-95

• do_and_grab on page 5-97

5.4.1.3 Using Sequences from a “first of” Block

When using a do action in a first of branch, the do action might terminate prematurely if a differentbranch concludes first. Table 5-1 describes the way the sequence mechanism handles the situation,depending on the state of the do action.

pre_body() This lets you do any actions (time-consuming or non-time-consuming) priorto execution of body() and, if need be, prevent the execution of body() bycalling the stop() method.

post_body() This lets you do any actions (time-consuming or non-time-consuming) afterthe execution of body().

Table 5-1 Handling of Premature Termination of do Action

State of do Action Description of Behavior

Waiting for scheduling The sequence driver will not schedule this do action.




Note Table 5-1 is relevant only when the do action applies to an item. When the do action applies to asequence rather than an item, no interaction with the driver is involved.

When calling a get/try_next_item() method in a first of branch, the method might terminateprematurely if a different branch concludes first. Table 5-2 describes the way the sequence mechanismhandles the situation, depending on the state of get/try_next_item().

Notes

• When working with a layered protocol, a get/try_next_item() method might be called as a result ofa do action from another layer. That do action might also be inside a first of, in which case theget/try_next_item() would also be inside the first of.

• When a first of branch calling get/try_next_item() is terminated after the item is received,driver.item_done must still be emitted.

In pre_do() The sequence driver will not be able to schedule another do actionduring the current cycle. Normal operation resumes in the next cycle.

You can enable resumption of normal operation in the current cycle bycalling the method any_sequence_driver.branch_terminated() afterthe first of completes.

After pre_do() and itemgeneration

The sequence driver will return the item (if not already returned).Normal operation resumes after emitting item_done.

Table 5-2 Handling of Premature Termination of get/try_next_item()

State of get/try_next_item() Description of Behavior

Driver has not yet chosen a do action Nothing happens (as if there was no call toget/try_next_item()).

Driver already chose a do action butget/try_next_item() did not returnyet

Chosen do action is discarded (even if the item is alreadygenerated). The sequence continues to run (as if the dofinished normally).

Table 5-1 Handling of Premature Termination of do Action

State of do Action Description of Behavior




5.4.1.4 Parameterizing Sequences

Cadence recommends representing any specific behavior of the sequence by a field so that the value ofthe field is the parameter for the specific feature in the sequence behavior. For example, if your sequencecreates items in a loop, then the number of iterations of the loop is a typical parameter. These parameterscan be viewed as the public interface of the sequence.

In this way, you can later control the parameters using constraints from the outside without knowing theactual implementation of body().

For example, consider the predefined RANDOM sequence:

extend RANDOM ex_atm_sequence {count: uint;!sequence: ex_atm_sequence;

body() @driver. clock is {for i from 1 to count {

do sequence;};

};};

The parameter of this sequence is count, which is the number of random sequences that will be createdby the sequence. You can control the behavior of all RANDOM sequences in the environment byconstraining the count:

extend RANDOM ex_atm_sequence {keep count in [10..20];

};

Note Such a constraint can also be applied locally to a RANDOM sequence field in another sequenceor even in a specific do.

5.4.1.5 Enhancing the User Interface

In addition to using the do action directly, you might want to define a more high-level interface byencapsulating a set of actions in methods. This can be done by wrapping a do action by either methodsor macros.

Using Methods

In the sequence struct, you can define methods that encapsulate a typical do action. An example is aread/write interface.

For example, assume that a bus-based design with the basic item c_bus_op is defined as follows:




struct c_bus_op like any_sequence_item {kind: [READ, WRITE, OTHER];address: int;color: [RED, GREEN, WHITE];when WRITE c_bus_op {

data: int; // Sent data};when READ c_bus_op {

!data: int; // Returned data};

};

You can perform read operations by using the do action as follows:

do c_bus_op keeping {.kind == READ; .address == 0x100};

But sometimes it is more convenient to write something like:

write(0x100, j);k = read(0x104);

To do that, define methods in the corresponding sequence that implement these operations:

extend ex_c_bus_sequence {!write_op: WRITE c_bus_op;!read_op: READ c_bus_op;

// Do a c_bus writewrite(address: int, data: int) @driver.clock is {

do write_op keeping {.address == address; .data == data};};

// Do a c_bus read// NOTE: The read operation returns a value to the sequence. This// requires additional infrastructure in the send_to_bfm() method to// ensure that the data on the operation will be valid after the do// action.read(address: int): int @driver.clock is {

do read_op keeping {.address == address};return read_op.data;

};};

This lets you use the convenient procedural interface while still keeping the ability to constrain otherfields (such as c_bus_op.color) from the outside.

For more information about a read/write interface, see “DUT-Independent Read/Write Interface” on page5-39.



Sequences: Constructing Test ScenariosCreating a Sequence Library

Using Macros

Sometimes, you might need the greater syntactical flexibility that only macros can afford. In that case,Cadence recommends creating action macros that implement typical do actions. For example:

define cell'action "cell <len'num> <kind'name>[ <x'num>]" as {do cell keeping {

.len == <len'num>;

.kind == <kind'name>;

.x == <x'num|0>;};

};

Then you can write shorthand like:

body() @driver.clock is only {cell 2 GREEN;for i from 1 to 20 do {

cell 3 BLUE;};

};

5.4.2 Creating a Sequence LibraryOnce you define the sequence struct, you can create various scenarios (sequence kinds) by creatingsubtypes of the sequence using the kind field. Each kind of sequence can implement a typical scenarioor a combination of existing scenarios. The set of sequence kinds is the “sequence library”.

Cadence recommends defining the sequence library in a separate file or files that can be loaded on top ofthe environment. This lets you include or exclude some of the sequence kinds upon demand of specifictests.

Note The term “subtype” applies when creating a new type using when inheritance.

To create a sequence library:

1. Extend the sequence kind type with the desired new kind.

For example:

extend ex_atm_sequence_kind: [SHORT_LONG];

2. Extend the new sequence subtype of the kind with any of the following:

• New parameters

• New implementation of body()



Sequences: Constructing Test ScenariosWriting Tests Using Sequences

• Any other struct members such as constraints, methods, and so on

For example:

extend SHORT_LONG ex_atm_sequence {// new parametershort_count: int [1..8]; // number of short cells in sequence// New implementation of body()body() @driver.clock is {

for i from 1 to short_count do {do cell keeping {.len <= 2};

};do cell keeping {.len == 5};

};};

Note Cadence recommends encapsulating any meaningful scenario as a new sequence kind.

3. Iterate Step 1 and Step 2 as required.

5.5 Writing Tests Using SequencesAfter defining sequences and implementing several subtypes in the environment, it is time to use them.As a sequence models the input stream of an agent, it becomes the common interface for writing tests.

Cadence recommends using sequences in tests to create a sequence library by defining many subtypes ofsequences based on the kind field of the sequence. (See “Creating a Sequence Library” on page 5-17.)Then create tests that use these subtypes by parameterizing them, enhancing them, or using them as iswith some weights.

In some simple cases you can avoid defining new sequence kinds altogether by directly redefining thebody() method of the MAIN sequence.

Alternatively, you can define a specific new sequence kind directly in the test and then use it.

This section demonstrates all of the above options. This section includes:

• “Writing the Simplest Test: Redefining MAIN Sequence body()” on page 5-19

• “Writing a Typical Test: Using the Sequence Library” on page 5-19

• “Writing a Dedicated Test: Creating a New Sequence Kind” on page 5-21

• “Writing a Unit-Related Test: Using Unit ID” on page 5-21

Note The eRM library contains example directories with many sequence definitions and tests that youcan study and run.



Sequences: Constructing Test ScenariosWriting the Simplest Test: Redefining MAIN Sequence body()

5.5.1 Writing the Simplest Test: Redefining MAIN Sequencebody()

The simplest way to write tests is to redefine the behavior of the MAIN sequence by overriding itsbody() method.

This is sufficient to create a test, because the MAIN sequence is started automatically as part of theinfrastructure of sequences and so there is no need to handle that in the test.

This approach is useful for creating simple directed tests.

Example

extend MAIN ex_atm_sequence {body() @driver.clock is only {

do cell;do cell keeping {.color == GREEN};

};};

5.5.2 Writing a Typical Test: Using the Sequence LibraryThe most powerful way to write tests with sequences is by creating a rich library of sequence kinds andthen using them, mixing them, slightly modifying them, and so on. Typically, the resulting tests are acombination of all of the above. This section demonstrates two modes of use for existing sequencekinds:

• “Writing a Random Test: Setting Weights” on page 5-19

• “Modifying an Existing Sequence” on page 5-20

5.5.2.1 Writing a Random Test: Setting Weights

The easiest and quickest way to create a test based on the sequence library is to choose a subset that willbe activated in the specific test, then set weights for each kind using keep soft … select according to therequired appearance frequency.

Example

extend MAIN ex_atm_sequence {keep soft sequence.kind == select {

30: ALTERNATING_COLOR;60: SHORT_LONG;10: FIXED_LEN;

};



Sequences: Constructing Test ScenariosWriting a Typical Test: Using the Sequence Library

};

5.5.2.2 Modifying an Existing Sequence

Often, using the existing kinds is not sufficient. Sometimes it is enough to just apply additionalconstraints on the sequence parameters, but sometimes you want to introduce somewhat differentbehavior (for example, waiting three more cycles) into an existing sequence.

The way to modify an existing sequence is to extend the sequence subtype in the test itself.

Example

// Modify the behavior of FIXED_LEN sequence - wait additional 3 cycles// after it endsextend FIXED_LEN ex_atm_sequence {

body() @driver.clock is also {wait [3] * cycle;

};};

// Use the (modified) kind in the testextend MAIN ex_atm_sequence {

keep soft sequence.kind == select {60: SHORT_LONG;40: FIXED_LEN;

};};

This approach can be used in conjunction with a specific unit. In that case, you can add a flag thatdetermines the behavior and then constrain the flag under the specific unit. For example, to apply theabove (waiting 3 cycles) only to sequences under unit ATM_0, extend the target_sequence within the efile describing the current test or sequence.

// Add control to the behavior of 'fixed_len' sequence.// Add option to wait additional 3 cycles.// Add a unit-related constraint to activate the additional behavior.extend FIXED_LEN ex_atm_sequence {

use_extra_waits: bool;// Set default behavior.keep soft use_extra_waits == FALSE;// Activate additional behavior for ATM_0.keep in_unit(ATM_0 ex_atm_driver) => use_extra_waits == TRUE;

};

// Implement the additional behavior under the new subtype.extend use_extra_waits FIXED_LEN ex_atm_sequence {



Sequences: Constructing Test ScenariosWriting a Dedicated Test: Creating a New Sequence Kind

body() @driver.clock is also {wait [3] * cycle;

};};

// Use the (modified) kind in the test.extend MAIN ex_atm_sequence {

keep soft sequence.kind == select {60: SHORT_LONG;40: FIXED_LEN;

};};

Note This is very modular, even though an existing sequence is extended inside a file describinganother sequence.

5.5.3 Writing a Dedicated Test: Creating a New SequenceKind

Although the recommended way of writing sequences is to use the sequence library, it is sometimeseasier to define the new kind directly in the test. This can be done when:

• You do not intend to use the sequence in any other test.

• You do not want to expose the environment to this sequence (to avoid random sequences using thiskind occasionally).

To define a sequence kind in a test, use the same methodology recommended in “Creating a SequenceLibrary” on page 5-17.

Note If you redefine a sequence in several tests, consider adding that sequence to the sequence libraryand using it as mentioned in “Writing a Typical Test: Using the Sequence Library” on page 5-19.

5.5.4 Writing a Unit-Related Test: Using Unit IDCadence recommends that units have ID fields associated with their roles within the parent unit.

These ID fields can be enumerated types (for example, ex_atm_name) or numbers (for example,agent_num). In effect, these fields correspond to the role the field is playing. For example, you can addto your environment a code similar to this:

type ex_atm_env_name: [NORTH, SOUTH];extend ex_atm_env {

name: ex_atm_env_name;};unit comm_env {



Sequences: Constructing Test ScenariosWriting a Unit-Related Test: Using Unit ID

north_atm: NORTH ex_atm_env is instance;south_atm: SOUTH ex_atm_env is instance;ethernet_ports: list of ethernet_port is instance;

keep for each in ethernet_ports {.ind == index};};

These ID fields are convenient for specifying constraints for sequences and also for constraints on theunit itself. For example:

extend NORTH ex_atm_env {keep foo == 4;

};

Once such IDs exist, you can use methods like those mentioned in “Propagating Parameters in theSequence Tree” on page 5-31 and “Migrating Unit Attributes to the Sequences” on page 5-32 to apply theIDs to the sequences themselves.

Note The name “NORTH ex_atm_env” specifies a role of ex_atm_env, sometimes mistakenly calledan instance.


• “Unit IDs to Constrain Sequences” on page 5-22

• “Hierarchical Unit IDs” on page 5-22

5.5.4.1 Unit IDs to Constrain Sequences

Use unit IDs to constrain sequences when the scenario depends on a particular unit.

Suppose you want to write a test in which only one ATM env will run the multi_write sequence (with anaddress of 20). The rest will run random. You could achieve that as follows:

extend MAIN ex_atm_sequence {keep in_unit(NORTH ex_atm_env) =>

soft sequence is a MULTI_WRITE ex_atm_sequence (s) ands.address == 20;

};

5.5.4.2 Hierarchical Unit IDs

Use hierarchical IDs when roles are not unique throughout the DUT.

For example, you could define an SoC containing four comm_envs as follows:

unit SoC {comm_envs[4]: list of comm_env;

keep for each in comm_env {.index == index};



Sequences: Constructing Test ScenariosSequence File Organization

};

You now have four NORTH ex_atm_envs. If you load your previous test on top of this environment, itwill run a multi_write sequence on each one of them. If, instead, you want to have all but the first be oftype xx, you can do that as follows:

extend MAIN ex_atm_sequence {keep in_unit(NORTH ex_atm_env) and in_unit(comm_env) (C) and

C.index != 0 => soft sequence is an XX ex_atm_sequence;};

5.6 Sequence File OrganizationTypically, sequence implementation is split into several files:

Note The erm_lib directory contains several full environments (see the LIBRARY_README.txt file).However, outside the area of sequences, it is not a good example. For one thing, it defines the whole ATMenvironment in one file (ex_atm_env.e) to simplify the exposition.

See Also

• Chapter 3 “eVC File Organization”

5.7 Using Virtual SequencesBFM sequences are tightly connected to their own type and items. In other words, BFM sequences canonly do sequences of their own type or items of the type specified in the sequence statement. BFMsequences cannot do sequences created by other sequence statements.

Virtual sequences, unlike BFM sequences, are not tightly connected to a specific sequence type or item.Virtual sequences can do sequences of other types (but not items). As a result, you can use virtualsequences to:

Sequence definition files Define a sequence for a specific item (packet, transaction,and so on) in any environment

DUT-specific sequencehook file

Extends the sequence for use with a specific DUT and hooksthe sequence to the environment

Sequence libraries Define various sequence subtypes that implement specificscenarios, either generic or DUT-specific

Test files Import relevant sequence libraries and use them



Sequences: Constructing Test ScenariosCreating a Virtual Sequence

• Drive more than one agent

• Model a generic driver

A virtual sequence is driven by a virtual sequence driver, which typically has references to the individualBFM sequence drivers. Virtual sequences can be used to synchronize and dispatch BFM sequences toseveral BFM drivers.

A virtual sequence driver is not connected to a specific BFM. Therefore, it lacks the logic andfunctionality of a BFM driver. For example, a virtual sequence driver does not schedule items—it onlydrives sequences. As much of the driver functionality is aimed at controlling and manipulating thescheduling of items, any method that controls this functionality cannot be called for a virtual sequence.For example, you cannot grab/ungrab a virtual sequence driver, because grabbing manipulates thescheduling of items. For a full list of driver interface methods that cannot be used for virtual drivers, seeTable 5-17 on page 5-113.

The following sections describe how this is done.

See also ex_soc_1_sequences.e in the ex_soc/e directory, or just load ex_soc_1_test.e (in theex_soc/examples directory) and run it.


• “Creating a Virtual Sequence” on page 5-24

• “Passing of Sequence Drivers” on page 5-26

• “Making Other Sequence Drivers Behave” on page 5-26

• “Sequences for SoC” on page 5-27

• “Transactions” on page 5-29

5.7.1 Creating a Virtual Sequence

To create a sequence that controls several sequence drivers:

1. Define a virtual sequence with a corresponding virtual sequence driver.

For example:

sequence comm_sequence; // Note no "item=" option

2. Add fields to the virtual sequence driver that point to the subdrivers.

For example:

extend comm_sequence_driver {atm: ex_atm_master_sequence_driver;



Sequences: Constructing Test ScenariosCreating a Virtual Sequence

ethernet: ethernet_sequence_driver;

3. Define the get_sub_drivers() method to return the subdrivers.

For example:

get_sub_drivers(): list of any_sequence_driver is {return {atm; ethernet};

};};

Note Although this method is needed by the sequence mechanism only when applying stop() onvirtual sequences, you might find the method useful for applying procedural actions on yoursubdrivers. For example:

for each (d) in get_sub_drivers() {....

};

4. Define the sequence driver in the appropriate unit in your environment (probably the lowest unitenclosing all of the component drivers).

For example:

extend comm_subsystem_unit {driver: comm_sequence_driver is instance;// Constrain the subdrivers.keep driver.atm == atm1_unit.driver;keep driver.ethernet == ethernet_router_unit.driver;

};

The sequence driver will launch under its MAIN comm_sequence.

5. Define a clock for the sequence driver.

For example:

extend comm_sequence_driver {event clock is only @sys.any;

};

Notes

• A virtual sequence cannot do items directly, but only sequences. To activate single items from avirtual sequence, use the SIMPLE sequence. You can pass any desired parameters to the item bydefining the parameters as fields in the SIMPLE sequence and propagating them by constraining theitem.

• For the full list of driver interface methods that cannot be used for virtual sequences, see “SequenceInterface” on page 5-110.



Sequences: Constructing Test ScenariosPassing of Sequence Drivers

5.7.2 Passing of Sequence DriversBy default, the driver of a called sequence (including the driver of an item that is created within asequence) is the driver of the calling sequence.

This is enforced via a soft constraint. However, when a virtual sequence is do-ing a BFM sequence, itmust pass the appropriate subdriver to the BFM sequence.

To pass a sequence driver for a sequence:

• Constrain the sequence driver in the keeping block of the do action.

For example:

do RWR ex_atm_sequence keeping {.driver == driver.atm};

5.7.3 Making Other Sequence Drivers BehaveSuppose you create a virtual sequence driver that controls two subdrivers (as in theex_soc_1_sequence.e file). How do you want the subdrivers to behave while your new, virtual sequencedriver is also sending them items?

There can be three main answers:

• Business as usual:

You want the virtual sequence driver and the original sequence drivers to work at the same time,using the built-in capability of the original sequence drivers.

This is the default behavior. There is no need to do anything to achieve this.

• Disable the subdrivers:

This is most simply achieved as follows (taken from ex_soc_1_test.e):

extend MAIN ex_atm_sequence {keep count == 0;

};

extend MAIN ex_c_bus_sequence {keep count == 0;

};

Setting the count to 0 means these MAIN sequences will return immediately.

Note Alternatively, you can override the body() TCM of the MAIN sequence to do nothing asfollows:

extend MAIN ex_c_bus_sequence {body() @driver.clock is only {};



Sequences: Constructing Test ScenariosSequences for SoC

};

• Use grab() and ungrab():

Using grab() and ungrab(), a virtual sequence can achieve full control over the subdrivers for alimited time, then let the original sequences continue working.

Note When grabbing several sequence drivers, make sure to use some convention to avoiddeadlocks. For example, always grab in a standard order.

5.7.4 Sequences for SoCSoC environments typically require synchronization of the input of several agents, as illustrated inFigure 5-2 on page 5-27.

Figure 5-2 eVCs within SoC Design

To control a multiple-agent environment:

1. Ensure that each of the agents has its own sequence (and sequence driver).

2. Define a new (virtual) sequence (and sequence driver) using the sequence statement and omittingthe item parameter.

MemoryController

DMAController

System Chip

CPU Bus

Peripheral Bus

Virtual SequenceBFM

SD

Mon

BFM

SD

Mon

BFM

SD

MonBFM

SD

MonBFM

SD

MonBFM

SD

Mon

Bridge

EthernetUSBGPIOUART



Sequences: Constructing Test ScenariosSequences for SoC

3. Add the existing sequence drivers as fields of the new sequence driver.

4. Pass the existing sequence drivers using constraints to the BFM sequences done by the virtualsequence.

SoC Sequence Example

sequence comm_sequence; // Note no "item=" optionextend comm_sequence_driver {

atm_driver: ex_atm_master_sequence_driver;eth_driver: ethernet_sequence_driver;

};

extend comm_subsystem_unit {driver: comm_sequence_driver is instance;

keep driver.atm_driver == ex_atm_unit.driver;keep driver.eth_driver == ethernet_unit.driver;

};

extend MAIN comm_sequence {!atm_sequence: ex_atm_sequence;!eth_config: ethernet_sequence;body() @driver.clock is only {

do eth_config keeping {.driver == driver.eth_driver};do atm_sequence keeping {.driver == driver.atm_driver};

};};

extend MAIN ex_atm_sequence {keep count == 0;

};-

Figure 5-3 on page 5-29 demonstrates the above example.



Sequences: Constructing Test ScenariosTransactions

Figure 5-3 SoC Sequence Example

5.7.5 TransactionsThe term “transaction” includes both items and sequences. In an SoC context, there can be DMAtransactions, MPEG transactions, and so on.

Such transactions normally consist of writing to several registers to initialize the DMA or MPEG deviceand possibly sending an MPEG input packet to the MPEG input channel, either in parallel or afterwriting to all of the registers.

It is easiest to package the transaction as a virtual sequence. Then you can have a higher-level sequencego as follows:

do sequence keeping {.kind == DMA_TRANS};do sequence keeping {.kind == MPEG_TRANS};

5.8 Advanced Generation-Related Aspects ofSequences

This section explains some advanced aspects of sequences in relation to generation.

Virtual Driver

BFM

comm_subsystem_unit

seq

eth_config

atm_sequence

ATM Sequence Driver

seq

atm_env

Ethernet Sequence Driver

eth_env

seqseq

seq

seq

do eth_config keeping {.driver=eth_driver;

};

do atm_sequence keeping {.driver=atm_driver;

};

BFM



Sequences: Constructing Test ScenariosSpecifying Subtype in do Actions

This section contains:

• “Specifying Subtype in do Actions” on page 5-30

• “Propagating Parameters in the Sequence Tree” on page 5-31

• “Migrating Unit Attributes to the Sequences” on page 5-32

• “Generating the Item/Sequence in Advance” on page 5-33

• “Constraining Complex Sequence Items” on page 5-33

5.8.1 Specifying Subtype in do ActionsWhen you want to do subsequences or items of known subtype(s), you can improve performance in oneof two ways:

• Statically defining the subtype of your subsequences or items

• Explicitly specifying the subtype of your subsequences or items in the appropriate do actions

When all subsequences or items are of the same subtype, then statically define the subtype. When theyare not all of the same subtype, then specify the subtype in the appropriate do actions.

Syntax for Specifying Subtype in do Actions

do when-determinant1…n field [keeping { it. … };]

Parameters

Note “it” already refers to the subtype. There is no need for casting to access the subtype attributes.

Example 1

extend MAIN my_sequence {seq: my_sequence;

body() @driver.clock is {do RED seq keeping {

it.red_level == 10 // Access red_level without casting};do GREEN seq keeping {

when-determinant1…n Must be when determinants of the declared type of the field.

field The sequence or item



Sequences: Constructing Test ScenariosPropagating Parameters in the Sequence Tree

.green_level == 18;};do ATOMIC GREEN seq keeping {

it.green_level == 12;it.atomic_level == PARTIAL;

};do YELLOW seq ;

};};

Example 2

extend MAIN my_sequence {!seq: GREEN my_sequence;

body() @driver.clock is {// seq will be generated to LONG GREEN my_sequence (not GREEN LONG -// order does matter).do LONG seq keeping {

it.length > 10; // length is a field of LONG};// seq will be generated to ATOMIC GREEN my_sequencedo ATOMIC seq keeping {

it.green_level == 12;it.atomic_level == PARTIAL;

};};

};

5.8.2 Propagating Parameters in the Sequence TreeSometimes you must propagate the value of a sequence parameter (for example, unit ID) down thesequence tree so that the root sequence (for example, the MAIN sequence) is assigned a specific value.This value then propagates automatically to all sequences generated using do anywhere along thehierarchy underneath the root sequence.

To propagate parameters down the sequence tree:

1. Add the parameter to the base sequence type.

2. Use the predefined field parent_sequence to propagate the value.

For example:

keep parent_sequence != NULL => soft my_param ==parent_sequence.as_a(ex_atm_sequence).my_param;



Sequences: Constructing Test ScenariosMigrating Unit Attributes to the Sequences

3. Add an additional constraint for the root sequence in the root-sequence parent.

Example

type ex_atm_port_id: [ATM_0, ATM_1];

extend ex_atm_sequence {port_id: ex_atm_port_id; // Field to be propagatedkeep parent_sequence != NULL => // The propagating constraint

soft port_id == parent_sequence.as_a(ex_atm_sequence).port_id;};

extend ex_atm_driver {port_id: ex_atm_port_id;keep sequence.port_id == port_id; // Constrain sequence root in driver

};

5.8.3 Migrating Unit Attributes to the SequencesIt is often good methodology to migrate unit names and attributes to corresponding sequences.

To migrate unit names and attributes to corresponding sequences:

1. Define a field in the sequence struct to represent the unit attribute.

2. Migrate the value from the unit using get_enclosing_unit().

Example

extend ex_atm_sequence {// 1. Define the unit name in the sequence.name: ex_atm_name;// 2. Migrate the value from the enclosing unit.keep name == get_enclosing_unit(ex_atm_agent).name;

};

Then you can say things like:

extend NORTH MAIN ex_atm_sequence {...

};

This is a useful shorthand. Nevertheless, you might still need to reference the IDs of the enclosing unitsif you want a more complete hierarchical identification.



Sequences: Constructing Test ScenariosGenerating the Item/Sequence in Advance

5.8.4 Generating the Item/Sequence in AdvanceSometimes you might want to generate or instantiate the item or sequence before the do action. Youcould then use the instantiated item or sequence in the do action without regenerating it.

To generate/instantiate the item/sequence in advance:

1. Define an additional field/variable of the same type as the item/sequence.

2. Either generate the field/variable using the gen action or instantiate it using the new action.

3. Constrain the field in the do action to be equal to the additional field/variable (defined in Step 1).

For example:

extend FOO ex_atm_sequence {

// Items/subsequences!cell: ex_atm_cell;

// The body() methodbody() @driver.clock is {

var preprepared_cell: ex_atm_cell;gen preprepared_cell;...do cell keeping {it == preprepared_cell};

};};

To return immediately (non-blocking do), implement the method that processes the item to benon-time-consuming and return immediately.

5.8.5 Constraining Complex Sequence ItemsConstrain complex sequence items when

Suppose you have a data item that contains a list with items that you want to constrain. In this case, youcannot use the it variable to refer to the list items, because it already refers to the data item itself. Instead,you must specify a new name for the list items. In the following example, the name “item” is used forthis purpose.

extend NEW my_sequence {body @driver.clock is only {

do burst keeping {.addr <= 1000;.type in [READ, WRITE];for each (data_item) in .data { // Specify name for list item



Sequences: Constructing Test ScenariosImplementing Complex Scenarios

data_item > 10 and data_item < 90;};

};};

};

5.9 Implementing Complex ScenariosThis section contains:

• “Defining Concurrent Sequences” on page 5-34

• “Initializations and Configurations before Starting Sequences” on page 5-35

• “Interrupt Sequences” on page 5-36

• “Resetting and Rerunning Sequences” on page 5-37

• “DUT-Independent Read/Write Interface” on page 5-39

• “Controlling the Scheduling of Items” on page 5-42

• “Locking of Resources” on page 5-43

• “BFM-Driver Interaction Mode” on page 5-43

• “Handling Pipelined Protocols” on page 5-45

5.9.1 Defining Concurrent SequencesYou can create concurrent sequences in two ways:

• Using the do action within an all of block

• Starting several sequences using the start_sequence() method

Example 1 Using the do action

In this example, the number of sequences is determined statically.

// Do multiple SHORT_LONG sequences in parallelextend ex_atm_sequence_kind: [PARALLEL_3];extend PARALLEL_3 ex_atm_sequence {

!sl_seq: SHORT_LONG ex_atm_sequence;body() @driver.clock is {

all of {{do sl_seq keeping {.short_count == 1}};{do sl_seq keeping {.short_count == 2}};



Sequences: Constructing Test ScenariosInitializations and Configurations before Starting Sequences

{do sl_seq keeping {.short_count == 3}};};

};};

Example 2 Starting several sequences in parallel

In this example, the PARALLEL_N sequence activates n sequences in parallel. It does not wait for thesequences to complete, but immediately finishes after activating the sequences.

// Do multiple SHORT_LONG sequences in parallelextend ex_atm_sequence_kind: [PARALLEL_N];extend PARALLEL_N ex_atm_sequence {

// num_of_sequences can be constrained from abovenum_of_sequences: int;keep soft num_of_sequences == 3;// The list of sequences to activatesl_seq_l: list of SHORT_LONG ex_atm_sequence;keep sl_seq_l.size() == num_of_sequences;keep for each in sl_seq_l {

it.driver == driver;};

body() @driver.clock is {for each (seq) in sl_seq_l {

it.start_sequence();};

};};

Note The number of sequences that PARALLEL_N activates can be controlled by a higher-levelsequence.

5.9.2 Initializations and Configurations before StartingSequences

The sequence driver generates the MAIN sequence and starts its body() method upon run(). Sometimesyou might want to perform some operations before starting to randomize the sequences. For example, atest might start with a configuration stage and an initialization stage before the actual testing starts.

You can implement these preliminary stages of the test with sequences. For example:

extend MAIN ex_atm_sequence {body() @driver.clock is only {

do initialization_sequence;



Sequences: Constructing Test ScenariosInterrupt Sequences

...};

};

Another way to perform initializations before the test is by extending the pre_body() method to delaythe execution of body(). For example:

extend MAIN ex_atm_sequence {pre_body() @sys.any is {

// Perform configurationconfigure_dut();// Wait until initialization is donesync true(driver.initialization_done);

};};

5.9.3 Interrupt SequencesMany environments include an interrupt option. Typically, an interrupt occurrence should be coupledwith some reaction from the agent. Once the interrupt is done, you can consider either aborting anyprevious activity or continuing it from the point where it stopped. All of this can be supported usingsequences.

To handle interrupts using sequences:

1. Define an interrupt sequence that implements the reaction-upon-interrupt scenario, including:

a. Wait for the interrupt event to occur (that is, serves as the interrupt handler).

b. Grab the sequence driver for exclusive access.

c. (Optional) Stop the activity of the other existing sequences.

d. Execute the interrupt scenario.

e. Ungrab the sequence driver.

2. Instantiate the interrupt sequence under the sequence driver.

3. Start the interrupt sequence in the run() method of the sequence driver.

Example

(Taken from ex_interrupt_abort_test.e in the ex_atm/examples directory.)

// 1. Define an interrupt sequence.extend ex_atm_sequence_kind: [INTERRUPT_ABORT];



Sequences: Constructing Test ScenariosResetting and Rerunning Sequences

extend INTERRUPT_ABORT ex_atm_sequence {// Upon interrupt, grab driver, terminate all its main activity, and// send a configuration sequencebody() @driver.clock is {

sync @driver.interrupt; // Wait for the interrupt event.grab(driver); // Grab the driver.driver.sequence.stop(); // Stop the MAIN sequence activity.do cell keeping {.color == RED}; // Execute the interrupt scenario.

do cell keeping {.color == GREEN};do cell keeping {.color == BLUE};

ungrab(driver); // Ungrab the driver.};

};

extend ex_atm_driver {// 2. Instantiate the interrupt sequence under the sequence driveriseq: INTERRUPT_ABORT ex_atm_sequence;

keep iseq.driver == me;

// 3. Start the interrupt sequencerun() is also {

iseq.start_sequence();};

};

// The test partextend MAIN ex_atm_sequence {

keep count == 1;keep sequence is a ALTERNATING_COLOR ex_atm_sequence;

};

Note You can make the activity-termination option a parameter of the interrupt sequence. For example,you could have the sequence actually terminate the other activity only if a Boolean flag is set.

5.9.4 Resetting and Rerunning SequencesSometimes you might need to re-execute (reactivate) the sequence driver and its sequences. Forexample, this could happen upon reset of the DUT.

All Specman structs have the predefined method rerun() for reactivating the struct and re-executing therun() method.

There are two typical modes of operation upon reset:

• Call quit() upon reset. Then, at the end of the reset, call rerun().

• Call rerun() upon reset. Then use the reset-qualified clock for the struct’s TCM.



Sequences: Constructing Test ScenariosResetting and Rerunning Sequences

For sequence drivers, the following methods support re-execution of sequences:

Notes

• When calling to rerun(), the driver continues driving items until the end of the cycle. If the driverwas in the middle of do-ing an item at the end of the cycle, then that item might be lost.

• When you have a virtual sequence that controls multiple BFM sequence drivers, rerunning any ofthe BFM sequence drivers does not terminate the virtual sequence. If the virtual sequence was in themiddle of do-ing a BFM sequence that was do-ing an item at the end of the cycle, then that itemmight be lost but the BFM sequence continues.

The following runtime data is reset upon rerun, at the beginning of the next cycle:

Any additional actions needed at quit() time can be added to the quit() method of the driver using isalso. For example:

extend ex_atm_sequence_driver {quit() is also {

driver.quit() Calls to quit() for every started sequence under the driver

driver.rerun() 1. Calls to quit()

2. Resets the runtime data of the driver

3. Resets the runtime data of all started sequences

4. Re-executes the run() method, which by default starts the MAINsequence

All do item actionswaiting to be performed

This includes do actions initiated by a higher-level virtualsequence that continues to run. In such case, those do item actionsare skipped, and the sequence continues to run.

grab() method If the driver was grabbed by a sequence before the reset, then thegrab will be canceled along with the entire queue of sequenceswaiting to grab the driver. Therefore, a higher-level virtualsequence that grabbed the driver before the reset must regrab it ifneeded. Sequences that were waiting to grab the driver (that is,were blocked in the grab() method) are released without grabbingthe driver.

The list of previously sentitems

You cannot use last() to retrieve items that were done before thererun. For more information on last(), see “last()” on page 5-105.



Sequences: Constructing Test ScenariosDUT-Independent Read/Write Interface

out("quitting driver", me);};

};

Any additional actions needed at rerun() time can be added to the rerun() method of the driver using isalso. For example:

extend ex_atm_sequence_driver {rerun() is also {

out("rerunning driver", me);};

};

Sometimes, you might want to regenerate some of the driver’s data upon rerun() (before re-executingthe driver’s run()). You can do that by extending the method driver.regenerate_data(). For example:

extend ex_atm_sequence_driver {regenerate_data() is also {

gen sequence;};

};

Notes

• The rerun() method performs the following operations:• Quits the struct (which causes the termination of all TCMs and TEs).• Executes the run() method.• Re-initiates all TEs.

• The rerun() method does not cause an automatic emission of the @item_done event.

5.9.5 DUT-Independent Read/Write InterfaceThe uniform interface of sequences lets you develop a generic read/write interface that might be appliedto many environments and is not related directly to a specific DUT. Such an interface enablesdevelopment of system-level tests that are suitable for many configurations of the environment.

A typical example is a bus-based configuration test that can be executed over multiple buses, forexample, a PCI bus as well as an ATM bus.

To implement a DUT-independent interface:

1. Define a virtual read/write sequence that uses a generic low-level sequence driver to execute thelow-level read/write transactions.

2. Hook the virtual sequence driver to a specific sequence driver as follows:




a. Instantiate the virtual sequence driver.

b. Connect its low-level sequence driver to a specific sequence driver.

c. Implement the read/write interface methods of the low-level sequence driver.

Note The last portion of the step (2c) might be done already as part of the specificenvironment. See “Enhancing the User Interface” on page 5-15.

3. Use the virtual sequence driver in tests.

Note Each of these steps should reside in a separate file (to allow reuse).

Example

(This is from ex_cbus_rw_test.e in the ex_c_bus/examples directory.)

1. Define a virtual read/write sequence.

sequence config_sequence;extend config_sequence_driver {

low_driver: any_sequence_driver;event clock is only @sys.any;

// Implement the read/write interface so that it uses the// low-level sequence driver interface.

write(address: list of bit, data: list of bit) @clock is {low_driver.write(address, data);

};

read(address: list of bit) : list of bit @clock is {result = low_driver.read(address);

};};

2. Hook up the virtual sequence driver.

extend sys {cbus_env: c_bus_env is instance;

// Instantiate the virtual sequence driver.config_driver: config_sequence_driver is instance;

// Connect its low-level sequence driver to a specific// sequence driver.keep config_driver.low_driver == cbus_env.driver;

};




// Implement the read/write interface methods of the low-level// sequence driver.extend ex_c_bus_driver {

write(address: list of bit, data: list of bit) @clock is {sequence.write(pack(NULL, address), pack(NULL, data));

};

read(address: list of bit) : list of bit @clock is {result = pack(NULL, sequence.read(pack(NULL, address)));

};};

// Make the c_bus MAIN silent.extend MAIN ex_c_bus_sequence {

keep count == 0;};

3. Test Example: A generic (that is, DUT-independent) configuration test.

extend MAIN config_sequence {!w_data: uint(bits:4);!r_data: uint(bits:4);!addr: uint(bits:6);

body() @driver.clock is only {gen w_data;gen addr;

outf("sending data: %d to address: %x\n", w_data, addr);driver.write(%{addr},%{w_data});r_data = %{driver.read(%{addr})};

outf("received data: %d from address: %x\n", r_data, addr);};

};

Notes

• The test itself has no notion of the actual agent that eventually executes the read/write transactions.

• A similar approach can be used to develop additional generic actions such as reset.

• The use of list of bit and packing in the read/write interface of the sequence driver is essential toprevent dependency on a specific agent or format and a specific bit width.



Sequences: Constructing Test ScenariosControlling the Scheduling of Items

5.9.6 Controlling the Scheduling of ItemsThere might be several sequences do-ing items concurrently, but the driver can only handle one item ata time. So the driver maintains a queue of do actions; and when there is a demand for an item, the driverchooses a single do action to perform from the do actions waiting in the queue. Therefore, when asequence is do-ing an item, the do action is blocked until the driver is ready to choose it.

The scheduling algorithm works on a first-come-first-served basis. You can change the algorithm usinggrab() and is_relevant().

If a sequence is grabbing the driver, the driver will choose the first do action that satisfies the followingconditions:

• It is done by the grabbing sequence or its descendants.

• The is_relevant() method of the sequence do-ing it returns TRUE.

If no sequence is grabbing the driver, the driver will choose the first do action that satisfies the followingcondition:

• The is_relevant() method of the sequence do-ing it returns TRUE.

If there is no do action to choose, then get_next_item() is blocked. The driver will try to choose again(reactivate the scheduling algorithm) when one of the following happens:

• Another do action is added to the queue.

• A new sequence grabs the driver, or the current grabber ungrabs the driver.

• The method driver.check_is_relevant() is called. (For more information see “Forcing a Reevaluationof the do Action Queue” on page 5-54.)

• A new cycle begins.

When calling to try_next_item(), if the driver does not succeed in choosing a do action before the timespecified by driver.wait_for_sequences() elapses, then try_next_item() returns anyway but withNULL.

To control scheduling:

• Use is_relevant() to specify a condition for performing a do action.

or

• Grab the driver.



Sequences: Constructing Test ScenariosLocking of Resources

5.9.7 Locking of ResourcesSometimes a sequence might need to lock resources for a while so that temporarily other sequences willnot be able to touch them.

For example, a divide-by-zero machine instruction sequence might look like this:

extend DVZ inst_sequence {op1_reg: register;op2_reg: register;

body() @driver.clock is {do SET_REG inst_sequence keeping {.reg == op1_reg};...Do any random sequence not writing to op1_regdo SET_REG inst_sequence keeping {.reg == op2_reg; .value == 0};...Do any random sequence not writing to op1_reg or op2_regdo instr keeping {

.op == divide;

.op1 == op1_reg;

.op2 == op2_reg};...Release the locking on op1_reg and op2_reg

};};

The question is what to put in the lines starting with the ellipsis “...”. grab() and ungrab() will not workhere. They are useful to grab sequence drivers, not registers.

Cadence recommends using either Boolean flags or lockers inside the sequence driver (or inside the unitwhere the sequence driver resides). Have one flag or locker for every resource that you want to lock (forexample, a register that you do not want people to write to).

5.9.8 BFM-Driver Interaction Mode“Hooking the Sequence Driver to the Environment” on page 5-9 describes how to hook the sequencedriver into the environment. In the example given, there is a TCM in the BFM that explicitly calls todriver.get_next_item() in order to receive an item. This means that the environment controls when toget an item from sequences. This style of interaction is called PULL_MODE. It is the default mode.

Sometimes you might want the sequences to be the initiators so that you do not need to request an item.Instead, when the driver is ready to do an item, there is an implicit call to driver.send_to_bfm(). Thisstyle of interaction is called PUSH_MODE.

The interaction mode is determined by the value of driver.bfm_interaction_mode, which is constrainedby default to PULL_MODE.



Sequences: Constructing Test ScenariosBFM-Driver Interaction Mode

5.9.8.1 Working in PUSH_MODE

To work in PUSH_MODE:

1. Constrain driver.bfm_interaction_mode to be PUSH_MODE.

2. Implement the driver.send_to_bfm() TCM so that it calls the BFM TCM that drives the item intothe DUT.

Notes

• In PUSH_MODE, driver.item_done is automatically emitted when driver.send_to_bfm() returns.

• PUSH_MODE is implemented using PULL_MODE in the following way:

send_loop() @clock is {while TRUE {

var seq_item := get_next_item();send_to_bfm(seq_item);emit item_done;

};};

• The BFM interaction mode is a static property of the environment. It must not be modified duringsimulation.

For more information about the difference between PUSH_MODE and PULL_MODE, compare Figure5-18 on page 5-122 to Figure 5-19 on page 5-123.

Table 5-3 PULL_MODE versus PUSH_MODE Example

PULL_MODE PUSH_MODE

extend ex_atm_bfm {execute_items() @clock is {

var seq_item: ex_atm_cell;while TRUE {

seq_item =driver.get_next_item();

drive_cell(seq_item);emit driver.item_done;

};};

run() is also {start execute_items();

};};

extend ex_atm_driver {// Set interaction modekeep bfm_interaction_mode ==

PUSH_MODE;// Transfer the item from the// driver to the BFM:// Add a call to the BFM's TCM in// the sequence driver's// send_to_bfm()send_to_bfm(seq_item: ex_atm_cell)

@clock is only {bfm.drive_cell(seq_item);

};};



Sequences: Constructing Test ScenariosHandling Pipelined Protocols

5.9.9 Handling Pipelined ProtocolsIn pipelined protocols, data items undergo a number of processing phases. For example, a data transfermight be either in the address phase or in the data phase. In addition, the DUT can handle concurrentlymultiple data items with each item in a different phase.

When implementing pipelined scenarios with sequences some typical problems arise:

• How to launch a new data item while the current data item is still being processed

• How to ensure that the fields of the data item are stable before sampling them

To implement pipelined scenarios:

1. In the appropriate sequence, list the desired series of pipelined do actions.

2. Emit the item_done event when a trigger event in the BFM indicates that a new data item should besent to the DUT.

This releases the current do action and lets the sequence perform the next do action.

For example:

extend my_sequence {!trans1 : READ transfer;!trans2 : WRITE transfer;

body()@driver.clock is {-- List a series of pipelined do actionsdo trans1;do trans2;

};};

extend my_bfm {bfm_loop()@clock is {

while TRUE {trans = driver.get_next_item();start put_on_bus(trans);

-- Emit the item_done event when the trigger event occurswait @need_new_item;emit driver.item_done;

};};

};




If sampling of data items is required, you need a mechanism for detecting when the data-item fields areupdated and ready for sampling. In the above example, the sequence can start to do the WRITE burstbefore the fields of the READ burst are fully updated.

To ensure that data-item fields are ready for sampling:

1. Add a Boolean field to the data item that is set to TRUE when all fields are up to date.

2. Delay sampling of fields with a wait or sync action that is satisfied when the field is TRUE.

For example:

extend transfer {-- Add Boolean field!finished : bool;

};

extend my_sequence {!trans1 : READ transfer;

body()@driver.clock is {do trans1;-- Delay samplingsync true(trans1.finished);sample(trans1);

};};

When sampling of a pipelined data item’s fields is required immediately after the item is completelyprocessed, then the above approach must be refined. The sampling of each item must occur in a threaddistinct from that of the do of the next item. You can achieve this in several ways.

Example 1 Combine do action with associated sampling


get_data()@driver.clock is {-- Delay samplingwait true(finished);do_something_with(data);

};};

extend my_sequence {!trans1 : READ transfer;!trans2 : WRITE transfer;




body()@driver.clock is {var num_of_items : uint;all of {-- Create separate thread for each do-sample pair{ // First thread

do trans1;num_of_items = 1;trans1.get_data();

};

{ // Second threadsync true(num_of_items==1);do trans2;trans2.get_data();

};};

};




};};

};

Example 2 All do actions in a single thread but sampling in separate threads


get_data()@driver.clock is {-- Delay samplingwait true(finished);do_something_with(data);

};};

extend my_sequence {!trans1 : READ transfer;



Sequences: Constructing Test ScenariosMiscellaneous Advanced Features

!trans2 : WRITE transfer;

body()@driver.clock is {message(NONE,"running ",kind," burst");do trans1;start trans1.get_data(); // Sample in separate threaddo trans2;start trans2.get_data(); // Sample in separate thread

};};




};};

};

5.10 Miscellaneous Advanced FeaturesThis section includes:

• “Disabling Automatic Launch of the MAIN Sequence” on page 5-48

• “Creating a Common Base for Your Sequences and Sequence Drivers” on page 5-49

• “Applying Default Behavior When No Item Is Done” on page 5-51

• “Synchronization within a Cycle” on page 5-52

• “Quitting Sequences and Sequences Items” on page 5-54

5.10.1 Disabling Automatic Launch of the MAIN SequenceNormally, the MAIN sequence is generated and started automatically upon driver.run(). However, youcan disable this automatic process.

To disable automatic generation and launching of the MAIN sequence:

• Constrain the gen_and_start_main field under the sequence driver to be FALSE.



Sequences: Constructing Test ScenariosCreating a Common Base for Your Sequences and Sequence Drivers

For example:

extend ex_atm_driver {keep soft gen_and_start_main == FALSE;

};

5.10.2 Creating a Common Base for Your Sequences andSequence Drivers

A typical environment contains several sequences that use different items and also virtual sequences.For example:

sequence atm_sequence using item=atm_cell;sequence ethernet_sequence using item=ethernet_packet;sequence comm_sequence;

Although atm_sequence, ethernet_sequence, and comm_sequence are different sequence families, theycan have a common logic and functionality. Therefore, you might want to define a common base foryour sequences and a common base for your drivers. Some times when this could be useful are:

• When using layered sequence drivers that have a common functionality (for example, in the waythey extract data from the higher-level driver)

• When you want each sequence to print a standard header or footer when it is started or ended

• When you want to associate different sequences or drivers that use different items in one logic family,(for example, all AHB sequences)


• “Creating a Common Base for Your Sequences” on page 5-49

• “Creating a Common Base for Your Sequence Drivers” on page 5-50

5.10.2.1 Creating a Common Base for Your Sequences

To create a common base for your sequences:

1. Define a base_sequence struct that inherits from any_sequence (directly or indirectly).

struct base_sequence like any_sequence {

2. Implement the common logic for your sequences in your base_sequence struct.

3. Add the option sequence_type=base_sequence to the sequence statement for each sequence structthat you want to inherit from base_sequence.



Sequences: Constructing Test ScenariosCreating a Common Base for Your Sequences and Sequence Drivers

For example:

sequence my_seq using item=my_item, sequence_type=base_sequence;

Specifying sequence_type causes newly created sequence structs to inherit from base_sequencerather than any_sequence.

Notes

• The base_sequence struct can be derived from another base_sequence struct, not only fromany_sequence.

• The base_sequence struct only establishes a common logic. You cannot instantiate or generate aninstance of this type.

5.10.2.2 Creating a Common Base for Your Sequence Drivers

To create a common base for your sequence drivers:

1. Define a base_sequence_driver unit that inherits from any_sequence_driver (directly orindirectly).

struct base_sequence_driver like any_sequence_driver {

2. Implement the common logic for your sequence drivers in your base_sequence_driver unit.

3. Add the option sequence_driver_type=base_sequence_driver to the sequence statement for eachsequence with a sequence driver that inherits from base_sequence_driver.

For example:

sequence my_seq using item=my_item,sequence_driver_type=base_sequence_driver;

Specifying sequence_driver_type causes newly created sequence drivers to inherit frombase_sequence_driver rather than any_sequence_driver.

Notes

• The base_sequence_driver unit can be derived from another base_sequence_driver unit, not onlyfrom any_sequence_driver.

• The base_sequence_driver only establishes a common logic. You cannot instantiate or generate aninstance of this type.



Sequences: Constructing Test ScenariosApplying Default Behavior When No Item Is Done

5.10.3 Applying Default Behavior When No Item Is DoneSome designs require the BFM to perform activity under any circumstances. For example, some busesrequire a continuous transmission of data, even if it is an idle data. For such designs, using the normalhookup scheme cannot suffice; because in those schemes, if there is no valid do action at the moment,the sequences block any BFM activity. In other words, the return of get_next_item() is blocked until avalid do action exists.

To solve such cases, you can use the try_next_item() TCM:

any_sequence_driver.try_next_item(): seq_item @clock;

This TCM tries to return the current item being done by the sequences. However, unlikeget_next_item(), if no such item exists, it returns NULL in the same cycle that it is called. This lets theuser create a default item instead of the item that was supposed to be created by the sequences, therebyadhering to the DUT rules.

Note try_next_item() does not just look for an existing candidate for a do but also allows sequencesto execute their body() TCMs and then look for a possible do action. This is done by calling thewait_for_sequences() TCM (see “Solving Possible Race Conditions” on page 5-53).

To apply default behavior when no item is currently created by the sequences:

1. Replace the call to driver.get_next_item() (as demonstrated in Step 4 of the hookup scheme in“Hooking the Sequence Driver to the Environment” on page 5-9) with a call to the try_next_item()TCM.

Note This method must be used in PULL_MODE only.

2. When try_next_item() returns NULL, explicitly create your item instead.

Example

extend ex_atm_bfm {pull_send_loop() @clock is only {

var seq_item: ex_atm_cell;while TRUE {

seq_item = driver.try_next_item();if seq_item == NULL {

seq_item = new;};drive_cell(seq_item);emit driver.item_done;

};};

};



Sequences: Constructing Test ScenariosSynchronization within a Cycle

See Also

• Figure 5-20 on page 5-124


5.10.4 Synchronization within a CycleThis section contains:

• “Delaying the Driver Clock” on page 5-52

• “Solving Possible Race Conditions” on page 5-53

• “Forcing a Reevaluation of the do Action Queue” on page 5-54

5.10.4.1 Delaying the Driver Clock

Sometimes you must let the environment execute before the sequences execute. A typical example iswhen a BFM must export its status before sequences are evaluated so that they can use the new status togenerate updated data.

To enable an intracycle delay (a delay within the same cycle) of sequence activity:

• Use the delay_clock() TCM.

any_sequence_driver.delay_clock() @sys.any;

After an intracycle delay, the delay_clock() TCM emits the driver’s clock just once.

To delay the driver clock:

1. Remove any connection to the driver clock (see the hookup scheme in “Hooking the Sequence Driverto the Environment” on page 5-9).

2. Define a TCM that calls to driver.delay_clock() every cycle.

For example:

extend ex_atm_bfm {delay_driver_clock() @a_clock is {

while TRUE {// Emit the driver.clock after some delaydriver.delay_clock();wait cycle;

};};run() is also {



Sequences: Constructing Test ScenariosSynchronization within a Cycle

start delay_driver_clock();};

};

Note This TCM replaces the regular clock connection, so make sure that the clock is not alsoemitted.

5.10.4.2 Solving Possible Race Conditions

In complicated environments (for example multilayer environments), a race condition might occurbetween parallel threads of TCMs. For example, this could occur between layered BFMs or between theBFM and the sequence driver.

A typical case is when one thread produces some data that another thread consumes. If the consumer isevaluated before the producer, it could happen that the consumer will be called first and will miss theproducer, even though both occurred in the same cycle.

Solving such cases can be done by explicitly performing a context switch in the consumer that lets theproducer be evaluated first.

To perform a context switch that forces a producer to be evaluated before a consumer:

• Use the wait_for_sequences() TCM:

For example:

any_sequence_driver.wait_for_sequences() @sys.any;

This TCM can be called by the consumer before or in parallel with waiting for the producer. This TCMdoes not exceed the boundary of the cycle but uses time-consuming actions such as sync [0] to create anartificial context switch.

This TCM is already used in the sequence mechanism in the call to try_next_item(). try_next_item()calls wait_for_sequences() to allow evaluation of the sequences before looking for existing do actions.

You can also extend or override this TCM if the existing implementation does not satisfy the needs ofyour environment. For example:

extend ex_atm_driver {wait_for_sequences() @sys.any is only {

for i from 1 to 100 {sync [0];

};};

};

Note Overriding wait_for_sequences() also affects the behavior of try_next_item().



Sequences: Constructing Test ScenariosQuitting Sequences and Sequences Items

5.10.4.3 Forcing a Reevaluation of the do Action Queue

When there is a demand for items, the driver chooses a do action only if the is_relevant() method of thesequence returns TRUE. But the returned value of is_relevant() might depend on the current state of theenvironment. In that case, the driver might fail to choose a do action when the sampling time ofis_relevant() is prior to the changes in the env. In that case, you can force a reevaluation of the do actionqueue.

To force a reevaluation of the do action queue:

• Call the method driver.check_is_relevant().

Note This check_is_relevant() method is meaningful only for synchronization within a cycle. Whena new cycle starts, the driver automatically reevaluates the queue.

5.10.5 Quitting Sequences and Sequences ItemsSpecman Elite continues evaluating temporal expressions until quit() is called. Garbage collection for astruct only occurs after Specman Elite stops evaluating the struct’s temporal expressions. This alsoapplies for sequences and sequence items. Therefore, if you use temporal expressions in a sequence orsequence item, quit() must be called before Specman Elite can perform garbage collection on thesequence or sequence item.

To enable automatic quitting of sequences and sequence items:

• Set the predefined method any_sequence_item.auto_quit() to TRUE.

extend any_sequence_item {auto_quit() : bool is only {

return TRUE;};

};

When auto_quit() returns TRUE, quit() is automatically called for sequences after the sequence isfinished and for sequence items after driver.item_done is emitted.

Note By default, auto_quit() currently returns FALSE. In future, the default will change to TRUE.

You can override the setting of auto_quit() for specific types.

To override the auto_quit() setting:

• Extend the relevant sequence or sequence item type.

For example:

extend my_sequence_item {auto_quit() : bool is only {



Sequences: Constructing Test ScenariosLayering of Protocols

return FALSE;};

};

5.11 Layering of ProtocolsThis section discusses the layering of protocols and how to implement it using sequences.


• “Introduction to Layering” on page 5-55

• “Styles of Layering” on page 5-59

• “Using Layered Sequence Drivers” on page 5-63

5.11.1 Introduction to LayeringSimple eVCs and VEs might not need layering of protocols, but in complex situations it is oftenrequired. Two examples are TCP/IP over Ethernet and ATM over Sonet.

Sequence layering and virtual sequences are the two main ways in which sequence drivers can becomposed to create a bigger whole.

In the erm_lib directory, there are two example packages that demonstrate layering:


• “What Is Layering of Protocols?” on page 5-56

• “Layering and Sequences” on page 5-56

ex_blayers This eRM package (basic layers) demonstrates a simple layeringconfiguration. It shows a low-layer packet sequence driver that can either workalone or pull information from a high-layer frame sequence driver. (Fordetails, see the PACKAGE_README.txt of the package.)

ex_layers This eRM package demonstrates the use of multiple high- and low-layersequence drivers as well as virtual sequence drivers, all interacting in thelayering scheme. It also demonstrates late binding of the various layers(emulating a situation where different people wrote separate eVCs that arelater bound together by yet another person). (For details, see thePACKAGE_README.txt of the package.)



Sequences: Constructing Test ScenariosIntroduction to Layering

5.11.1.1 What Is Layering of Protocols?

The classic example is where the don't-care data (just a list of byte) in the lower-level protocol suddenlyis forced by the higher-level protocol to be meaningful.

For example, assume that there are two sequence drivers. The low-layer sequence driver drives packetsthat are defined as:

struct packet like any_sequence_item {data[10]: list of byte;... -- Other fields

};

So the low-level sequence driver is defined as:

sequence packet_sequence using item = packet;

In one case, you just want to send packets with random data. In another case, you want the data to comefrom a higher-layer data protocol. The higher-layer protocol in the example drives frames. So thehigh-level sequence driver is defined as:

sequence frame_sequence using item = frame;

A frame would then have various fields that must be packed together and sent in the data lists of nconsecutive packets.

5.11.1.2 Layering and Sequences

Layering is best implemented in e via sequences. There are two main ways to do layering usingsequences:

• “Layering Inside One Sequence Driver”—Applies for simple cases only

• “Layering of Several Sequence Drivers”—Applies for all layering needs

Layering Inside One Sequence Driver

In this case, you simply generate a data item of the higher layer within the lower-layer sequence. You dothat by inventing another sequence kind for the lower-layer sequence driver. For example:

extend packet_sequence_kind: [FRAME_SENDER];

The FRAME_SENDER sequence generates a single frame and sends it in chunks, in one or morepackets, until the data of the frame is exhausted. For example:

extend FRAME_SENDER packet_sequence {frame: frame;!packet: packet;




body() @driver.clock is {var full_data: list of byte = pack_the_frame(); // Pack the frame

while not done_with_full_data() { // while not done with full_datavar next_piece: list of byte=get_next_chunk_from_full_data();do packet keeping {.data == next_piece};

};};

};

The FRAME_SENDER sequence can then be used by other sequences. For example, you could define aSUPER_FRAME_SENDER packet_sequence that takes a super_frame (whatever that is), chops it intoframes, and executes in a loop as follows:

do FRAME_SENDER sequence keeping {.frame == get_next_frame_in_super_frame();

};

Layering inside one sequence driver is easy to write and understand. However, it only works well insimple cases. For complex cases, you need a more general approach.




Layering of Several Sequence Drivers

Figure 5-4 Layering Architecture

The more general approach uses multiple sequence drivers (see Figure 5-4 on page 5-58).

Taking the frame and packet example, there would be a low-layer packet_sequence and a high-layerframe_sequence (complete with their sequence drivers). The packet_sequence would pull data from theframe_sequence_driver (or from its BFM).

Each sequence driver might even be encapsulated in an eVC so that layering could be done byconnecting the eVCs.

See Also

• “Using Layered Sequence Drivers” on page 5-63

seqPacket SD

DUT

Packet BFM

seqseq

Single-LayerArchitecture

DUT

seqPacket SD

seqseq

Multi-LayerArchitecture

This packet sequencepulls information directlyfrom the Framesequence driver

Packet BFM

seqFrame SD

seqseq



Sequences: Constructing Test ScenariosStyles of Layering

5.11.2 Styles of LayeringThis section includes:

• Applies for all layering needs

• “One-to-One, One-to-Many, Many-to-One, Many-to-Many” on page 5-60

• “Different Configurations at Pre-Run Generation and Runtime” on page 5-61

• “Timing Control” on page 5-61

• “Data Control” on page 5-62

• “Complex Inter-Packet Dependencies” on page 5-62

• “Using Virtual Sequence Drivers” on page 5-62

5.11.2.1 Basic Layering

The simplest general scenario is:

• The actual BFM accepts layer1 packets.

• The layer1 packets are constructed out of layer2 packets in some way, the layer2 packets are in turnconstructed out of layer3 packets, and so on.

• Between every layerN and layerN+1, there is a mechanism that takes layerN+1 packets and convertsthem into layerN packets.

You could also have multiple kinds of layer1 and layer2 packets (as in Figure 5-5 on page 5-60). Indifferent configurations you might want to layer any kind of layer2 packet over any kind of layer1packet.

The rest of this section describes some possible variations and complications, depending on theparticular protocol or on the desired test-writing flexibility.




Figure 5-5 Layering of Protocols

5.11.2.2 One-to-One, One-to-Many, Many-to-One, Many-to-Many

Figure 5-6 Layer Mapping

heade kind Payload (32 bytes) CRC

header kind Payload (64 bytes) CRC

address Payload (31 bytes)

address length Payload (1..100 bytes)

header kind Payload (32 bytes) CRCLayer 1a

Layer 1b

Layer 2a

Layer 2b1 byte

1 byte 1 byte

Kinds:RAWLAYER2ALAYER2B


address Payload (31 bytes)

header kind Payload (32 bytes) CRCLayer 1a

Layer 1b

Layer 2aOne to One

2A

Many to One

address Payload (31 bytes)Layer 2a

hea kind Payload (32 bytes) CRC

add Payload (20 bytes)


Many to Many

2B

len add Payload (20 bytes)len add Payload (18 bytes)len


2A




The conversion mechanism might need to cope with any of the following situations:

5.11.2.3 Different Configurations at Pre-Run Generation and Runtime

You might want to build different configurations—either by loading different files or by randomizingsomething during pre-run generation.

For example, in one configuration, you might have only layer1 packets. In another configuration, layer1packets would be dictated by layer2 packets. You might also want to decouple the layers further, forexample, so that layer2 packets could drive either layer1 packets or layer1 cells (at another interface) orboth.

The general picture here is boxes with connecting pipes. At pre-run generation, you can connect thepipes according to the required configuration or topology.

Sometimes, you might want to decide on the mix of input from multiple sources at runtime. Forexample, you might want to have one low-layer sequence driver send n packets that come from onehigh-layer sequence driver and then m packets from another high-layer sequence driver.

5.11.2.4 Timing Control

In some configurations, the high-layer packets drive the timing completely. When high-layer packets arecreated, they are immediately converted into low-layer packets.

In other configurations, the low-layer sequences pace the operation. When a low-layer do is executed,the corresponding high-layer packet should appear in zero time, much like with reactive sequences.

Finally, there is a case where things are driven into the DUT according to the timing of the low-layersequences, but the high-layer sequences are not reacting in zero time. Rather, if there is no data availablefrom the high-layer sequences, then some default value (for example, a zero filler) is used instead.

One-to-one One high-layer packet must be converted into one low-layer packet.

One-to-many One big high-layer packet must be broken into many low-layer packets.

Many-to-one Many high-layer packets must be combined into one big low-layer packet (as inSonet).

Many-to-many Multiple higher-layer packets must be taken in and converted into multiplelower-layer packets. For example, high-layer packets are 10 bytes long, andlow-layer packets are 3 to 35 bytes long. In this case, there could be remainders.




5.11.2.5 Data Control

In some configurations, the high-layer transactions completely dictate what low-layer items reach theDUT. The low layer simply acts as a slave.

Often, however, both layers influence what reaches the DUT. For example, the high layer mightinfluence the data in the payload while the low layer influences other attributes of the items reaching theDUT. As such, the choice of sequences for both layers is meaningful.

5.11.2.6 Complex Inter-Packet Dependencies

In some cases, complex transformations must be performed. Just shoving data from the high layer to thelow layer will not suffice. For example:

One thing common to all of these examples is the need for some global information (the counter in thefirst example and the queue in the last example) and some corresponding global control.

5.11.2.7 Using Virtual Sequence Drivers

In the most general case, you have a graph consisting of several virtual sequence drivers and severalBFM sequence drivers. Some low-layer BFM sequence drivers are connected to the DUT, somehigher-layer BFM sequence drivers are layered above them, and some virtual sequence drivers on topfeed into all of the BFM sequence drivers below.

Serial number handling Assume that each packet has serial numbers, and serial numbers shouldbe given using some global algorithm that takes into account allhigh-layer requests.

Retransmit handling Assume that this is a two-way protocol. The other side can send backACK and NACK (acknowledge and not acknowledge) packets, and thehigh-layer protocol must retransmit some packets accordingly. At thesame time, you might already be outside the high-layer request thatcreated the original packet for which a NACK was received.

Complex blocking issues Assume that a given low-layer sequence driver is sending packets fromone high-layer source that drives a high-layer transaction to one target(slave). Assume also that the target cannot receive packets for otherhigh-layer transactions; however, other targets can. Thus, the givenlow-layer sequence driver can process multiple high-layer transactionsat the same time, as long as you do the necessary queueing so that anysubsequent high-layer transactions to the same slave wait for their turnin the correct queue.



Sequences: Constructing Test ScenariosUsing Layered Sequence Drivers

In the example configuration shown in Figure 5-7 on page 5-63, a low-layer sequence driver (L1B) getsinput from multiple high-layer sequence drivers (two instances of L2A) as well as from a virtualsequence driver.

Figure 5-7 Most General Case—Using Virtual Sequence Drivers

5.11.3 Using Layered Sequence DriversThe general solution for layering involves multiple, layered sequence drivers.

Assume that at the low layer you have a packet_sequence (and a packet_sequence_driver), and above ityou have a frame_sequence (and a frame_sequence_driver). Packets can either be layered (that is, theirpayload contains data from frames) or independent (that is, their payload is random). (See Figure 5-4 onpage 5-58.)


• “Overview of the Layering Solution” on page 5-64

• “Introducing Layering into the Low-Layer Sequence” on page 5-65

• “Late Binding” on page 5-67

seqL1A

DUT

seqseq

seqL2B SD

seqseq

seqL2A SD

seqseq

seqL1B SD

seqseq

seqL2A SD

seqseq

seqL2A SD

seqseq

seqVirtual SD

seqseq

L2B BFM

L1A BFM L1B BFM

Layering with virtual sequencesLayering with connector sequences




5.11.3.1 Overview of the Layering Solution

Layered sequence drivers work as follows:

• Lowest-layer sequence drivers send information to a real BFM (which typically toggles actual DUTsignals).

• Higher-layer sequence drivers only send information to lower-layer sequence drivers. They may ormay not have their own BFMs, depending on whether complex transformations are needed from thehigher layer to the lower layer.

• Lower-layer drivers point to the higher-layer driver(s) from which information must be pulled (usingget_next_item() / try_next_item() or some connector method). The actual pointer configuration isnormally decided during pre-run generation.

The pulled information (either the higher-layer data or some transformation thereof) is put in a fieldof the sequence and is then used to constrain various fields in the lower-layer item(s).

Following is an example of a connector packet sequence that pulls a single frame from the framesequence driver and then sends it as packets:

extend FRAME_SENDER packet_sequence {!frame: frame;!packet: packet;

body() @driver.clock is {-- Get the frame from the frame_driverframe = frame_driver.get_next_item();emit frame_driver.item_done;var full_data: list of byte = pack_the_frame();

while not done_with_full_data() {var next_piece: list of byte =

get_next_chunk_from_full_data();do packet keeping {.data == next_piece};

};};

};

Note This simple example is very similar to the one in “Layering and Sequences” on page 5-56. Butthere the frame was generated in the packet_sequence, and here it is pulled from the frame sequencedriver.

There are several ways to get information from a higher layer:

• You can get information from the higher layer by calling frame_driver.get_next_item() directly andgetting a frame (as was done in the single-item connector example above):

frame = frame_driver.get_next_item();




• You can call a method of the higher-layer BFM, not a method of the higher-layer sequence driver.For example, you might want the BFM to do some transformations on the higher-layer data, returninga list of bytes somehow extracted from it. For example:

raw_data = frame_bfm.get_data();

Note The BFM is called here in PULL_MODE. It would probably use get_next_item() to get thedata from the higher-layer sequence driver, also in PULL_MODE. (See Figure 5-8 on page 5-65.)

• You can call some intermediate connector method in the lower-layer sequence driver, which willlater be extended (see “Late Binding” on page 5-67). For example:

raw_data = driver.get_payload();

Figure 5-8 Pulling Information from a High-Level BFM

5.11.3.2 Introducing Layering into the Low-Layer Sequence

This section explains the three main ways to introduce layering into the low-layer sequence so that itwill be able to pull information from above and use it:

• “Using a Single-Item Connector Sequence”

• “Using Implicit Connection (by Extending the Low-Layer Sequence)”

• “Using a Protocol-Aware Multi-Item Connector Sequence”

Your needs will determine which way is best for you.

DUT

seqPacket SD

seqseq

This sequence pullsfrom the Frame BFM.

seqFrame SD

Frame BFM

seqseq

To achieve complex datatransformation, we need aBFM or a third-partytransformer unit.

Packet BFM




Using a Single-Item Connector Sequence

Sometimes, you want to freely mix layered packets (packets whose payload comes from frames) withindependent packets.

To allow for single-item granularity, you can use a single-item connector sequence, as demonstrated in“Overview of the Layering Solution” on page 5-64. The sequence takes a single high-layer item (frame inthe example) and produces one or more low-layer items (packets in the example).

Using Implicit Connection (by Extending the Low-Layer Sequence)

Another situation is where you initially have a whole library of lower-layer sequences. Suddenly, youwant all lower-layer data items in all sequences to be layered.

To do that, you can extend the basic, low-layer sequence (rather than a specific CONNECTORsequence) and pull the information from above using the pre_do() method. This lets you avoid changingthe original body() method (which was customized for each sequence in the library).

Following is an example of implicit connection by extending a low-layer sequence:

extend packet_sequence {use_layering: bool;

keep soft use_layering == FALSE;keep in_seqence(packet_sequence) (p) =>

soft use_layering == p.use_layering;!raw_data: list of byte;

pre_do(is_item: bool) @sys.any is {if is_item and use_layering then {

raw_data = frame_bfm.get_data();-- Here you get the information from the frame BFM, not from the-- frame sequence driver just to demonstrate this possibility.

};};

};

extend packet {keep in_sequence(packet_sequence) (p) and p.use_layering =>

data == p.raw_data;};

Loading the above code and constraining use_layering to TRUE makes that sequence (and sequencesunderneath it) use layering:

extend MAIN packet_sequence {keep use_layering == TRUE;

};




Note This allows conditional layering. If that is not needed, you can remove the use_layering flag andthe logic around it.

Using a Protocol-Aware Multi-Item Connector Sequence

Finally, there are cases where, in layered mode, the full low-layer sequence is (almost) completelydetermined by the protocol.

Quite often, there is no way to mix layered and independent data items without breaking the protocoland causing the DUT to go into an error state.

For example, the protocol might involve complex retransmit and blocking rules (see “ComplexInter-Packet Dependencies” on page 5-62). The logic for these rules could either be embedded in theBFM of the high-layer sequence driver (in which case the low-layer sequence is relatively free fromrestrictions) or embedded in the low-layer sequence (in which case it becomes protocol-aware and hasvery little freedom).

A protocol-aware sequence is typically a multiple data-item sequence (quite often lasting throughout thetest). Generally, it pulls the full high-layer item (frame in the example) as is from the layer above, addingit to some global list (in the sequence itself or in the sequence driver). It then starts to create low-leveldata items as needed. As required (for example, upon a NACK), it would consult the global list and otherglobal fields and do the appropriate thing (for example, retransmit some packets).

While this sounds like one, monolithic sequence, it might still have some degree of freedom (perhapsfreedom in timing or various ways to respond to a NACK). These should be encoded as generatablefields in the sequence (and its subsequences), which could be constrained from outside.

5.11.3.3 Late Binding

Sometimes several people (or groups of people) can be involved in the development of layers. There areseveral possibilities regarding how many persons are involved in the development and the role that eachperson plays. In addition, there is the test writer, who uses constraints to define the actual configurationof sequence drivers (and many other things).

One Person

Sometimes, the same party two layers and the connection between them are written together. Thistypically occurs when the two layers always go together.




Two Persons

In some cases, the lower layer was written by a person with no knowledge of layering. Thereafter, thehigher layer is written by another person specifically for that lower layer. In this case (as in the previousone), this strong coupling makes it possible to customize the BFM of the higher layer as needed to matchthe low layer.

This is demonstrated in the ex_blayers example package.

Three Persons

In this case:

• Person A writes the lower-layer part (item, sequence, sequence driver, BFM).

• Person B writes the higher-layer part (item, sequence, sequence driver).

A and B do not know about each other and might even ignore the need for layering.

• Person C connects the two by writing the connector sequence(s) and the rest of the connecting code.

Four Persons

This more general case is the one implemented in the ex_layers package. It goes as follows:

• Persons A and B are as in the three-persons case.

• Person C defines some empty connector methods in the lower-layer driver and then writes theconnector sequences that call those methods to pull in the information.

• Finally, person D defines how to pull information from any particular higher-layer source byextending the connector methods in the lower-layer driver.

This more flexible scheme allows for the case where each lower-layer sequence driver has multipleconnector-unit references that are only wired at configuration time. Thus, a particular sequence (writtenby person C or by the test writer) could take raw data from one connector unit and then some more datafrom a second connector unit without caring whether the two connector units are of the same type or not.

Example

1. Define a generic list of connector units and the empty connector methods (get_payload(),get_kind()), which initially just issue an error.

Note At this point this is not associated with any specific higher layer.

extend ex_layer1a_driver_u {

connectors : list of any_unit;




keep soft connectors.size() == 0;

get_payload(connector : any_unit) : list of byte @sys.any is {error("Unrecognized/NULL connector unit in get_payload()");

}; -- get_payload()}; -- extend ex_layer1a_driver_u

2. Define a sequence kind that pulls in a payload and a kind from a (yet unspecified) higher-levelsequence driver (or BFM) and stuffs it into a packet.

extend CONNECTOR ex_layer1a_sequence {connector: any_unit;

keep connector in driver.connectors; // Defined in Part 1

-- This is raw data coming from the higher layer protocol.!raw_data : list of byte;

-- This is the Layer1a kind field coming from the higher-level-- protocol.!packet_kind : ex_layer1a_packet_kind_t;

-- Before do-ing items, grab the required data from the-- higher-layer protocol by calling empty connector methods-- defined in the driver (defined in Part 1).pre_do(is_item : bool) @sys.any is also {

if is_item {raw_data = driver.get_payload(connector);packet_kind = driver.get_kind(connector);

};}; // pre_do()

body() @driver.clock is only {do packet keeping {

it.kind == packet_kind;it.payload == raw_data;

};}; // body()

}; // extend CONNECTOR ex_layer1a_sequence

3. In a separate file, specify how to connect layer1a to a specific higher-level driver (layer2a), byextending get_payload().

extend ex_layer1a_driver_u {get_payload(connector : any_unit) : list of byte @sys.any is first {

if connector is a ex_layer2a_driver_u (p) {var packet := p.try_next_item();if packet != NULL { // Has a real packet

emit p.item_done;



Sequences: Constructing Test ScenariosTracing and Debugging Sequences

return pack(packing.low, packet);} else { // No real packet. Therefore, return a filler

result.resize(32);return result;

};};

}; -- get_payload()};

5.12 Tracing and Debugging SequencesTable 5-4 describes the tools required for debugging sequences.

In addition, you can collect sequence debugging information, to get additional information in thevisualization windows (history and current state), tracing messages, and more.


• “Tracing Sequences” on page 5-71

• “Available Debug Information” on page 5-74

• “Using the Sequence Browser” on page 5-80

• “Transaction Attributes” on page 5-90

• “Working in ASCII Mode” on page 5-92

• show sequence on page 5-94

Table 5-4 Sequence Debugging Tools

Tool Lets you…

Source debugger Follow the sequence execution

Thread browser Search for the sequence thread and display its execution tree

Data browser View the sequence data

Waveform viewer View the sequence items sent by a driver

Sequence visualizationwindows

View detailed information on a sequence and sequence driver, includingstatistics and history



Sequences: Constructing Test ScenariosTracing Sequences

5.12.1 Tracing SequencesThe trace sequence command enables sequence tracing and debugging information on several levels.You must issue this command to access some history data.

The trace sequence command also lets you show the tracing mode of each sequence driver (seeShowing Trace Information on page 5-72.

Syntax

tra[ce] seq[uence] [destination] [mode] [wild]

Parameters

Description

This command can be activated at any time during the run. It changes the tracing mode for all specifieddrivers.

destination Can be:

• msg[_only]—Specman Elite collects and displays trace information.

• log[_only]—Specman Elite collects and displays trace information asstripes in a VT visualization window.

• trans[action[s]]—Specman Elite records trace information astransactions to be viewed in the SimVision for Cadence NC simulators.

Note Currently, the transactions option is not supported on the HPand AIX platforms.

• all—Specman Elite does all of the above.

The default option is all.

mode Can be:

• on—Tracing is enabled.

• off—Tracing is disabled.

The default option is on for all drivers.

wild Filters the effect of the command to the specified sequence drivers (thosewith the e path that matches wild).




5.12.1.1 Showing Trace Information

Syntax

tra[ce] seq[uence] -show

Description

This command shows the tracing mode of each sequence driver.

5.12.1.2 Using the Simulator Waveform

Viewing Sequences as Waveform Transactions

Figure 5-9 Driver Selected for Viewing




Figure 5-10 Viewing Sequences as Transactions in Waveform

To view sequences as waveform transactions:

1. In the simulator, open a Design Browser window.

A Testbench node appears in the Scopes pane.

2. Expand the Tesbench tree until you reveal the driver leaves. Then select the driver (or drivers) whosesequences you want to view (Figure 5-9).

In the right-hand pane, there is an entry for every root sequence of the selected driver(s). Inaddition, the sequence item for each selected driver is displayed.

3. Send the information to the waveform (for example, by dragging it into the waveform window).

Fibers for the root sequences and sequence items appear in the simulator waveform (Figure 5-10) asfollows:

• Each root sequence is displayed in a separate fiber that can be expanded to show any childsequences. You can see for each transaction the sequence attributes, such as depth and driver epath.



Sequences: Constructing Test ScenariosAvailable Debug Information

• If the root sequence is virtual, its child sequences first appear under the virtual driver andsubsequently appear under a BFM driver. There is a predecessor-successor relationship betweenthe parent virtual sequence and the child BFM sequence.

• Each BFM sequence driver has a single sequence item fiber. You can see all generated items forall sequences of the BFM driver. There is a predecessor-successor relationship between everyitem transaction and the transaction of the item’s parent sequence.

5.12.2 Available Debug InformationThis section describes the available debug information. It contains:

• “Tracing Lists” on page 5-74

• “Debug Messages” on page 5-75

• “Wave Info” on page 5-76

• “Stripe Info” on page 5-77

• “State Info” on page 5-77

5.12.2.1 Tracing Lists

During the run, trace lists are collected when the trace level is log_only or on.

The trace list of a sequence driver contains all sequences and items scheduled by the driver. The list canbe retrieved by the following predefined methods of any_sequence_driver:

• get_trace_list() : list of any_sequence_item

• get_item_trace_list() : list of any_sequence_item

• get_sequence_trace_list() : list of any_sequence

The trace list of a sequence contains all items and sequences done by the sequence. The list can beretrieved by the following predefined method of any_sequence:

• get_trace_list() : list of any_sequence_item

To view the trace lists:

• Use either of the following commands:

show seq -trace_list Shows a summary of all sequence drivers in the env

show seq -trace_list driver-idx Shows the trace list of driver specified by driver-idx




Note Trace lists are used when showing the stripe chart of the sequence and sequence driver.

5.12.2.2 Debug Messages

During the run, debug messages are printed to the screen when the trace level is msg_only or on. Thedebug messages specify information about sequence activity. The messages use theTRACE_SEQUENCE tag.

The default format of the output is as follows:

[time] short-name: SEQ(depth) message-body

Table 5-5 shows the various types of messages and their verbosity.

Table 5-5 Debug Message Format and Verbosity

Message Format of Message Verbosity

Start of sequence (using start()) Starting sequence-name LOW

End of sequence (started usingstart())

sequence-name ended LOW

Creation of sequence or item(using the do action)

sequence-name|item-name created For sequences:MEDIUM

For items: HIGH

Finish do-ing sequence or item sequence-name|item-name done For sequences:MEDIUM

For items: HIGH

Sending of data item by driver item-name sent by driver driver-idx HIGH

Sequence grabs driver sequence-name grabbed/immediatelygrabbed driver driver-idx

MEDIUM

Sequence ungrabs driver sequence-name ungrabbed driverdriver-idx

MEDIUM

Execution of default body() of theMAIN sequence

MAIN sequence-name: Executing defaultbody() method: doing count sequences

LOW

Rerunning a driver Rerunning driver driver-idx LOW

Stopping a sequence (using stop()) sequence-name stopped. All sequencesinitiated by root-sequence are stopped

MEDIUM




The nice_string() method is used for printing sequences and items in these messages.

There is also a method, any_sequence.post_trace(), which gets called for each sequence just after atrace message about it gets printed. This is useful for breakpoints.

Following is a sample message output:

Starting the test ...Opening file for debug: atm.elogRunning the test ...[0] ATM 1: SEQ(0) Starting MAIN ex_atm_sequence-@2[0] ATM 1: SEQ(1) PARALLEL_3 ex_atm_sequence-@3 created[0] ATM 1: SEQ(2) SHORT_LONG ex_atm_sequence-@4 created[0] ATM 1: SEQ(2) SHORT_LONG ex_atm_sequence-@5 created[0] ATM 1: SEQ(2) SHORT_LONG ex_atm_sequence-@6 created[0] ATM 1: SEQ(3) ex_atm_cell-@7 (A1 GREEN 2) created[3] ATM 1: SEQ(3) ex_atm_cell-@7 (A1 GREEN 2) sent by drvr 0[3] ATM 1: SEQ(3) ex_atm_cell-@8 (A1 BLUE 2) created[6] ATM 1: SEQ(3) ex_atm_cell-@8 (A1 BLUE 2) sent by drvr 0[6] ATM 1: SEQ(3) ex_atm_cell-@9 (A1 GREEN 1) created[8] ATM 1: SEQ(3) ex_atm_cell-@9 (A1 GREEN 1) sent by drvr 0[8] ATM 1: SEQ(3) ex_atm_cell-@10 (A3 RED 1) created[10] ATM 1: SEQ(3) ex_atm_cell-@10 (A3 RED 1) sent by drvr 0[10] ATM 1: SEQ(3) ex_atm_cell-@11 (A4 GREEN 5) created[16] ATM 1: SEQ(3) ex_atm_cell-@11 (A4 GREEN 5) sent by drvr 0[16] ATM 1: SEQ(2) SHORT_LONG ex_atm_sequence-@5 doneLast specman tick - stop_run() was calledNormal stop - stop_run() is completedChecking the test ...Checking is complete - 0 DUT errors, 0 DUT warnings.

5.12.2.3 Wave Info

This feature is for runtime tracing of items sent by the sequence driver in the waveform viewer.

Syntax

wave seq[uence] [bfm-driver-num]

Quitting a sequence (using quit()) sequence-name quit MEDIUM

Table 5-5 Debug Message Format and Verbosity (continued)

Message Format of Message Verbosity




Description

This command adds the specified BFM sequence driver (default: all of them) to the waveform viewer.The bfm-driver-num is according to the numbering of the show sequence command. For each sequencedriver, the following six lines are added to the waveform:

5.12.2.4 Stripe Info

This feature is for visualization of sequences using the VT window as part of the visualization of the env.It is available when the tracing level is log_only or on.

5.12.2.5 State Info

The state info contains information about the current state of a sequence, sequence driver, and do action.It lets you see the exact point in the execution of a do action and the interaction between the sequencesand the driver. From this information, you can answer questions like:

• What happened to this do action? From the state info you can see when a do action is waiting forscheduling in the driver’s queue. You can also see when a do action is in pre_do() waiting for somedata from a higher layer and so on.

• What happened with this sequence? From the state info you can see that the sequence was mistakenlystopped, ended normally, and so on.

The state info is available when the tracing level is on. The state info is shown in the visualizationwindows of the sequence and sequence driver or when printing the sequence while working in ASCIImode.

Table 5-6 shows the possible states of a sequence.

struct Shows the e path of the sequence driver (constant).

item Shows the nice_string() of the current item being sent by the sequencedriver. Reverts to “XXX” when no item is being sent.

do_line Actual source line of the do that produced this item, with comments.

do_location Location of that do, for example, “at line 44 in @foo”.

sequence The nice_string() of the sequence containing the do.

parent_sequence The nice_string() of the parent sequence.




Notes

• The states “in pre_body()” and “in post_body()” are relevant only when the sequence was startedusing the start() method.

• The state is “unknown” when there was no change in the state after the tracing level was set to on.It will not happen if you set the tracing level to on before the simulation starts.

Table 5-7 shows the possible states of a do action.

Table 5-6 Sequence States

State Description

In pre_body() The sequence is in the middle of pre_body().

In body() The sequence is in the middle of body().

In post_body() The sequence is in the middle of post_body().

Stopped The sequence is stopped. It happened when calling to stop() for this sequence orone of the sequences in the whole sequence tree.

Ended The sequence was ended or done normally.

Unknown The state of the sequence is unknown (see notes below).

Table 5-7 do Action States

State Description

Wait for scheduling The do action is waiting for scheduling in the driver’s queue.

In pre_do() Now executing the pre_do() of the sequence.

Now generated The item or sequence is now generated.

In mid_do() Now executing the mid_do() of the sequence.

Item in BFM Item is now in BFM.

Sequence in body Now executing the body() of the done sequence.

In post_do() Now executing the post_do() of the sequence.

Done The do action finished normally.

Skipped The do action was skipped due to stop()/rerun().




Notes

• The states “wait for scheduling” and “item in BFM” are relevant for do item only.

• The state “sequence in body” is relevant for do sequence only.


Table 5-8 shows the possible states of a BFM sequence driver.

Notes

• The state is “idle” from the time item_done is emitted until the next call toget_next_item()/try_next_item().

• The state is “item in BFM” from the time get_next_item()/try_next_item() returns until item_doneis emitted.


Unknown The state of the do action is unknown (see notes below).

Table 5-8 BFM Sequence Driver States

State Description

Idle The driver is idle. There is no current call to get_next_item() ortry_next_item(), and no do action is currently performed.

Trying to choose do The driver is trying to choose the do action to perform.

Processing do A do action was chosen. The driver currently performs it.

Item in BFM An item was generated and is now sent to BFM.The driver is waiting for item_done to complete the do action.

Unknown The state of the driver is unknown (see notes below).

Table 5-7 do Action States (continued)

State Description



Sequences: Constructing Test ScenariosUsing the Sequence Browser

5.12.3 Using the Sequence BrowserThe Sequence Browser lets you view all information available for your sequences. The SequenceBrowser consists of the following windows:

The content of these windows changes according to the current tracing level of each driver. The windowcontent is updated automatically when something changes during simulation.

When the tracing level is none or msg_only, then the windows show basic information. Moreinformation is available when the tracing level is log_only and on.


• “Using the Env Sequences Window” on page 5-80

• “Using the Sequence Window” on page 5-82

• “Using the Sequence Driver Window” on page 5-84

• “Finding an Interesting Point to Start” on page 5-88

• “Detecting Problems” on page 5-89

5.12.3.1 Using the Env Sequences Window

The Env Sequences window of the Sequence Browser (see Figure 5-11 on page 5-81) lets you view asummary of all sequence drivers in the selected unit. The window contains links to the Sequence Driverwindow of each sequence driver in the env.

Env Sequences window The main browsing window.

• Shows a summary of all sequence drivers in a unit

• Shows the sequence threads (when there are less than twentysequence drivers in the window)

Sequence window Shows detailed information on the selected sequence

Sequence Driver window Shows detailed information on the selected sequence driver




Figure 5-11 Env Sequences Window

Table 5-9 describes the various ways you can open the Env Sequences window.

Table 5-9 Opening the Env Sequences Window

Open Option Result

From the Specman> prompt, issuethe show seq command

Shows all sequence drivers under sys

From the Specman> prompt, issueshow seq top-unit-name

Show all sequence drivers under the unit top-unit-name

On the View menu of the SourceDebugger, select Sequence Browser

Shows all sequence drivers under sys

In an Env window of the eRM Utility,click the Sequences button

Shows all sequence drivers under the env




5.12.3.2 Using the Sequence Window

The Sequence window of the Sequence Browser (see Figure 5-12 on page 5-83) displays all availableinformation on a selected sequence with links to other tools like the Data Browser and the ThreadDebugger.

Table 5-10 shows the information contained in the Sequence window.

Table 5-10 Sequence Window Information

Info Description

Enclosing env Link to the env

Driver The sequence driver

Sequence type The type of the sequence—BFM or virtual

State (Available only when the tracing level is on) All possible states of thesequence, when the current state is marked

Activation mode Specifies whether the sequence was started or done

Parent sequence The parent sequence (if any)

Items sent (Available only when the tracing level is log_only or on) The number ofitems sent by the sequence and its descendents

Grabbing driver Specifies whether the sequence is currently grabbing the driver

Start/End time (Available only when the tracing level was set to log_only or on before thesequence was started) The time the sequence was started or ended.

For a started sequence, the start_time is the time the start_sequence()method is called. For a subsequence, the start_time is the time the sequenceis generated.

History stripe button (Available only when the tracing level is log_only or on) Opens the historystripe chart of the sequence to show all items and sequences done by thesequence.

Full Active stripebutton

(Available only when the sequence is still active) Opens the active stripechart of the sequence to show sequences and items currently done by thesequence

Thread Tree button (Available only when the sequence is still active) Opens the thread debuggerto show the sequence thread tree

body() source Link to the source of the sequence body() (including all of its extensions)




Note The number of items sent by the sequence and the stripe charts of the sequence are based on thetrace list of the sequence. This might not be accurate if the tracing level was none or msg_only duringpart of the sequence run.

Figure 5-12 The Sequence Window

Table 5-11 describes the various ways you can open the Sequence window.

Comments Comments on the tracing level

Table 5-10 Sequence Window Information (continued)

Info Description




5.12.3.3 Using the Sequence Driver Window

The Sequence Driver window of the Sequence Browser (see Figure 5-13 on page 5-87) displays allavailable information on a sequence driver with links to other tools like the Data Browser and the ThreadDebugger.

Table 5-12 shows the information contained in the Sequence Driver window.

Table 5-11 Opening the Sequence Window

Open Option Result

From the Specman> prompt, issue the show seqsequence-name command

Shows the specified sequence sequence-name

In the Data Browser, click the Visualize button Shows the selected sequence

In the other Sequence Browser windows (Env orSequence Driver), click a sequence link

Shows the selected sequence

On the View menu of the Source Debugger, selectSequence when the me is a sequence

Shows the current sequence

In the Thread Browser, click the Sequence buttonwhen the me of the selected thread is a sequence


In the Thread Tree window, click the Sequencebutton when the me is a sequence


Table 5-12 Sequence Driver Window Information

Info DescriptionBFMOnly

e path Driver path from sys No

Enclosing env Link to the env No

Driver type The type of the driver— BFM or virtual No

State (Available only when the tracing level is on) All possible states ofsequence driver, when the current state of the driver is marked

Yes

Grabbing sequence The sequence currently grabbing the driver (if any) No

Pending grabbers List of all sequences waiting to grab the driver (if any) No




Number of items sent (Available only when the tracing level is log_only or on) Thenumber of items sent by the driver

Yes

Number of pendingdo actions

Number of do (item) actions waiting in the driver queue. Yes

Current item The item currently being sent Yes

Tracing level Shows the current tracing level of the sequence driver. Also showsother tracing levels. You can change the tracing level by selectinganother value.

No

Stripe button (Available only when the tracing level is log_only or on) Opens awindow showing the stripe chart of the driver

No

Requesting Thread (Available only when the tracing level is log_only or on) Opens awindow showing the thread that last called driver.get_next_item().

Yes

Wave Indicates whether the driver is shown in the wave. (To add thedriver to the wave, click the Add To Wave button)

Yes

Current do (Available only when the tracing level is on) Current do actionhandled by the driver. The following information is shown:

• Sequence do-ing it• Source of the do action• Whether belongs to the grabbing sequence (Not applicable if

no sequence is grabbing the driver)• State of the do action• Item generated

List of pending doactions

A table specifying all do actions waiting in the driver queue. Foreach do action, the following information is shown:

• Index of the do action• Sequence do-ing it• Source of the do action• Whether belongs to the grabbing sequence (Not applicable if

no sequence is grabbing the driver)• Current result of the do-ing sequence’s is_relevant() method

Yes

Table 5-12 Sequence Driver Window Information (continued)





Notes

• The BFM Only column specifies whether the information is shown just for BFM sequence drivers(“Yes”) or also for virtual drivers (“No”). Virtual sequence drivers lack the complex logic of a BFMsequence driver.

• For virtual drivers, a list of subdrivers are shown only if get_sub_drivers() is implemented.

• The Add To Wave button is disabled when a driver is already added to the wave.

• The list of pending grabbers is shown only when there are sequences waiting for the grab.

• The number of items sent, the stripe charts of the driver, and the stripe charts of started sequencesare based on the trace list of the driver. They might not be accurate if the tracing level was none ormsg_only during part of the run.

List of startedsequences

A table specifying all active sequence threads under the driver. Foreach sequence, the following information is shown:

• Index of sequence• Name of sequence• Status of the sequence• Number of items sent by the sequence• Button to show the history stripe of the sequence• Button to show the active stripe of the sequence• Button to show the sequence thread tree in the Thread Debugger

The last two buttons are available only when the sequence is active.

The number of items sent and the stripe chart are available onlywhen the tracing level is log_only or on.

The status of the sequence is available only when the tracing levelis on.

No

Table 5-12 Sequence Driver Window Information (continued)





Figure 5-13 The Sequence Driver Window




5.12.3.4 Finding an Interesting Point to Start

A complex environment might include:

• Multiple eVCs

• Multiple instances of an eVC

• Multiple threads

• Multiple visualization windows

To find an interesting starting point:

• Select the interesting unit and display its Env Sequences window. Then in the Env Sequences window,click a link to the window of an interesting sequence driver.

Or

• If you know the interesting sequence or sequence driver, open its window directly (using links,buttons, or the show sequence command).

Table 5-13 describes the various ways you can open the Sequence Driver window.

Table 5-13 Opening the Sequence Driver Window

Open Option Result

From the Specman> prompt, issue the showseq sequence-driver-name command.

Shows the specified sequence driversequence-driver-name

In the Data Browser, click the Visualize button Shows the selected sequence driver

In the other Sequence Browser windows (Envor Sequence Driver), click a sequence driverlink.

Shows the selected sequence driver

On the View menu of the Source Debugger,select Sequences when the me is a sequencedriver.

Shows the current sequence driver

In the Thread Browser, click the Sequencesbutton when the me of the selected thread is asequence driver.


In the Thread Debugger, click the Sequencesbutton when the me is a sequence driver.





Or

• If there are many threads, use the Sequence Driver window to find an interesting sequence thread todebug with the source debugger.

5.12.3.5 Detecting Problems

The Sequence and Sequence Driver windows can help you detect problems. By examining theinformation shown in the window, you can understand what is the current state of the sequence and thesequence driver. From the state of the sequence and the sequence driver, you can detect many problems.

Table 5-14 Identifying Problems from Sequence and Sequence-Driver States

State Possible Problem

idle When the driver state remains “idle”, the driver clock might not be connected orthere was no call to get_next_item(). This can be verified by examining the code.

trying to choosedo

When the driver state remains “trying to choose do”, this can imply one of thefollowing:

• No sequence is currently do-ing items. This can be verified by examining thedo actions in the driver queue displayed in the Sequence Driver window.

• A sequence is grabbing the driver but not do-ing any items. This can be verifiedby examining the grabbing sequence and the do actions in the driver queuedisplayed in the Sequence Driver window.

• The is_relevant() method returns FALSE for all sequences that are trying todo items. This can be verified by examining the do actions in the driver queuedisplayed in the Sequence Driver window and sampling their is_relevant()method.

Processing do When the driver state remains “processing do”, the sequence might be hangingwhile in pre_do(). This can be verified by examining the state of the current doaction in the Driver window or by examining the sequence thread in the SourceDebugger.

Item in BFM When the driver state remains “item in BFM”, item_done might not have beenemitted or the BFM cannot process item_done. This can be verified by locatingthe thread that calls to get_next_item().



Sequences: Constructing Test ScenariosTransaction Attributes

5.12.4 Transaction AttributesSpecman Elite uses a predefined set of attributes when recording transactions. The predefined set ofattributes varies in accordance with the transaction type: root sequence (depth == 0), regular sequence(depth > 0), or sequence item.

Figure 5-14 shows how the waveform displays these attributes.

Figure 5-14 Transaction Attributes

For version 5.6 or earlier of NC simulators, attribute inheritance takes place. In other words, transactionsinherit the attributes of their parents. From version 5.7, there is no attribute inheritance.

For example, the “driver e-path” attribute belongs to the predefined set of attributes for root sequencetransactions but not for regular transactions. Nevertheless, in Figure 5-14 (which is captured from the 5.6NC simulator), the waveform displays this attribute for all sequences, root and regular.

5.12.4.1 Adding Attributes to Transactions

Sequences and sequence items in your design have fields that are specific to the design. As these fieldsare user-defined, they are not represented in the predefined sets of transaction attributes.



Sequences: Constructing Test ScenariosTransaction Attributes

To add custom transaction attributes:

• Implement the method get_traced_field_names() for the relevant type.

The method returns a list of field name strings.

Example 1 Adding a single transaction attribute

In the vr_xbus eVC, the field master_name of the master sequences (type: vr_xbus_master_sequence)is specific to the design. As such, Figure 5-14 does not display an attribute for this field. You could addan attribute for the master_name field by extending the vr_xbus_master_sequence type as follows:

extend vr_xbus_master_sequence {get_traced_field_names() : list of string is {

result.add("master_name");};

};

Figure 5-15 shows the resultant waveform with the master_name attribute.

Figure 5-15 Custom Transaction Attributes



Sequences: Constructing Test ScenariosWorking in ASCII Mode

Example 2 Adding multiple transaction attributes

Assume that you want to add the following transaction attributes:

• master_name for all master sequences (type: vr_xbus_master_sequence)

• prevent_test_done and drain_time for master root sequences (type: MAINvr_xbus_master_sequence)

You could do it as follows:

extend vr_xbus_master_sequence {get_traced_field_names() : list of string is {

result.add("master_name");};

};

extend MAIN vr_xbus_master_sequence {get_traced_field_names() : list of string is also {

result.add("prevent_test_done");result.add("drain_time");

};};

5.12.5 Working in ASCII ModeFor efficient debugging, it is best to work in Specview. When working in ASCII mode, the SequenceBrowser windows are not available. Nevertheless, in ASCII mode, you can get most details aboutsequences by issuing the show sequence command or by printing a sequence or sequence driver.

For example:

• To print a summary of all sequence drivers:

show sequence

• To print a summary of all sequence drivers in the unit sys.atm_env:

show sequence sys.atm_env

• To print debug information for a specific sequence:

show sequence ex_atm_sequence-@2

• To print debug information for a specific sequence driver:

show sequence ex_atm_sequence-@3

When printing the sequence or sequence driver, detailed information on the sequence or sequence driveris shown at the end of the regular output.



Sequences: Constructing Test ScenariosWorking in ASCII Mode

Example 1 : Debug Information for a Sequence

---- Debug Information: ----------------------

Enclosing Env: packet_env-@0Driver: packet_driver-@1Sequence type: BFMState: In body()Activation Mode: doneParent Sequence: PARALLEL_SORT packet_virtual_sequence-@12Items Sent: 0Grabbing Driver: NoComments: Trace level of driver is on. all details are available.


Example 2 : Debug Information for a Sequence Driver


Enclosing Env: packet_env-@0Driver Type: BFMState: Item in BFMGrabbing Sequence: NONENumber of Items Sent: 0Number of do in queue: 1Current Item: SINGLE packet-@15Tracing level: onWave: OffComments: Trace level is on. all details are available.

No sequence threads under driver currently.

Current do:source: do packet keeping { at line 73 in @pack*done by: GROUP packet_sequence-@11state: In BFMitem: SINGLE packet-@15belongs to grabber: N/A

Pending Dos:0. source: do packet keeping { at line 73 in @pack*

done by: GROUP packet_sequence-@14belongs to grabber: N/A


Note To get full information, the trace level must be log_only or on.



Sequences: Constructing Test Scenariosshow sequence

5.12.6 show sequence

Syntax

sh[ow] seq[uence] [-ascii] [sequence-name| driver-name | driver-idx | unit-name]

sh[ow] seq[uence] [-ascii] -log [sequence-name| driver-name| driver-idx]

Description

This command displays debugging information and activates the Sequence Browser. The command canbe issued at any time during the run.

Parameters

The default (when no parameter is provided) is to open the Env Sequences window of sys.

Examples

• Print a summary of all sequence drivers under sys in textual output:

show seq -ascii

-ascii Force textual output, even in GUI mode.

-log Show the history log (the trace list) of a specified sequence or sequencedriver. With this option, you must specify sequence-name, driver-name,or driver-idx. You must not specify unit-name.

sequence-name Show the window of the specified sequence.

In ASCII mode, show debug information in text format.

driver-name Show the window of the specified sequence driver.

In ASCII mode, show debug information in text format.

driver-idx Shows the window of the sequence driver with driver-idx, driver with thespecified index in relation to all drivers under sys. To locate a driverindex, issue the show sequence command with no arguments.

unit-name Show the Env Sequences window of the specified unit. This displays allsequence drivers of the unit.

In ASCII mode, show textual output of all sequence drivers in this unit.



Sequences: Constructing Test ScenariosSequence-Related Actions

• Open a stripe chart window with the trace list of driver number 1:

show seq -trace_list 1

• Open the window of ex_atm_sequence-@23:

show seq ex_atm_sequence-@23

• Open the window of ex_atm_sequence_driver-@3:

show seq ex_atm_sequence4_driver-@3

• Open the Env Sequences window, displaying all sequence drivers under sys.packet_env:

show seq sys.packet_env

• Open the Env Sequences window, displaying all sequence drivers under sys

show seq

5.13 Sequence-Related ActionsThis section includes:

• do on page 5-95

• do_and_grab on page 5-97

5.13.1 do

Syntax

do field_name [keeping {constraint;...}]

Parameters

Description

The do action performs the following steps:

field_name Must be a field in the current struct. The field must have an exclamation mark (!)in front of it and must be either a basic item or a sequence.

constraint Can be any constraints on the field.



Sequences: Constructing Test Scenariosdo

Notes

• When do-ing an item, you must emit the event driver.item_done to let the sequence complete the doaction and inform the driver that the item was processed. (Typically, this is done when the transmissionof the item via the BFM is done.) Without emitting this event, the sequence cannot continue, and thedriver cannot drive more items.

• The do action can only be activated inside sequences.

• For items, Step 1 (waiting for the sequence driver to be ready) is performed before Step 2 (generation)to ensure that generation is done as close as possible to the actual driving. In this way, if the constraintsdepend on the current status of the DUT/environment, that status will be as accurate as possible.

• BFM sequences cannot do sequences created by other sequence statements.

• The sequence driver decides when the item is ready by managing a FIFO that also considers anygrab/ungrab actions done by the various sequences and the value of is_relevant() of the sequences.If no grab is done, and is_relevant() returns TRUE for all sequences, the order of doing the items isdetermined by the order of the do actions in the various sequences that refer to the sequence driver,regardless of their depth or origin. Keep in mind that sequences and items can also be done in parallel,using the all of and first of actions. (See “grab()” on page 5-101 and “is_relevant()” on page 5-105.)

• do is a time-consuming action encapsulating a set of actions that can be considered as an atomicactivation of an item/sequence. However, if for some reason you want to perform any of these stepsseparately from the do, you can easily do so.

On a subsequence 1. Generates the field, considering the constraints, if any.

2. Calls its body() TCM.

The do action finishes when the subsequence body() returns.

For more information, see Figure 5-17 on page 5-121.

On an item 1. Waits until the driver is ready to perform the do action.

2. Generates the field, considering the constraints, if any.

The item is returned by get_next_item().

The do action finishes when emitting the event driver.item_done.

For more information, see Figure 5-19 on page 5-123 and Figure 5-18 onpage 5-122.



Sequences: Constructing Test Scenariosdo_and_grab

Example

extend FOO ex_atm_sequence {// Parametersi: int;b: bool;

// Items/subsequences!cell: ex_atm_cell;!seq: bar ex_atm_sequence;

// The body() methodbody() @driver.clock is {

do cell keeping {.len == 4};do cell;for i = 1 to 20 do {

do cell keeping {.address == i};};do seq keeping {.f == 2};

};};

5.13.2 do_and_grab

Purpose

This action executes a do action and a grab() method simultaneously.

Syntax

do_and_grab field_name [keeping {constraint;...}]

Parameters

Description

The do_and_grab action differs from a normal do action in that it also grabs the do-ing sequence’sdriver.

field_name Must be a non-generatable basic item in the current struct. In other words, thefield represents a sequence item and not a sequence.

constraint Can be any constraints on the field.



Sequences: Constructing Test ScenariosSequence-Related Methods

The do_and_grab action differs from a regular grab() as follows. When a regular grab() occurs, theattempt to lock the driver is immediate. With do_and_grab, no grabbing is attempted until the driverstarts handling the item.

Notes

• If get_next_item() terminates before returning the item done by do_and_grab, the grab still takeseffect.

Example

...do_and_grab my_item;do my_item keeping {.x==BLUE;};do another_item;ungrab(driver);...

See Also

• do on page 5-95

• grab() on page 5-101

5.14 Sequence-Related MethodsThis section includes:

• start_sequence() on page 5-99

• stop() on page 5-100


• ungrab() on page 5-102

• is_blocked() on page 5-103

• is_grabbed() on page 5-103

• current_grabber() on page 5-104

• is_relevant() on page 5-105

• last() on page 5-105

• branch_terminated() on page 5-107



Sequences: Constructing Test Scenariosstart_sequence()

• has_do_available() on page 5-107

5.14.1 start_sequence()

Purpose

This method of any_sequence is used to initiate the run of a sequence.

Syntax

[sequence-exp.]start_sequence()

Parameters

None

Description

start_sequence() is a non-time-consuming method that starts the body() TCM of the sequence. Use thismethod instead of starting the body() TCM directly. When doing so, a new sequence tree is executed.

Notes

• The start_sequence() of the MAIN sequence is called automatically by the driver.

• Before calling the start_sequence() of all sequences other than the MAIN sequence, you mustgenerate the sequence and connect the driver to the sequence using either a constraint or proceduralcode.

• The parent_sequence field of a started sequence is NULL. A started sequence has no parent sequence,because it serves as the root of a new sequence tree.

See Also




Sequences: Constructing Test Scenariosstop()

5.14.2 stop()

Purpose

This method of any_sequence is used to terminate the run of a sequence.

Syntax

[sequence-exp.]stop()

Parameters

None

Description

stop() is a non-time-consuming method that terminates the execution of body() (if such exists) bykilling its thread. This might become useful if, for example, you want to terminate a sequence in themiddle upon interrupt and execute an alternative sequence instead.

Notes

• Stopping a sequence also stops its containing tree. To stop only the sequence’s subsequence tree,make sure that the sequence is started (not done) by its parent sequence.

• Stopping is done on a cycle boundary, so some non-time-consuming actions in the stopped sequencemight still be executed after the sequence itself was stopped.

• When stopping a sequence, the event stopped is emitted both for the stopped sequence and its root.

• When a sequence is stopped, it and all of its subsequences are released from the grab.

• For correct behavior of stop() for virtual sequences, make sure that the method get_sub_drivers()of the virtual driver is implemented correctly and returns all BFM drivers to which the sequence andits subsequences might send items. This is also important when stopping a BFM sequence that wasdone by a virtual sequence. For more information about virtual sequences, see “Using VirtualSequences” on page 5-23.



Sequences: Constructing Test Scenariosgrab()

5.14.3 grab()

Purpose

This method of any_sequence lets sequences have an exclusive control over a sequence driver.

Syntax

[sequence-exp.]grab(driver) @sys.any

Parameters

Description

grab() is a blocking TCM that grants its calling sequence an exclusive access to driver. A sequence thatwants exclusivity can call grab(driver). This grants exclusive access to that sequence and itssubsequences from the moment grab() returns (perhaps, after a slight delay) until the sequence calls acorresponding ungrab(driver). During this grabbing period, the sequence driver belongs to thesequence. The driver drives only the items that were done by the grabbing sequence or its subsequences.

When a sequence driver belongs to a sequence, only that sequence can send items to the sequence driver.All other sequences are blocked from sending (that is, their items remain blocked).

Notes

• Virtual drivers cannot be grabbed, because they do not schedule items.

• Sequence drivers cannot be grabbed while they execute a do action on a sequence item. The grab isgranted immediately after the completion of the do action.

• Exclusive control means that the sequence and all its subsequences can use the sequence driver. Allother calls are blocked until ungrab().

• When grabbing a sequence driver, make sure that the is_relevant() method of the sequence that grabsthe driver returns TRUE. This averts a situation in which the driver cannot send items.

• grab() is hierarchical. If a sequence s1 grabs the sequence driver and then a sequence s2 enclosedby s1 also grabs the sequence driver, there will be no delay as long as s2 has the sequence driverwithin s1. So, for example, s3 (the brother of s2) cannot access the sequence driver. Only when s2ungrabs does s3 finally get access, but everything outside s1 is still blocked.

driver A BFM sequence driver expression



Sequences: Constructing Test Scenariosungrab()

• grab() is somewhat similar to lock(), but it is different in the following respects:

• grab() is hierarchical.• grab() interacts with how items are sent.

• Rerunning a driver cancels the grab. If a sequence grabbed the driver before driver.rerun() wascalled, the sequence must regrab the driver. If a sequence was blocked while waiting to get the grab,then it is released without grabbing the driver. For more information, see “Resetting and RerunningSequences” on page 5-37.

See Also

• grab_test.e in the ex_atm/examples directory (an example of grabbing and ungrabbing)

• ungrab() on page 5-102

5.14.4 ungrab()

Purpose

This method of any_sequence stops sequences from having an exclusive control over a sequence driver.

Syntax

[sequence-exp.]ungrab(driver)

Parameters

Description

ungrab() is a non-time-consuming method that releases the driver from the exclusive control of thesequence that was previously granted by calling grab().

Notes

• A virtual driver cannot be ungrabbed, because it does not schedule items.

• Calling ungrab() when a sequence did not grab the driver results in error.

driver A BFM sequence driver expression



Sequences: Constructing Test Scenariosis_blocked()

See Also

• grab_test.e in the ex_atm/examples directory (an example of grabbing and ungrabbing)


5.14.5 is_blocked()

Purpose

This method is valid for BFM sequences only. It indicates whether a sequence is blocked from sendingitems. It happens when another sequence that is not an ancestor has grabbed the sequence driver.

Syntax

[sequence-exp.]is_blocked(): bool

Parameters

None

Description

is_blocked() is a non-time-consuming method that returns TRUE if the sequence is blocked by anothersequence that grabbed the sequence driver.

See Also


5.14.6 is_grabbed()

Purpose

This method is valid for BFM sequence drivers only. It indicates the grab status of the sequence driver.

Syntax

[driver-exp.]is_grabbed(): bool



Sequences: Constructing Test Scenarioscurrent_grabber()

Parameters

None

Description

is_grabbed() is a non-time-consuming method that returns TRUE if the sequence driver is grabbed by asequence.

See Also


5.14.7 current_grabber()

Purpose

This method is valid for BFM sequence drivers only. It indicates which sequence (if any) has exclusivecontrol over a sequence driver.

Syntax

[driver-exp.]current_grabber(): any_sequence

Parameters

None

Description

current_grabber() is a non-time-consuming method that returns the sequence that currently hasexclusive control over the sequence driver. It returns NULL if no sequence currently has exclusivecontrol over the sequence driver.

See Also




Sequences: Constructing Test Scenariosis_relevant()

5.14.8 is_relevant()

Purpose

This method is valid for BFM sequences only. It indicates whether the sequence is currently relevant fordo-ing items.

Syntax

[sequence-exp.]is_relevant(): bool

Parameters

None

Description

is_relevant() is a non-time-consuming method that returns TRUE if the sequence is currently allowed todo items. By default, this method returns TRUE. You can implement it to respond to the changingconditions of the simulation. It is particularly useful for sequences used by reactive agents.

5.14.9 last()

Purpose

This method is valid for BFM sequence drivers only. It enables access to previously sent items in thesequence driver.

Syntax

[driver-exp.]last(index): item

Parameters

index The index in the sequence history. 0 is the currently sent item, 1 is theprevious item, and so on.



Sequences: Constructing Test Scenarioslast()

Return Value

Description

last() is a non-time-consuming method that lets you directly access items in the history of the sequence:

• last(0) returns the item currently being driven in (or the last item that was driven in, if there is noitem currently being driven in).

• last(1) returns the item before last(0), and so on.

The length of the history is determined by the field num_of_last_items in the sequence driver, which canbe constrained by the user. The default is 1.

Notes

• last(i) results in an error if i >= num_of_last_items.

• The maximum value for num_of_last_items is 1024.

• num_of_last_items is a static property of the BFM driver. Therefore, it cannot be changed during therun.

Example 1

You could create a sequence that alternates colors from red to green as follows:

extend packet {keep color == (driver.last(0) is a GREEN packet ? RED : GREEN);

};

Example 2

You could configure the buffer to store the last 10 items (instead of the default 1 item) as follows:

extend packet_seq_driver {keep num_of_last_items == 10

};

Notes

• The is a construct is a convenient way to also avoid checking for non-NULL.

item The item that was created index items ago by the sequence. The return valueis NULL if such item does not exist.



Sequences: Constructing Test Scenariosbranch_terminated()

• For efficiency, in the sequence driver you might want to set Boolean flags that summarize the last()information. In that case, the constraint can refer to the Boolean flags rather than last().

• You can also use last()-based constraints in sequences (not just items).

• The last() buffer is cleared upon driver.rerun().

5.14.10 branch_terminated()

Purpose

This method of any_sequence_driver is relevant when performing a do action inside a first of block.

Syntax

[driver-exp.]branch_terminated()

Parameters

None

Description

This method lets you resume normal operation in the current cycle when a do action in a first of blockterminates prematurely.

See Also

• “Using Sequences from a “first of” Block” on page 5-13

5.14.11 has_do_available()

Purpose

This method of any_sequence_driver tells an inquiring BFM if a do is available for execution.

Syntax

[driver_exp.]has_do_available(): bool



Sequences: Constructing Test ScenariosSequence-Related Pseudo-Routines

Parameters

None

Description

This method of any_sequence_driver returns TRUE if the driver can execute a do immediately. This canonly happen when the following conditions are met:

• The driver is not already busy handling a do (because the driver can only handle one do at a time).

• The driver has in its queue at least one relevant do (that is, its parent sequence returns TRUE foris_relevant()).

• The relevant do is not blocked (because another sequence has grabbed the driver).

Note Even when has_do_available() returns TRUE, an item might not be returned immediately byget_next_item(). It depends on the pre_do() TCM.

Example

...if my_driver.has_do_available() {

var an_item := my_driver.get_next_item();};...

5.15 Sequence-Related Pseudo-RoutinesThis section includes:

• in_sequence() on page 5-108

• in_unit() on page 5-109

5.15.1 in_sequence()

This pseudo-routine can be used inside sequences and items.

Syntax

[exp.]in_sequence(sequence_type) [(name)]



Sequences: Constructing Test Scenariosin_unit()

Parameters

Description

The in_sequence() routine returns TRUE if exp is an item or a sequence that was created using do insidea sequence of type sequence_type (at any depth). If name is specified, it assigns the found sequence toname.

If exp is a BFM sequence driver sd, then in_sequence() returns TRUE if sd.last(0) returns TRUE.

in_sequence() can be used in constraints to determine whether an item is inside a specific sequencetype. This allows enforcing constraints on every item in the sequence tree under a specific sequence.Therefore, this kind of constraint is called a tree constraint. It is useful when you want to say somethinglike:

“Every ATM cell under the FOO sequence should be green, regardless of how far down it is in thehierarchy.”

Example

extend ex_atm_cell {keep in_sequence(FOO ex_atm_sequence) => color == GREEN;// Implements the condition above

keep in_sequence(BAR ex_atm_sequence) (B) => len == B.len1;// If this cell is somewhere under a BAR ex_atm_sequence,// then set len to this sequence's len1 field

};

Of course, the in_sequence() pseudo-routine can also be used in normal procedural code. For example:

if in_sequence(BAR ex_atm_sequence) (B) then {print B.len1;

};

5.15.2 in_unit()

This pseudo-routine can be used anywhere.

exp An item, sequence, or a BFM sequence driver expression. If exp is missing,me is used.

sequence_type Any type or subtype of a sequence (that is, it inherits from any_sequence).

name Reference for the found sequence.



Sequences: Constructing Test ScenariosSequence Interface

Syntax

[exp.]in_unit(unit_type) [(name)]

Parameters

Description

in_unit() returns TRUE if you are inside such a unit (at any depth). If name is specified, it assigns thefound unit to name.

Note

• in_unit(foo) is equal to: try_enclosing_unit(foo) != NULL. The motivation behind this routine isto make it shorter and similar to in_sequence() as well as to enable tree constraints.

See Also

• “Writing Tests Using Sequences” on page 5-18

5.16 Sequence InterfaceThe sequence model consists of:

The following tables contain the full list of methods and fields for “any_sequence_item Interface”,“any_sequence Interface”, and “any_sequence_driver Interface”.

exp A struct. If exp is missing, me is used.

unit_type Any type or subtype of a unit.

name Reference for the found unit.

item Inherits from any_sequence_item

sequence Inherits from any_sequence so that any sequence struct that you create has boththe any_sequence interface and the any_sequence_item interface

driver Inherits from any_sequence_driver




Notes

• The information in this section also applies to sequences.

• The driver field is not defined in any_sequence_item. For this field to be defined, you must use theitem in a sequence statement.

• The get_driver() method is declared as undefined in any_sequence_item. For this method to bedefined, you must use the item in a sequence statement.

• Never use is only on the pre_generate() or post_generate() of items or sequences. Theparent_sequence and driver of fields are assigned in the pre_generate() of any_sequence_item.

Table 5-15 any_sequence_item Interface

Struct Member Description

Read Only Member (can only be accessed)

get_depth(): int Depth from the sequence driver, valid from pre-generation.

get_driver(): driver_name Returns the driver for an item.

!parent_sequence: any_sequence; Backpointer to the sequence in which an item was created.Assigned automatically in the pre_generate() of the item.

do_location(): string Returns a string describing the source location of the do actionthat generated the current item.

Not relevant for sequence_items not created via the do action.

Read/Write Member (can also be set, constrained, or implemented)

driver: driver_name Driver for the item, soft-constrained to be its parent sequence’sdriver.

nice_string(): string is empty A short string representing the item for tracing. It is used bytrace sequence, wave sequence, and show sequence (see“Tracing and Debugging Sequences” on page 5-70).

The default implementation returns the value of to_string().

Table 5-16 any_sequence Interface



get_depth(): int Depth from the sequence driver, valid from pre-generation.




get_driver():driver_name

Return the driver for a sequence.

!parent_sequence:any_sequence;

Backpointer to the sequence in which this sequence was created. Assignedautomatically in pre_generate() of the sequence if such a parent exists.

get_index(): int Starts at 0 and gets incremented after every do.Provides a declarative style.

grab(driver:any_sequence_driver)@sys.any is undefined

Grab the sequence driver for exclusive access and returns when you haveexclusive access.

is_blocked(): bool Indicate whether the sequence is blocked.

is_relevant(): bool Apply a condition for performing a do item action, so that the do actionwill not be scheduled until is_relevant() returns TRUE.

start_sequence() Starts sequence activity by starting body().

Note Call this method instead of starting body() directly.

See also Figure 5-16 on page 5-120.

stop() Terminates my body(), if it exists.

ungrab(driver:any_sequence_driver)is undefined

Releases the grab on a sequence driver and returns immediately.


driver: driver_name Driver for the sequence, soft-constrained to be its parent sequence’sdriver.

nice_string(): string isempty

A short string representing the sequence for tracing. It is used by tracesequence, wave sequence, and show sequence (see “Tracing andDebugging Sequences” on page 5-70).

The default implementation returns the kind followed by the instancename (for example, “RED atm_sequence-@2”).

@ended Emitted immediately after body() is finished.

@started Emitted just before body() is called.

Table 5-16 any_sequence Interface (continued)





Note Some of the methods in Table 5-16 above are inherited from the any_sequence_item interfaceshown in Table 5-15 on page 5-111.

body() @driver.clock isempty

Main method called by do of parent sequence after it generates the currentsequence.

kind: kind_name The kind field that determines which sequence it is (within its whenfamily).

mid_do(s:any_sequence_item)is empty;

Hook method called in the middle of do, just after s is generated andbefore it is executed by calling the body() TCM.

post_body() @sys.anyis empty;

Hook method called after body() when sequence is started using thestart_sequence() method.

post_do(s:any_sequence_item)

is empty;

Hook method called at end of do, just after the execution of s.body().

post_do_tcm(s:any_sequence_item)@sys.any is empty;

Hook TCM called after post_do(). Extends the life of a do after theitem_done event is emitted. The sequence driver, freed by the item_doneevent, no longer manages the current item. It can handle other items.

post_trace() Gets called for every sequence just after a trace message about it getsprinted. (Useful for breakpoints.)

pre_body() @sys.anyis empty;

Hook method called before body() when sequence is started using thestart_sequence() method.

pre_do(is_item: bool)@sys.any is empty;

Hook TCM called at start of a do performed by the sequence. ‘is_item’specifies whether you are in a context of do-ing an item or a sequence.

Table 5-17 any_sequence_driver Interface

Struct Member DescriptionBFMOnly


current_grabber(): any_sequence Indicates which sequence (if any) has exclusivecontrol over a sequence driver.

Yes

Table 5-16 any_sequence Interface (continued)





get_current_item():any_sequence_item

Returns the item currently being sent. (NULL if theBFM is currently idle.)

Yes

get_index(): int Returns index of this sequence driver in theall-driver list.

No

get_item_trace_list(): list ofany_sequence_item

Returns a list of the items handled (sent) by thesequence driver (the item sublist of the trace log).

Note The list is populated only if the tracesequence command was activated in On or LogOnly mode.

Yes

get_next_item(): item_name@clock

This TCM should be called in PULL_MODE toreceive the next item from the BFM driver. ThisTCM is blocked until there is an item to do in thedriver.


Yes

get_num_items_sent(): int Returns count of items sent (excludingcurrent_item, if any).

Yes

get_sequence_trace_list(): list ofany_sequence

Returns a list of the sequences handled by thesequence driver (the sequence sublist of the tracelog).


Yes

get_trace_list(): list ofany_sequence_item

Returns a list of all sequences and items handled bythe sequence driver (the full trace log).


Yes

is_grabbed(): bool Indicates the grab status of the sequence driver. Yes

last(index): any_sequence_item Enables access to previously sent items in thesequence driver.

Yes

Table 5-17 any_sequence_driver Interface (continued)





try_next_item(): item_name@clock

This TCM should be called in PULL_MODE whenthe BFM has to receive an item or perform somedefault behavior. Unlike get_next_item(), in casethere is no available item waiting to be done in thecurrent cycle, this TCM returns NULL.

Note try_next_item() returns in the same cycle ifthere is no pending do action. However, if a doaction started execution, then try_next_item()might take longer than a cycle, for example, if youextend the pre_do() TCM to take longer than acycle.


Yes


bfm_interaction_mode:bfm_interaction_mode_t

Specifies the way the driver and the BFM interactwith each other. Possible options arePULL_MODE (the default) and PUSH_MODE. Itcan be constrained.

See also “BFM-Driver Interaction Mode” on page5-43.

Yes

max_random_count: int Used in setting the maximum number ofsubsequences in a RANDOM or MAIN sequence.

keep soft max_random_count ==MAX_RANDOM_COUNT; // Defined to

// be 10

No

max_random_depth: int Used for setting the maximum depth insideRANDOM sequences. (Beyond that depth,RANDOM creates only SIMPLE sequences.)

keep soft max_random_depth ==MAX_RANDOM_DEPTH; // Defined

// to be 4

No

num_of_last_items: int Used for setting the length of the history ofpreviously sent items. Default is 1.

Yes






gen_and_start_main: bool Enable or disable automatic generation and launchof the MAIN sequence upon run. Default is TRUE(MAIN sequence is generated and started).

No

check_is_relevant() For forcing a driver to recheck the relevance (valueof is_relevant()) for each sequence that has itemsin the driver’s item queue. It can be useful whensomething has changed in the BFM that affects therelevance of some sequences.

Yes

delay_clock() @sys.any This TCM can be used to emit the driver’s clockwith some intercycle delay to let the BFM exportits state before activation of sequences in a specificcycle.

Note This TCM should be activated INSTEADof connecting the clock to another event.

No

event clock The main clock. Should be tied to some temporalformula by users during the sequence driverhooking.

No

event item_done Synchronization event for the do action inPULL_MODE. When working in PULL_MODE,you must emit this event to complete the do itemand let the driver get more items usingget_next_item().

See also “Sequence Driver Unit” on page 5-7.

Yes

get_sub_drivers(): list ofany_sequence_driver is empty

For virtual sequence drivers, this method is to befilled in by the writer of the specific sequencedriver. It should return the list of subdrivers of thesequence driver. For a BFM sequence driver, itshould be left unchanged, that is, return an emptylist.

Virtualonly

read(address: list of bit): list of bit@clock is undefined;

For implementing a DUT-independent interface.

See also: “DUT-Independent Read/Write Interface”on page 5-39

No





Sequences: Constructing Test ScenariosPredefined Sequence Kinds

Notes

• Some of the driver members are relevant only for BFM drivers. See the last column in the table above.

• Never use is only on the pre_generate() or post_generate() of drivers. The list of previously sentitems of the driver is initialized in the post_generate() of the driver.

• Never use is only on the run() or rerun() of drivers. Some important initializations are performedin those methods.

5.17 Predefined Sequence KindsThere are three predefined sequence kinds: MAIN, RANDOM, and SIMPLE. The following sectionsdescribe their implementation.

• “MAIN Sequence” on page 5-118

regenerate_data() is empty Regenerates driver’s data upon rerun().

See also “Resetting and Rerunning Sequences” onpage 5-37.

No

send_to_bfm(seq_item:item_name) @clock is empty

When working in PUSH_MODE, sends the item tothe corresponding BFM. To be implemented byusers as part of hooking.

This method is called automatically (when workingin PUSH_MODE).

Yes

wait_for_sequences() @sys.any This TCM is called to delay the return oftry_next_item() and let sequences create items. Itcan also be called in other locations to helppropagation of activity (for example, amongseveral layers of sequences). It can also beoverridden to implement a different scheme thanthe default one.

Yes

write(address: list of bit, data: listof bit) @clock is undefined;

For implementing a DUT-independent interface.

See also “DUT-Independent Read/Write Interface”on page 5-39.

No





Sequences: Constructing Test ScenariosMAIN Sequence

• “RANDOM Sequence” on page 5-118

• “SIMPLE Sequence” on page 5-119

5.17.1 MAIN SequenceThis sequence subtype is defined directly under the sequence driver and is started by default. It is usedas the root for the whole sequence tree.

extend MAIN sequence_name {count: uint;!sequence: sequence_name;

keep soft count > 0;keep soft count <= MAX_RANDOM_COUNT;keep sequence.kind not in [RANDOM, MAIN];

body() @driver.clock is only {for i from 1 to count do {

do sequence;};

};};

5.17.2 RANDOM SequenceThis sequence subtype is used for creating random scenarios based on SIMPLE and user-definedsequence subtypes.

extend RANDOM sequence_name {count: uint;!sequence: sequence_name;

keep soft count > 0;keep soft count <= MAX_RANDOM_COUNT;keep sequence.kind not in [RANDOM, MAIN];keep depth_from_driver >= driver.max_random_depth =>

sequence.kind == SIMPLE;

body() @driver.clock is only {for i from 1 to count do {

do sequence;};

};};



Sequences: Constructing Test ScenariosSIMPLE Sequence

5.17.3 SIMPLE SequenceThis sequence subtype generates and executes a single item.

extend SIMPLE sequence_name {!seq_item: item;body() @driver.clock is only {

do seq_item;};

};

5.18 BFM-Driver-Sequence Flow DiagramsThis section contains diagrams to show how the BFM, the driver, and the sequences interact with eachother:

• “sequence.start_sequence() Flow” on page 5-120

• “do Subsequence Flow” on page 5-121

• “do Item Flow in Push Mode” on page 5-122

• “do Item Flow in Pull Mode Using get_next_item()” on page 5-123

• “do Item Flow in Pull Mode Using try_next_item()” on page 5-124



Sequences: Constructing Test Scenariossequence.start_sequence() Flow

5.18.1 sequence.start_sequence() Flow

Figure 5-16 sequence.start_sequence() Flow

Figure 5-16 describes the flow when starting a sequence using the start_sequence() method.

For more information on the start_sequence() method, see “start_sequence()” on page 5-99.

The sequence driverdoes not schedulesequences but onlyitems. Therefore, whenstarting a sequence, nosynchronization isdone between thedriver and the startedsequence.

Sequence Driver Sequence

start_sequence()- Parent sequence is NULL.- Sequence is already generated.- Driver is not NULL.

trace: “Starting sequence.”sequence is added to the driver’s trace list”.

emit @started.

Start TCM that:- Calls pre_body() TCM- Calls body() TCM- Calls post_body() TCM

emit @ended.

Return of start_sequence()

Note This flow does not depend on the bfm_interaction_mode



Sequences: Constructing Test Scenariosdo Subsequence Flow

5.18.2 do Subsequence Flow

Figure 5-17 do Subsequence Flow

Figure 5-17 describes the flow when do-ing a subsequence.

For more information on the do action, see “Activating Items and Subsequences” on page 5-13.

Sequence Driver (driver)(1)

Sequence(n)

do subsequence

Call pre_do() TCM, with is_item = FALSEGenerate subsequence with:

- parent_sequence = sequencedriver = sequence.driver (by constraint)

Trace: “subsequence created”

End of do subsequence

Note This flow does not depend on the bfm_interaction_mode.

The sequence driverdoes not schedulesequences but onlyitems. Therefore, whendo-ing a sequence, nosynchronization isdone between thedriver and the doingsequence or the donesubsequence.

Call subsequence.body()

subsequence is added to the driver’s trace list

Emit @subsequence.startedCall mid_do()

Call post_do()Trace: “subsequence done”Emit @subsequence.ended



Sequences: Constructing Test Scenariosdo Item Flow in Push Mode

5.18.3 do Item Flow in Push Mode

Figure 5-18 do Item Flow in Push Mode

Figure 5-18 describes the flow when do-ing an item when driver.bfm_interaction_mode is set toPUSH_MODE.


For more information on driver.bfm_interaction_mode, see “Hooking the Sequence Driver to theEnvironment” on page 5-9.

BFM(1)

Sequence(n)

Driver(1)

do item

The do action is listed in the driver’s queue

Wait for the driver acknowledgement

Trace: “item created”

End of do item

Choose a do action to beexecuted on afirst-come-first-served basis,considering grabbers, andsequence.is_relevant()

Call mid_do()

Call pre_do() TCM, with is_item = TRUE

item is added to the driver’s trace list”

Wait for @driver.item_done

Acknowledge the driver that item is readyto be sent

Add item to driver’s last() buffer

Generate item with:- parent_sequence = sequencedriver = sequence.driver (by constraint)

Trace: “item sent by driver”Call post_do()

Sends item to DUT

Note This flow occurs when driver.bfm_interaction_mode == PUSH_MODE

Wait until item is generated

Acknowledge the sequence

Call send_to_bfm(item)Emit @item_done



Sequences: Constructing Test Scenariosdo Item Flow in Pull Mode Using get_next_item()

5.18.4 do Item Flow in Pull Mode Using get_next_item()

Figure 5-19 do Item Flow in Pull Mode Using get_next_item()

Figure 5-19 describes the flow when do-ing an item when driver.bfm_interaction_mode is set toPULL_MODE and driver.get_next_item() is used to receive items from the driver.



For more information on driver.get_next_item(), see Table 5-17 on page 5-113.

BFM SequenceDriver

do item

The do action is listed in the driver’s queue

Wait for the driver acknowledgement

Trace: “item created”

End of do item

Call mid_do()

Call pre_do() TCM, with is_item = TRUE

item is added to the driver’s trace list”

Wait for @driver.item_done

Acknowledge the driver that item isready to be sent

Add item to driver’s last() buffer

Generate item with:- parent_sequence = sequencedriver = sequence.driver (by constraint)

Trace: “item sent by driver”Call post_do()

Emit @item_doneSends item to DUT

Note This flow occurs when driver.bfm_interaction_mode == PULL_MODE.

Choose a do action to beexecuted on afirst-come–first-servedbasis, considering grabbers,and sequence.is_relevant()

Acknowledge the sequence

Wait until item is generated

Get next_item() returns

Call driver.get_next_item()



Sequences: Constructing Test Scenariosdo Item Flow in Pull Mode Using try_next_item()

5.18.5 do Item Flow in Pull Mode Using try_next_item()

Figure 5-20 do Item Flow in Pull Mode Using try_next_item()

Figure 5-20 describes the flow when do-ing an item when driver.bfm_interaction_mode is set toPULL_MODE and driver.try_next_item() is used to receive items from the driver.



For more information on driver.try_next_item(), see “Applying Default Behavior When No Item Is Done”on page 5-51 and Table 5-17 on page 5-113.

5.19 Sequence DeprecationThis section contains:

• “Method sequence.start() Deprecation” on page 5-125

BFM Driver

Call driver.try_next_item()

Create a default item

Notes

• This flow occurs when driver.bfm_interaction_mode == PULL_MODE

• try_next_item() might take more than a cycle, in case a do is chosen and pre_do() takes more than a cycle

First of:

YesNo

Send item to the DUT

Continue as inget_next_item()flow.try_next_item()returns an item.

try_next_item()returns with NULL

{choose a do action}{wait_for_sequences()}

A do action is chosen beforewait_for_sequences returns?



Sequences: Constructing Test ScenariosMethod sequence.start() Deprecation

• “Field sequence Deprecation” on page 5-125

• “Sequence item Deprecation” on page 5-127

5.19.1 Method sequence.start() DeprecationAll sequences currently have a method named start(). As start is now an e keyword, the name of thismethod must be changed to something that does not conflict. Therefore, from Specman 4.3, the start()method of any_sequence changes to start_sequence().

Note Currently the default severity of this deprecation is IGNORE. You will not get any warning orerror message unless you change the severity level.

Associated Notification IDs

DEPR_SEQUENCE_START_KEYWORD

Sample Notification Message

If any sequence uses the start() method and you have set the severity level to WARNING, you willreceive a message like the following:

*** Warning: DEPR_SEQUENCE_START_KEYWORD: The keyword 'start' is used asan identifier. Replace the method any_sequence.start() withany_sequence.start_sequence()

at line 50 in @seqmy_sequence.start();

For more information, search help for 'DEPR_SEQUENCE_START_KEYWORD'.

For more information on the deprecation process, see “The Deprecation Process for Syntactic Changes”in the e Language Reference.

5.19.2 Field sequence DeprecationMAIN and RANDOM sequences currently have a field named “sequence”. As sequence is now an ekeyword, the name of this field must be changed to something that does not conflict. From Specman 4.3,the “sequence” field changes as follows:

• The name of the MAIN sequence field under a sequence driver changes from “sequence” to“main_sequence”.

• Under the MAIN sequence, the name of the field “sequence” changes to “sub_sequence”.

• Under the RANDOM sequence, the name of the field “sequence” changes to “sub_sequence”.



Sequences: Constructing Test ScenariosField sequence Deprecation


To use the new field names:

• Constrain the sequence driver flag using_new_sequence_naming to TRUE.

keep using_new_sequence_naming == TRUE;

This enables the new names for the “sequence” field in the driver and its associated sequences.


DEPR_SEQUENCE_FIELD_KEYWORD



If your code uses the old name for the MAIN sequence field under a sequence driver and you have setthe severity level to WARNING, you will receive a message like the following:

*** Warning: DEPR_SEQUENCE_FIELD_KEYWORD The keyword 'sequence' is usedas an identifier. Replace 'sequence' of my_sequence_driver with'main_sequence' after constrainingmy_sequence_driver.using_new_sequence_naming to TRUE.

For more information, search help for 'DEPR_SEQUENCE_FIELD_KEYWORD'

If your code uses the old sequence field name under MAIN and you have set the severity level toWARNING, you will receive a message like the following:

*** Warning: DEPR_SEQUENCE_FIELD_KEYWORD The keyword 'sequence' is usedas an identifier. Replace 'sequence' of MAIN'kind my_sequence with'sub_sequence' after constrainingmy_sequence_driver.using_new_sequence_naming to TRUE.


If your code uses the old sequence field name under RANDOM and you have set the severity level toWARNING, you will receive a message like the following:

*** Warning: DEPR_SEQUENCE_FIELD_KEYWORD The keyword 'sequence' is usedas an identifier. Replace 'sequence' of RANDOM'kind my_sequence with'sub_sequence' after constrainingmy_sequence_driver.using_new_sequence_naming to TRUE




Sequences: Constructing Test ScenariosSequence item Deprecation

5.19.3 Sequence item DeprecationThe SIMPLE sequence currently has a field named “item”. As item is now an e keyword, the name ofthis field must be changed to something that does not conflict. Therefore, from Specman 4.3, the “item”field of the SIMPLE sequence changes to “seq_item”.



DEPR_SEQUENCE_ITEM_KEYWORD


If the SIMPLE sequence uses the “item” field and you have set the severity level to WARNING, you willreceive a message like the following:

*** Warning: DEPR_SEQUENCE_ITEM_KEYWORD: The keyword 'item' is used asan identifier. Replace 'item' of SIMPLE'kind my_sequence with 'seq_item'

after constraining my_sequence_driver.using_new_sequence_naming toTRUE.

For more information, search help for 'DEPR_SEQUENCE_ITEM_KEYWORD'.


5.20 Known LimitationsFollowing are the known limitations of the sequence model:

• “Same Item Cannot Be Used in Two Different Sequences” on page 5-127

• “Item Children Cannot Be Created with Like Inheritance before Sequence Statement” on page 5-128

• “Sequences Are Supported Only from Version 4.1” on page 5-128

5.20.1 Same Item Cannot Be Used in Two DifferentSequences

Description

You cannot use the same item type in two different sequence statements in the same environment.



Sequences: Constructing Test ScenariosItem Children Cannot Be Created with Like Inheritance before Sequence Statement

Workaround

Create two (or more) subtypes and use the subtypes in the sequences (a different subtype for eachsequence type).

Example

You could create two different sequences for ATM cells as follows:

1. Define the type to create the subtypes.

For example:

type cell_seq_kind: [A, B];

2. Add the type to the item for which you want to create sequences.

For example:

extend ex_atm_cell {seq_kind: cell_seq_kind;

};

3. Use the sequence statement to create two different sequences for the two different subtypes.

For example:

sequence atm_A using item=A ex_atm_cell;sequence atm_B using item=B ex_atm_cell;

5.20.2 Item Children Cannot Be Created with Like Inheritancebefore Sequence Statement

Specman does not allow the addition of fields to a struct that already has like children. The sequencestatement adds fields and methods to the item struct. Therefore, if you have created like item childrenbefore the sequence statement, Specman reports an error when the sequence statement occurs.

Example

sequence my_seq using item=my_item;// Create children of my_item only after the sequence statementstruct my_new_item like my_item {...}

5.20.3 Sequences Are Supported Only from Version 4.1The sequences package can be run only on top of Specman version 4.1 or higher.



Sequences: Constructing Test ScenariosSequences Are Supported Only from Version 4.1



Erm Sequences 061205

Documents

Transcript of Erm Sequences 061205