Hello and welcome to lecture number two. In this lecture, we will discuss the methodology that you need to apply to plug in functional coverage into your overall design verification methodology. There are three components that you need to be aware of in order for you to make sure that you have verified everything. One is the system where a lot of such as keyword called cover. Second is the cover group and cover points of the functional coverage. And the third is the core coverage.

Let me go a little bit into detail of each of these three components. So under system or log umbrella, as I described in the first lecture, you have to select assertions as a sub language in your functional coverage as another sub language. Under system or log assertions you have assert a keyword that basically measures or verifies a given temporal condition to see that it holds. At the same time unnecessarily log assertions there is a keyboard called cover. So, not only that you have verified that the property holds, you also make sure that the property has been covered. So, for all the low level temporal domain conditions you need to use the cover photo system or log assertions.

And the second part of coverage is using the cover group and cover point features or functional coverage, which is the gist of this course and we will go into plenty of detail on what cover groups are, what cover points are, etc. And lastly, code coverage. Now code coverage as I described earlier is a structural coverage. It does not really tell you if you are very far the intent of the design, which is okay. For example, code coverage will still go ahead and tell you if you have exercised all the branches offered if then else condition, or have you verified all the case statements of case logic. So even though it doesn't tell you about the intent of the design, it is still very useful.

So again, in order for you to make sure that you have an objective measure of the coverage of your design, you need to use a system or local sessions cover cover group and PowerPoints and bins or functional coverage, sub language and also the code coverage. Only when you have done this that you can answer the question that your management for example keeps asking can be free is the logic. So let me go through a couple of slides on the methodology guidelines that you need to keep in mind. So start with the test plan, which is obviously based on the functions that you want to test and cover. So basically create a functional cover matrix that includes each of the points functions and ratio the function I mean the control functions and data functions or control path, functions and data by functions. So, identify in this matrix all your functional cover groups and cover points, which again we will see in detail and measure the coverage as verification progresses.

You do not measure your coverage at the end of the project, you continually measure it. And you may even automate updating the matrix your coverage matrix directly from the coverage reports and I will explain that to you in a couple of slides. I have I will show you a methodology on how you can automatically update the matrix directly from your coverage reports. But also know that some of the new popular simulators do this for you making your life a lot easier and automatically measure the effectiveness of your tests. From the coverage reports, so for example, let's say you have written tests that continually access mostly the 32 byte granules, then your coverage for byte word core word etc will be low, if not covered at all. So, when you look at the coverage report change or add new tests to hit those parts of the data path which have not been covered or for example, this is very important by the way in order to find critical bugs, you have cycles that access by followed by quad word followed by multiple code words.

This is what I call transition coverage and the functional coverage language allows you to do that, unless and until you cover such transitions you do not know if you have found all your critical bugs. There is also something called cross coverage. So, for example, you have data error in progress You're servicing a data error in your second level cache. For example, at the same time in another cache line, a tag error occurs, for example, you're reading the data for for a given cache line. And now you're trying to access another cache line which has a tag error. What happens?

How will your design react when both data error and diagonal PR simultaneously and so that's what you need to figure out using the cross coverage of the language. Some more methodology guidelines, I just explained how the system assertions cover, you can use to go the temporal domain assertions, and throughout the design give heading counterpoint for critical functional paths. For example, a right to enter is followed by a read from the same address and that this happens from let's say, a to processor one unified ltk That you make sure that the both processors issues such right and read combinations at the same time. Now, unless and until you write a test to cover something like this, you will not find critical bugs in your functional coverage plan should include cover points for such conditions. And lastly, always remember to operator function cover cover plan just because you created a plan in the beginning it does not mean that you basically covered everything as you gain more knowledge of your design, you will come across conditions which he was say that hey I need to cover this also took keep your coverage plan live and continuously keep adding cover points.

Now, I will explain to you what I just said how to automate your coverage table so to say So let me explain this is just but one methodology. And luckily some of the new popular simulators have looked at certain methodologies and are beginning to provide you with tools that does the same thing. So on the left hand side, you have assertions and, and you have functional coverage we won't go into I won't go into the detail of assertions because that's not part of this course. But basically in the assertions you when you assert a property, you give it a label. Similarly, when you write functional coverage, cover groups, cover points, etc. You have name of the cover group, and you have the variables for which your writing cover points, so they have the names too.

Now, what you do is when you write the assertions, you also create something what I call properties table. And in this properties table, you use the same label that you use for the property. Okay, and then you see with the help of the cover keyword from the outset, You can figure out whether that particular assertion was covered or not. Similarly, in the functional coverage when you create a functional coverage code, so to say, you also create a coverage table. And again, in this coverage table, you can associate the same names that you use in your functional coverage code. So cover groupies, PCI commands and power points are PCI requirements and PCI requirements.

Once you have created these tables, and the assertions and functional coverage, you then simulate your design. All the simulators create something called a coverage database. Now you can write your own API or use an API provided by the simulator or you can write a script for that matter. You go through the scan through the coverage database and automatically update your coverage table. So for example, the coverage database says PCI commands. gov group have been covered and the PCI recommends have been covered to or not covered, you go ahead and update this coverage table and then you will know right away right after the simulation, you know, have your coverage, coverage is progressing and you will take actions based on that as I will show you the next slide.

So, again, this kind of methodology is very important you do not want to manually look at the coverage reports, after every simulation, it will be a drag on your project schedule. So, try to automate it or use a simulator provide a methodology or tool to achieve such automation. So, here's what I call a very high level methodology. All this time before system or functional coverage language was available. What we normally did was the the DB team that design verification They will look at the specs create the test plan and the test match, the design team will look at the same specs and start RTL coding. And then they will go ahead and simulate and debug.

What you now need to do. Very importantly is that from the spec, you also create your SBA cover properties and the functional coverage cover groups, you need to create this plan, right when you are beginning to write your test when for example, and now you simulate it as well with the design. And as I just showed you in the previous slide, you update your coverage plan automatically if possible. And then you see if the coverage is complete or not. If the coverage is not complete, then what it means is you need to enhance your design verification logic basically your test bench and everything, all your reference models and everything you need to update and make sure that those are conditions which have not been covered. You're going to cover them in the next round.

Similarly, on the other side, if there are bugs, you go ahead and debug your design. And finally, if the coverage is complete, and if there are no bugs, that's when you say, Hey, we can freeze the logic, music to management years, and then we can decide whether we are going to tap out the chip or not. So this is a very simple, but very effective methodology that you can deploy in your project. One of the bugs, what do I mean by that? One of the most important thing you need to make sure in your methodology is when do you start the coverage? What do I mean by that?

So during the initial stages of verification, more support and functional coverage will be low, because you just have basic tests that you're running and you have not achieved the optimal code in functional coverage. Now remember that this code in functional coverage when you turn them on, it adds to the simulation overhead. So don't turn on this coverage at the very beginning of the project. And bear with me, you will see the reasons for this. But you may ask, okay, what do you mean by beginning of the project? How long does the beginning of the project last?

So that's where the bugs come into picture. What do you do is starting with the very beginning period of your project, create bug rate charts, see if the bugs are covered in a in a nice linear manner going up? Or are they just coming up with an exponential rise and then total low these will help you tremendously as you will see in the next few bullets. And as a side hint, your management would love this bug rate charts, also. So during the beginning time, your coverage will be low, but your burn rate should be high. Because all the low hanging fruit you have covered all the simple simple bugs will be caught very easily even with the basic tests.

So baud rate will be high. But now what's going to happen is as your project moves forward, your bug rate will start dropping. Why does it stop dropping? Because it may be that your existing test rate strategy is running out of steam. So whenever the bug rate starts dropping, the beginning has come to an end. So that's when you start coding functional coverage to determine if new tests and this happens very often, or simply banging on the same logic repeatedly.

You keep repeating the test and you keep exercising the same logic. And once the test start passing you think wow, I'm in good shape. Well Most likely you're not. And that's where the coverage comes into picture, you look at the coverage and you say, Yes, I'm not finding any bugs or the tests are passing, but look at my coverage is so low. So then you have to develop tests for the uncovered functionality. And this is a very important part of the methodology that you can effectively deploy in your project, create bug rate charts, and then follow the bugs.

So I guarantee you, huh, famous last words, I guarantee you that if you follow this methodology, your bug rate will indeed go up until the very end of the project when obviously it has to come down to zero. So that's all for this lecture. We have looked at the methodology components for deploying functional coverage in your project. Thanks a lot for your time, and I'll see you soon in the next lecture.