UVM - Step by Step guide to learning UVM .

1. Introduction: Hello, everyone. Welcome to the System where Log UVM step by step course. This is the introduction chapter of the course. Before understanding the course objectives, let's try to step back and understanding the challenges facing the industry today. I think you've all heard of the moose law. The number of transistors on a microchip doubles every two years. What does this mean? The number of features that are there on a chip is linearly increasing year on year. There is a need for your design and your verification to keep up with the feature size. There are tools now which can basically synthesize your TL code to a transistor level code. The design productivity has kept up with the feature size. But the biggest difference you see is in terms of the verification productivity. The verification gap is lagging the most law. So there are only two ways that this can be addressed. Either add more verification engineers or improve the verification flow or the reusability. The acelar or the system Verilog body basically came up with the UVM methodology to address this verification gap. Coming to the course objectives, the course is focused on an example based learning. I'll be taking an example design and showing you how system log and UVM based concepts can be used on the design. At the end of this course, students should be able to understand and learn how to apply system log based UVM concepts on their projects. I have broken the course into two sets. One is the introduction set. This will help you gain knowledge on the language and the methodology history. I will also try to answer the question on why there is a need for UVM and what are the basic consciens of a UVM based test bench. The second part of the course is an example based learning of a system log based UM concept. I will take you through all the important concepts that are needed to build a usable system wi log environment. At the end of the course, students should be able to understand, learn, and apply system log based UM concepts on their projects. I've also provided a list of important resources at the end of the course to help you with your UVM journey. I would like to welcome you all on the course. You should be able to access the next part of the course through the Skillshare promotional premium membership. Thank you. 2. History and evolution: Hello, everyone. Welcome to the UVM methodology Series. This is the Chapter one of the series. Today we will talk about the history and evolution of UVM. From my experience, I see a lot of students and professionals struggling with UVM because the history of how the system Verilog language and the UVM methodology evolved is not clear. Today we will see the brief history of the different verification languages and how the methodologies evolved. So if you see the diagram here on the X axis, I have the ears and on the Y axis, I have the verification capabilities. This will give you a good picture on the evolution of the methodology. If you see early 2000, the verification was mainly done using traditional Verilog bench. But with growing design size, it became difficult to have traditional Verilog bench. Hence, there was a need for a new methodology. Vera or Specmen was the first verification language introduced in the market. This was quite successful, I think it is still used in a lot of companies today. System Mary log was introduced by acelera. Accelera is basically a standards body which combined the good practices from different languages. New constructs were added to the Verilog language to make it more powerful and easy for verification. With the introduction of system Mery log, there was a need for a new methodology. The traditional system Verilog test benches were not reusable and each EDA company started their own verification methodology and how the system log language needs to be used. VMM was introduced by synopsis. URM and ABM was introduced from cadence and mentor. Later, URN and ABM combined to form OVM. There was still a problem with reuse of methodology. As each methodology was vendor specific, the TB or BIP developed with any of these vendor specific methodologies were not reusable on a different simulator. Excel again started an initiative. They combined all the good practices from the different methodologies and UVM was introduced. This slide basically gives you a gist of what I discussed in the previous slide. If you see a Ospecman was introduced in early 2000 and became the first verification language to cater to verification needs. Verilog was enhanced with new constructs to make it more verification friendly and System Mog initiative was started by AxillarA. Then there was a need for methodologies. MM was introduced by synopsis. Cadence and mentor as a joint effort provided a common methodology called OVM. Then there was an unification of all verification methodologies to enable reuse of verification IP on different simulators. UVM was introduced by Excel in May 2010. So in May 2010, when the first version of the early adopter kit was released, it was based on OVM with callbacks and objection mechanism. The first version of UVM was released in March 2011 with configuration enhancements, runtime facing in built register package, which we'll discuss later. There was also an implementation of TLM and other sequence enhancements. UVM one dot one was released in June 2011 with some bu fixes. We can also see the ecosystem on the right. We have some of the major EDA companies supporting this methodology. We have cadnce, mentor, synopsis and other VIP providers which basically complete the release and ecosystem. This brings us to the end of Chapter one of the series. In the next series, we will see why there was a need for UVM and what are the components that constitute a UVM. Thank you. 3. What is UVM : Hello, everyone. Welcome to the UVM methodology series. This is the Chapter three of the series. In the previous chapter, we learned about the brief evolution of verification methodology and how UVM came into existence. We also learned why there is a need for UVM based verification methodology. Today we will learn what constitutes an UVM and what are the building blocks. So what you see in this diagram is the most essential building block of a UVM based verification environment. It is called the base class library. The UVM base class library provides all the building blocks you need to quickly develop well constructed reusable verification components and test environments. The advantages of using a UVM class based library include a robust set of built in features. The UVM base class library provides many features that are required for verification, including complete implementation of printing, copying, test faces, factory methods, and more. So if you see the diagram here, the UVM object is the most basic component in a UVM base class library. All the other components are basically derived from the UVM object. The UVM component forms the next level of hierarchy, and it incorporates all the necessary methods for copy, pack, print, et cetera. The UVM component also includes certain methods for pacing, which we will discuss later. All the components inside the UVM, like the driver, sequencer, monitor, agents, scoreboard are all derived from the UVM component. This basically uses the class based object oriented programming concepts to help in reuse of verification components. As we discussed in the last slide, each UVM component goes through the phase implementation. In this slide, we will try to understand what a UVM phase is. Once the run method is called, the UVM root component triggers and initiates the UVM phasing forces. The build phase executes in time zero. This basically builds all the testbench components. The next phase is the connect phase where all the testbench components are connected together, it makes all the TLM connections, assigns all the handles to the testPngsurces. Then we come to the run phase. The run phase is where the stimulus gets generated and simulation time advances. The build phase build and connect phase basically runs in time zero. The run phase is again, subdivided into different smaller phases in the new UVM implementation. We will not go to this, but it is basically different implementation on the pre reset phase, configure phase, pre main phase main phase, and pushed main phase. Then we come to some of the cleanup phases. The cleanup phase is used to extract results from the scoreboard, check whether the test case passes or fails based on some conditions. This may be, for example, if all packets sent from an ethernet master or received on an ethernet slave. In the last slide we discussed about the UVM phasing. In this slide, we are going to discuss another concept of UVM and what constitutes UVM. That is the factory. The factory basically is used in the build phase. Factory has two different types of override options. You can override any component in your environment using a type or using an instance. If you see the example here, you have an APB master driver that is being used. When you basically use this in your test pens, the APB usar driver gets replaced by APB new master driver. So all the components which are using the APB master driver type gets changed to the APB master driver type. This is really helpful in developing reusable agents. So in the last slide, we saw how type O ride works. In this slide, we are going to see how the instance Oride for a factory works. Here you have a monitor that you want to replace with a new type, but you don't want to replace all the components which are derived from APB master monitor. But you only want to replace a specific instance of the monitor. You basically go down the text page hierarchy and you say, I want to replace the APB monitor, which is of the type APB master monitor with a new type that is the APB new Master monitor. When this gets executed in the build phase, the testbench component the architecture of the testbench changes the pb dot monitor changes to the APB new Master monitor. Here is another concept of UVM that you need to be aware of. Here I use something called the configuration database. The configuration database is the central database, which is outside your verification environment. Here I am disabling the checks for the monitor in my environment. Unlike factory which needs to make change to the environment at a build phase, configuration database can change the settings at runtime. Anytime during the simulation, you can just disable the checks when you use the configured database. Here in the example, you're seeing that go through the environment hierarchy and all the monitors inside the environment has the hash checks field, you're turning off the hash checks. The monitor checking will be disabled in your environment. Here there are other UVM concepts like the objection mechanism, which is used to synchronize the testing activity and indicate when it is time to end the test. Then there is a register layer, which we are going to discuss in detail in a later section, and there is a TLM port Export communication, which is used to communicate between different components. In this chapter, we learned what are the basic constituents of a UVM. The three chapters form the introductory core set for the UVM. Don't be worried if you are not able to follow the concepts here, because in the next set we will take an actual example and see how each of these concepts are put to use. We will talk in detail on how to build an UVM test bench, UVM environment, a reusable UVM agent, a driver sequencer interaction, building a monitor with TLM ports. We'll also discuss about the register layer. In the end, I will also provide you with useful links that will help you in starting your own UVM journey. 4. Why UVM: Welcome to the UVM methodology series. This is the Chapter two of the series. The last chapter we discussed about the brief evolution of the verification methodology and how UVM came about into existence. Today we will learn why there is a need for UVM and the reason ACC verification industry is moving towards this approach. If you're a verification engineer or a verification specialist who develops test benches for your company, you would have heard about the three Cs that are important in verification. The first one is constraint, the second one is coverage, and the third one is check. UVM provides the framework for doing all the three Cs of verification. You can quantitatively measure completeness of your task. You can track your functional coverage, code coverage, assertion coverage using the UVM framework. Basically, the first point is it gives you the completeness for your verification. The second biggest point of UVM is the reusability. UVM has standard functions and interfaces defined, and it also has the TLM implementation. A verification IP built with UVM concept can be reused across simulator and across products. Let us come to the other two important points. The most essential building block of a UVM based verification environment is the base class library. The UVM base class library provides all the building blocks you need to quickly develop well constructed reusable verification components and test environments. This will help in basically increased efficiency. Increased efficiency means higher productivity and greater reuse across products. This slide is a simple example of a UVM based environment. What is that is needed to make a verification environment reusable? First is something like a plug and play feature. We need to have a consistent architecture for developing so that it can be reused. Assume you have three agents as shown in this example here. So the agent one can be from a VIP, provide one agent two can be from another vendor, and you can have your own in house VIP that is developed. When I'm integrating these into a SOC architecture, there's a need to have a consistent coding style. UVM forces this consistency in architecture and coding style, which helps in integration and verification at assoc level. The second point is segregation from test and test writer. The test writer must be able to override the default behavior of components without changing the actual environment. The factory and configured database that is there in UVM helps to automatically change configurations without changing the actual architecture. And then we also have the UVM register layer, which can be automatically generated and used to generate sequence and measure coverage. We'll talk about all these components in detail in later slides. This slide gives you a gist of what we discussed in the previous slide. Once we have a consistency in building a verification environment, you can have a plug and play feature. The factory and configuration database can be used to segregate test writer and a verification specialist. This brings us to end of Chapter two. In Chapter one, we discuss about the history and evolution of UVM then in Chapter two, we discuss why there is a need for UVM and how UBM can be reusable and improve productivity. The next chapter, we will try to understand what are the basic building blocks of a UVM based test bench. 5. UVM testbench top: Welcome to the UVM methodology series. This is the Chapter four of the series. In the previous chapter, we learned about the brief evolution of verification methodology and how UVM came about into existence. We also learned why there is a need for UVM based verification methodology, and what are the constituents of UVM and their building blocks. From this chapter onwards, we will take an example design and try to show how the different UVM components are built. So this diagram shows you an example of a simple UVM test bench for the UBS protocol. I have taken this example as this example is easily available in the UVM user guide. If you Google UVM user guide, you should be able to download the user guide, which has a clear description of the example that I am taking. So in this chapter, I will briefly explain to you the different UVM components in the UBS test environment. We will anyway go through each of these component in detail in subsequent lectures. As you see in this environment, the UBS contains of two agents, a master agent and a slave agent. The master agent and the slave agent both drives a common UBS interface. The UBS master enslave agent is packaged in a UBS environment with a UBS bus monitor instantiation. The UBS environment is again created in an test bench here and also has the example scoreboard, which is a product scoreboard. They are all connected up through TLM connections. At the top layer lies the test, the UVM test. For example, here, we have a test for a read modified it. What is important for today's lecture is to understand the UBS interface. We will see in detail in next slide how the UBS interface is created in the test bench. Before understanding the UBS interface, it is very important to understand what a static component is and what a dynamic component is. As the name indicates, dynamic components are generated and perform their tasks and their lifespan is finished at the end of a simulation cycle. On the other hand, static components are physical components which are present since the beginning and remain existed even after the end of simulation. A standard classification of UVM environment is shown in the figure. So if you see most of the class based environment is a dynamic component. They are mostly created and they end their lifespan when the simulation cycle ends. The DOT and the interface is static components. So what really interfaces between these dynamic components and the static components is the interface. But since the interface itself is static component, we basically send the handle of the interface called the virtual interface to all the class based hierarchies. In this example, we will see how the static components and dynamic components are created. We will also see how the design is instantiated and how the virtual interface connects to your design. If you see on the line number seven, you have the system Verilog interface to your design. This is the interface. Here you create the instance of your UBS interface. And here you have the DOT dummy, which is the instantiation of your design. So how does the class based hierarchy talk to your design through the interface? You need to basically connect the virtual interface signals to your design. So if you see here, these lines are basically connections between the design and the virtual interface. And then we come to the initial begin phase, we have the run test. The run test creates the class based hierarchy. What is important here is the use of the config database. If you see here, the UBS interface is basically sent through config database to all the class based hierarchy. So a link to the interface is sent to the class based hierarchy. The components inside the inside the UVM can get this virtual interface and basically can monitor or drive signals through this interface. You'll see this in detail when we discuss about the driver. And here we also initialize some of the signals for the virtual interface, which will also initialize the design because they are connected together. So this brings us to the end of the short lecture. So we discussed in brief about how the duty is instantiated and how the duty gets connected to the virtual interface. What are dynamic and static components and how the dynamic world talks to the static world. So in the next lecture, we will see how the test bench and the test are created. We will individually go through each of the components that I showed in the simple UBM test bench example. Thank you. 6. UVM test: Hello, everyone. Welcome to the UVM methodology series. In the previous lecture, we learned about how the testbench stop gets created. We also learned how to create an instantiate a virtual interface. We learned how to connect it to the design. We also got an understanding about the static and dynamic components. In this chapter, we will learn about one of these components. That is the UVM underscore test. If you remember from previous chapter, UVM test is derived from the UVM component. It goes through the phasing mechanism. What we are going to discuss today is the topmost layer. That is the UVM underscore test. In the example here, it is the test read modifier. What is the UVM underscore test? What are the things that it typically performs? The main functionality of a UVM test is to instantiate the top level environment. In this example, it is the UBS example test bench. You will basically have to instantiate the UbsEample test bench in the test. The second aspect of a UVM underscore test is to configure the environment. Basically for some tests, you would want one master agent for another test, so you would want more than one master agent. For some of the tests you may want to have the checks. So tests you may want to disable some of the checks. All these configurations are done at the test level. This is one of the main tasks of a UVM underscore test. The third main task is to apply stimulus by invoking the UVM sequences. If you see here, the UBS master sequencer has a different sequences, the test would ideally invoke one of the sequence. The sequence would then go onto your virtual interface and then be driven out. It would basically go into your master driver and then to a virtual interface and then be driven out onto your design. So in the previous slide, what we saw is a test by name, test read modifier ride. Usually each test in UVM extends from its base test. For the example here is Uber's example based test. So what does the UBS example based test do? It basically creates the test bench and also creates some of the printer methods. If you see here, a factory is used to create the test bench. And then you basically define the printer depth to three. Since example base test is derived from the UVM test, it goes through the phasing mechanism. You build phase is first executed and you create the Test Bench and the printer and at the end of elaboration phase, you basically print the test bench hierarchy. This is mainly for debug purpose. A test that will extend from the base test will print the test bench hierarchy. You will also probably set the drain time for your simulation. Basically, when all the objections are dropped, after 50 nanoseconds, the simulation will end. All the basic things that are needed for every test is configured in the UBS base test. What we see here is the hubs derived test. The Ubers derived test. Basically, the test read modifier. It extends from the base test. What does the base test do? It basically creates the environment, prints some of the environment hierarchy and sets the dry time. What does this test do? This test basically tells you what is the sequence that needs to run. For here, using the resource database, The example here is saying that the Uber's example test bench, the master sequencer main phase should run the read modifier write sequence. It's the same case for here. Here it is saying the slaves default sequence should run the slave memory sequence. When the run phase is called, these particular sequences starts to execute. In this chapter, what we learned is how the UVM underscore base test is created, and then how individual tests are created by extending from the base test. This forms the topmost hierarchy in our simple UVM test bench. In the next lecture, we will see how the environments test bench is created. Thank you. 7. UVM testbench: Welcome to the UVM methodology series. This is the Chapter six of the series. In the previous chapter, we learned about how the UVM test pinch stop was created. We also learned how the virtual interface interacts with your design. We learned about the static components, dynamic components. We also saw some examples on how the base test is created and how to derive from base test and create a simple reterrit test. Today, we learn about how to write the Test Bench class and the components inside the test Pinch class. As you see in the diagram, the UBS example test wench is created in the test read modifier write class. But from the previous chapter, we learned that it is actually created in the base test. But since test modifier write is extending from the base test, the UBS example test wench also gets created in the test modifier rate class. So what are the things that are usually present in the test bench components? Since it is somewhat in the top of the hierarchy, it usually tells how the environment should be configured. For example, the UBS example test bench will be telling how many master agents to create, how many slave agents to create, and what should be the connection between the slave agent and the scoreboard basically an instantiation of a product scoreboard. And also since it is at the top of the hierarchy, it also creates the register layer. The register layer is not shown in the example here, but we will go through this in detail in the next few chapters. So as I discussed in the previous slide, the TB architecture can define any number of environments. So you can have, say, for example, multiple instances of Ubers, PCI, AHB, et cetera. Then there is usually a product scoreboard at the top to do the checks. You'll see the syntax in detail in the next slide. So this is how usually UBS test bench looks. Basically, if you see here, this has a built phase where you're setting the number of masters in your environment. So here, in this case, you're setting the number of masters to one, the number of slaves to one. You're creating the UBS environment using the factory method, you're creating the product scoreboard. These are all what happens in the build phase. You're basically configuring the environment. Then you come to the connect phase. In the connect phase, you are basically connecting all the slave monitors item collected port to the product scoreboard. As I mentioned earlier, you're also setting the address map. I mentioned that the register layer is also usually present in the top test bench. The address map for your slave is also set up at the top test bench level. So to recap on the short chapter today, we discussed how the TB class is defined. What are the main components of the TB class, how the TB class can be used to configure different environment settings. In the next chapter, we will see how the actual environment class is created. Thank you. 8. UVM Env: Welcome to the UVM methodology series. This is the Chapter seven of the series. In the previous chapter, we learned how to write a basic test, how to derive from the basic test and write a simple readwrite test, how to build a test bench. In this chapter, we will learn about the UVM environment. So today we'll be discussing about the UBS environment class. UbsEenvironment components can contain any number of Ubus master agent or Ubers slave agent. So how many number of master agents and slave agents should be present in an environment is entirely dependent on your design verification. But what needs to be taken care is when the environment class is coded, it is coded in a reusable way so that it can be overdd in the test pinch. We saw from the previous chapter the test pinch was setting the number of master and the number of slave agents to one. The UBS environment agent has to take this into consideration that whatever is the setting from the top can be handled at the hubs environment agent level. Apart from the master and the slave agent, the UBS also has the bus monitor. You'll see in detail in the next slide. As we discussed in the previous slide, the example here is creating one master agent, one slave agent, and a single bus monitor. We will see the syntax of this in the next slide. So this is the UBS Environment syntax. If you come to the build phase, the build phase is basically getting the number of masters. This number of masters can be driven from the tspins class or any other class higher up from the environment. And it is also basically getting the HAS bus monitor field, which can be controlled again from the top test bench. Then if the control for Habs field is set to one from the top test bench, a bus monitor is created. Again, so here from line 14 to line 21, you see there is a four loop. What is this loop doing? Based on the number of masters that are set by the test bench class? A dynamic array of master is created. This loop basically based on the number of master creates the number of agents that are needed in your verification environment. So this is the same with the slave class. The number of slaves is again driven from a top level hierarchy. The con database gets the number of slaves and based on the number of slave settings, the environments, number of slave agents gets created. Again, in this short chapter, we learned how to create a reusable UVM environment. We also learned how to dynamically size the number of masters and slave agents. In the next chapter, we will understand how the agent class is created and how to develop reusable agents. 9. UVM agent: Welcome to review Methodology series. This is the Chapter eight of the series. In the previous chapter, we learned how to write a base test, how to derive a simple readwrite test, how to build a test bench and how to write reusable environments. Today, we will learn how to code the agent class. As I discussed, the focus of today's lecture will be on the agent. We will be discussing on how the master agent is coded, how a slave agent is coded, and what are the basic differences. Before we understand the syntax of a UVM agent, we will try to understand what are its components. If you see the diagram here, you basically have a sequencer which produces data the sequencer is connected to a driver through a special TLM port. The driver basically gets the data and transfers the data into pin level activity. The sequence or driver interaction is at a transaction level and the driver breaks the transaction into pin level activity onto your design. How is the data sent to your design through the virtual interface? And then there is the monitoring part. You monitor keeps checking on your interface to basically receive the data. So you're converting your pin level activity again back to a transaction. You're monitoring on your design for any new transactions. Once the transaction is received, it is basically written written through an analysis part onto the product scoreboard or to any other TLI port which is connected to this monitor. The agent also has other important information like the active passive and has checkN has coverage. The active passive basically tells whether the agent is being used to drive data or only used to monitor. If it's an active agent, you will have the sequence or driver present in the agent. If it's a passive agent, you will only have the monitoring part of the agent. The agent also has methods to basically disable checks. You can disable checks in your monitor or you can disable coverage in your monitor. All this has to be reusably coded in your agent. To recap, each component in your agent is characterized by its interfaces. The agent configuration is controlled by the top level environment. Basically, the top level environment is seeing whether it's an active agent or a passive agent, and also whether the checks and coverage should be enabled for the agent. And it uses TLM ports. TLM ports basically helps in a set of communication methods. Another important aspect of an agent is it's consistent architecture. Since the architecture is consistent, it is easy to learn, adapt, configure, and reuse from product to product and platform to platform. So here we see the UV master agent for the UBS example. The master agent consists of a sequencer, which is parameterized by the type ubus transfer. You have the driver which pulls the transaction of the type Ubus transfer and drives it onto your UBS design. Then you have the UBS master monitor, which is used to monitor the virtual interface. So this is a simple syntax of the ubers agent. So you have the build phase. Inside the build phase, you have the monitor, which is created by default because both active agents and passive agents always have a monitor. But if the agent is active, then a sequencer is created. A driver is created, and then in the connect phase, we basically connect the sequence item port to your sequencer. The driver sequence item port is connected to your sequencer. We will learn in detail in next chapter on what these individual components in the agent look like. Just to recap in this chapter, we learned on how a UVM agent is created, how to make a UVM agent reusable. What is an active agent? What is a passive agent, and what are the different components inside the agent. In the next chapters, we will learn on each of these individual components. Thank you. 10. UVM driver: Welcome to the UM methodology series. This is Chapter nine of the series. In the previous chapter, we learned how to write a base test, a simple rewrite test, how to build a test pinch, how to write reusable environments and reusable agent. Today we will learn how to code a UVM driver. We will also learn about D driver sequencer interaction in this lecture. So as you see in the UBS example Test Bench, we have two different drivers. You have the UBS master driver, which is a part of the UBS master agent, and you have the Ubus slave driver, which is part of the Ubus slave agent. But both the master driver and the slave driver, they are driving the same Ubus interface. What is the difference between these two? So if you see the UBS master driver writes the UBS master sequences. So these may be sequences that are, for example, writing onto the bus, you might do a readwrite transaction onto the bus. There is a sequencer driver interaction, master sequencer master driver interaction here. And what is the slave sequencer doing? The slave sequencer is basically pulling requests from the slave sequence and syndicate onto the WIP. This may be some of the response items that you see on the bus. We will see in detail how the driver is coded and how the interaction between the sequencer and driver happens. So as you see in this slide, the sequencer controls which sequence items are provided to the driver. There are multiple sequences here, you have a read modifier sequence, incremental read sequence. Basically, what happens is in the test, you specify what sequence needs to run on, what sequencer. You would probably say run a read modify write sequence on the UBS master sequencer at the runtime. So at time zero, this particular sequence starts to execute. As you saw from the previous slide, from the test, we probably say what sequence needs to run on? What sequencer. Sequence is sent to the driver, it is sent through a special TLM port. So the sequences are still at a transaction level. This has to be broken down to pin level activity. What does the master driver do? It basically gets the next item from the sequence from the sequencer, it breaks down the transaction. And send the transaction onto the design through the virtual interface, we'll see in detail how this is done. As I mentioned in the previous slide, there's a special TLM port that connects the sequencer and the driver. Where does this connection happen? If you remember from the previous lecture in the agent, we saw the connection between the sequencer and the driver in the connect phase. So the driver and the sequence are connected via DTLMPort the driver's item port. The sequencer produces the data items to the driver and the driver consumes these items through the sequence item port. We will see the syntax in the next slide. So this is a typical run phase of the master driver. So it's usually on the forever begin end loop. So what is happening in this loop. So when the design is out of reset, you're seeing on the first clock edge, you wait for the item from the sequencer. So when the sequencer sends a sequence onto your design, that is a request here, you basically drive the transfer onto your virtual interface. The sequencer waits for the item done to be sent back to send additional new transactions. There's also a response port which is optional, so you can send the response back to your sequencer if you want to do additional things in your sequencer. This is basically the loop that you've probably seen in most of the drivers. So to recap in this chapter, we learned about the sequencer driver interaction, how a transaction is sent from a test to a sequence to a sequencer, and then onto the driver, how the driver breaks this transaction into pin level activity. So this finishes the driving part of the test bench. Then the next chapter, we will see the receiving or the monitoring part works. Thank you. 11. UVM monitor: Welcome to the UVM methodology series. This is the Chapter ten of the series. In the previous chapter, we learned about how to write a simple test, how to build a test bench, how to write reusable environments, reusable agents, and how to code the UVM driver. We also learned in the previous lecture on the driver sequence or interaction. In this chapter, what we will try to understand is the monitoring part. That is the response path from the testbench. Oh so as you see from the UBS example test wench, there are two monitors. You have the master monitor and you have the slave monitor. What is the master monitor doing? The master monitor is basically monitoring the virtual interface, collecting any master transactions that are sent onto the interface. What is the slave monitor doing? The slave monitor is also monitoring the interface for any slave transactions and the transaction is then broadcasted onto the scoreboard. I here is an example of a UBS master monitor. What is the main job of the master monitor? The master monitor collects the pin level activity. It's always probing the pin level activity. A new transactions that are there on the pin of your design will be captured in your monitor. It'll be converted from the pin level activity to a transaction level activity. Then certain checks or covers can be added to these transactions. You'll see that in detail in the next slide. As you see in this diagram, the DUT level activity gets converted to a transaction level activity by the monitor. The monitor will then use this transaction to broadcast the transaction to a product scoreboard or a register model. Usually the conversion of the pin level activity to transaction level activity is done in the monitor. Some of the interface and frame related checks are also added here. You have the hash checks and a hash coverage. Anywhere from the top hierarchy, these checks and coverages can be disabled for this monitor. And then this transaction is also sent to the product Scoreboard to do additional checks. For instance, say a data related check can be done at the product scoreboard level. All the frame related checks and interface related checks are usually done at the monitor level. So this is a simple syntax of how a master monitor looks like. So you have a master monitor which extends from the UVM monitor. So you have the bus interface, which is basically the interface that you are collecting the transactions from. You have the checks enable and coverage enable. As I discussed in my previous lectures, these can be disabled from the higher level hierarchy. Then you have a definition of your analysis port. What is this analysis port? It's a item collected port. Once you have the transaction collected on this item collected port, it is broadcasted onto different scoreboards. You have some events, these events are triggered whenever there's a new transaction that is captured in your monitor. So there are some item definitions here. And then so here is a simple trans collected coverage group. So you have certain coverages that are defined in your monitor. And these have to be created in the new method here. You have the need new method here, an item collected port is created here. This is the important part. This is the run phase of your monitor. You run phase of your monitor, there's a collect transaction, which is called what happens in the collect transaction? In the collect transaction method, you're in a forever begin loop. Basically, you're always running this, always capturing any new transaction. So basically on any new clockage you're collecting the data that is basically converting a virtual interface pin level activity to transaction level activity. Then if checks are enabled, you are doing transfer checks. I coverage is enabled, you are doing certain coverage. And once the transaction gets collected here, based on your interface protocol, it is also written onto the product scoreboard and the register layer. This is how a basic monitor run phase looks like. So to recap, in this chapter, we learned how the transactions are captured from a virtual interface to your master monitor and how these transactions are sent from your master monitor onto the product scoreboard and the register layer. In the next lecture, we will see more about how the register layer interaction happens with the monitor. Thank you. 12. UVM Reg: Come to VM methodology series. Today we are in the Chapter 11 of the series. In the previous chapter, we learned on how to write a base test, a simple rewrite test, how to build a test bench, how to write reusable environments and agents. We learned about the driver and sequencer interaction. We also learned how to build a reusable monitor. We also learned in the previous chapter on how monitor interacts between the register component. Today we will discuss in detail about the register layer of UVM. O so this is a simple example of UVM register. Here I am modeling the SPI data register. So the SPI data register extends from the UVM rec field. And what are the items inside the register? So you have the data field. In the build phase, the data field is created, and it is also configured. This configuration basically tells what is the bitwidth of this data field? What is the access policy? What is the reset value, et cetera? So in the previous example, we saw the class definition for one of the registers. So if you take a product, it consists of multiple registers, multiple IPs. This has to be defined in a specific way. Here, if you see, each of the IP is packaged in a block. For example, SPI register are packaged inside a SPI block, which contains instantiation of your SPI registers. Then there is an IAT block. The IAD block, for example, contains the register description of your IAT registers. And at a product level, you have an instantiation of these different blocks. And then there is an address map. What does the address map tell? The address map basically tells where each of these registered blocks are sitting in the product address space. So in the previous slide, we saw how to model the project register map. In this slide, what we will try to see is how this is integrated to the agent. When you want to write to a particular register, you will have to go through the register hierarchy. In this example, say, I want to write two register one. The address is then picked from the address map here. There is a predefined TLM port which is provided in the address map. This basically connects to the adapter. What adapter basically does is then converts this register operation. To a bus specific operation. The register operation says write to register by name with a value 20. The register to bus layer has a way to convert to your bus transaction. Your bus may have certain signals like the size that needs to be added to your register operation. Say you want to address it with a word access. All this gets added in the register to bush bus adapter. The write to the register one goes to the address map and then to the adapter and then to the bus agent and then goes to the driver. Sorry, the design. So the data that is written by the driver is also monitored through a TLM port. This is through something called a predictor. The bus monitor agent, as we saw in the previous chapter has a TLM port which connects to the predictor. The predictor basically has the bus to reg implementation. It basically converts the bus transaction to a UVM register transaction. So when you do a read, assume you do a read on register one. When the read is detected by the monitor, the predictor converts that into the register transaction. Then based on the address map, that particular register is updated. You register model will always hold the updated value of the value in the design. So we saw in the previous slides how the register map is written and how it is integrated to a bus agent. So here we will see what are the advantages of using a register model. The first advantage is basically an abstraction from the physical address. Assume you have an evolving design, which keeps changing the register address or the register fields. The register map can be abstracted from the physical address. That is the register maps can be automatically generated and then reused in your environment. There are a lot of predefined sequences that are available in the register model, if you want to say run a marching pattern onto your memory, there are predefined sequences available in the UVM register base class library, which can be used. It is very easy to maintain. As I mentioned, if you have scripts to generate this model, it becomes easy to maintain this register model, another Advantage AT coverage. You can basically see what are the register fields that are written, whether all the access to the register is done based on your product requirement. This coverage sampling is also present in your register model. So to recap, in this chapter, we learned how to build a basic register model, how this register model gets integrated to your agent, and how you can write basic sequences onto your register layer. We also learned on how this register layer can make your product environment more reusable. Thank you. 13. UVM recap and resources: Welcome to the UBM methodology series. This is the final chapter of this series. In this chapter, I will try to recall all the concepts that we discussed in this lecture. I'll also provide you with some of the resources that I think is useful for your journey with UVM. So in the previous lectures, we discussed how to build a UVM test, the use of factory and configuration database. I discussed about how to build a top test bench and how to build reusable UVM environment. We discussed about the register layer on how the register layer interacts with the UVM agent in the previous lecture. We also discussed in detail about the UVM agent. We discussed in detail about the UVM agent, how an agent can be made an active agent, a passive agent. We discussed about the sequence or driver interaction. We discussed about the monitoring side of it, how to monitor can disable or enable checks and coverage and how transaction can be broadcasted through the TLM port to the outside world. So these are some of the resources that I compiled for you to continue with your UVM journey. The first two links are basically the UVM user guide and the UVM class reference guide. These are available as a part of Accelera if you remember, the simple UVM test bench is taken from the UVM user guide. So you can click on these links to understand more about how the simple UVM test bench is generated and how it can be used. I also added some resources that I felt has a good collection of UVM training and UVM knowledge guide. You can use this for continuing with your UVM journey. Thank you for your time. This brings us to the end of the course. I hope the course was useful in getting a good understanding of UVM basics. I hope you will use these concepts in your verification. Thank you.