Easier UVM - Coding Guidelines And Code Generation
Easier UVM - Coding Guidelines and Code GenerationJohn AynsleyDr. Christoph SühnelDoulosChurch Hatch, 22 Market PlaceRingwood, United Kingdom 44 1425 e 2cD-82487 TRACTThis paper describes our experiences with the Easier UVM codingguidelines and code generator with the objective of encouraging theUVM community to think about and eventually converge upon someset of coding guidelines for UVM. Easier UVM consists of acomprehensive set of coding guidelines for the use of UVM and anopen-source UVM code generation tool that automatically generatesthe boilerplate UVM code for a project according to these guidelines.Easier UVM helps individuals and teams get started with UVM,helps avoid pitfalls, helps promote best practice, and helps ensureconsistency and uniformity across projects. Easier UVM helps teamsto become productive with UVM more quickly, and reduces theburden of maintaining a UVM codebase over time. Both theguidelines and the tool can be taken as they are or can be used as astarting point and modified according to the demands of a specificproject.KeywordsSystemVerilog, UVM, functional verification, constrained randomverification, programming language, code generator1. MOTIVATIONOver the past two years SystemVerilog has become the language ofchoice for new adopters of constrained random, coverage-drivenverification, effectively displacing the earlier proprietary languages(e and Vera) in many situations. Although e still retains a customerbase, most new adopters are choosing SystemVerilog for one reasonalone: SystemVerilog is a standard. SystemVerilog is activelysupported by all of main simulator vendors, both in the technicalsense that the simulators have robust support for most of thelanguage features, and in the commercial sense that the vendorsactively promote the adoption and use of SystemVerilog. There isnow an ecosystem of tool vendors, IP providers, consultants, andtraining providers supporting SystemVerilog.But SystemVerilog is not without its problems. It is an extremelylarge and complex language, and the road to the current level of toolsupport has not been an easy one. The sheer scale and complexity ofthe task of implementing a SystemVerilog simulator has forced toolvendors to prioritize their implementation efforts, giving mostattention to the particular language features being demanded by theircustomers or perceived as necessary to meet their own productpositioning and marketing goals. Even today, there are stilldifferences in interpretation and implementation across thesimulators.One very powerful business driver for the convergence of the mainSystemVerilog implementations has been the desire to win customersfrom the competition by offering excellent compatibility withwhatever SystemVerilog methodology libraries the competingvendor happens to champion. A few years back, this was AVM forMentor, URM for Cadence, and VMM for Synopsys. Commercialpressures eventually lead to the convergence of these threemethodologies in a single methodology, UVM, but along the wayeach tool vendor had to make sure that they fully supported theSystemVerilog language constructs used by the competingmethodologies, and more than that, had to ensure that theyinterpreted the relevant areas of the standard in a mutually consistentway. This process became a virtuous circle, whereby the presence ofan emerging standard SystemVerilog class library put pressure on thesimulator vendors to implement the standard fully and accurately,and the improved tool support across all the full range of vendorslead to an increased confidence to adopt both the SystemVeriloglanguage and the UVM library.Doulos has directly experienced a significant jump in the volume ofSystemVerilog training delivered with the introduction of eachstandard methodology (AVM, VMM, URM, OVM, UVM), thebiggest jump appearing alongside with the introduction of UVM.So while UVM has been a catalyst for the adoption ofSystemVerilog, the adoption of UVM itself has not been without itschallenges. While UVM is arguably an improvement over itsancestor methodologies, it is itself complex and challenging to learnand to use. A quick survey of UVM training classes offered by thetool vendors themselves and by independent training providersshows the average class length to be 4 days in a range of 3 to 5 days,and in every case these classes assume a working knowledge of theSystemVerilog language as a starting point. In the case of Doulos,the typical formal training program for engineers already familiarwith Verilog would consist of a 4 day training class to teach theverification features of the SystemVerilog language, followed by 4days to teach UVM. Experience has shown that this level of trainingis the minimum required for effective adoption: although managerswith limited budgets of time and money will often try to reduce theextent of formal training, this is usually a false economy in that itgreatly increases the on-the-job learning time and leads to bugs andfalse starts. All-in-all, the adoption of UVM requires a significant upskilling which is frequently underestimated.Even assuming the highest quality training, there is still a need forfurther help to get started with the first project. Training is necessary,but it is not sufficient. User companies quote timescales from 3months to 12 months before their engineers are fully up-to-speedwith UVM. In order to assist in the adoption process, tool vendorsoffer UVM-aware graphical capture tools, text editors, simulationenvironments, and debug environments. Specialist verificationconsultants offer coaching and mentoring. Some vendors offerpackages combining tool purchase with training or mentoringschemes. User companies themselves develop their own in-houserules and coding guidelines.The UVM base class library itself presents its own challenges. Itconsists of around 300 separate SystemVerilog classes, and thedocumentation included with the UVM release, consisting of a Class1
Reference and a User Guide, is incomplete in some areas and leavesmany questions unanswered. This is exacerbated by the fact thatUVM still maintains a form of backward compatibility with itsancestor methodologies, so the UVM codebase still includes codefrom AVM and URM that is not necessarily maintained to the samequality as the more widely used features. UVM offers “more thanone way to do it”, and there are areas in which the experts still debatewhich is the best approach. There are sometimes alternativeapproaches offered by the various ancestor methodologies betweenwhich the user must choose. There are optional shortcuts (such astext macros) which the experts still debate. There are new featureswith an experimental flavor that are championed by some expertusers while being frowned upon by other expert users. To add fuel tothe fire, the web has created a forum in which experts, both real andself-proclaimed, can propagate their advice to the wider community.This advice is sometimes excellent, sometimes contradictory,sometimes misguided, and sometimes just plain wrong. Having asandpit in which people can play with new ideas can be a verypositive thing, but at the same time it can be hard and timeconsuming to sort the wheat from the chaff in the absence of adefinitive methodology. Several pundits have observed that UVM isstill in need of a “methodology”, in the sense of a definitive set ofrules and guidelines directing its use.2. INTRODUCING EASIER UVMIt is three years since Doulos first presented a paper entitled EasierUVM at DVCon. The goal of that first Easier UVM paper was toidentify a minimal set of concepts sufficient for constrained randomcoverage-driven verification in order to ease the learning experiencefor engineers coming from a hardware design background. The firstpaper was explicitly aimed at mainstream Verilog and VHDL users,not verification experts. A lot of UVM marketing material andworkshops were then (and still are) aimed at early adopters andverification experts, and as such have their place, but it is Doulos'direct experience that many new UVM users do not considerthemselves experts and need some help getting started. The goal ofEasier UVM "version 1" was primarily educational and pedagogical,that is, to reduce UVM to a set of simple concepts and coding idiomsthat are relatively easy to learn. Practically speaking, Easier UVMwas a subset of UVM, but was not meant to exclude any features ofUVM, just give a good starting point for learning: other features ofUVM could always be introduced as the user became moreconfident. It was always recognized that, despite the title, learningUVM is still not easy.Since that time there has been a very rapid adoption of UVM acrossthe industry, and the experience gained from training and consultingwith many users over that period gives us the confidence to proposea more prescriptive set of UVM coding guidelines complemented bya UVM code generation tool.This second paper on Easier UVM introduces a set of specific codingguidelines that suggest “one way to do it”, helping to give new usersclear direction regarding best practice, and an automatic codegeneration tool that can generate the first tier of the UVM codebasefor a new project, generating the basic UVM structures starting froma simple template. This offers a number of specific benefits, asfollows. Easier UVM can help individuals and teams to get startedwith UVM, reinforce what they learned during training,learn best practice, and avoid the most common pitfalls. Easier UVM can help individuals and teams to becomeproductive with UVM more quickly. In practical use onindustrial projects, one of us (Suehnel) has found the use ofthe code generator to cut around 6 weeks from the codingeffort at the start of the project Easier UVM helps teams to use UVM in a more consistentway across and between projects within a company, andthus to reduce the burden of supporting the UVM codebaseover time. Easier UVM helps make the planning and execution ofUVM projects a more predictable process and can helpkeep even the first project on schedule.The net effects are to accelerate the timescales of the first project onwhich UVM is adopted and to reduce the costs of maintaining aUVM codebase over time.There is also a human element to this which should not beunderestimated. By helping to avoid some of the basic pitfalls ofSystemVerilog and UVM and by getting a simple working test benchup-and-running within a few days, project teams are encouraged andmotivated to persevere with UVM where otherwise they might giveup in frustration. On real projects the provision of a code generatorhas been found to make a dramatic difference in overcoming theresistance to change.The Easier UVM guidelines document itself is too long to beembedded directly in this paper, but the guidelines and codegenerator can be downloaded, used, and modified free-of-charge [1].3. CODING GUIDELINESThis paper describes our experiences with a specific set of codingguidelines and an associated code generator, but the intent of thispaper is not to advocate the adoption of any one specific guidelineover any other. We have found that any individual guideline willhave its advocates and its detractors: company-specific codingguidelines usually end up being unique because opinions as to bestpractice can be subjective and differ substantially according toexperience. If this paper encourages the UVM community to thinkabout and eventually converge on any set (or sets) of codingguidelines, it will have fulfilled its objective.That said, the Easier UVM coding guidelines address the followingareas: Lexical Guidelines and Naming ConventionsGeneral GuidelinesGeneral Code StructureClocks, timing and onentsConnection to the DUTTLM ConnectionsConfigurationsThe FactoryTestsMessagingFunctional CoverageThe Register LayerAgent Data Structure and Packaging2
Most of the guidelines could be regarded as common sense: there isnothing revolutionary. However, the guidelines document is a lotmore prescriptive than either the official UVM Class Reference orthe UVM User Guide: this document gives very specificrecommendations about which UVM features to use and exactly howto use them. In some cases, this meant recommending best practiceas commonly agreed upon across the industry. In other cases it meantmaking a rather arbitrary choice to favor one way of doing thingsrather than another. In most cases it was felt more useful to provideclear direction to do things in a certain way rather than to presentalternatives along with a rationale for choosing between them,although there are still a few cases where we felt obliged to presentusers with a choice. In any case, Easier UVM is not meant to excludeany part of the SystemVerilog or UVM standards: the Easier UVMguidelines are offered as a suggestion of best practice, and users arefree to take them, leave them, or modify them for their ownpurposes.3.1. Coding PatternsThe Easier UVM coding guidelines start by defining coding patternsfor the most common user-defined UVM classes, including obviousthings such as the order of declarations, specific naming conventions,which macros to use, and which methods to override. To give anidea, here are the outlines of the three main coding patterns forcomponents, transactions, and sequences:Componentsclass my comp extends uvm component; uvm component utils(my comp)// Transaction-level ports and exports// Virtual interfaces named vif or * vif// Internal data members named m *function new(string name, uvm component parent);super.new(name, parent);endfunctionfunction void build phase(.);.// Other standard phase methodsendclassTransactionsclass my tx extends uvm sequence item; uvm object utils(my tx)class my seq extends uvm sequence #(my tx); uvm object utils(my seq)// Data members named m * acting as control knobsfunction new(string name "");super.new(name);endfunctiontask body;.endclassThe guidelines also prescribe coding patterns to deal with specificsituations, for example how to use configuration objects, how toconfigure sequences through the configuration database, how to startregular sequences from virtual sequences, and how to prolong runtime phases until all components have finished. The set of codingpatterns is not exhaustive, and some of the guidelines will inevitablybe contentious, but it was felt that offering some concrete advice wasbetter than offering no advice.An example of a very specific but very arbitrary choice is thatconcerning naming conventions. We recommend specific prefixesand suffixes to be used when naming class members (m ), ports( port), virtual interfaces ( vif) and so forth. There is nothing rightor wrong about the particular conventions chosen, except insofar asthey are in general consistent with the conventions used within theUVM base class library itself, but there is clear benefit to be gainedfrom adopting some naming convention. A company couldconceivably replace these conventions with their own whileotherwise adhering to some or all of the Easier UVM guidelines.As another example of an arbitrary choice, on the contentious issueof whether or not to allow the use field macros, the Easier UVMguidelines advise against the use of field macros in general and givespecific guidelines, with examples, concerning how to override builtin methods such as do copy, do compare, do print and so forth. Thecode generator is able to generate the code for these methodsautomatically, thus counteracting one of the potential disadvantagesof choosing not to use field macros. The arguments against the use offield macros include the compile-time and run-time overheadintroduced by the code generated by these macros and the difficultymany users have experienced trying to understand and debug thefield macros. On the other hand, many users do use field macrossuccessfully, and recognizing that there may be situations where thefield macros do get used, the Easier UVM guidelines suggest a wayto highlight whether or not field macros are being used, namely: When not using field macros (recommended), register theclass with the factory using one of the macros uvm component utils or uvm object utils as the firstline within the class. If using field macros (not recommended), register the classand the fields using one of the macros uvm component utils begin or uvm object utils beginimmediately after the declaration of any member variables.// Data members named m *function new (string name "");super.new(name);endfunctionfunction string convert2string;.function void do copy(uvm object rhs);.// Other overridden methodsendclassSequencesAs another example of an arbitrary choice, we have chosen torecommend overriding the callbacks pre start and post start ratherthan pre body and post body when wanting to execute code beforeor after the execution of the body task of a sequence. There is somejustification for this decision in that the pre/post body methods arenot called when a sequence is started using a macro from the uvm do family, whereas pre/post start are called however thesequence is started.3
An example of a coding guideline that encourages good coding styleis to always call the randomize method of a sequence object beforestarting the sequence on a sequencer, whether or not the sequenceclass explicitly named at that point in the source code contains anyrand variables. The justification for this guideline is that the type ofthe sequence object could be replaced at run-time using a factoryoverride, and the extended class with which the sequence is replacedcould contain rand variables, even if the base class did not. If thesequence object is not randomized before it is started, the randvariables within the extended class would not get randomized.3.2. General GuidelinesAs well as specific conventions, the coding guidelines also offermore general advice on the best way to structure the verificationenvironment and how to handle commonly encountered problems.This goes beyond what might typically be found in company codingstandards and overlaps with the good practice that might be learnedduring training. Hence the coding guidelines may help a project teamto reinforce what they learned during formal training.At the highest level, the Easier UVM guidelines show how tostructure a UVM verification environment containing parallel agentscontrolled by virtual sequences and sending out transactions to ascoreboard for analysis, as illustrated in the figure below: advice on packaging data and structuring files for reuseAs an example, consider the use of the configuration database. TheEasier UVM guidelines recommend that where a component hasmultiple configuration parameters, those parameters should begrouped together into a configuration object that gets stored in theconfiguration database and is associated with that componentinstance. Typically, each component instance would be associatedwith a unique configuration object, but it is also allowable that acomponent instance has no configuration object or, whereappropriate, that several component instances share the sameconfiguration object. A component may set configuration objects forits children, grandchildren and so forth, thus skipping generationsdown the hierarchy, but a component is only allowed to read its ownconfiguration object, not the configuration object of its parent orgrandparent. By this rule, the configuration of a component is onlydependent on parameters contained within its own configurationobject, and hidden dependencies on configuration informationcontained outside the immediate context of the component areforbidden.The coding guidelines address the issue of how to return transactionsfrom the driver in response to requests from the sequencer, wherethere are three common approaches: returning a separate response object from the driver to theseque
SystemVerilog, UVM, functional verification, constrained random verification, programming language, code generator ancestor methodologies, it is itself complex and challenging to learn 1. MOTIVATION . Easier UVM "version 1" was primarily educational and pedagogical, that is, to reduce UVM to a set of simple concepts and coding idioms .
Easier UVM is meant to be taken as a set of coding guidelines or biases. Easier UVM alone will not address every issue you are going to face as you build a complex verification environment, and for that reason, every rule in Easier UVM can have exceptions. While all the code produced from the Easier UVM
Mar 03, 2015 · UVM Quonset Hut Storage - UVM 6 Colchester Avenue 1E 6-04 UVM Ready Hall - UVM Trinity Campus 246 Colchester Avenue 1E 6-04 UVM Redstone Apartments 500 South Prospect Street 6S 6-05 UVM . Stafford Greenhouse - UVM Main Campus 45 Carrigan Drive 1E 6
Getting Started with UVM Vanessa Cooper Verification Consultant Getting Started with UVM ! What is UVM? ! Building a Testbench ! Testbench Architecture ! Phases ! Sequence Items ! Macros and the Factory ! Configuration Database ! Connecting a Scoreboard ! Creating Tests ! .
Easier UVM – Functional Verification for Mainstream Designers Introducing UVM Transactions and Components Sequencers and Drivers Configurations and the Factory
User Experience with UVM Stephen D’Onofrio & Peter D’Antonio Stacking Verification Components in UVM . - Improve functional verification and ultimately product . - Easier to understand, create, and share - 2, 3 and 4 stacked UVCs .
and memories. IP-XACT is an XML format that defines and describes electronic components and their designs in this case register and memory map of design. This paper explains current verification practices and issues of verifying register models. It gives details how to convert IP-XACT to UVM Register Model using Magillem UVM generator.
Verification tools Universal Verification Methodology (UVM) – Class library written in SystemVerilog – Very powerful, but very complex Over 300 classes in UVM! – Grad students unlikely to have prior experience with SystemVerilog Open Source VHDL Verification Methodology (OSVVM) – Library written in VHDL – Similar to UVM
components due to the thermal stresses set up. This makes it necessary for, the temperature variation to be kept to a minimum. . In an automotive with Liquid Cooling System, the heat is carried away by the use of a heat absorbing coolant that circulates through the engine, especially around the combustion chamber in the cylinder head area of the engine block. The coolant is pumped through .
