Verifiers rejoice: R&D has just released all-new Assertion-Based Verification IP (ABVIP) code as part of Cadence's Verification IP (VIP) and SoC Catalog offerings.  Specifically, the ABVIP code in the July 2012 release has been completely re-architected to be: 

• Higher performing for both Incisive formal and simulation engines (with gains from 1.5x to ~ 10x!)
• Simpler to instantiate and configure
• Easier to use with context-sensitive IP title support in the SimVision waveform debug environment
• Inclusive of new protocols: APB4 and AXI4

Here are the details:

* The ABVIP code itself has been internally re-architected to reduce complexity, and thus provide higher performance and better quality of results.  For starters, the code has been re-implemented in System Verilog Assertions (SVA) to take advantage of performance enhancements made for the SVA engines in both Incisive formal tools (Incisive Formal Verifier (IFV) and Incisive Enterprise Verifier (IEV)) and Incisive Enterprise Simulator-XL (IES-XL).  In terms of the AXI3/AXI4 titles, the complexity is now controlled by the number of outstanding transactions rather than the width of the ID bus.

* The new ABVIP is simpler to instantiate and configure than its predecessors.  The user simply instantiates the correct model of the ABVIP: master, slave or monitor, and the constraints are automatically configured -- no more need for Tcl configuration.  Furthermore, there are additional capabilities depending on the title selected.  For example, an instance of the AXI3 Master module automatically configures the ABVIP to configure all master properties as constraints without user intervention.

* Waveform debug has been enhanced to automatically provide an IP-title, context sensitive grouping of signals in all formal counter-example, and witness waveforms.  Specifically, when IFV or IEV is being used, the tools are aware of the ABVIP's presence and they create interface signal groupings to aid in the viewing and/or debug of waveforms.  For selected ABVIPs, all instances of the ABVIP interfaces will have their signals available in the waveforms; and each instance will have a separate group of signals in the waveform.  As is evident in the screen shot included below, this is a huge time saver when trying to view witness waveforms or debug failures.

* In addition to enhanced waveforms, for the AXI family of protocols, transaction tables are available to show the currently active transactions.  As shown in the following screen shot for the AXI3 ABVIP, this feature makes it easier understand the currently active transactions and which state they are in. 

In this example, you can see that the ABVIP is configured for a maximum of 2 deep transaction queue where there are 2 valid write transactions in flight, and one valid read transaction in flight, as indicated by the "Valid" column.  Hence, with the waveform cursor it's very easy to deduce the state of the bus at any time in the waveform.

* The following table lists all the supported protocols and features available with each protocol, including the new AXI4 and APB4 titles.  Please note the migration guides are supplied to help existing users migrate to the new ABVIP.

In summary, the new ABVIP models incorporate enhancements to improve performance, simplify instantiation and configuration, provide a more productive debug environment, and expand the catalog to include APB4 and AXI4 protocols.

Jose Barandiaran
R&D Product Expert Team

On Twitter: http://twitter.com/teamverify, @teamverify

And now you can "Like" us on Facebook too, where we post more frequent updates on formal and ABV technology and methodology developments:
http://www.facebook.com/pages/Team-Verify/298008410248534

Reference Link: Cadence's Verification IP Catalog

Over the past several years at various EDA trade events, one of the more popular forums have been panel discussions and interviews asking teenagers about the technology in their daily lives.  However, those forums have been comprised of amateurs, whereas in this interview I've secured a professional technology consultant -- Ms. Kristine Bonhoff, a college student by day, and a paid technical coach and volunteer in her spare time.  Specifically, people of a certain age pay Kristine to coach them on how to get the most out of the various gadgets and related apps they own.  She also volunteers to give tech training courses to inner city residents. 

In this interview Kristine shares her clients' most common FAQs, their biggest positive and negative misconceptions about various technologies, and her wish list for the future.

If the video doesn't play, click here.

I believe you will find much food for thought in her remarks.  My take-away is that there are two clear and very challenging implications for the EDA industry:

* Apps will continue to drive the requirements and demand for their respective host devices, and not the other way around.

* Enabling low cost to the end-consumer - whether it's a low retail price or via clever rent-to-own business models - is as important for our customers as ever.

Joe Hupcey III

On Twitter: http://twitter.com/jhupcey, @jhupcey

Ernie & Duracell

"I feel great" - long pause - "I feel great, I feel great".

6 weeks later: "I feel great, I feel great, I feel great" - pause  - "I feel great".

I hear this sound coming out of my son's room. What is going on in my house? Is there such a thing as too much euphoria? No, sometimes my son does utter this phrase, but most of the time it is coming from an Ernie toy he inherited from his cousin several years ago.

This particular toy is over 14 years old and still "feels great". We had it for over 5 years. So, by now the batteries should have given up. Nonetheless, we still get these random, out of the blue utterances of the phrase: "I feel great". This is supposed to be triggered by some sort of child-toy interaction. However, it mutated into sound generation at random intervals. This phenomenon is very bizarre, as the pauses are very long, causing completely random operation.

The other day the toy went off again: "I feel great". My suspicion was that this might wake up my son in the middle of the night. As Ernie's electronics and wiring obviously have some issues, and as Ernie does not have an on/off switch, my first recourse was to remove the batteries.

To my surprise, the batteries are more than 10 years old and we have never replaced them since we received the toy. The circuit is not supposed to draw a lot of current. However, it is always on and ready to "speak". Overall, this is pretty amazing battery longevity - Hats off to Duracell!

Moving From Sesame Street to the Real World

In verification, your goal is to put the DUT into all known scenarios, and as many unknown scenarios as possible. Constrained random test generation is particularly helpful in achieving the latter. In e [IEEE 1647] constrained random generation is front and center. It is a core principal of the e language and the associated methodology. By default, everything, every aspect and every field, is random in e. This will ensure that you get to as many unknown and unanticipated scenarios to test your device as thoroughly as possible, and that you identify the associated bugs during simulation.  

When everything is random by default you are not at risk of forgetting to randomize any aspects. Consequently, you are less dependent on the quality of your coverage model to detect flaws in the test generation ability of your environment.

JL Gray, VP of Verilab North America puts it like this : "Setting up a verification environment where you have to decide what not to randomize ends up being far more randomized in the end than one where you have to decide what to randomize."

Another effect of default randomization is that it enables early bug detection. More randomization shakes out more bugs. Since detecting bugs early is less costly than detecting them later, this has a positive impact on the overall verification cost.

Default randomization does not imply that you bring up your environment with the wildest transactions imaginable. You still control what you want to see initially. However, it does mean that you are typically moving to a high level of randomization more quickly.

This principal of a default randomized environment, is called Infinity Minus (∞-) and is illustrated by the following code:

// apb_trans_s.e (abridged file) - sequence item definition
struct apb_trans_s like any_sequence_item {

   addr : 		uint;
   data : 		uint;
   direction :	read_write_t;
   delay :		uint;

   ...
}

In this simplified and abridged example of an APB transaction definition, all fields are randomized by default. In other words, you get random addresses combined with random data, random direction (read or write), and random delays between transactions.  Subsequently, you impose rules by adding constraints and reigning in the randomization to suit your particular testing needs.

E * D   ≈ ∞-      Ernie * Duracell ≈ Infinity Minus

The broken electronics in the Ernie toy, and the almost infinite longevity of the Duracell batteries, are behaving just like they are driven by an infinity minus stimulus generator. Ernie feels great at random times, but you will feel great all the time knowing your designs have been verified using the infinity minus verification approach.

Keep on verifying!

Axel Scherer
Incisive Product Expert Team
Twitter, @axelscherer

Starting from version 12.1, the SimVision Watch Window accommodates Specman watch items together with HDL watch items. Now you can use the same window to inspect all your watches.

Hyperlink support in the SimVision Watch Window is still on its way, so right now Specview is the default for Specman watches. Nevertheless, you are invited to try out the new feature and voice your opinion.

To choose which watch window should display Specman watches, use the newly introduced
 "-use_watch_window" configuration option belonging to the "debug" category:

config debug -use_watch_window=window

The ‘window' parameter can have the following (self-explanatory) values:

• specview
• simvision
• both

You can change the configuration "on the fly". Your watch items will be moved to the appropriate window (or copied if you choose both).

You can also change the configuration while still in batch mode. It will take effect whenever you connect to the GUI.

Alex Chudnovsky

Specman R&D

Last week, a favorite customer of mine called me in a panic, just days from tape-out of a large multimedia SoC. After a minor change in their RTL code their Specman testbench started crashing, even though the e code wasn't changed. Could I help?

Knowing that this customer compiles their e code, and that Specman doesn't tend to crash, the first thing I did was to get them to recompile the e code with the debug switch set to irun: "irun -sncompargs -debug". This turns off some of the compiler optimizations. Significantly in this case it turns on null pointer checks in the user's code, since these checks are normally turned off to get higher performance. With debug enabled, the test was re-run and we quickly saw the point of failure: a call to the vr_ad register model was dereferencing a null pointer. Phew! At least I knew Specman's reputation wasn't about to be blemished by some random crash, but why would a minor RTL change cause such a dramatic effect in the testbench?

Knowing the scale of the testbench, and the proximity of the tape-out, I figured we would track down the null pointer problem another day. The more immediate problem was to identify where the RTL had gone wrong so it could be fixed ASAP, but how to pinpoint that bug on such a big chip, from the other end of the phone without even knowing the design? A big challenge...

First we tried running the simulation using UVM FULL verbosity and comparing the log against the previous iteration of the RTL, but this was slow and not particularly easy. I needed a better solution, and quick.

What I hit upon was to take the binary search approach: split the problem into RTL and testbench, and determine which side of the boundary the problem occurred. To enable such an approach, I wrote a small e file that loaded on top of Specman, using the e language's powerful Reflection API to scan the entire design for any "simple_port" connections to the RTL. By fetching the ports' hdl_path() attributes, the script dynamically created "probe" commands for all the ports. My customer then loaded this e code into her "good" and "bad" RTL versions, saving the ~4000 waveforms into two separate database files.

Next we loaded the databases into SimVision and used the powerful SimCompare feature to locate the differences between the two simulations. We nailed the problem in moments: the RTL change had left a register without a reset, leading to large X propagation problems once the reset signal was de-asserted.


Figure 1: Results from a SimCompare analysis highlighting the differences between identical signals from two different databases

With hindsight I found myself thinking, could we have debugged this any faster? Perhaps, if we'd known the exact nature of the RTL changes and where in the design those changed modules were instantiated, we could have started from the changed file and worked forward towards the testbench, but that doesn't work if you don't know every last detail about the design. As an e expert, could I have debugged back from a vr_ad call to understand why that pointer was null? Probably, but it was most likely not an easy thing to trace; after all we didn't know if we should be tracing a wrongly null pointer or an errant call that used a legitimately null pointer.

As it stands, I'm happy that we took the most efficient route; the time to write the e code was minimal, and it made the analysis really simple. Best of all, it required no design knowledge and is totally reusable on any Specman testbench, which is quite a result! All thanks to Reflection and SimVision's SimCompare GUI...

For the curious, here's the e code, a mere 83 active lines including a convenience macro and debugging output code.

Steve Hobbs

>// Dumps an ncsim Tcl script for probing all the signals that Specman is connected to.
//
// Usage:
//
//   load sn_waveports;
//   wave_ports [-db <name>] [-tb <name>] [unit_instance]
//     Where -db is the ncsim SHM database name to generate.
//           -tb specifies the VHDL testbench name to be stripped off.
//           <unit_instance> is something like sys.tb_env.my_agent.smp
//
// Limitations:
//
//   - Macro options are parsed in a basic fashion and must be in the order shown.
//   - Testing has been against mixed Verilog+VHDL designs,
//     Verilog-only names may be mangled.
//   - No support yet for dynamic use in interactve simulation,
//     this is primarily meant for batch-mode use.
//
// Plans:
//
//   - Add support for sending commands direct to ncsim / simvision.
//   - Add grouping to SimVision waveforms, based on unit tree.
//   - Use default "ncsim" SHM if -db not given.
//   - Allow multiple invocations to share the same SHM file.
<'

struct waveports_util {

  !all_signals : list of string;

  !user_tb_name : string;

  dump_ports( db : string, dump_unit : any_unit = sys ) is {
    var version   : string = "0.1";
    var nctcl     : file;
    var log       : file;
    var logName   : string = append(db,".log");
    var nctclName : string = append(db,".tcl");

    nctcl = files.open(nctclName, "w", "Tcl script");
    log   = files.open(logName,   "w", "Log file");

    all_signals.clear();

    files.write(nctcl, "# Auto-generated by sn_waveports utility");
    files.write(nctcl, append("database -open ",db," -shm"));

    files.write(log, append("# sn_waveports version ", version));
    files.write(log, append("#   db   : ", db));
    files.write(log, append("#   unit : ", dump_unit.e_path()));
    files.write(log, append("#   tb   : ", user_tb_name));
    files.write(log, append("#   tcl  : ", nctclName));

    for each (u) in rf_manager.get_all_unit_instances(dump_unit) {
      if u is not a message_logger {
        var subtype: rf_struct = rf_manager.get_exact_subtype_of_instance(u);
        var signals : list of string;
        for each (port_field) in subtype.get_fields().all(it.is_port_instance()) {
          if port_field.get_type() is a rf_simple_port {
            var port : any_port = port_field.get_value_unsafe(u).unsafe();
            var full_hdl_path : string = port.full_hdl_path();
            files.write(log,append("e_path    : ", port.e_path()));
            files.write(log,append("hdl_path  : ", full_hdl_path));
            files.write(log,append("connected : ", port.is_connected()));
            files.write(log,append("agent     : ", port.agent()));
            full_hdl_path = str_replace(full_hdl_path, "/~\//", "");   // remove ~/ prefix
            full_hdl_path = str_replace(full_hdl_path, "/[./]/", ":"); // replace . and / with :
            full_hdl_path = str_replace(full_hdl_path, "/::+/", ":");  // remove multiple colons
            // ignore ports which are not connected or are already probed
            if port.is_connected() and not all_signals.has(it==full_hdl_path) {
              all_signals.add(full_hdl_path);
              if user_tb_name != NULL {
                // search and replace explicit VHDL-TB name if given
                full_hdl_path = str_replace(full_hdl_path, appendf("/^%s/",user_tb_name), "");
              };
              signals.add(full_hdl_path);
              files.write(log,append("hdl_path' : ", full_hdl_path));
            };
          };
        };
        if 0 != signals.size() {
          files.write(nctcl, appendf("# Unit %s\n", u.e_path()) );
          files.write(nctcl, appendf("probe -create -database %s %s\n",
                                     db, str_join(signals, " ") ) );
        };
      };
    };

    if 0 == all_signals.size() {
      out(
        "*** Error: No e ports were found",
        "    Try again after invoking 'gen' to construct the unit tree."
      );
    };

    files.close(nctcl);
    files.close(log);

    out("Wrote ", nctclName, " and ", svcfName,".\nSourcing ",nctclName,"...\n");
    simulator_command(append("source ",nctclName));
  };
};

extend global {
  waveports : waveports_util;
};

define <wave_ports'command> "wave_ports[ -db <db'file>][ -tb <tb'any>][ <du'struct_member>]" as computed
{
  if NULL == global.waveports {
    global.waveports = new;
  };
  if <tb'any> != NULL {
    out("Setting '",<tb'any>,"' as the VHDL testbench name.");
    global.waveports.user_tb_name = <tb'any>;
  };
  var db : string = "sn_waveports";
  if <db'file> != NULL { db = <db'file>; };
  var du : string = "sys";
  if <du'struct_member> != NULL { du = <du'struct_member>; };
  return appendf("global.waveports.dump_ports(\"%s\", %s);", db, du);
};

'>

Luckily I was able to track down my very busy colleague Bin Ju between assignments and interview her about her first-hand observations of what's going on here in Silicon Valley today.  Bin is an expert on formal and assertion-based verification (ABV), so her remarks focus on the trend toward increasing adoption of formal analysis, how users are leveraging "formal apps" to enable rapid adoption of this technology by all team members, and thus how customers' are improving their return on investment.

If the embedded video doesn't play, click here.

Are you seeing these trends in your company?  Please share your thoughts below, tweet or Facebook them, or contact me offline.

Joe Hupcey III
for Team Verify

On Twitter: http://twitter.com/teamverify, @teamverify

And on Facebook:
http://www.facebook.com/pages/Team-Verify/298008410248534

Reference Links
DVCon 2012: Product Engineer Chris Komar reviews the tutorial on formal apps

February 2012: article by industry analyst Richard Goering on, "How Formal Analysis ‘Apps' Provide New Verification Solutions"

In July we released 12 videos of the UVM SystemVerilog Basics series with Chinese audio . Now we are completing the set and releasing the remaining 13 videos.

13. Interface UVC Environment
14. Virtual Sequencer - Sequence
15. Module UVC
16. Scoreboard
17. DUT Functional Coverage
18. Testbench
19. Test
20. Configuration
21. Factory
22. Phases
23. Objections
24. Virtual Interface
25. Class Library Overview

Once more I would like to thank my colleague, Yih-Shiun Lin for his great job in translating the audio. It is his voice you hear on these videos.

Besides releasing the videos to YouTube, we are also publishing them on

YouKu, the Chinese version of YouTube.

Link to YouTube Playlist (Chinese)

Link to YouKu Playlist (Chinese)

Link to YouTube Playlist (English)

Link to YouKu Playlist (English)

Axel Scherer
Incisive Product Expert Team
Twitter, @axelscherer

So you are developing your verification environment in e, and like everyone else, you've been hearing a lot of buzz surrounding UVM (Universal Verification Methodology). Maybe you would also like to give it a try. The first question that pops in your mind is, "What would it take to migrate from e to UVM e?"

Well, this is a bit of a trick question. The short answer is that if you've adopted eRM in the past, migration to UVM e will only take a few minutes. If your environment is not eRM-compliant, it will take you longer.

And now to the details. What exactly is UVM e, in comparison to native e (IEEE 1647), and to eRM? What is in UVM? And what's all the fuss about?

Let's start with a high-level view of the methodology. The UVM describes the creation of a reusable universal verification component (UVC). Each UVC defines a reusable verification environment for one protocol (AXI, PCIe, etc.) or a system (an interconnect, a bridge, etc.). The UVCs are built of agents, sequence drivers (sequencer), monitors, etc. Sounds familiar? Of course. This is eRM, and UVM is based on eRM.

So, the concept and methodology are the same. No "migration" required here.

Let's take a look at the technical details. Other than documentation, what utilities and infrastructure does the UVM package contain? UVM provides a messaging mechanism, synchronization between components, infrastructure for sequences definition and driving. Again, this should be no big news to any e user. These are things you learned in basic e training. It might seem like some terminology is not aligned. But let's look more closely. In UVM documentation or discussions you might have heard the terms "UVC," "sequencer," and "report." These are simply the UVM SV names for "eVC," "sequence driver," and "message,"; all terms you should be familiar with.

And this is why "What would it take to migrate from e to UVM e?" is a trick question. If you took Specman basic training and adopted its guidelines, you are already using UVM e. The "bread and butter" of UVM e has been part of e LRM (and Specman) for several years now.

To paraphrase the French playwright Molière, "Good heavens! For 10 years you have been using UVM without knowing it!"

So if you were simply concerned about trying out UVM, well, you already are using it!

But  Cadence has more to offer. UVM e is being extended with features and methodology examples that target system verification challenges. These new capabilities are part of Cadence UVM open source, which contains the following:

• Base Types - The UVM base types define the components role in the environment, and can be used by other tools (also tools developed by users). For example, to perform some action on all units deriving from uvm_monitor. This is the only element in UVM e that requires modification of existing code, and is not a must in order for the environment to be UVM-compliant.
• Testflow-run-time phases - Breaks run time into various phases, allows defining domains (with or without synchronization), re-runs to a specific phase and also skips to a future phase. (Note: There is ongoing work in the standards committee to implement this in SystemVerilog, but it is ready within UVM e.)
• UVM Scoreboard - Infrastructure for data check, with searching and data transformation algorithms.
• UVM Low Power - A UVC, created automatically based on a CPF file, verifying and stimulating the power aspect of the device.
• UVM Acceleration - User-friendly interface to Palladium, implementing SCE-MI communication between the acceleration machine and the UVC running on the host.
• vr_ad - This register and memory package is now part of the Cadence contribution to UVM e. It became open source, and is being enhanced with additional capabilities (and performance improvements, which should be great news to all of you vr_ad users).

To get a real feeling for what a "UVM UVC" is -- and how it differs from what you already know about verification components in e -- take a simple step: Run the Incisive Verification Builder, and create a UVM e UVC. Next, you can try to convince your colleagues and management that they should also start using UVM e.

Efrat Shneydor

In this post, we will discuss the interesting challenge of reset during simulation.

Specman has a very robust implementation of reset during test, which imitates a return to cycle 0. All threads are terminated, the run() method is called again, and evaluation of temporal expressions is restarted. UVM Testflow has the option to go back to any phase, not just to cycle 0, by calling rerun_phase(target phase). When issuing rerun_phase, making the extreme decision to "just kill all threads" is generally a bad idea. For example, some monitoring threads should run continuously throughout the test, uninterrupted, recording all activities on line.

The UVM Testflow contains an API providing the verification engineers and test writers fine tuned control of component behavior during the rerun_phase.

Let us look, for example, at sequences. Three entities are part of the sequence mechanism:

• 1. Sequence(s)
• 2. BFM
• 3. Sequence driver (seq-er).

Sequence

Some sequences are phase independent. These sequences should continue running completely unaffected by the rerun_phase().

On the other hand, some sequences define a scenario which is phase dependant. Example -- a series of initialization transactions is phase dependant: If the INIT_DUT phase is terminated with a rerun_phase, the initialization sequence should stop.

If a sequence is phase dependent, you should register it to the appropriate phase, so as to achieve the following:

• 1. The sequence is terminated if the phase is terminated.
• 2. If you registered the sequence with blocking == TRUE (that is, the sequence blocks the phase), the domain will not proceed to next phase before the sequence had finished.

You register sequences to a phase using register_sequence. For example:

    !sub_seq1 : SEND_DATA my_seq;

    body() @driver.clock is only {

        gen sub_seq1 keeping {.driver == me.driver; .ctr == 1};

        sub_seq1.start_sequence();

        // register to the FINISH_TEST phase, as blocking

        driver.tf_get_domain_mgr().register_sequence(sub_seq1,

                                                     FINISH_TEST,

                                                     TRUE);

    };

};

Bus Functional Model (BFM)

If a BFM serves one domain, it can be seen as belonging to the domain, and get rerun whenever the domain undergoes reset. On the other hand, if a BFM serves sequences from various domains, the BFM should not be affected by rerun_phase, and should run continuously throughout the test.

Registration of a BFM to a phase is done using the register_thread_by_name api: For example:

Sequence Driver (seq-er)

The seq-er maintains a list of ‘do' requests coming from the running sequences. When rerun_phase is issued, there is a question of what to do with the items in the queue.

One option is for the seq-er to clean the queue, that is, to remove all items and "start from fresh."

However, if the seq-er handles items coming from higher levels that are unaware of the reset, it should not clean the queue. Instead, once reset is finished and BFM up and running again, the seq-er should continue passing to the BFM the items have been waiting in the queue there since before the reset. In this case, the reset of the low level and its BFM is said to be transparent to the high level sequences.

Defining the seq-er behavior upon rerun_phase is done using the seq-er Testflow API. For example:

Read more about Testflow, rerun_phase, and registration of objects in the UVM e User Guide and UVM e Reference manual.

Efrat Shneydor,

UVM e

Right up there with functional verification, the challenges of low power design and verification present an existential threat to our customers' products, and ultimately their businesses.  Clearly both sides of the low power coin -- reducing generated heat and/or increasing efficiency to make the most of every available joule -- are of primary concern.  But what happens when external, environmental factors conspire to betray even the best low power electrical design?  In the case of the GoPro "Hero2" camera, ironically the device's waterproof housing that has help propel this amazing system to some incredible heights can sometimes undermine its operational performance in certain corner cases.

First, let me describe the system setup.  As shown in the image below, the GoPro Hero2 camera is the little cube on the left.  In the middle is the (empty) polycarbonate protective housing that's gasketed to keep out water and dirt.  On the right the camera is sealed inside the housing.

As per this video I shot exclusively with GoPro Hero2 this summer, I can personally attest that the camera and housing make for a very solid and effective mechanical system.  (If the embedded video doesn't play, click here.



Overall the camera performed brilliantly.  However, there was one issue that emerged: whenever the camera got too hot it would automatically shut down to avoid damaging itself.  For example, when the system is in direct sunlight the housing seems to act like a greenhouse and/or it insulates the camera such that the camera heats up significantly faster than when it's out of the housing (especially on an already hot summer day).  So while I praise the Hero2's designers for building-in this automatic fail safe, at the same time it's frustrating to wait for the camera to cool down.  (FYI, keeping the system submerged in the pool, or putting it in a cooler with the drinks and snacks expedites the turnaround process.  But I digress ...)

What are the lessons for EDA here?  I see three:

* The need to model "out of band" behaviors in the digital design domain - i.e. consideration of expected environmental factors in addition to the device's specified logic and firmware performance - will need to become more prevalent as our customers develop more devices destined for mobile use.

* Electronic Design Automation (EDA) will need to get even closer to Mechanical Design Automation (MDA).  I know my colleagues in PCB design and IC packaging are well down this road, but this GoPro case study suggests that SystemC/RTL design and verification must also consider macro-level physical factors as well.  Beyond today's UVM Low Power flows, should there be a "UVM Thermal Behavior" verification flow?

* Last but not least, the general moral of this story is that as far as we've come, collectively the EDA industry has a ways to go before our innovations make low power one of our customers' lower priorities.

Joe Hupcey III

On Twitter: http://twitter.com/jhupcey, @jhupcey

P.S.  For fellow parents:
Chances are you have probably heard of GoPro cameras before, but might have dismissed them as being only for young adventurers.  Certainly GoPro supports such customers and their extreme sports very well.  However, I quickly realized that this camera and its ruggedized shell is as effective for capturing my constantly on-the-go daughter's activities as it is for motor sports and outdoor adventures.  Since I'm constantly asked about the Hero2 system by other parents, allow me to anticipate the question "Does the GoPro ‘work' for capturing family-style activities?" with a hearty "Yes".   In a nutshell, it's a perfect second camera for the many times where you would rather avoid subjecting your "regular" camera (be it a cell phone camera, point&shoot, DSLR, or camcorder) to rigors and risks of family-oriented activities like swimming, bicycling, rainy hikes, and winter sports.

So what’s the big deal with the iPhone 5?

Some folks have commented: "It is “just” a bit faster, taller, lighter – no big deal."

Let me tell you one thing: Seeing, no handling and touching is believing. Like so many devices in the past, you have to try it yourself to appreciate it. It is a similar experience as with the original iPhone and iPad.

The minor weight difference actually makes a huge difference in holding and handling the device. It feels unbelievably light and still very sturdy.

The other major take away is speed. It is particularly noticeable in web browsing. (See video below.) The engineering efforts put into the A6 SOC have paid off. It is very impressive!

As expected the build quality is superb. It is a very noticeable improvement over the iPhone 4S. I love great, high quality tools and hardware. The iPhone5 is smoking and takes the crown.

Go check it out for yourself.

Axel Scherer
Incisive Product Expert Team
Twitter, @axelscherer

Please join Team Verify and other design and verification engineers at the next "Club Formal" on the Cadence San Jose campus on Wednesday, October 17 at 11:30am. This free, half-day event (including lunch) is a great opportunity to learn more about general advances in formal analysis and assertion-based verification, and to network with others in your field.  Based on attendee feedback from previous events, we will deep-dive on the following topics:

* How customers are using the new Coverage Unreachability formal app to save time, power, and die area

* A presentation of the HVC-2011 paper, "Liveness vs Safety - a practical viewpoint", by B. A. Krishna, of Chelsio Communications Inc.

* The award-winning DAC User Track paper on bypass verification with formal techniques, reviewed by Vigyan Singhal of Oski Technology

* Updates and product roadmaps for Incisive Formal Verifier (IFV), Incisive Enterprise Verifier (IEV), and Assertion-Based Verification IP, presented by Chris Komar of Cadence R&D  (You might remember Chris from our DVCon tutorial on formal apps this past spring.)

Again, this free event will run from 11:30am to 4:30pm on the Cadence San Jose campus, Building 10, in the Kirra Point conference room. (Building 10 is the high-rise on the intersection of Montague Expressway and Trimble - street address 2655 Seely Avenue, San Jose, CA 95134).

Sign-in and lunch start promptly at 11:30am.

Register today!  http://www.secure-register.net/cadence/SILR_Club_Formal_4Q12

We look forward to meeting with you soon,

Team Verify

On Twitter: http://twitter.com/teamverify, @teamverify

And on Facebook:
http://www.facebook.com/pages/Team-Verify/298008410248534

P.S.  What's a free "Club Formal" user group event like?  Here are highlights from prior events we've held here in San Jose and around the world: http://goo.gl/3xOK8

Snapshot from the last Club Formal San Jose (with 50 attendees!)

P.S.S. We also support private Club Formal events too, held on a customer's site so attendees feel free to talk about their proprietary challenges.  Let Team Verify know (and/or let your friendly local AE or Salesperson know) an onsite Club Formal would be of interest.  Alternatively, to get the latest data ASAP we can also host live webinars with an agenda focused on your company's formal and ABV top concerns.  (Of course, the downside of this approach vs. going to a public event is you don't get to network with other engineers outside your company to glean new insights, tips, and tricks from their experiences.)

Indexed ports are used to access composite HDL objects in SystemVerilog (SV). Their most frequent use is to access SV multi-dimensional arrays by defining a simple indexed port and accessing the array elements with the port indexes.

Ports in general, and Indexed ports specifically, are static objects that need to be known in the environment build up. Indexed ports were implemented in such a way that each port needs SV stub code, meaning, you have to load your e code and write its stub file using ‘write stub <agent>' command. Otherwise, you would get a checksum error during simulation.

There are several disadvantages of using a stub file:

1. In general, generating a new stub file requires HDL recompilation and re-elaboration. This might take a very long time since it actually rebuilds the entire DUT.
2. Some additional port attributes are required to describe the indexed port characteristics. Those additional port attributes are for stub purposes only, and cthey reate a need for extra coding
3. Non IES (Incisive Enterprise Simulator) users can't use Indexed ports to access Verilog memories; they can only access SV arrays. The reason for this limitation is that the code we generate in the stub file uses constructs that are supported only in SV (DPI-C functions).

After saying this, wouldn't it be nice if we could make indexed ports to work without a stub file?

This is where the new port attribute pli_access() comes to our help. pli_access() allows  you to access the HDL object, in this case the SV or Verilog array, with the PLI -- which is the C interface of the simulator -- rather than through stub access.

Let's look at an example which demonstrates how pli_access() can add flexibility to your code:

//top.sv
module top();
   reg [9:0] arr [10:0][10:0];
endmodule // top

top module has a 2 dimensional array named arr.

Typically, you would define an indexed port to access this array like that:

<' //top.e
method_type foo(a:int,b:int);
unit u {
    p : simple_port (foo) of uint(bits:10) is instance;
    keep p.hdl_BLOCKED EXPRESSION == "<p>[<a>][<b>]";
    keep p.hdl_path() == "arr"; 
};
‘>

But, what if instead of 10, my memory size is determined by parameter? Alternately, the size can be bigger than 32 bits but I don't know it up front. With the regular usage, I have to define the type of the port element prior to run time, so it will go into the stub.

However, using the pli_access() attribute will not create an entry in the stubs, and therefore will not need to know the size before the run. We then can use the port type as a list of bit, which will be dynamically allocated according to what we will assign:

<' //top.e
method_type foo(a:int,b:int);
unit u {
    p : simple_port (foo) of list of bit is instance;
    keep p.pli_access() == TRUE;
    //keep p.hdl_BLOCKED EXPRESSION == "<p>[<a>][<b>]"; //not needed
    keep p.hdl_path() == "arr"; 
};
‘>

As you can see above, we applied the following changes:

1. We set pli_access() port attribute to TRUE, indicating this port should not affect the stub.
2. We don't need to set hdl_BLOCKED EXPRESSION port attribute anymore; this used to define the indexed port access in the stub.
3. We changed the type of the port element to be list of bit instead of a fixed type (this would not have worked without pli_access() in place - Specman would have told us it needs a static type with a known size). In general, If you use pli_access(), you also don't need to use declared_size() indexed port attribute

Please note that pli_access() can be used to access only static arrays which are not defined inside classes.

pli_access() also eliminates the need to create a stub file when using the part select on a signal's hdl_path() when using the VCS simulator.

Please refer to documentation for more information about pli_access().

Nir Hadaya and Avi Farjoun

[Preface: the upcoming "Club Formal" on October 17 here at the Cadence San Jose campus will also touch on this topic - please join us!]

While it's now common knowledge that there are many benefits to using simulation technology within a metric-driven verification (MDV) flow, as it turns out there are also an equal number of benefits to using formal analysis technology in such a flow as well.  Even better, users can combine the resulting metrics from simulation and formal to take advantage of the best each technology has to offer.  However, combining metrics of different types from completely different types of engines is not trivial without common semantics, methodologies, and technologies to harmonize heterogeneous data into something that is meaningful to a metric-driven functional verification flow. 

Recently Team Verify's Chris Komar (a Product Expert that you may remember meeting at DVCon 2012) and our colleague John Brennan (an expert in coverage and metric driven methodologies and tools) gave a webinar covering all these issues and solutions, entitled "Combining the Best of Both in an MDV Flow - Simulation and Formal".  A recording of this free webinar is available at http://www.cadence.com/cadence/events/Pages/event.aspx?eventid=684 (registration is required).

What you will learn from this free presentation is the detailed operational and technical information on how to combine verification metrics from both simulation and formal analysis, allowing you to substantially save in the overall verification effort. A new metric methodology --"enriched metrics"-- managed by Cadence® Incisive® Enterprise Verifier ("IEV") enables the co-operation of engines and, combined with higher level management tools, better visualization and a more refined verification flow.  Consider the following example of enriched metrics in action:

On the left hand side of the diagram are the results from simulation and dynamic assertions; on the right are formal cover and proof results.  In the above example, the results from the formal analysis are a mathematical proof that it's impossible to write a test to hit this cover point.  Hence, you should halt your simulations or formal analysis and begin debugging why this is the case.  The next diagram shows the happier case where the formal results on the right prove with mathematical certainty that this case can never fail.

It's important to note that that while the simulation and dynamic assertion results on the left hand side of this diagram are positive, those results are only true for the relatively narrow cases that the user encoded in the given test(s).  In contrast, the positive formal result on the right is proven true for all inputs, for all time -- truly a relief to know!  Plus: you can also safely stop developing new tests and/or testbenches to hit this coverpoint, often saving substantial amounts of time.  (There are many customers that run formal on an IP block first.  If verification of the block can be completed with firmal alone, they use this results display to show management it's save to move on and/or skip block level simulation.)

Fortunately, in the webinar Chris shows how the results can be fed back into the main project verification plan and results database in a useful way, to wit:

* Checks and coverage are visibly linked to the human and machine readable verification plan

* The user can easily implement appropriate checks as assertions manually, or have the tool generate them automatically given certain specs, and/or leverage Assertion-Based Verification IP

* Assertions can be run on all available formal and simulation engines

* All Ccntributions from all engines shown in a unified view

All of these activities output data in format that makes sense to the simulation-centric management -- and thus, all of the sudden the isolation of formal and multi-engine flows ends, and these tools and related solutions gain mainstream acceptance.

Again, the webinar recording is free (registration is required):

http://www.cadence.com/cadence/events/Pages/event.aspx?eventid=684

and clocking-in at well under an hour, it's perfect for informative lunch time viewing.

Enjoy!

Team Verify

On Twitter: http://twitter.com/teamverify, @teamverify

And now you can "Like" us on Facebook too:
http://www.facebook.com/pages/Team-Verify/298008410248534

Every SoC project uses multiple languages. Even if the design itself is purely Verilog RTL, it's likely that you have some PLI-based stimulus. In many cases there are multiple languages in use due to multiple suppliers, globalized teams, multiple abstractions, and more. Integrating e, SystemVerilog, SystemC, and C/C++ into one simulation is basic but insufficient for SoC verification.  The question asked by SoC verification teams is "how can these work together in a cohesive environment?"

Cadence saw this need in the years leading to the UVM and was the first to contribute a multi-language solution. That work was first contributed to the now offline OVMWorld in 2009. It was updated to align with the Accellera Systems Initiative UVM standard and contributed to the UVMWorld in 2010.  Since then, this solution was updated several times to remain synchronized with the UVM and add new functionality. With more than 1,500 downloads, it remains the first and leading open-source solution for UVM multi-language applications.

On Thursday October 25 at 9:00 am PDT, we'll review the solution and discuss the latest new features.  This technical discussion will be lead by Gabi Leshem, Solutions Architect, and Guy Mosenson, Senior Solutions Architect using the Incisive Verification Kit delivered with the Incisive Enterprise Simulator.  The Incisive Verification Kit is a superset of the Cadence UVM reference flow (with 4,000+ downloads covering v1.0 and v1.1) available on UVMWorld.  During the discussion you will learn about the following topics:

• Requirements for modeling multi-language UVM-based environments
• How to implement and integrate a UVM-ML verification environment
• Multi-language communication and synchronization features
• Advanced debug techniques key to analyzing multi-language environments and resolving multi-language issues 

So if you are a verification engineer, designer, or manager interested in leveraging existing VIP and improving reuse, this webinar is for you.  You can register for the webinar here:  http://www.cadence.com/cadence/events/Pages/eventseries.aspx?series=Functional%20Verification%20Webinar%20Series%202012&CMP=Home.

Regards,

 Adam "ML" Sherilog, Incisive Product Marketing Director 

Two of the key factors for successful and productive simulation-based hardware verification are an  efficient verification language and an associated methodology. As the global design and verification eco system is scattered and evolving rapidly, it is hard to keep all engineers trained.

We are looking at MOOCs, Massive Open Online Courses, as popularized by organizations like Khan Academy, to address the need for more accessible and globalized training. To determine how MOOCs can be applied to verification training, we are partnering with Udacity, one of the premier players in this field.

MOOCs require a very different approach. Repurposing traditional, in-person training is not sufficient. The challenge is to keep students engaged while keeping the material at a high standard. This is not trivial, as online users can be distracted very easily and the online drop out rate is even higher than in the real world.

Our class on Udacity is called: Functional Hardware Verification: How to verify chips and eliminate bugs. More information on this class can be found here:
http://www.udacity.com/overview/Course/cs348/CourseRev/1

Udacity announced our class and classes from other industrial partners such as Google, Microsoft, AutoDesk, and Wolfram, in their press release today

See the promotional video below.

Get your MOOCs on!

Axel Scherer
Incisive Product Expert Team
Twitter, @axelscherer

Last week over 35 power users from over a dozen companies came together for the latest installment of "Club Formal" -- a user group meeting exclusively focused on topics in formal analysis and Assertion-Based Verification (ABV).  This instance of Club Formal featured several papers from Silicon Valley power users on expert-level techniques, as well as highlights of new "verification apps" that are highly automated such that any engineer can run them.  In addition to networking with industry peers, Cadence R&D and field specialists were on hand to share our product roadmap and discuss new requirements from the attendees to better align our R&D development with their needs.

[

Here are some specific highlights of the event:

Expert Presentation: Liveness vs. Safety
B. A. Krishna of Chelsio Communications Inc. treated the attendees to an encore presentation of his HVC-2011 paper, "Liveness vs. Safety - a practical viewpoint" (full citation below).   The DUT at the heart of the paper was a Deficit Weighted Round Robin (DWRR) arbiter, and the critical verification task was to check if the port will be eventually given access to a given grant, regardless of the weight distribution across ports. One verification option is to write this as a "liveness" property.  As Krishna explained, on the plus side this is easy and/or intuitive to write. However, for verification purposes it required considerable effort to identify abstractions that could get conclusive results for the property. 

The other option is to write a "safety property".  Unfortunately, this requires a lot of effort in finding out the upper bound for forward progress. This was a painstaking process, but once they had written the property, verification did not require any abstractions - it's practically DUT independent.  For the given project they had the opportunity to apply both methodologies and compare the two, and thus the conclusion of the paper was an insightful review of their results and/or which approach would make more sense in a particular scenario.   Given the amount of questions and discussion this paper prompted, it was clear the merits of both approaches were of keen interest to the audience.

Expert Presentation: Bypass Logic Verification
Bypass logic verification is a common and difficult challenge for modern VLSI design that arises in the verification of CPU, GPU, and networking ASICs.   If you miss a bug in the bypass logic the whole system can simply freeze.  In this presentation, Club Formal alumni and favorite speaker Vigyan Singhal of Oski Technology gave an encore of the 2012 DAC User Track Best Presentation award-winning paper on this challenging topic, entitled "Deploying Model Checking for Bypass Verification" by engineers from Cisco and Oski Technology (full citation below). 

For starters, the DUT was a bear featuring a tough-to-verify, 25-deep bypass logic schema.  In a nutshell, their technique was to use the DUT itself as a reference model based on the fundamental principal of bypass logic: whether the bypass is active or not, the results should be the same regardless. In this case, the input commands to the reference model (1st DUT instance) have been separated by 25 cycles where the bypass logic is inactive. However, the challenging twist is that input commands to the 2nd DUT instance are randomly separated by anywhere from 1 to 24 cycles.  Another key factor to their success was using "memory random" as a simple abstraction of the design depth.  This allowed the tool to concentrate on the key elements of the DUT/state space. 

Bottom-line: they achieved phenomenal results, with 10 bugs found in this already heavily simulated IP.   Indeed, many corner cases they reached with formal would have been practically impossible to reach with only a constrained-random, simulation-based testbench given the permutation of command-combinations, the number of cycles that each command pair was spaced out, and so forth.

Roadmaps and New Product Previews
Chris Komar of Cadence R&D - specifically, a leader of the Product Expert Team - took the stage to give sneak previews of a new verification app coming out in just a few weeks, as well as the 18 month roadmap for our whole verification apps portfolio, expert level flows, and enhancements to the Incisive Formal Verifier (IFV) and Incisive Enterprise Verifier (IEV) platforms.

Allow me to again thank the attendees for their warm reception of our product roadmap, and being generous with comments about where you'd like to see more attention.  This feedback is invaluable to R&D, and as you saw we were all taking careful notes.

Lunch, Snacks and Networking!
Last but not least, the intermissions and social segments were of high value as well.   Whether it was the casual lunchtime discussions, or informal Q&A during the breaks, truly these venues - comfortable, community settings where users get to swap stories with other users to brainstorm solutions and share tips&tricks -- were some of the best parts of the day.  I know my Cadence colleagues appreciated your feedback and ideas!

Bottom-line:
An engaging, informative time was had by all, and I believe I speak for everyone in looking forward to the next Club Formal!

Until the next time, happy verifying!

Joe Hupcey III
for Team Verify

On Twitter: http://twitter.com/teamverify, @teamverify

And on Facebook:
http://www.facebook.com/pages/Team-Verify/298008410248534

Reference Info: Paper Citations
Haifa Verification Conference 2011: "Liveness vs Safety - a practical viewpoint"
B. A. Krishna, Chelsio Communications Inc, San Jose, CA
Jonathan Michelson, Cisco Systems, San Jose, CA
Vigyan Singhal, Oski Technology, San Jose, CA
Alok Jain, Cadence Design Systems, Noida, India

DAC 2012 User Track: 8U.2 - Deploying Model Checking for Bypass Verification
Prashant Aggarwal - Oski Technology, Inc., Gurgaon, India
Michelle Liu - Cisco Systems, Inc., San Jose, CA
Wanli Wu - Cisco Systems, Inc., San Jose, CA
Vigyan Singhal - Oski Technology, Inc., Mountain View, CA

P.S. Team Verify is working on the 2013 event calendar now.   Hence, this the perfect time to let us know If you would like to see a Club Formal in your area!  Simply jump to the Team Verify home page and "send Team Verify a private message".

P.S.S.  In case you are unable to attend a Club Formal near you, be sure to check out our calendar and archived recordings of free, technical webinars:
http://www.cadence.com/cadence/events/pages/default.aspx

Working with the conventional Specman C language interface has two major disadvantages:

1.       There is a tight dependency between the e code and the C code. The user must include the Specman header file which was generated based on the e code. Every minor change in the e code requires regeneration of the header file.

2.       The C interface doesn't support calling e TCMs (Time Consuming Methods) from C code.

Let's take a look at the following C interface example:

<' //top.e

struct packet { ... };

unit u { 

    send(p:packet) is dynamic C routine libtest.so:;

    update()@sys.any is {

        wait [10];
        message(LOW,"[e] update after waiting 10 cycles");
        //do something

    };

    main_thread()@sys.any is {

        gen p; //a packet
        send(p);
        stop_run();

    };
};

C export u.update();

'>

In the above example we show the send() method which is implemented in C and therefore defined as dynamic C routine. update() is exported so you can call it from C code.  

The C code then implements send() and calls update() with SN_DISPATCH:

/* test.c */
#include "sn_top.h"
#include <stdio.h>

void send(SN_TYPE(u) me, SN_TYPE(packet) p) {

  /* Do something */
  SN_DISPATCH(update,me,u,(me));

}

This simple example illustrates the two disadvantages we mentioned earlier:

1.       Tight dependency - sn_top.h which is included in the C code must be regenerated each time the e code is changed no matter what the change was. Of course, regenerating the header enforces recompilation of the C code...

2.        Calling TCMs - update() is a TCM, "The run-time behavior of a TCM called from C is undefined" (quoted from Specman docs). Trying to run the example above will give an OS11 error. Undefined indeed...

The new Function Level C interface addresses those issues. Let's take a look in the following modified example:

unit u {

    //send(p:packet) is dynamic C routine libtest.so:; old declaration
    send(p:packet)@sys.any is import C libtest.so:;

};

//C export u.update(); old declaration
export C u.update();

As you can see, the e code remains the same but we changed the way we export and import the functions. Please note that send() was changed to be a TCM; this way we can call update() TCM from the C code.

And the new C code looks like:

#include "sn_fli_top.h"
#include "e_func_intf_user.h"
#include <stdio.h>

void send(eStructHandle me, eStructHandle p) {

  /* Do something */
  update(me);

}

You might want to pay attention to the following:

• We use a header file sn_fli_top.h which is a generated header file, but in this case we need to generate a new file only if we change one of the export or import prototypes.
• Structs and lists parameters are passed as handles (eStructHandle or eListHandle).
• e_func_intf_user.h contains some auxiliary routines to take care of the handles. For example, to get or to set an item of a list. This file resides in Specman installation directory.
• We call update() directly, SN_DISPATCH and other C interface macros are not needed anymore. Note that the first argument is the instance which routes the call.

How to generate the new header file? Which auxiliary routines does e_func_intf_user.h define?  What about save-restore flow?  You can get the answers to these questions and more details in Specman documentation.

Enjoy,

Nir Hadaya

Specman R&D 

Recently an EDA industry observer relayed some Specmaniacs' concerns about satisfying the increasing demand for e/Specman trained verification engineers in Europe and other geographies.   Team Specman is seeing this growth too, and here is what we [Cadence] are doing to help:

* First, we have a network of expert e/Specman service providers located around the world (many of which who can support projects in geographies other than their headquarters location).  Our list of "Verification Alliance" partners is here: http://www.cadence.com/Alliances/verificationalliance/pages/default.aspx

I welcome specific queries to me offline so I can help introduce Specmaniacs to these firms -- just use the "Contact" button at the upper right hand side of this page.

* Current Cadence customers and partners should be aware that they now have access to free online e/Specman training for refreshing their skills, or training someone from scratch.  To apply for this, send an email to training_enroll at cadence dot com with "SPECMAN" in the subject line, and the following information in the message body - Your Name, Company, Address, Phone, name of your Cadence Sales person or partner program contact -- and our Educational Services team will follow-up with you.

* Finally, in partnership with leading massive open online course (MOOC) provider Udacity, in early 2013 we are offering a course on functional verification with the e language (IEEE 1647).  The course is free and open to all - pre-register on the Udacity web site now: http://www.udacity.com/overview/Course/cs348/CourseRev/1

Hannes Froehlich
Team Specman Solutions Architect

If you are a Specman vr_ad user, you probably know that register access is implemented  using the read_reg / write_reg. For reading/writing a register, you have to

1. Extend a vr_ad_sequence

2. Add a field of the type of the register you want to access

3. In the body() , call the read/write_reg

For example:

extend MAIN vr_ad_sequence {

    !tx_data_reg : VR_AD_TX_DATA  vr_ad_reg;

    !tx_mode_reg : VR_AD_TX_MODE  vr_ad_reg;

    body() @driver.clock is only {

        read_reg {.driver == reg_driver} tx_data_reg;

        read_reg {.driver == reg_driver} tx_mode_reg;

    };

};

For simplifying test writing, starting Specman 12.1 the read/write_reg actions can:

• Be called from any TCM, not only from within a sequence
• Access not only a local field, but also a variable, or a reference to a field within the e registers model

One of the nice capabilities achieved with these enhancements is that you can embed access to registers among other activities. For example -- in a system level sequence, as in this code example :

extend SEND_AND_CHECK system_seq {

  !serial_frame : LEGAL frame;

  body() @driver.clock is {

    // Perform activity on serial interface, via the i/f driver

    do serial_frame on driver.serial_driver; 

    // Local variable of a register, read it and check the value

    var status_reg : STS vr_ad_reg;

    read_reg {.driver == driver.reg_driver} status_reg;

    check that status_reg.get_cur_value() == 0x37;

    // Access registers without defining fields nor variables

    write_reg {.driver == driver.reg_driver} driver.reg_model.reg0 val 0x12;

    write_reg {.driver == driver.reg_driver} driver.reg_model.reg1 val 0xFA;

    write_reg {.driver == driver.reg_driver} driver.reg_model.reg2 val 0x3;

    write_reg {.driver == driver.reg_driver} driver.reg_model.reg3 val 0x0;

    };

};

Note that register accesses are handled by the vr_ad_driver. So, when accessing a register from a TCM which is not a vr_ad sequence, you have to specify the vr_ad_driver to handle this operation.

We encourage you to check out the latest UVM e reference manual and user guide for details (both are part of Cadence Help).

Enjoy verification

Efrat Shneydor & Reuven Naveh,

UVM e