Figure 9.1 Local Variables - Basics
Local variables are functions that you may use frequently. They can be used in sequences and properties. They are called local because they are indeed local to a sequence and are not visible or available to other sequences or properties. Of course, there are workarounds for this limitation, which we will investigate further in this chapter. Figure 9.1 points out the key elements of local variants. The most important and useful aspect of a local variable is that it allows multi-threaded applications and creates a new copy of the local variable for each sequence instance that uses it. The user does not need to worry about creating copies of local variables each time the sequence is called. The application above says that as long as RdWr is sampled high at posedge clk, then rData will be compared to wData after 5 clocks. This example shows how to implement this specification. In clk posedge the local variable int local_data will store rData and then compare it to wData after 5 clocks. Note that RdWr can be sampled to true every posedge clock. The sequence data_check will go in every clock; a new copy of local_data is created, and a new thread is created which will check local_data+'hff with wData after 5 clocks. Figure 9.2 shows additional semantics for local variables. Pay close attention to the rule that local variables must be attached to expressions, and comparisons cannot!
Figure 9.2 Local Variables - Dos and Donts
As shown in Figure 9.2, when storing a value, a local variable must be attached to the expression. However, when comparing values stored in local variables, it cannot be attached to an expression.
In the top example, local_data = rData is appended to the sequence rdC. In other words, the assignment "local_data = rData" will only happen when the sequence rdC is complete. Continuing the story of storing this value into a local variable, what if there is nothing attached to the local variable when the value is stored? Use 1'b1 (always true) as the expression. This means that whenever a sequence is entered, the expression is always true and the value should be stored in a local variable. Simple!
Likewise, what if the value on your comparison expression is true? You can do this by separating the expressions as shown in Figure 9.2. The resulting sequence (the last sequence in Figure 9.2) would be understood as "go to dataCheck, store rData into local_data, wait 5 clocks, then if b (sequence rdC) is true within 5 clocks, compare wData with Stored local_data + h'ff comparison".
Figure 9.3 Local variables - and formal parameters
Figure 9.3 points out some other important features. First, there are no restrictions on using local variables in sequences or properties. Also, you cannot declare a local variable as a formal parameter and pass it as the actual value in another sequence/property. This makes sense, otherwise why would it be called local?
Figure 9.4 Local Variables - Visibility
In Figure 9.4, we see that a local variable in a sequence is invisible to the sequence that instantiated it. The solution is very simple. Don't use the local variable directly, just pass the parameter to the sequence containing the local variable. When the sequence L_seq updates the parameters locally, it will be visible to the calling sequence (H_seq). Note that Ldata is not declared as a local variable in the sequence L_seq (otherwise this would be a bug of our discussion). L_seq just updates a formal parameter and passes it to the calling sequence, which is actually declared as a local variable. This is shown at the bottom of Figures 9.4, 9.5.
Figures 9.6, 9.7, 9.8, 9.9, 9.10, 9.11, 9.12 show finer rules. Use them as a reference when you start writing complex assertions. The notes in the figure explain the situation.
Figure 9.5 Local variable compound sequence with 'OR'
Figure 9.6 Local variables - used to OR allocate local data - before compound sequences
Figure 9.6 describes the semantics of controlling local variables when used in the 'OR' of two sequences. Local variables must be assigned in a sequence of ORs. But what if you can't do it? Several solutions are provided in Figure 9.7.
Figure 9.7 Local variables - assigning local data in two sequences of OR
Figure 9.9 describes the semantics of managing an 'and' two sequences. In contrast to one or two sequences, a local variable cannot be attached to the two sequences involved in 'and'. The first solution is the same as 'or'. Local variables are allocated outside of the two sequences as shown. Alternatively, just assign the local variable in one of the two sequences, which is an obvious solution. In addition to solution #1 in figure 9.8, figure 9.9 also shows solution #2.
Figure 9.8 Local Variables - 'and' Compound Sequence
Figure 9.9 Local variables - more subtle nuances III
Figure 9.10 Local Variables - Further Nuances IV
Figure 9.10 describes more rules for controlling local variables. First, you can assign multiple local variables to an expression. Second, you can also manipulate the specified local data in the same order (as in the case of ldata2). But as before, there are differences in allocating (storing) local variables and comparing their stored values. You cannot compare multiple local variable values in a single expression in a sequence, as is the case in the line (//wData == ldata1, wretryData == !ldata2). This is illegal. Of course, there is always a solution, as shown. Simply compare multiple values in two subsequences with no delay in between. The 'Solution' annotation in the figure illustrates this.
Figure 9.11 Local variables cannot be used in deferred scope
Figure 9.11 shows that you cannot use local variables in scope operators. However, it's not a local variable fault. This is the fact that we cannot have variable delays in #m or #[m:n] delay operators. From a software perspective, the delay range operator needs to be known at elaboration. So they can't be variables? From a hardware perspective, this is a bummer!
Figure 9.12 shows that you cannot define local variables with formal parameters. Likewise, the declared size of a vector (bus) can only be a constant. Again, this has a software reason and a hardware reason. I'll leave it to the readers to guess what I think!
Figure 9.12 Local variables - cannot use formal parameters to determine the size of a defined variable
9.1 Application: Local Variables
Figure 9.13 Local Variables - Application
The application in Figure 9.13 breaks down as follows.
($rose(read),localID=readID
On $rose(read), readID is stored in localID.
not (($rose(read) && readID==localID) [*1:$])
Then, we check if another read has occurred ($rose(read)) with the same readID as the one we previously stored in localID. We keep checking continuously until ##0 ($rose(readAck) && readAckID == localID).
If the consecutive checks did result in a match, then that means we got another $rose(read) with the same readID as the previous read. This violates the specification. That's why we take the negation of this expression (not) to see that it checks for an error in the match and the property ends.
If successive checks before ##0 ($rose(readAck) && readAckID == localID) arrives that do not result in a match, then we do get a readAck with the same readAckID that issued the original read. This property will pass.
In short, we have shown that once a 'read' is initiated, another 'read' from the same readID cannot be reissued until a 'readAck' of the same ID returns.