Chapter 1 Introduction
1.3 Proposed approach
In this thesis, we propose a transaction-level functional coverage methodology, and provide a mean to specify functional transactions at a higher level of abstraction. First, the interface protocol is given as a specification FSM (spec. FSM) by using the concept in [12-13]. Then a transaction can be defined as a specific sequence of state transitions within the spec. FSM. We also develop a transaction description language,
State-Oriented Language (SOL), which is cable of modeling diverse state transition sequences precisely and rigorously. The transactions can then be specified in a simpler and more systematic way. Moreover, the specified transactions with the spec. FSM can be translated into the corresponding functional coverage analyzer automatically.
The rest of this thesis is organized as follows. In Section 2, the basic concept and
7
the related works of transaction-level functional coverage are introduced. Section 3 presents the proposed new transaction description language State-Oriented Language. In Section 4, the details of our verification methodology are given. Section 5 demonstrates the proposed methodology with the AMBA AHB slave interface protocol and shows the experimental results. Finally, the concluding remarks are given in Section 6.
8
Chapter 2
Transaction-Level Functional Coverage
As mentioned, functional coverage concentrates on identifying how much of the original design specification has been verified, and it is favorable to improve the quality of interface compliance verification. Transaction-level functional coverage is one of the commonly used methods to measure the functional coverage for an interface design [14-16]. An interface protocol specification usually defines a set of different transactions.
Note that a transaction here can be thought as the transfer of data and control over an interface to perform certain basic operation. For example, a transaction can be a 4-beat
9
burst or an 8-beat burst, or a 4-beat burst followed by an 8-beat one. By considering the design information (e.g., supported burst modes or responses) with these pre-defined transactions, the interesting transactions for a specific design can then be derived.
Transaction-level functional coverage is generally measured by how many interesting transactions are exercised. However, a design instance usually implements a subset of the full interface protocol. For example, ‘WAIT’ response is optional in a specific interface protocol. A design which complies with this interface protocol does not allow
‘WAIT’ response during transaction. If ‘WAIT’ response is required to occur in coverage metric for this design, the coverage will never achieve 100%. This coverage result becomes ineffectual and insignificant. Since the interesting transactions for a given design are specific to design specification, they are usually derived manually and subjectively. This idea is illustrated in Figure 2. Therefore, a user-friendly but still rigorous transaction description language is needed.
Figure 2. The interesting transactions derivation.
2.1 Related works
Several approaches are proposed for transaction-level functional coverage. For M-path coverage [13], the protocol is first modeled as a spec. FSM. Then an M-path is defined as a path which can form a complete bus transfer in the FSM model. In other
Transactions
10
words, an M-path, which is a finite sequence of state transitions, is actually a simple transaction. M-paths are used as the targets for coverage measurement. However, the proposed FSM model here is too simple. Since only several control signals are checked, many transactions cannot be differentiated from others. For the AMBA AHB protocol, the write transactions cannot be distinguished from the read ones due to the signal HWRITE is not checked. This may make it too easy to achieve 100% M-path coverage.
Besides, the definition of M-path is neither clear nor rigorous enough. It is not convenient to put it to good use for lack of sufficient expressive power. Moreover, consecutive transfers are not considered in this work. It may conceal the design errors since some errors may merely occur during consecutive transfers.
In [14], Component Wrapper Language (CWL) is used to describe signal sequences based on regular expressions. For example, there are three sample transactions, idle, read and write. The timing diagram of each transaction is given in Figure 3. CWL descriptions of these transactions are depicted in Figure 4. In CWL descriptions, the input and output signals must be declared first. Then signal values at each cycle are defined as signal sets. For the cycle RRB, the signal values of clk, reset, wait_n, msel_n, read_n, adr, and dat are R (for rising edge), 0, 1, 0, 0, Xa (for the read address), and ? (for the unknown read data), respectively. Next, each simple transaction is modeled by utilizing the defined signal sets. For example, the idle transaction comprises at least one NOP. Finally, a more complex transaction can be built up by assembling simple ones. Users can construct transactions and do transaction-level verification by using CWL.
11
Figure 3. Sample transactions.
Figure 4. CWL descriptions of Figure 3.
In this approach, individual signals need to be considered when describing thorough transactions. In other words, the signal-level descriptions are required. If the transactions are getting more complex, it might be troublesome and time-consuming to
Signal Set Naming Port Declaration
Overall Definition Transaction Definition idle read write
12
author the corresponding CWL descriptions. Thus, CWL is not suitable to model complex transactions.
2.2 Motivation
Typically, the interesting transactions need to be derived manually before measuring transaction-level functional coverage. It is tedious and error-prone for human to specify transactions if the detailed signal values are required. Take a 4-beat burst of the AMBA AHB protocol as an example. The corresponding timing diagram is given in Figure 5. If the signal-level description is used for this transaction, each signal must be specified at each cycle, and similar processes must be done iteratively until the description is complete. As the transactions get more complex, the description processes become very tedious. Under this low-level description style, it is really a bothersome and time-consuming work to specify transactions.
Figure 5. A 4-beat burst of the AMBA AHB protocol.
13
To cope with this issue, it is a good idea to provide a simple, human-friendly, rigorous, and systematic way to specify transactions at a higher level of abstraction instead of at the signal level.
2.3 Concept of our transaction description style
The transaction description style in our approach is directly inspired by the work proposed in [12-13]. Both works give the concept of specifying interface protocol in the higher FSM level. All engineers are very familiar with this style and are very likely to accept this style since no particular specification languages need to be learned.
In our work, the interface protocol is specified as a spec. FSM by using the methods in [12-13]. The spec. FSM only needs to be created once for a specific interface protocol and can be massively reused later. A transaction can then be defined as a specific sequence of state transitions within the spec. FSM. This enables the use of states in the spec. FSM as basic elements to describe transactions. This method can raise the level of abstraction as well as encapsulate the details of the low-level signals. In other words, the detailed signal values are no longer required. Hence, one can put more emphasis on the functionality at the higher FSM level.
14
Chapter 3 State-Oriented Language
Since the existing transaction description languages are neither simple nor human-friendly enough, we develop a new transaction description language, State-Oriented Language (SOL), in which we can specify transactions at the higher FSM level. In SOL, PSL-like syntax [17] is used to represent a sequence of state transitions within the spec. FSM as a transaction. We believe the expressive power of SOL is stronger than that of traditional regular-expression-based approaches. Therefore, it is easier to model complex transactions by using SOL.
15
3.1 Abstract structure
SOL consists of four layers - Boolean, Sequential, Transaction, and Coverage layer - which cut the language along the axis of functionality.
(1) Boolean layer is used to build expressions which are used by the other layers.
Boolean expressions are evaluated over a single state transition.
(2) Sequential layer is used to describe basic sequences. Sequential expressions are evaluated over a specific sequence of state transitions.
(3) Transaction layer is used to define sequences as transactions (named sequences) by using the assignment operator.
(4) Coverage layer is used to specify interesting transactions for coverage measurement.
3.2 Syntax conventions
The formal syntax described in this work uses the following extended Backus-Naur Form (BNF).
(1) The initial character of each word in a nonterminal is capitalized. A nonterminal can be either a single word or multiple words separated by underscores. When a multiple-word nonterminal containing underscores is referred within the text, the underscores are replaced with spaces. For example,
Boolean_Expression Indicates a Boolean Expression.
16
(2) Boldface words are used to denote reserved keywords, operators, and punctuation marks as a required part of the syntax. These words appear in a larger font for
distinction. For example,
“Condition”
(3) The ::= operator separates the two parts of a BNF syntax definition. The syntax category appears to the left of this operator and the syntax description appears to the
right of the operator. For example,
Condition ::= Boolean_Expression
(4) A vertical bar separates alternative items (use one only) unless it appears in boldface, in which case it stands for itself. For example,
SERE ::= State | Sequence | Sequence_Name
(5) Square brackets enclose optional items unless they appear in boldface. In which case they stand for themselves. For example,
State ::= State [“Condition”]
Indicates “Condition” is an optional syntax item for State.
(6) Braces enclose a repeated item unless they appear in boldface, in which case they stand for themselves. A repeated item may appear zero or more times. For example, Sequence_Set ::= < {Sequence_Name} { ,{Sequence_Name} } >
Indicates {Sequence_Name} may appear more than one time.
(7) A comment is preceded by a colon unless it appears in boldface, in which case it stands for itself.
17
The detailed syntax of SOL is introduced below (shown in shaded area). The FSM shown in Figure 6 is taken as an example to introduce the operators in SOL.
Figure 6. An example FSM.
3.3 Boolean layer
Since a transaction can be defined as a specific sequence of state transitions within the spec. FSM, States are used as basic elements in Boolean layer.
3.3.1 Extra signal qualification ( “ ” )
In order to keep the spec. FSM as simple as possible, extra signals can be included in additional to the states while defining a transaction. The Boolean expression built from the extra signals should be enclosed in double quotes, shown in Box 1.
State ::=
State [
“
Condition”
]Condition ::=
Boolean_Expression : An expression that yields a logical value
Box 1. Extra signal qualification.
18
Example 1.
In Figure 6(b), the extra signal V must be checked to be true when moving from S1 to the next state.
S1 “ V==1 ”
3.4 Sequential layer
State Extended Regular Expressions (SEREs), shown in Box 2, describe single-cycle or multi-cycle behavior built from a series of States.
SERE ::=
State
| Sequence
| Sequence_Name
Sequence ::=
{
SERE}
Box 2. SEREs and Sequences.
3.4.1 Concatenation ( ; )
The concatenation operator, shown in Box 3, constructs a SERE that is the concatenation of two other SEREs.
SERE ::=
SERE
;
SEREBox 3. Concatenation operator.
19
Example 2.
In Figure 6(a), T1 is a transaction with the state transitions that starts from S1, then
moves through S3, S4, and ends at S1.
T1 : S1 Æ S3 Æ S4 Æ S1 T1 = { S1 ; S3 ; S4 ; S1 };
The sequence can be defined as a transaction by using the assignment operator which is detailed described in Section 3.5 Transaction layer.
Example 3.
In Figure 6(b),T2 is another transaction with the same state transitions sequence as T1 while the extra signal V must be true when moving from S1 to S3.
T2 : S1
⎯
V⎯ →
==⎯
1 S3 Æ S4 Æ S1 T2 = { S1 “V == 1” ; S3 ; S4 ; S1 };
3.4.2 Repetition ( [ ] )
The repetition operators are used to describe succinctly repeated concatenations of a sequence. There are three types of repetition operators: consecutive repetition ( [* ] ), non-consecutive repetition ( [= ] ), and goto repetition ( [Æ ] ). Each is introduced below.
20
(a) consecutive repetition ( [* ] )
The consecutive repetition operator, shown in Box 4, constructs repeated concatenation of the same State or Sequence.
SERE ::=
A repeats any number of times (including 0 time) A[+] = A[*1:] A repeats at least one time
21
Example 4.
In Figure 6(a), T3 is a transaction with the state transitions that starts from S1, moves to S2, and stays at S2 for three consecutive cycles, then ends at S1.
T3 : S1 Æ S2 Æ S2 Æ S2 Æ S1 T3 = { S1 ; S2 ; S2 ; S2 ; S1 };
T3 can also be defined by using the consecutive repetition operator.
T3 = { S1 ; S2[*3] ; S1 };
Example 5.
In Figure 6(a), T4 is a transaction with the state transitions that starts from S1, moves to S2, and stays at S2 for one to five consecutive cycles, then ends at S1.
T4 : S1 Æ S2 (1~5 cycles) Æ S1 T4 = { S1 ; S2[*1:5] ; S1 };
Example 6.
In Figure 6(a), T5 is a transaction with the state transitions that starts from S1, moves to S2, and stays at S2 for any consecutive cycles (including zero cycle).
T5 : S1 Æ S2 (Any number of cycle)
T5 = { S1 ; S2[*] };
22
(b) non-consecutive repetition ( [= ] )
The non-consecutive repetition operator, shown in Box 5, constructs repeated (possibly non-consecutive) concatenation of a State.
SERE ::=
A[=:] = A[=0:inf] A occurs any number of times (including 0 time)
Example 7.
In Figure 6(a), T6 is a transaction with the state transitions that starts from S1, and then visits S2 three times. The visits of S2 need not to be in consecutive cycles. In addition, T6 holds after the 3rd S2 is visited and still holds before the 4th S2 appears.
23
T6 : S1 Æ…Æ S2 Æ…Æ S2 Æ…Æ S2 Æ…
T6 = { S1 ; S2[=3] };
If the transactions below occur during simulation, T6 matches from the state S1 to the state before the 4th S2 happened.
(c) goto repetition ( [Æ ] )
The goto repetition operator, shown in Box 6, constructs repeated (possibly non-consecutive) concatenation of a State, such that it holds on the last cycle of the sequence.
24
Informal semantics: (1 ≦ n ≦ m)
A[Æn] A occurs n times
A[Æn:m] A occurs between n to m times
A[Æ:m] = A[Æ1:m] A occurs at most m times (excluding 0 time) A[Æn:inf] = A[Æn:] A occurs at least n times
A[Æ1:inf] = A[Æ:] A occurs one or more times A[Æ] = A[Æ1] A occurs exactly one time
Example 8.
In Figure 6(a), similar to T6, T7 is also a transaction with the state transitions starts from S1, then moves to S2 three times (can be non-consecutive). In addition, T7 holds only at
the cycle in which the 3rdS2 is visited.
T7 : S1Æ…Æ S2 Æ…Æ S2 Æ…Æ S2
T7 = { S1 ; S2[Æ3] };
Under the same condition during simulation as that in Example 7, T7 matches from the state S1 to the 3rd S2 exactly.
S1ÆS2ÆS2ÆS2ÆS1ÆS3ÆS4ÆS1ÆS2
S1ÆS2ÆS1ÆS2ÆS1ÆS2ÆS1ÆS2 S1ÆS3ÆS4ÆS1ÆS2ÆS2ÆS2ÆS2
S1ÆS3ÆS4ÆS1ÆS2ÆS2ÆS1ÆS3ÆS4ÆS1ÆS2ÆS2
25
3.4.3 Sequence AND ( && )
The transaction comprising two sequences using the sequence AND operator, shown in Box 7, holds only if both sequences hold and complete at the same cycle.
SERE ::=
Sequence
&&
SequenceSequence ::=
{
SERE}
Box 7. Sequence AND operator.
Example 9.
In Figure 6(a), similar to T7, T8 is also a transaction with the state transitions starts from S1, and then visit S2 three times (can be non-consecutive). However, S3 is strictly not
allowed showing up in the sequence T7.
T8 : S1 Æ…(!S3) Æ S2 Æ…(!S3) Æ S2 Æ…(!S3) Æ S2 T8 = { S1 ; {S3[=0]} && {S2[Æ3]} };
Under the same simulation condition as that in Example 8, T8 not only matches to the 3rd S2 exactly but the state S3 occurs zero time within the matched duration.
S1ÆS2ÆS2ÆS2ÆS1ÆS3ÆS4ÆS1ÆS2
S1ÆS2ÆS1ÆS2ÆS1ÆS2ÆS1ÆS2 S1ÆS3ÆS4ÆS1ÆS2ÆS2ÆS2ÆS2
S1ÆS3ÆS4ÆS1ÆS2ÆS2ÆS1ÆS3ÆS4ÆS1ÆS2ÆS2
26
3.4.4 Sequence OR ( | )
The transaction comprising two sequences using the sequence OR operator, shown in Box 8, holds if one of two alternative sequences holds.
SERE ::=
Sequence
|
SequenceSequence ::=
{
SERE}
Box 8. Sequence OR operator.
Example 10.
In Figure 6(a), T9 is either one of the following two sequences,
T9 : S1 Æ S3 Æ S4 Æ S1 S1 Æ S2 Æ S2 Æ S2 Æ S1
T9 = { {S1;S3;S4;S1} | {S1;S2[*3];S1} };
Note that above two sequences are previously defined as T1 and T3. Hence, T9 can also be defined in terms of these named sequences.
T9 = { {T1} | {T3} };
Under the same simulation condition as before, T9 matches sequence T1 or T3.
S1ÆS2ÆS2ÆS2ÆS1ÆS3ÆS4ÆS1ÆS2
S1ÆS2ÆS1ÆS2ÆS1ÆS2ÆS1ÆS2 S1ÆS3ÆS4ÆS1ÆS2ÆS2ÆS2ÆS2
S1ÆS3ÆS4ÆS1ÆS2ÆS2ÆS1ÆS3ÆS4ÆS1ÆS2ÆS2
27
3.4.5 Sequence fusion ( : )
Similar to the concatenation operator, the sequence fusion operator, shown in Box 9, concatenates two sequences overlapping by one cycle. In other words, the 2nd sequence starts at the cycle in which the 1st sequence completes. This operator is used to concatenate two consecutive transactions.
SERE ::=
Sequence
:
SequenceSequence ::=
{
SERE}
Box 9. Sequence fusion operator.
Example 11.
In Figure 6(a), T10 is a transaction shown below,
T10 : S1ÆS3ÆS4ÆS1ÆS2ÆS2ÆS2ÆS1 T10 = { S1;S3;S4;S1;S2[*3];S1 };
T10 can also be treated as two sequences that overlap each other for one cycle:
T10 : S1ÆS3ÆS4ÆS1 : S1ÆS2ÆS2ÆS2ÆS1 T10 = { {S1;S3;S4;S1} : {S1;S2[*3];S1} };
Again, T10 can also be defined in terms of T1 and T3.
T10 = { {T1} : {T3} };
28
3.5 Transaction layer
A sequence can be defined once as a named sequence (transaction) and then be reused later. The assignment operator, shown in Box 10, is used to declare a named sequence. The left-hand side of the assignment operator becomes a synonym for the sequence on the right-hand side. The sequence names must be enclosed in braces when referred. This operator is extensively used in the previous examples.
Transaction_Declaration ::=
Sequence_Name
=
Sequence;
Box 10. Transaction declaration.
3.6 Coverage layer
The interesting transactions for coverage measurement, shown in Box 11, can be defined by the previously declared sequence names or generated by the sequence set cross operator.
Coverage_Declaration ::=
Sequence_Name
;
| Sequence_Cross
;
Box 11. Coverage declaration.
29
3.6.1 Sequence set cross ( ** )
A sequence set comprises one or more sequences. Sequences are enclosed in angle bracket and separated by commas. A sequence set cross operator, shown in Box 12, is used to represent a set of back-to-back consecutive transactions with cross behavior.
Sequence_Cross ::=
Sequence_Set
**
Sequence_Set {**
Sequence_Set } Sequence_Set ::=< {
Sequence_Name}
{,{
Sequence_Name}
}>
Box 12. Sequence set cross operator.
Example 12.
Assume the transactions with the following cross behavior are interesting.
These 6 transactions can be defined by the previously introduced operator:
{{T1}:{T3}}; {{T1}:{T4}}; {{T1}:{T5}};
{{T2}:{T3}}; {{T2}:{T4}}; {{T2}:{T5}};
These transactions can also be defined by using the sequence set cross operator.
The transaction T1 and T2 can form a sequence set, and the transaction T3, T4, and T5 can form another. Then these 6 transactions can be defined as follows,
<{T1},{T2}> ** <{T3},{T4},{T5}>;
T3 T1
T2 T5 T4
30
This means each sequence in the first sequence set must be followed by each sequence in the next sequence set, respectively.
Example 13.
The sequence set cross operator can also work on more than two sequence sets.
<{T1},{T2}> ** <{T3},{T4}> ** <{T9},{T10}>;
For this expression, 8 (2*2*2) transactions are generated for coverage measurement.
That is,
{{T1}:{T3}:{T9}}; {{T1}:{T3}:{T10}}; {{T1}:{T4}:{T9}}; {{T1}:{T4}:{T10}};
{{T2}:{T3}:{T9}}; {{T2}:{T3}:{T10}}; {{T2}:{T4}:{T9}}; {{T2}:{T4}:{T10}};
The sequence set cross operator can provide a much more elegant but equivalent representations while the transactions become complex. This operator can reduce the transaction description complexity as well as help generate more interesting transactions easily.
3.7 Case study
To apply our methodology, the interface protocol should be given as a spec. FSM first. The details about how to construct a spec. FSM can be found in [12-13]. The AMBA AHB slave interface protocol [18] is adopted as an example here to demonstrate how to define transactions in SOL. The spec. FSM of the simplified AMBA AHB slave protocol is given in Figure 7.
31
Figure 7. The spec. FSM of the simplified AMBA AHB slave protocol.
In this spec. FSM, only several important control signals (HSEL, HTRANS, HREADY, and HRESP) are concerned. Besides, one special state is defined: DUV_ERR.
If the DUV behaves illegally, the design moves to the state DUV_ERR. Otherwise, the design moves among the other normal states excluding DUV_ERR. By traversing the spec. FSM, many defined properties can be found. For example, in the state IDLE/BUSY, if HREADY is not asserted or HRESP is not set to OKAY, the design moves to the state DUV_ERR. This infers that a slave cannot respond anything but a zero WAIT state OKAY response to an IDLE or a BUSY transfer. In addition, in the state WAIT, if HREADY is asserted but HRESP is not set to OKAY, the design moves to the state DUV_ERR. This implies that a slave can only respond OKAY when HREADY is transient to be asserted. These are explicitly defined in the AMBA AHB specification.
32
However, the spec. FSM is not omnipotent for the lack of consideration to each signal. For example, the read transactions cannot be distinguished from the write transactions. The burst mode of each transaction cannot be detected, either. To retrieve these issues, the extra signal qualification operation should be applied.
Now, use SOL to define basic transactions on the spec. FSM.
Example 1.
Example 1.