Course : Systemverilog Verification 6 : L8.1 : Classes & Coverage Simulation Regions

[00:00:02]welcome to the next session of this course system blog simulation regions and throughout all previous sessions you have learned about how any program or module or interface items in system vlog simulation will be evaluated so you know there are dedicated regions and dedicated functionalities for every region so you have seen in detail how every item in a module or in a program is being executed throughout all the previous lectures now the question is what about classes and functional coverages uh so while going through these three items you have also seen about assertions so you have seen about assertion execution will happen in concurrent the concurrent assertion execution will happen in observed regions so the remaining items are classes and functional coverage and in this session you are going to see where these items will get evaluated in in terms of simulation region so the first question in which region the class items will be executed so let me ask you a question back so how do you use a class in the db so assume that you are writing a large number of classes to model different interfaces driver monitor and to encapsulate everything into single class and finally you are going to instantiate all these classes in a module or if you are instantiating if you are creating objects of class in some other top hierarchy again you need to instantiate the top level class in in a module and therefore all the functions and tasks in the class are falling under the module scope and all what all rules are applicable for model will be applicable for those classes which are instantiating within a module so by default uh they will be executed in the active region set and if you are instantiating a class within the program block then by default um all these class items uh will be evaluated in the re um re-region set so note that in the class you have only two right two type of procedural uh blocks which are function syntax so the class functions and the class tasks will be executed in the active region set if they are instantiated in the module and in the same if the class is instantiated in ah class object is created and used in a program block then either class the task and function will be elevated in the re-region set and if there is functional coverage written in the class we will see in the next slide and let me ask you one more question here do we really need to use program block uh in class based test bench say for example your test punch is a uvm waste test bench or even if it is not uvm based it is a class-based test bench so in none of the large test benches used in the industry i have never seen any program blocks and why we don't need program blocks to synchronize our events in the simulation so the answer is if you code your program if you code your test very correctly and if you use clocking blocks you will get a very predictable output and inputs stimulus behavior so program blocks are not necessary to use in the test bench and the coding guideline will be to use cloaking blocks and for sampling signals which are coming into the tbs or which are input to the db use a clocking block with an input skew as harsh one step so for example if you have if you wanted to monitor something if you're writing a monitor class so while while in the monitor class you you need to use um a cloaking block so that will be written often in the interface class in the interface and while you write an interface you you say the cloaking block then input skew of first one step and always sample the signals with respect to that cloaking block in any of the classes in or any of the functional functional code in the test bench so by sampling all the signals with the hash fund step with in a clocking block you will be always you'll be always sampling them in a pre point region and in the same way if you wanted to drive something into the duty so if there is some output from the dispense to the duty so say for example if there is a driver class then always use a clocking block with an output skew of heart zero so as you have already seen when you're driving signals in the clocking block with a clocking block with output skewers r0 those will be updated in the re-nba region so thus you will be getting a very predictable output behavior and just by using both of these combinations for input and output or input and output to the test bench you will be able to achieve pretty predictable behavior in simulation and also remember don't use any of other fancy coding stuff like any other harsh delays in your in any of your program always use a clocking block without any other delays so uh the input skew need to be hard front step and output you need to be hard zero and this is true for most of the scenarios in verification and finally we will look at the functional coverage so you can write the functional coverage items the cover groups either in a module or net class so first we look at the module items so if you're writing a functional coverage item in a module without any clocking blocker without anything just plain functional coverage items from plain functional cover points then uh those will be sampled like any other any other module item so those will be symbol in the active region but if you are using a clocking block along with the functional coverage items say for example if you are sampling the functional coverage like cb dot variable then based on the input skew the sampling will be happening either in the preponderance or in in observed region so there is a slight difference in the behavior of clocking blocking in case of uh sampling with assembling for functional coverage so if the clocking blocks input squeeze um specifying a harsh front step so as always it will be assembled in the pre-point region but if the inputs q is given as just heart 0 note that this is input skew so if the input skew is heart 0 then that events that signals will be sampled in the observed region so this is a slight different behavior to all those behavior that we were explaining throughout this um course so if you told you wanted to specify uh you wanted to sample a functional coverage item uh using clogging blocks you need to give an input skew of heart zero though this remember this scenario the scenarios where you want to use this heart zero input squares will be very limited but remember that if you are using clocking blocks in functional coverage then harsh front step will be sampled in the pre-point region and r0 input skew will be sampled in the observed area and one more notable point about cover points is the stop function so there is an option in cover group specification where you can specify that it need to be strobed so that is specified by using type underscore option dot stop is equal to one so while writing cos group if you are specifying this option as one by default this option is zero but if i explicitly specifying this option as one then all sampling of for this cover point will be happening at the end of this time slot which is in the first pawn region so this is the behavior of functional coverage that is written in the module so by default those will be assembled in the active region if the if they are using uh cloaking blocks they will be appropriately sampled in these two regions and if in the curve group specification if you are using dollar stop the stop function uh stop option is set to one then they will be sampled in the postponed region and if they are written in a class and then the same set of rules that that is applicable for all the class items are applicable here as well based on whether they are called from a module or a program block so by default if you are calling from a module they will be sampled in the active region if there is no explicit cloaking block or something is used in the class and finally i would like to tell about a uvm tb and typically in in uvm based suspension you will be writing cover groups in within the agents or in the environments and let's see where those items would be getting sampled so you know that you will be uh sampling items in the interface in a modern uvm monitor and those will be converted into transactions and while sampling them you need to use a cloaking block with appropriate um input hash one step delay so those will be sampled with the sub values of the pre-pawn region and those transactions will be sent to the coverage items again using another functions therefore while sampling in the coverage items as the cow groups in the coverage class uh there's those the sampling will be happening with the values of the um pre-pawn region so this is the case of a uvm dash test bench value where you write your coverage items in class