Home > Community > Blogs > Functional Verification > constrained random test generation in e ieee 1647 ernie duracell infinity minus
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Constrained Random Test Generation In e [IEEE 1647], Ernie * Duracell ≈ Infinity Minus

Comments(2)Filed under: Functional Verification, Testbench simulation, Verification methodology , SoC, eRM, SystemVerilog, IES, Specman, IEEE 1647, hvl, verification, Incisive, uvm, testbench, simulation, e language, coverage, universal verification methodology, YouTube, uvmworld.org, Incisive Enterprise Simulator, video, Axel Scherer, UVM training, test generation, UVC, Constrained random, UVM tutorial, verification tutorial, video tutorial, Stimulus, URM, cowbell, Infinity minus, Duracell, Ernie

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

Comments(2)

By Igor Krymgand on August 9, 2012
Axel, chapeau! Funny and precise explanation about the way constrained random test generation has to be applied...... Unfortunately,however, in many cases verification teams behave the opposite way - starting with very limited randomization (sometimes even with no randomization at all and single seed) calling it "bring up testing",then they proceed to "advanced testing" which is usually a flavor of "bring up" but involves more tests and 2 :) seeds ....and then they eventually run out of project time......so poor Ernie does not even get a chance to feel anything

By Axel Scherer on August 21, 2012
Hi Igor - Agree -there is a wide spectrum of approaches. Projects and developers have many constraints, legacy, experience and so forth. The good news is that more people are moving to advanced verification flows. Eventually almost everyone will join Ernie on Sesame Street to combat verification challenges. Axel

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.