Hello and welcome to the course on system Verilog functional coverage. This is a comprehensive course which will guide you step by step through the language, methodology and applications. The main goal of this course is to help you achieve an objective measure of the functional coverage of your design and test match. This course has nine lectures. This is simply a copyright notice, telling you that the course has been copyrighted. A bit about myself.

My name is Ashok Mehta. I've been a CPU and SOC design and verification engineer for over 30 years. I have 13 patents issued on SOC and 3d ic design verification. And I also published a book on system Verilog assertions and functional coverage in 2014. It was published by Springer. So let's see how did this course help you?

The foremost gain from this course is that you will objectively be able to measure the functional coverage of your test image and design. There is no subjectivity here the language will help you make sure that you are functionally covered everything in your design. And in today's design verification landscape, this is a very important part of overall functional verification methodology. And I believe that all the verification engineers do need this knowledge to be successful. And it will also be a highlight of your resume, as most of the employers now require you to know function coverage fundamentals. This course as I said earlier, will not only provide you a step by step guide to the learning or the language, but also it will show you your real life applications to solidify your concepts.

Okay, let's first see how functional coverage fits under the overall IEEE 1800 standard system or log language, even though most people think that system Verilog is just but one language, there are indeed sub languages under this umbrella. So let's start with your duty your design under test, you need to provide the simulators, you need to check the response. And now even increasingly important, you have to know if you have covered everything in your design. In other words, you can also say, easier test bench comprehensive. If the test bench is not comprehensive, then your coverage will not be comprehensive. So in some sense, it's a measure of your test page also.

Now, under the system Verilog language, you have a complete set of features, which are like classes are also known as object oriented programming features. It is under this feature set that the universal verification methodology fits And also you have constrained random features. So those are what I call test which controls the other sub language as I call it is functional coverage language. We discover groups and cover points that we will soon see in other language. Know that the functional coverage language is orthogonal, meaning its syntax and semantics is different from the OP syntax and semantics constrained random syntax and also orthogonal to the system, such as language. In other words for you to learn functional coverage language, under system Verilog, you don't really need to know or P or the SBA.

Okay, the important thing that we need to understand during this introductory lecture is the difference between code coverage and functional coverage. code coverage, as you probably know is derived from directly from the design, it is not user specified. You simply give your RTL design to a given simulator, turn on the code coverage and you get the code coverage of things like branch expressions, state transitions, case statements, etc. In other words, that design structure has been covered not the intent. So, it does not evaluate the intent of the design, what is it that the design really wants to do? For example, let's say your end of specifying bus grant equal to bus request and idle or bank reset.

This is what you write in your RTL code. code coverage will go through and tell you if reset have been exercised idle have an exercise bus request has been exercised and thereby bus Grant has been exercised. He does not know whether this equation is correct or not. So if you Your intent was at bus grinding call the bus requests and idle and bank reset code coverage has no idea. That's our functional coverage comes into picture. So functional coverage is user specified.

You tell the simulator, this is the function this is the intent I want to cover. So, obviously is based on design spec, you read the design spec and you decide what is it that you want to cover functionally. So, it will give you an answer in an objective manner rather than guessing. Hey, can we tape out? This is probably the most important question you face during any SOC project. And just a couple of points on what kind of functional coverage for example control oriented coverage, have I exercise all possible protocols that the recycled supports, burst, non burst etc.

And there is also what I called Data oriented coverage, how are exercised the cache line at all granular levels, byte word, quad, quad word, etc. So this kind of control coverage and data oriented coverage is simply not possible with code coverage. And that's what functional coverage really comes into picture and you will see a lot more different types of control and data oriented coverage in coming lectures. So that's all folks for this introductory lecture. Thanks for attending. And I will soon see you in the next lecture.