03 March 2017 - Cadence Design Systems

What is UVM Register Modeling?

UVM contains a register modelling layer to help in the verification of designs which contain many registers. Here we describe how the register layer can be used ...

hi I'm Brian Dickinson and I want to

tell you about UVM register modeling what it is and how it can help us so pretty much all of our duties these days have registers hundreds if not thousands of registers so for example here's my memory controller it has a small block of memory but it also has some local mode and some status and some counter registers and all of these are accessed for an APB interface so to verify the controller I'm going to need to control and to observe these registers firstly to check their characteristics are correct they have the right reset value the right address the right access policies and secondly to check their behavior as part of a design and it will typically involve setting up some configuration registers doing read and write accesses to the registers the memories of the controller and finally checking the reset values to make sure they are what we expect so also want to collect coverage here make sure we've written and read perhaps to every bit of our status register so how could we verify that memory controller so here I have it instantiated and connected to a UVM test bench environment that has a UVC of the APB protocol that allow us to

read and write from at the U T so what I'm going to do is I'm going to create a reference model of the registers inside of my UVM test bench it's what we call the register model this is going to capture the address size reset value all the characteristics of the registers inside the D UT and then I'm going to run sequences on my APB UVC to read and to write the UT registers so I do a write on the register by D UT I'm also going to update the register model with the expected results every time I do a read or a write to my Det registers I'll also want to do the same operation to my register model to try and keep it consistent with the actual results inside of a D UT and then during the course of simulation I can do to consistency checks I can compare my expected results in my register model against the actual results inside of my D UT so this sounds like a good plan to verify that memory controller how can you VM help well firstly you VM provides a series of base classes to allow you to create the register model and these are base classes are hierarchical so you've got a

hierarchical architecture where you can define a certain number of bits are a field within a certain register and a certain number of registers go up to make a block of registers and you can have memories and blocks and registers in a hierarchical architecture you can also capture the characteristics of the register the address the size the reset value the access policy you can also link a name to an address register so this is really good instead of having to reference our registers via address having to reference register 1000 all the time we can use the name of the register instead I can access register mode 0 and the register model knows that mode 0 is at address 1000 but my code is much more readable because I have references to mode 0 everywhere rather than address 1000 and obviously they're going to hold the expected values that we're going to use for consistency checking as well we also can build in register coverage into our register model and these models then become reusable IP blocks so for a standard set of registers that you're using in all of your designs you can then write the register model once and then reuse that

model amongst all of your projects the second thing that you VM register modeling gives us is a standard series of methods for reading writing and accessing registers now these are called the API methods and they allow us to access not only to register model but also the D UT and indeed randomize or access them individually as well as together so the idea about this is that the test writer can now write a series of sequences to access the registers of the design without having to understand the underlying protocol which is used to access these registers you can just say write mode 0 read the status register so the register sequences are independent of the protocol used to access those registers in addy UT which means they can be reused with different protocols and again register sequences can become important verification IP that can be reused within and in between projects there's also a number of built-in predefined sequences for common register operations and memory operations there's a nice standard walking one pattern for testing memory which is really useful to have so these sequences come in two forms you can have

a sequence which accesses front-door register access or backdoor register access and in the next slide we'll try to explain a difference between the two so first of all front door access okay all of our rights and read operations of front door by default and in front door the the right or the read operation creates a generic register operation and this needs to be converted to the transaction item used by your UVC so there must be an adapter to do this so the adapter okay converts the generic register operation from the read or the write into a specific UVC transaction item passes that down to the sequencer the sequencer passes it into driver and then does an operation a transaction via the interface on the front door of your D UT now obviously this needs an adapter and the adapter should come as part of your UVC so the developer of the UVC should write the register adapter that front door access backdoor access is via a hierarchical path name so it's like a standard vera log out of module reference okay it's a direct path name down to the variable in the D UT which stores the value of the register that you're trying to access now obviously

this requires a pass name and more importantly it acquires a path name which is kept up-to-date with the changes in your D UT now normally this is part of your register model but occasion it can be created in other form but usually we build it into the register model and then the read or write operation can extract that path name from the register model when it does a backdoor access operation okay that's front door and back to access sequence operation one last thing to have a look at is prediction Gaye and prediction is the art and it is an art in keeping your register model up-to-date with what we think is in addy UT now there's various different formats for doing this and if you're interested in this as a separate training byte on different prediction modes I encourage you to search for that in the support site but we'll show you explicit prediction in this particular slide so we have a predictor component this is provided to us by UVM we just instantiate it configure it and connect it and we connect it to the monitor we connect it to the analysis port of our monitor from our UBC so our UVC monitor

captures all the transactions in carried out in our D UT these are pass to our predictor the predictor uses the adapter of the UVC to convert the UVC transaction into a generic register operation and it uses that generic register operation to update your register model and keep it up to date and of course it Abbes the access policy when it does that say for example if you're trying to write to a read-only register the rightful sale okay so and this is register modeling in UVM and here are some of the acknowledged benefits in using register modeling so first of all productivity improvements so you don't or very rarely write the register model yourself we normally generate the register models from some kind of specification such as the I Triple E standard IP exact or from any other kind of XML or spreadsheet content so this is really easy to keep the model up-to-date if something changes in our model we update the specification and regenerate the register model from that you also have ease-of-use because your test writers now can use those simple built-in register methods the API calls to do

read and write operations and your registers with no knowledge of the protocol that's actually being used by your D UT and we can adapt existing register sequences to use a new register model nice and quickly and easily or for example using the explicit prediction we showed you on the previous slide I remember the whole series of built-in testing sequences provided by UVM to enable us to get quick results and these are fully configurable so you can do an operation on all the registers in your design and then use a separate switch to exclude individual registers or groups of registers and the whole thing is revolving around reuse here so the APB so these sequences that we create the register sequences we create it can be reused in different projects with different protocols with different interfaces the register model for our block can be used in a system level simulation together with other models from other blocks in our design and the register model itself is reusable for other projects so if you're interested in finding out more about register modeling cadance has a course on UVM

register modeling in this course we'll show you how to generate a register model how to integrate and connect the model into a verification environment how to simulate that model with pre-built and use defined register sequences will show you different ways of prediction to keep that register model up-to-date for the D UT and finally we'll show you how to model quirky and strange and unusual register behavior inside of your register model [Music]

XML Transcript: