uvm methodology takes another step forward: a uvm …€¦ · | presentation title | 2 9/3/14 |...

| PRESENTATION TITLE | 9/3/14 | Confidential1

UVM METHODOLOGY TAKES ANOTHER STEP FORWARD: A UVM-1.2 PRIMER Roman Wang @ AMD

Uwe Simm @ Cadence Mike Bartley @ TVS

DVClub Bangalore 2014


Why UVM?

UVM is the Universal Verification Methodology‒ A methodology and a library that codifies the best practices for efficient and exhaustive

verification

Enables automation and reuse via coverage driven verification Open, Interoperable, and Standard

‒ Open to all via Apache open source license‒ Runs on any IEEE compliant simulator

Eco-system and tools‒ Simulation, Low power, mixed signals, accelerator, etc.‒ Books, trainings, and examples‒ Many trained engineers and great support forums ‒ Available on http://www.accellera.org/community/uvm/ ‒ Advanced debug and features in the tools

http://www.accellera.org/community/uvm/


AGENDA

UVM-1.2 : What has changed from UVM-1.1?

Migration Challenges

Cadence Incisive UVM Solution


The UVM is keeping revolution!The Story from UVM-1.0 to UVM-1.2

UVM-1.0

Registers

TLM2

Resources/Config_db

Run-time Phases

UVM-1.1

UVM-1.1(a,b,c,d) UVM-1.2

Bug fixes (Registers, Resources and sequences)

Renamed phase objections

Messaging and transaction recording

Lint cleanup

Bug fixes

UVM_NO_DEPRECATED

+UVM_RESOURCE/CONFIG_DB_TRACE

Pre/post_start() callback added for sequences

Bug fixes

Message/debug infrastrucure

Phase-aware Sequences


~90 Mantis items addressed (60 bugs/Clarifications,

30 enhancements)

UVM core is today ~64kLOC (29kLOC doc, 35K LOC code)

from UVM-1.1d (26kLOC doc, 30K LOC)

Git says: UVM-1.1d -> UVM-1.2 is 12kLOC added and 4kLOC

removed

~15% more and improved developer tests

What can you expect from UVM-1.2?• Bug fixes, performance fixes and cleanups• Enhancements• Few API and semantic changes• User guide cleanup and update• Largely backward compatible but maybe not 100% for your project

UVM-1.2 : Here we go!

Note: The success of your verification project typically does NOT depend upon the latest features. Please consult with your tool, VIP, and training supplier to see how the new features best fit into your environment. Cadence is the best for your choice.

In the release notes, you could find that 50% of items are API changes and 25% break back compatibility

IEEE usually could take 6 months to 1 year to release it


Notable Changes in UVM-1.2

Registers, Objects, Phasing

Configure Database, Factory

Objections, UVM Event, Transaction Recording

Misc Items: such as DAP, uvm_coreservice, etc.

Reporting Infrastructure, Sequences


Notable changes: Reporting

removed all $display calls (mostly for debug output) from base class library (BCL)


Notable changes: Sequences


Notable changes: Registers

For example: DUT registers are 32bits wide and big endian access, and the bus interface universal verification component (UVC) is 16 bits wide.

Transaction 1 -- Lower address + First word [31:16] Transaction 2 -- High address + Second word [15:0]


Notable changes: Objects


Notable changes: Phasing


Notable changes: uvm_config_db


Notable changes: Factory


Notable changes: Objections


Data access policy objects (dap) provide controlled access to embedded objects (get-to-lock, set-before-get,..)

Visitor pattern infrastructure added (uvm_visitor, uvm_structure_proxy, uvm_visitor_adapter)

uvm_coreservice_t common container for package scope variables with set/get accessors

uvm_sequence_library now documented uvm_severity_type (int) deprecated -> uvm_severity (enum)

uvm_factory f = uvm_factory::get(); // same as

uvm_coreservice_t cs = uvm_coreservice_t::get();uvm_factory f = cs.get_factory();

Notable changes: Misc


uvm_enum_wrapper converter‒ Convert from string via

uvm_enum_wrapper#(T)::from_name(“STR”,ref T o)‒ uvm_field_enum now scans string type resources in addition to

enum,int during auto config. e.g. one can set enum fields via string literals from cmdline

Messages in DPI-C now routed back to UVM message facilities Separation of classes into abstract API and “_default_”

implementation for uvm_factory, uvm_report_server

§ Cleanup of package scope variables (factory; missing UVM_ prefix eg. “UVM_”SEQ_ARB_RANDOM )

class my_server extends uvm_default_report_server;

Notable changes: Misc


Largely backward compatible but maybe not 100% for your projects

Some items still need to be manually modified after conversion script.

Encrypted VIP could NOT be migrated by conversion script.

UVM-1.2 could NOT be mixed with other UVM version in one verification environment.



Backward incompatible changes outlined in migration document

release-notes.txt does have list of addressed mantis items with marker for backward compatibility

Migration scripts provided‒ ./bin/add_uvm_object_new.pl it adds uvm_object ctor if missing

‒ ./bin/uvm11-to-uvm12.pl It may help to do the simple changes around starting_phase, set/get_config, reporting

‒ bin/ovm2uvm.pl -the old OVM -> UVM10 script

Migration from UVM-1.1 to UVM-1.2


Manual migration. Not list in the conversion script

Manual migration after the conversion script

Manual work for Migration


Cadence Incisive UVM Solution


Cadence Incisive UVM SolutionOptimized to run UVM and differentiated by VIP and MDV


UVM Debug in Simvision


Summary

UVM-1.2 offers some new incremental features‒ UVM-1.2 is mostly backward compatible ‒ Migration from UVM-1.2 is typically straight forward

and a migration script is provided

Cadence provides high-performance UVM solution with‒ Interactive and post-processing debug‒ Specialized UVM debug facilities


Thank You!Questions?

Additional text or bullets

Call-out or headline


Disclaimer & AttributionThe information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions and typographical errors.

The information contained herein is subject to change and may be rendered inaccurate for many reasons, including but not limited to product and roadmap changes, component and motherboard version changes, new model and/or product releases, product differences between differing manufacturers, software changes, BIOS flashes, firmware upgrades, or the like. AMD assumes no obligation to update or otherwise correct or revise this information. However, AMD reserves the right to revise this information and to make changes from time to time to the content hereof without obligation of AMD to notify any person of such revisions or changes.

AMD MAKES NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE CONTENTS HEREOF AND ASSUMES NO RESPONSIBILITY FOR ANY INACCURACIES, ERRORS OR OMISSIONS THAT MAY APPEAR IN THIS INFORMATION.

AMD SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE. IN NO EVENT WILL AMD BE LIABLE TO ANY PERSON FOR ANY DIRECT, INDIRECT, SPECIAL OR OTHER CONSEQUENTIAL DAMAGES ARISING FROM THE USE OF ANY INFORMATION CONTAINED HEREIN, EVEN IF AMD IS EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

ATTRIBUTION

© 2014 Advanced Micro Devices, Inc. All rights reserved. AMD, the AMD Arrow logo and combinations thereof are trademarks of Advanced Micro Devices, Inc. in the United States and/or other jurisdictions. Other names are for informational purposes only and may be trademarks of their respective owners.

uvm methodology takes another step forward: a uvm …€¦ · | presentation title | 2 9/3/14 |...

Documents