Hello and welcome to lecture number six on transition coverage. This is one of the most useful features of functional coverage language. Note that not transaction level transitions are very important to cover, for example, the CPU issue or read followed by a write invalid, or did you issue a D cache miss followed by a D cache hit cycle. So transitions are where the bugs occur. And we want to make sure that we have indeed exercised such transitions. So let's dive deep into the syntax and semantics of the transition coverage.
Let's look at this example. Here I have two variables, ADR one and ADR two. I have declared a cover group called GC whose sampling point is at Paul's edge of clock. Inside the governing group I have two core points called point for ADR one variable and PowerPoint for add to our variable Now inside this PowerPoints, like we know, like we always have, I have declared bins, but these bins are to our transition coverage. So for example, beans a r1 states that if the value of ad r1 is 800, at this clock, at disposes of clock, because positive clock is a sampling edge. If the value of area one is 800, at this positive clock that the next positive clock it should be eight hex FF.
So, basically you have to make sure that your test bench creates a test that produces this transition. And that way we make sure that, for example, if you're writing to if you're reading from a cache line that the very next cycle should be, for example, right invalid. So this is just a very simple example of how you you can do Clara bins for transition. Similarly, here's the other core point add to it states that add to this variable here should go from one to zero on successive clock edges. Now here what I've done is, this is something interesting. I'm gonna cross of these two core points counterpoint AC and core point DC.
Each of this core point as we just discussed transition coverage in it. So how is this going to work? The way this cross of transition will work is you look at the very first value of each of the transition coverage point in each other core point which is 800. And one take B one. That means at this policy of law, if address one it has 00 and address two is one, Big B one. That the next block.
We should have address. One going great hex FF and address two going to zero which is what is explained here. So, this is an interesting way of crossing even the transitions. Okay, let's look at some more semantics of what kind of transitions Can you specify? Here again there is a variable called ATR one eight bit wide and I will go group GC pauses of clock inside this goal point for this ad r1. I have four different bins that I have declared.
The first bin says that ad r1 this particular address, one variable should go from one to two to three at successive pauses of clocks. And obviously, you can have as many transitions as you like in this kind of a sequence. The second one is a bins and again, as I have said before, These two brackets mean create as many beans required as you see on the right hand side. On the right hand side, we see one comma two, and the next clock three comma four. What this means is the transition there are four transitions that need to take place. And each of those four transition will be covered in a automatically generated bit.
So the four transitions are 123124223 and two to four. Why didn't you do so what we are basically saying is that your test bench should exercise that design such that we see these four transitions because that's where the bugs may be. And that these four transitions we must exercise that must be covered in this auto generated beds. Similarly, beans at RB five states that I just want to domain hex FF hex F for three consecutive blocks. Start three means three consecutive transitions that means address one should go from hex F, next clock hex F and next clock hex F. And in a similar manner at every six states that hex a should transition non consecutively. What that means is, at a given clock age, you may have address one equal to hex A, then after a few blocks later again it goes to x a, and after a few growth, it may again go to hex a, but these three non consecutive transitions must take place and nothing in between.
So your test bench again is to make sure that you create a certain for example, a cache read. And after a while, do another cache read and I'll provide you another cache raid. And these three for example, or five or 10 And number of cache reads is something you want to make sure that if you do continual, non consecutive cache reads that you are going to be able to find a bug. And here's the simulation log. We showed all the transitions. One of the good things about this particular simulator that I'm using, it clearly shows in the law, the number of transitions that are specified, and it will show you the coverage of it.
So 123, which is the first beans, then the four transitions of the second beans, then the consecutive transition, so the third one, and then the non consecutive of ADR basics, and they are all covered. Of course, the way I wrote the test which let's look at some more examples. This example I just want to make sure how to transition semantics actually word syntax and semantics. So in this government GC, we already saw a bins where the transitions are specified as one comma two, and three comma four. And these means 123124223 and two to four. But now look at this line.
Here I'm saying one followed by three, one followed by four, two followed by three, and two followed by four. These bins at before is not the same as the bins at RV three. Do not confuse do not specify transitions as an ADR before, if you want to have the transitions as specified in the address v3. So how does this work? Think of this particular line as such, put the three comma one into parenthesis, four comma two in the parenthesis and so on and so forth. If you put the pattern This is in the proper places, then you will know how the transitions of this line will look like.
And here they are in the simulation log, the way the transitions will look like 123 to 423 to four, first one, for example, and second 1123242224 and so on and so forth. So altogether there will be eight transitions. So again to make sure that if there's two lines, the the type of transitions that you should expect are totally different and they are not the same even though the first glance shows you that they are the same. Okay, let's go back to our PCI commands example that I've been carrying forward among different features. Again, that is the enum for the PCI commands. to crawl different types of PCI commands, and in the power probe, what we have done earlier is we created Bains for PCI raids, been for PCI rights and went for PCI miscellaneous.
What that means again is that in this Ben's create as many bins as required, and cover IO read memory count freight mem, read multiple and memory line. So, basically, make sure that when all the reads or the read commands or PCI, have been exercised, that all these beans should be considered covered. Similarly for right and similar, similarly for the miscellaneous cycles, but now, that is fine. But in all honesty when you are doing functional coverage, when you're testing your beauty, is the transitions where things can go wrong. For example, you go from IRA to IRA, right? Or you go from IRA to meme, right?
Or you go from memory to IO, right? these transitions is where you may have bugs. And we have to make sure that we have your test bench have exercise each of this transition. So that's what we are doing here. So I'm creating two more bins means read to write and beans, right to read. And here what I'm doing is I'm specifying all the recycles followed by all the right circles.
And just like what you saw in the previous slide, what this is going to do is is going to make sure that you have covered for example, I will read to it right. I will read to mem right, I already to confirm right, I will read to mem right invalid and then it will continue on with memory to IO right memory to memory right memory to concrete and memory to memory invalid, and so on and so forth. Only when all this options have been exercised by your test bench that these bins are to who will be considered covered. And, and again, as I said earlier that when your bug rate starts dropping when you're not finding new bugs is when you go back and look at your coverage report. And you may notice that a lot of different types of transitions have not been exercised. So transition in my mind is one of the most useful feature of functional coverage language.
That's all folks. This is a brief introduction to the transition coverage. Thanks for your time in attending the lecture and I will see you soon in the next lecture.