11.1 .ended
Figure 11.1 .ended - Endpoint of a sequence
Before we learn how .ended works, let's take a look at what's changed in the IEEE 1800-2009 standard.
The 2009 standard dropped .ended and replaced it with .triggered. In other words, .triggered has the same meaning as .ended, only .triggered can be used where .ended is used and where .triggered is allowed where previous versions allowed. In other words, .triggered can be used in sequences, in program blocks, and in level-sensitive 'wait' statements.
From 1800-2009LRM:
IEEE Std 1800-2005 17.7.3 starts and needs to be used. The ending .ended method in sequence expressions and the .triggered sequence method in other contexts . Since the two constructs have the same meaning, but have mutually exclusive usage contexts, in this version of the standard, the .triggered method is allowed in sequential expressions, and the usage of .ended is deprecated and will not appear in Standard for this version.
I'll still go ahead and explain how .ended works in case you didn't switch to 1800-2009.
ok, go on...ended...
If you're primarily interested in the end of the sequence, regardless of when it started, .ended is what you need. The main advantage of the method of detecting the end of the sequence is that it does not require knowledge of the beginning of the sequence. All you care about is when a sequence ends.
Figure 11.1 shows this behavior. A sequence 'branch' is the complete sequence of branch completions. It can start anytime. The attribute endCycle ensures that the 'branch' sequence does end when the endBranch flag goes high. In other words, the branch must end whenever $rose(endBranch) is detected as true at the next clock. This is indeed a very powerful and useful feature. This makes assertions also intuitive.
However, if you simply write the assertion at the end of "branch", see endBranch going high in ''branch(a,b,c,d)|=>$rose(endBranch)''. What's wrong with that? So what if $rose(endBranch) goes high while the "branch" is still executing? $rose(endBranch) will be ignored until the end of the sequence "branch". The .ended operator understands this. This property will fail if endBranch goes high while the sequence "branch" is still executing. This is because endCycle expects 'branch' to end when endBranch goes higher. Since endBranch may go high prematurely, the property will fail to see that the 'branch' sequence in $rose(endBranch) has not ended. Look-ahead properties don't capture this. This is a very important point. Please note it down.
Also note that the clocks in the source and destination sequences must be the same. But what if you want the source and destination clocks to be different? That's what '.matched' does, which will be discussed shortly.
Figure 11.2 explains further nuances.
Figure 11.2 .ended and the overlapping implication operator
In this example, $rose(c) means that the sequence aRb must end. The key point to note here is that implication operators are overlapping. This means that the sequence aRb should end when $rose(c) occurs on the same clock. As shown in Figure 11.2, when $rose(c) is true, at the same clock $rose(b) must occur and the previous clock $fell(a).
Figure 11.3 depicts the same example, but with non-overlapping operators.
Figure 11.3 .ended and the non-overlapping implication operator
You have to understand this very carefully, it's as simple as it seems. The non-overlapping implication operator states that when $rose(c) is true, at the next clock, the sequence aRb must end. Therefore, as shown, the property $rose(c) finds the end of aRb after one clock is established. This is intuitive, but easily misunderstood.
11.2.matched
Figure 11.4 .matched-basic
The main difference between .ended and .matched is that .ended requires the source and destination sequences to have the same clock. .matched allows you to have different clocks in the source and destination sequences.
Since the clocks can be different, understanding the matching can get a little complicated. But it follows the same rules as multiclock properties. As shown in Figure 11.4, the sequence 'e1' uses 'clk' as the clock, while the sequence 'e2' uses 'sysclk' as the clock. Sequence 'e2' means after 'reset'; 1 clock later; 'inst' must be true, and after 1 clock, sequence 'e1' must match (i.e. end) at least once, and after 1 more clock, branch_back Must be true. This is a very interesting way to insert a .matched (or .ended ) into a sequence. The sequence 'e1' runs by itself. What we really care about is that it matches (ends) where we expect it to. Let's look at some examples that will make this concept clear.
Figure 11.5 .matched - non-overlapping operators
Figure 11.5 shows that on the rising edge of 'c' we want to see aRb sequence match. Let's look at the timing diagram. When $rose(c) is true at posedge of clk1 (clk1=3), it looks for the end of the sequence 'aRb'. The sequence 'aRb' starts during clk=3 and ends at clk=4. Note that the end of 'aRb' (i.e. the match of $rose(bRose)) is right after the next 'clk' edge after the clk1 edge. This is what the property requires "@(posedgeclk1) $rose(c)|=>@(posedgeclk) aRb(a,b).matched;"
Figure 11.6 .matched-overlap operator
Figure 11.6 Using the overlapping implication operator and the same (in-phase) clock (the clocks must be the same because we use the overlapping implication operator). So when $rose(c) is true, it looks for the next (poseddge clk) that overlaps with it (posedge clk). But the next one (posedgeclk) is apparently 1 hour later. So, 1 clock after $rose(c), the sequence sees aRb match (ie .ended).
11.2.1 Application: .matched
Figure 11.7 .matched-application
In Figure 11.7, the sequence 'RdS' uses Busclk, and the attribute checkP uses sysclk. @(negedge sysclk) RdS.matched means that on the falling edge of sysclk, the sequence RdS (running from Busclk) must end. 'RdS' may finish slightly earlier than the nedgege sysclk (ie, when the previous posedge of the Busclk will arrive). It doesn't matter because we are transitioning from Busclk to sysclk (as long as the sequence RdS is done on the previous posedge Busclk).