Verification Academy

Search form

My Account Menu

  • Register
  • Log In
  • Topics
  • Courses
  • Forums
  • Patterns Library
  • Cookbooks
  • Events
  • More
  • All Topics
    The Verification Academy offers users multiple entry points to find the information they need. One of these entry points is through Topic collections. These topics are industry standards that all design and verification engineers should recognize. While we continue to add new topics, users are encourage to further refine collection information to meet their specific interests.
    • Languages & Standards

      • Portable Test and Stimulus
      • Functional Safety
      • Design & Verification Languages
    • Methodologies

      • UVM - Universal Verification Methodology
      • UVM Framework
      • UVM Connect
      • FPGA Verification
      • Coverage
    • Techniques & Tools

      • Verification IP
      • Simulation-Based Techniques
      • Planning, Measurement, and Analysis
      • Formal-Based Techniques
      • Debug
      • Clock-Domain Crossing
      • Acceleration
  • All Courses
    The Verification Academy is organized into a collection of free online courses, focusing on various key aspects of advanced functional verification. Each course consists of multiple sessions—allowing the participant to pick and choose specific topics of interest, as well as revisit any specific topics for future reference. After completing a specific course, the participant should be armed with enough knowledge to then understand the necessary steps required for maturing their own organization’s skills and infrastructure on the specific topic of interest. The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization’s processes so that you can then reap the benefits that advanced functional verification offers.
    • Universal Verification Methodology (UVM)

      • Advanced UVM
      • Basic UVM
      • Introduction to UVM
      • UVM Connect
      • UVM Debug
      • UVMF - One Bite at a Time
    • Featured Courses

      • Introduction to ISO 26262
      • Introduction to DO-254
      • Clock-Domain Crossing Verification
      • Portable Stimulus Basics
      • Power Aware CDC Verification
      • Power Aware Verification
      • SystemVerilog OOP for UVM Verification
    • Additional Courses

      • Assertion-Based Verification
      • An Introduction to Unit Testing with SVUnit
      • Evolving FPGA Verification Capabilities
      • Metrics in SoC Verification
      • SystemVerilog Testbench Acceleration
      • Testbench Co-Emulation: SystemC & TLM-2.0
      • Verification Planning and Management
      • VHDL-2008 Why It Matters
    • Formal-Based Techniques

      • Formal Assertion-Based Verification
      • Formal-Based Technology: Automatic Formal Solutions
      • Formal Coverage
      • Getting Started with Formal-Based Technology
      • Handling Inconclusive Assertions in Formal Verification
      • Sequential Logic Equivalence Checking
    • Analog/Mixed Signal

      • AMS Design Configuration Schemes
      • Improve AMS Verification Performance
      • Improve AMS Verification Quality
  • All Forum Topics
    The Verification Community is eager to answer your UVM, SystemVerilog and Coverage related questions. We encourage you to take an active role in the Forums by answering and commenting to any questions that you are able to.
    • UVM Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • UVM Forum
    • SystemVerilog Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • SystemVerilog Forum
    • Coverage Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • Coverage Forum
    • Additional Forums

      • Announcements
      • Downloads
      • OVM Forum
  • Patterns Library
    The Verification Academy Patterns Library contains a collection of solutions to many of today's verification problems. The patterns contained in the library span across the entire domain of verification (i.e., from specification to methodology to implementation—and across multiple verification engines such as formal, simulation, and emulation).
    • Implementation Patterns

      • Environment Patterns
      • Stimulus Patterns
      • Analysis Patterns
      • All Implementation Patterns
    • Specification Patterns

      • Occurrence Property Patterns
      • Order Property Patterns
      • All Specification Patterns
    • Pattern Resources

      • Start Here - Patterns Library Overview
      • Whitepaper - Taking Reuse to the Next Level
      • Verification Horizons - The Verification Academy Patterns Library
      • Contribute a Pattern to the Library
  • All Cookbooks
    Find all the methodology you need in this comprehensive and vast collection. The UVM and Coverage Cookbooks contain dozens of informative, executable articles covering all aspects of UVM and Coverage.
    • UVM Cookbook

      • UVM Basics
      • Testbench Architecture
      • DUT-Testbench Connections
      • Configuring a Test Environment
      • Analysis Components & Techniques
      • End Of Test Mechanisms
      • Sequences
      • The UVM Messaging System
      • Other Stimulus Techniques
      • Register Abstraction Layer
      • Testbench Acceleration through Co-Emulation
      • Debug of SV and UVM
      • UVM Connect - SV-SystemC interoperability
      • UVM Versions and Compatibility
      • UVM Cookbook
    • Coding Guidelines & Deployment

      • Code Examples
      • UVM Verification Component
      • Package/Organization
      • Questa/Compiling UVM
      • SystemVerilog Guidelines
      • SystemVerilog Performance Guidelines
      • UVM Guidelines
      • UVM Performance Guidelines
    • Coverage Cookbook

      • Introduction
      • What is Coverage?
      • Kinds of Coverage
      • Specification to Testplan
      • Testplan to Functional Coverage
      • Bus Protocol Coverage
      • Block Level Coverage
      • Datapath Coverage
      • SoC Coverage Example
      • Requirements Writing Guidelines
      • Coverage Cookbook
  • All Events
    No one argues that the challenges of verification are growing exponentially. What is needed to meet these challenges are tools, methodologies and processes that can help you transform your verification environment. These recorded seminars from Verification Academy trainers and users provide examples for adoption of new technologies and how to evolve your verification process.
    • Upcoming & Featured Events

      • Creating an Optimal Safety Architecture  - February 9th
      • The ABC of Formal Verification - February 11th
      • Events Calendar
    • On Demand Seminars

      • I'm Excited About Formal...
      • Visualizer Coverage
      • Formal-based ‘X’ Verification
      • 2020 Functional Verification Study
      • All On-Demand Seminars
    • Recording Archive

      • Improving Your SystemVerilog & UVM Skills
      • Should I Kill My Formal Run?
      • Visualizer Debug Environment
      • All Recordings
    • Mentor Training Center

      • SystemVerilog for Verification
      • SystemVerilog UVM
      • UVM Framework
      • Instructor-led Training
    • Mentor Learning Center

      • SystemVerilog Fundamentals
      • SystemVerilog UVM
      • Questa Simulation Coverage Acceleration Apps with inFact
      • View all Learning Paths
  • About Verification Academy
    The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization's processes so that you can then reap the benefits that advanced functional verification offers.
    • Blog & News

      • Verification Horizons Blog
      • Academy News
      • Academy Newsletter
      • Technical Resources
    • Verification Horizons Publication

      • Verification Horizons - November 2020
      • Verification Horizons - July 2020
      • Verification Horizons - March 2020
      • Issue Archive
    • About Us

      • Verification Academy Overview
      • Subject Matter Experts
      • Contact Us
    • Training

      • Questa® & ModelSim®
      • Questa® inFact
      • Functional Verification Library
  • Home /
  • Verification Horizons /
  • February 2013 /
  • The Evolution of UPF: What’s Next?

The Evolution of UPF: What’s Next?

Verification Horizons - Tom Fitzpatrick, Editor

 What's Next? by Erich Marschner, Product Manager, Questa Power Aware Simulation, Mentor Graphics

INTRODUCTION

Usage of the Unified Power Format (UPF) is growing rapidly as low power design and verification becomes increasingly necessary. In parallel, the UPF standard has continued to evolve. A previous article1 described and compared the initial UPF standard, defined by Accellera, and the more recent IEEE 1801-2009 UPF standard, also known as UPF 2.0. The IEEE definition of UPF is the current version of the standard, at least for now, but that is about to change. The next version, UPF 2.1, is scheduled for review by the IEEE Standards Review Committee in early March. When it is approved, UPF 2.1 will become the current version of the UPF standard.

UPF 2.1 is an incremental update of UPF 2.0, not a major revision. That said, UPF 2.1 contains a large number of small changes, ranging from subtle refinements of existing commands to improve usability, to new concepts that help ensure accurate modeling of power management effects. This article describes some of the more interesting enhancements and refinements coming soon in UPF 2.1.

FORMAT UNIFICATION

One of the most significant aspects of UPF 2.1 is the fact that it represents a major step forward towards a unified low power format that is supported by all EDA vendors. For some time, UPF and CPF, the Common Power Format from Si2 and Cadence, have co-existed as alternative low power formats. While similar in many ways, the two formats have been different enough to make automatic translation between them difficult, which in turn has created problems for users who have a multi-vendor flow that requires use of both formats. Because of this, many low power designers and verification engineers have been pushing for unification of the two formats into a single format that all tools would support.

Si2 took some steps in that direction several years ago, by adding certain features of UPF into the most recent version of CPF, but this did not really address the interoperability issue well enough. More recently, the IEEE P1801 UPF working group has been working to include some aspects of CPF in the next version of UPF. To enable these additions, Si2 and Cadence both joined the IEEE P1801 UPF working group in early 2011, Si2 donated the definition of CPF 2.0 to the working group, and Cadence has actively contributed to the development of UPF 2.1. As a result, UPF 2.1 includes some new features derived from CPF concepts. These features appear to be sufficient to enable CPF users to move to a UPF-based low power flow. IEEE P1801 working group members who use both formats have strongly supported the integration of CPF features into the next version of IEEE standard 1801 UPF.

POWER MANAGEMENT CELL DEFINITION

The primary CPF-inspired new feature in UPF 2.1 is a set of commands for defining power management cells such as isolation, level-shifting, and retention cells. These new commands enable users to provide a complete power intent specification in UPF, without relying on Liberty libraries for the definition of power management cells. Some users require such commands because their Liberty libraries may be out of date or incorrect, and the cost of modifying and re-verifying the modified libraries is often prohibitive. With these new power management cell definition commands, power intent for a given design can be expressed without updating the Liberty libraries.

MACRO CELL MODELING

The other CPF-inspired new feature in UPF 2.1 is a set of commands for defining power intent for macro models. While not strictly necessary – macro models can be represented with existing UPF 2.0 features – these new commands provide additional convenience by packaging up the power intent for a given macro so that it can be easily applied to each instance of the macro. These commands -begin_power_model, end_power_model, and apply_ power_model – effectively provide a standardized UPF subroutine definition and invocation capability.

Other enhancements in UPF 2.1 also address macro cells. In particular, refinements to the definition of the boundary of a power domain now enable isolation and level shifting strategies to apply to ports of a macro cell instance. New predefined attributes UPF_feedthrough and UPF_unconnected have been added also, to provide information about the internals of a hard macro instance that are required during network analysis to determine driving and receiving supplies of a net.

Additional changes clarify how anonymous supply sets are constructed for ports of a hard macro based upon the related supplies associated with the port and the pg_types of those related supplies. These anonymous supply sets are considered by isolation and level shifting strategies written using -source or -sink filters, so they need to be welldefined to ensure that isolation and level shifting insertion works correctly.

SUPPLY EQUIVALENCE

UPF 1.0 defined supply nets; UPF 2.0 added the concept of supply sets, which are collections of related supply nets. Both are used to model the supply networks providing power to various portions of a design.

The supplies powering logic driving and receiving a signal affect power management requirements:

  • If the driving supply can be off when the receiving supply is on, isolation is required.
  • If the two supplies can operate at significantly different voltage levels, level shifting is required.

Because of this, isolation and level-shifting strategies often use the driving/receiving supply as a filter to determine where isolation or level shifting cells should be inserted.

The -source filter for supply S selects any port that is driven by logic powered by a supply that matches S. The -sink filter for supply S2 selects any port that is received by (i.e., fans out to) logic powered by a supply that matches S2. The sink filter in particular makes it easy to selectively isolate certain paths from a port while leaving other paths unisolated, or to isolate different paths with different controls or different isolation supplies. But what does it mean for one supply to "match" another? This is where the UPF 2.1 concept of supply equivalence comes in.

At the lowest level, two supply nets are equivalent if they are connected directly or indirectly, either by HDL statements or by UPF commands or by a combination of both. This is called "electrical equivalence" in UPF 2.1.

If two supply nets are electrically equivalent, then they are also functionally equivalent: they will both always have the same state and voltage. Two supply nets can be declared to be equivalent even if they are not connected in the design, in which case the equivalence declaration acts as a constraint on the eventual implementation or on use of an IP block in a larger system.

The equivalence concept also applies to supply sets. Two supply sets are considered equivalent if their corresponding required functions (the supply nets, or placeholders for supply nets, that make up each supply set) are all equivalent. Two supply sets are also considered equivalent if they are declared to be equivalent.

This definition of equivalence enables other UPF commands to function in intuitively natural ways. For example, the set_isolation command will by default use supply equivalence in determining which ports are to be isolated when set_isolation is specified with a –sink or –source filter. The command create_composite_domain will also consider supply equivalence when ensuring that all subdomains have the 'same' primary supply. In general, where UPF 2.0 required two supplies to be "the same", UPF 2.1 now requires them to be equivalent.

SUPPLY SET REFINEMENTS

Several other changes in UPF 2.1 also focus on supply sets and related concepts. For example, UPF 2.0 allows specification of attributes representing the driver supply or receiver supply of a port, in case the logic driving or receiving that port is not in the design (for a primary input or output) or not visible (for a hard macro instance). However, UPF 2.0 assumes that all ports have drivers or receivers, as appropriate; the possibility that a port is left undriven or is not connected to a sink is not considered. In UPF 2.1, this is modeled explicitly with the above-mentioned UPF_ unconnected attribute, and the semantics of supply sets and driver/receiver supply analysis account for this, even to the point of making different assumptions about primary ports, which are assumed to be connected externally, and ports of leaf-level instances, for which the same assumption may not hold.

UPF 2.1 also refines the definition of default supplies for isolation and level shifting cells inserted by strategies that do not explicitly identify the relevant supplies. For level shifters, the default supplies are now those of the logic driving the input side and the logic receiving the output side, respectively, provided that the domain crossing involved is not overly complex. For isolation, the default isolation supply now reflects the fact that the location in which an isolation cell is inserted typically determines what isolation supply will be used for that cell. UPF 2.1 also adds the concept of supply availability: which supplies are available in a given domain to power buffers inserted during implementation. This allows the user to constrain implementation tool decisions to avoid routing difficulties.

STRATEGY REFINEMENTS

In UPF 2.0, buffers can be inserted at a given domain boundary port by associating a "repeater supply" attribute with that port. However, this attribute can only be associated with outputs of a domain, not with inputs; this limits its utility. In UPF 2.1, the repeater supply attribute has been replaced with a new strategy command, set_repeater, which supports much more flexible buffer insertion and functions consistently with other strategy commands for isolation and level shifter insertion.

The retention strategy command, set_retention, has also been improved in UPF 2.1. The initial definition for set_retention in UPF 1.0 was modeled on the use of a balloon latch to which a register's value could be saved before power down and from which the value could be restored after power up. UPF 2.0 added the –use_retention_as_primary option to reflect the fact that retention might be accomplished by just keeping the latch powered up. However, UPF 2.0 still requires both save and restore control signals even in this case. Also, the UPF 2.0 semantics for retention do not model very well some aspects of practical implementation methods, such as the "live slave" approach used with master-slave flipflops. In UPF 2.1, the semantics of set_retention have been adapted to allow for various types of retention, with various combinations of control signals, and the UPF 2.1 specification explains how each of these types is modeled in simulation.

SUMMARY

The changes in UPF 2.1 described above are only some of the many refinements that have been made in the new version of UPF. If these changes strike you as minor and incremental, you would be partly right: the changes are indeed incremental, but the aggregate effect is quite significant. Many of these changes focus on improving the precision, accuracy, and fidelity of power intent expressed in UPF, to make the standard easier to use and to ensure that it intuitively captures the concepts and functionality we need to represent. Just as a high-resolution display represents the same images as a lower resolution display but with much finer detail, UPF 2.1 will enable users to model their power intent using familiar concepts but with much greater finesse. Ultimately, the enhanced modeling precision and accuracy provided by UPF 2.1 should translate to higher quality and productivity in design and verification of low power systems.

Although UPF 2.1 is close to final approval, the 16+ user and vendor organizations making up the IEEE P1801 UPF working group will continue driving the evolution of UPF to address new and evolving requirements for low power design and verification. In fact, the next phase of UPF standard development will most likely begin soon after UPF 2.1 is approved, starting with decisions about what issues to tackle next and collection of requirements in those areas. If you are interested in influencing and/or contributing to the further development of UPF, you can join the working group and take part in its regular meetings.2

UPF is supported today by many of Mentor Graphics' products, including Questa Power Aware Simulation (PASim), Olympus, Veloce, Tessent, and Calibre. If you are interested in how these tools support and make use of UPF power intent specifications, contact the corresponding product managers for more information.

END NOTES

  1. Marschner, E., "Evolution of UPF: Getting Better All the Time", Verification Horizons, Oct. 2012 Issue.
  2. For more information about the IEEE P1801 UPF working group, go to the P1801 web page at http://standards.ieee.org/develop/project/1801.html or contact the author at erich@ p1801.org.

Back to Top

Table of Contents

Verification Horizons Articles:

  • What Do Meteorologists and Verification Technologists Have in Common?

  • Using Formal Analysis to "Block and Tackle"

  • Bringing Verification and Validation under One Umbrella

  • System Level Code Coverage using Vista Architect and SystemC?

  • The Evolution of UPF: What's Next?

  • Top Five Reasons Why Every DV Engineer Will Love the Latest SystemVerilog 2012 Features

  • SVA in a UVM Class-based Environment

  • The Formal Verification of Design Constraints

  • OVM to UVM Migration, or "There and Back Again: A Consultant's Tale"

© Mentor, a Siemens Business, All rights reserved www.mentor.com

Footer Menu

  • Sitemap
  • Terms & Conditions
  • Verification Horizons Blog
  • LinkedIn Group
SiteLock