Introducing soft constraints in SystemVerilog 2012

A well known aspect of constraint solving is the ability to classify hard vs. soft constraints. A quick Google search on “soft constraints” would lead you to; http://www.constraintsolving.com/tutorials/soft-constraints-tutorial in case you are interested in theory.

Taking a practical example, given the holiday season around the corner many of us would like to travel, book tickets etc. Let’s say that we want to travel from City-1 to City-2 (Say Bangalore to Chennai); the source & destination are fixed and are non-negotiable. But how we travel can be based on preference/availability/cost etc. For instance one may have options of:

• Flight
• Bus
• Train
• Car

Now modeling the above scenario using a constraint specification language like the one in SystemVerilog, there are “constraints” as below;

class my_travel_c;

  rand places_t src, dst;

  rand int cost;

  rand travel_mode_t travel_mode;

  // Non-negotiable src and dest locations

  constraint src_dst_h { src == BLR; dst == CHENNAI;}

  constraint minimze_cost { cost < 2000;};

  constraint travel_preference {travel_mode inside {AIR, BUS, TRAIN};}

endclass : my_travel_c

Now depending on various factors the cost & travel-mode constraints may not be solvable. For instance if only AIR travel is desired, the cost constraint is likely to be violated. As an avid traveler you may not mind that violation and say YES it is fine! But how do you tell that to SystemVerilog? In the past one may go and turn-off the relevant/violating constraint via constraint_mode(0);

However that becomes tedious as before every randomize call you would need to do it (perhaps across testcases).

Welcome the all new System Verilog 2012 soft constraint:

Now if the solver can satisfy the SOFT it shall, and provide you the optimal cost and travel experience. However in case it can’t, the soft can be “ignored” and other HARD constraints shall be obliged!

Now that’s a pleasure luxury to have a set of “default” values while designing the environment and use “soft” constraints, let the tests/scenarios override the same as needed.

BTW – this has been a widely used feature in e – IEEE-1647 language (many engineers relate it to the tool Specman, most popular implementation of the e language). So much so that a new user migrating from Specman to SystemVerilog finds it often annoying not to have this “feature”. Now, thanks to Santa in 2012, come 2013 – you will have that in SV too! Now it is time to ask for your XMAS wish with Santa and your EDA vendor to get this implemented in your favorite simulator!

Have a pleasant journey, holidays and be ready to rock even more with all the more powerful SystemVerilog 2012 soon!

Technorati Tags: SystemVerilog,EDA

Bringing in uniqueness constraint to SystemVerilog – welcome P1800-2012

If you are involved in functional verification I am sure you have atleast heard of System Verilog as the IEEE standard. The first IEEE standard was released back in 2005 and went in for a revision during 2009. Now there is yet another major update – 2012, expected to be fully ratified by early 2013 (on time for DVCon 2013). Here is a nice blog on this: http://blogs.mentor.com/verificationhorizons/blog/tag/ben-cohen/

A major part of this new version is all about assertions/SVA. If you need a detailed list of changes and examples, with applications – look no further, get hold of our new SVA 3rd edition @ SVA book 3rd edition @Amazon

In this article I wanted to introduce another nice, tiny, handy feature – unique constraint in SV. To give a background, consider a classical crossbar switch:

 

While every CPU can talk to/access every memory, for every access uniqueness must be maintained in terms of one-to-one connection. This is usually referred to as “Uniqueness Constraint” (ref: http://www.wonko.info/ipt/iis/infosys/infosys5.htm). In SV 2012, with unique constraint feature one may code a transaction model for this as:

 

 

One could perhaps combine this with a foreach and make it more elegant etc. But the bottomline – the unique constraint is really handy at times!

Welcome SV 2012/2013 :-)

Now our training in VSV (http://www.cvcblr.com/trng_profiles/CVC_LG_VSV_profile.pdf) can cover this as a lab exercise – make sure you enroll in a session to learn more! See: http://www.cvcblr.com/trainings for more!

Technorati Tags: SystemVerilog,EDA

Help yourself & UVM community by sparing few minutes – Verilab’s UVM survey

 

UVM Runtime Phasing and Phase Jumping Survey

If you are well aware of UVM runtime phasing/phase jumping issues, quickly help yourself and the UVM community at large by filling out this survey:

• Verilab UVM Phasing Survey

Now for a background and for those who are “undecided” whether or not I have an issue with it, here is more information:

One of the significant updates done to OVM while bringing up UVM as the standard for verification methodology was the phasing. (For a detailed paper on user issues with OVM phasing approach, see: http://www.synopsys.com/community/snug/india/pages/abstracts.aspx?loc=india&locy=2011 and https://www.synopsys.com/news/pubs/snug/india2011/TA1.2_Intel_paper.pdf)

As with any standard development, there are differing view points coming from various experts, users etc. around the globe.India being the most vibrant Verification geography, it is very probable that many of the verification leads here face these problems day-in and day-out. So why not speak up and help us fix the UVM phasing the way YOU would like it?

Verilab, a premier verification consulting firm based in the US is conducting a survey to find out whether UVM users are currently taking advantage of runtime phasing and phase jumps, and if so, whether or not they would be impacted by certain changes the committee might propose.

So in case you are an active user of UVM, please spare a few minutes and take the survey at:

• Verilab UVM Phasing Survey

Technorati Tags: UVM,EDA,VIP

Is my SystemVerilog mailbox half-full or half-empty? An engineer’s hunger now served!

As we wrap up 2012 with yet another successful VSV course at CVC today’s  topic was IPC in System Verilog. As most of the attendees in this session are young engineers, they have a constant thirst for knowledge and demand more. We at CVC love that challenge. Based on last few sessions we created more smaller examples around threads, mailboxes for the engineers to play around with. Here are some of the meddling around experiments you may do with Mailboxes in SV.

To start with – the size of the mailbox – a.k.a the DEPTH of the FIFO: Here is how you configure the same (the formal argument is named as bound by LRM):

And we had some interesting discussion around the bound & num()  - similar to FIFO’s DEPTH and LEVEL:

To get the code part of it straight, here is what LRM has on these 2 methods:

function new (int bound = 0);

i.e. the constructor for mailbox has an argument that’s defaulted to 0 – be careful with it, this could lead to memory leaks from user code (See: http://www.cvcblr.com/blog/?p=29 )

The summary there – use sized mailbox always. This would fix the DEPTH of the FIFO or the Mailbox:

Now there is a method to get the “current level” of the Mailbox, with prototype:

 function int num ();

Here is a pictorial way to explain its usage:

 

                              

 

To look at some SystemVerilog code:

And to close this article with more pictures than usual – be careful with generic mailboxes – i.e. those with no explicit parameterization. Avoid them if you can, watch this space www.cvcblr.com/blog for an upcoming article on that.

Do more with SystemVerilog! And do call us via training@cvcblr.com in case you want to learn SystemVerilog the right way!

 

Technorati Tags: SystemVerilog,EDA,training

Easier PLI integration with MPSim

Several engineers working and aspiring to work in the field of ASIC front-end design/verification tend to stay away from Verilog’s powerful PLI/VPI – some of them because they see it as old technology and many others – simply “FEAR” from it, thanks to its complex integration with the tools.

For those who believe it is old technology – think again, most of the cutting edge EDA innovations (in front end) happening around verification use Verilog’s PLI/VPI to talk to your underlying simulator. To quote a few examples:

1. NextOp/Atrenta’s BugScope 
2. Novas’s Verdi/Debussy
3. Axiom’s @Designer http://www.axiom-da.com (Debugger that can work with all standard Verilog simulators)
4. Trek from Brekersystems (www.brekersystems.com)
5. OnPoint from vennsa-da.com

Now for those who “fear” from VPI due to its integration challenges – to be fair – you’ve reasons to do so. However advanced functional verification solutions such as VCS, MPSim (http://www.axiom-da.com ) provide a convenient TABLE format to ease this task. All you need to do is to create the following table:

And use standard gcc to compile your C-code as below:

gcc -m32 -pipe -c -g ../pr_tscale.c -I$(ATHDLROOT)/tb/incl –DAXIOM

Now, invoke the atsim compiler with the tab-file as shown in below command:

atsim -c ../pr_tscale.v +tabfile+pr_tscale.tab +pliobj+../pr_tscale.o
./athdl_sv

 

For those trying it out at your end, notice the path to the *.o file should have “../” as the atsim compiled one-dir below (hidden dir).

Now if it was this simple, why would anyone FEAR  from it really? The answer is – that’s how the Verilog LRM defines it to be, see below if you have time and patience. Advanced verification platforms like MPSim will hide these details for you for your pleasure adn ease-of-use!

For those uninitiated with this fear, see how the Verilog LRM defines a data structure for this purpose below: (extract from standard vpi_user.h)

 

 

 

Now to use it in an end-user application such as the one found at: http://www.cvcblr.com/blog/?p=517 one needs to create a variable of this structure and fill in the integration details, see below:

If you managed to read up to this – then you are convinced that integration of VPI code isn’t for everyone – if not for tools like MPSim !

Good Luck!

TeamCVC 

Technorati Tags: Verilog,PLI,VPI,MPSim,EDA

Reducing power in a smartphone – who-will-bell-the-cat? – Possible answers from ARM

Earlier this week, Simon Segars, EVP & GM Processor and Physical IP Divisions (http://linkd.in/ThbmbZ) presented an excellent keynote at an invite-only, executive dinner event around the CDNLive India 2012 http://bit.ly/TxallC organized by Cadence. Our CTO Srini (http://linkd.in/e6cSbd)

His theme was around the low power requirements in modern mobile devices (understandably, as the market needs this topic and who is in a better position than ARM can talk about this – being at the center of most of those smartphones!)

In a well drafted, upto-the-point, picture-centric presentation Simon did a great job of explaining what ARM’s big.LIITLE architecture is all about!

As of today, ARM provides Cortex A-15 like cores for the high-end devices:

 

Quickly ARM realized there is a strong need for low-energy, low-cost cores too to serve the entry level smartphones – here comes the ARM Cortex A-7

 

Now with lot of data mining and analysis Simon showed a typical pattern that revealed 2 important data points:

1. For a whopping 88% of the time in a day, the kind of applications that are run on a smartphone can be done using a processor with speed < 500 MHz
2. For the remaining 12% the frequency needs to be > 500 MHz – these are the videos, gaming etc.

Agreed, your numbers may vary, but the fundamental point is – one could do lot of power saving if we have a big processor to serve the high-end apps and a LITTLE processor to attend to the regular, most-of-the-day work such as MP3 playback, phone calls etc.And this is precisely what ARM’s big.LITTLE architecture is all about – have dual cores with Cortex A-7 & Cortex A-15. I found a slightly older slide on a quick Google search as below (Simon had an updated version of the same)

 

Now of-course you need multiple teams to take advantage of such an architecture to deliver low power promise to the end user. Simon showed a nice slide listing some of the key stakeholder/steps:

• The system architects to decide which app will run on which core
• The underlying OS to be able to support such a live-scheduling
• The design team to design and implement the various low power techniques such as the DVFS
• The all the more important DV team doing the functional Verification to ensure all the valid power state scenarios are working fine
• Backend team to implement the intended power-save architecture in layout
• Circuit designers to do their bit in choosing various low level power saving techniques

Now going back to our starting question of “Who-will-bell-the-cat” of that “magical low power smartphone chip” – Simon concluded it is ALL-of-us together who need to do this – can’t achieve this level of gains without collaboration!

We at CVC are doing our part of the ecosystem work by developing advanced low power verification training on UPF, CPF modeling, case studies on a UVM SoC Kit etc. So if you are in need of verification training on any of these topics, call us via +91-80-42134156 or training@cvcblr.com

 

Technorati Tags: Low Power,EDA,ARM,Cortex,UPF,CPF,UVM

Upgrade yourself to SystemVerilog 2012 – our SVA handbook, 3rd edition is published!

They say “innovation never stops” – it is true for the SystemVerilog language committee. And it is very true for our co-author Ben Cohen, who even at the retired age keeps updating himself on latest on SV, VMM, OVM, UVM and of-course SVA. Ben Cohen is the Accellera nominated representative for the SV-AC committee on IEEE dev team.

See TOC at: http://systemverilog.us/SVA3rdE_preface_toc.pdf

The cover of this book is a NASA photograph of Mars, taken by Curiosity. Just like how Mars is enormously big, the verification state space of most of the modern day designs are extremely large. While there have been several advances in the area of "stimulus" or "activation of potential design errors", the amount of checking being done during such activation (either via simulation or formal analysis) demands detailed, precise design specification. This is precisely where SVA fits in the design flow. Just like how the whole world awaits pictures & findings from Curiosity to learn more about Mars, SVA could be used by the design verification teams to learn about the functional quality of designs.

Here is what the forewords say:

Dennis Brophy Director of Strategic Business Development, Mentor Graphics.

 

In 2010, research showed use of SystemVerilog was up more than 233% over prior years with more than 7 out of 10 design and verification engineers using it. Even more telling was the use of the SystemVerilog Assertions (SVA) part of the standard. Research showed that assertions enjoyed the same high level of use with 7 out of 10 design and verification engineers adopting SVA.
Assertion based verification (ABV) methodologies has been found to address design and verification challenges and the market use reflects it. The assertions portion of the IEEE SystemVerilog standard has also been enhanced over these years to extend and improve what can be done with them based on the cumulative experiences of the design and verification community to date.

The third edition to the SystemVerilog Assertions Handbook comes at a time when the IEEE updates its popular SystemVerilog standard and at a time when the FPGA community is increasing its adoption of SystemVerilog assertions as well. Design and verification engineers will find the handbook useful not just as a resource to begin to adopt assertions, but to apply the latest additions and updates found in the IEEE standard to the ever pressing design and verification challenges.

 

 

Sven Beyer, Product Manager Design Verification, OneSpin Solutions

http://www.onespin-solutions.com/

The SystemVerilog standard itself has been very much alive with two updates in 2009 and now in 2012, enhancing many existing features and adding numerous new ones. So more and more engineers are exposed to SVA while at the same time, the standard quickly evolves, trying to address the growing needs of those engineers for more productivity. This definitely calls for a first class reference documentation – and this book, SystemVerilog Assertions Handbook, 3rd Edition by Ben Cohen, Srinivasan Venkataramanan, Ajeetha Kumari, and Lisa Piper, provides such a comprehensive reference manual that is suited for both SVA power users and novices. It introduces assertion methodologies and gives a clear idea on what assertions are good for,addressing both coverage and the complementary strengths of dynamic and formal verification. It carefully
lays out the numerous SVA language constructs one by one in a way that really gets across to the typical engineer, emphasizing the intended usage, adding telling examples, and listing the counter-intuitive pitfalls that may cost an engineer precious time in debugging. Therefore, this book is sure to find its place on the bookshelf of numerous engineers all over the world, and since it is the first comprehensive reference manual to also address the IEEE 1800-2012 standard, for example with its numerous enhancements to the checker construct, it is sure to remain on this shelf and be extensively used for quite some time.

 

Stuart Sutherland , SystemVerilog Training and Consulting Wizard
Sutherland HDL, Inc.
http://www.sutherland-hdl.com

The complexity of the design we need to verify requires that an assertions language has a robust set of features and capabilities. The SystemVerilog Assertions (SVA) language meets that rigorous requirement. The robustness of SVA also means that it can be challenging to learn to use SVA -- and to use it correctly. The SystemVerilog Assertions Handbook is an essential resource for overcoming that challenge. The book examines the use of SVA in the context of verifying true-to-life designs. Thorough explanations of each feature of SVA show the where and how to use SVA correctly, as well as point out pitfalls to avoid. At my company, we feel this book is so essential for understanding and properly using SVA, that we include a copy of the book as part of the standard training materials in all of our “SystemVerilog Assertions for Design and Verification Engineers” training workshops.

Cristian Amitroaie CEO, Amiq

.

The first benefit this book brings is a systematic and clearly organized perspective on SVA, from planning to terminology, from how assertions work and how to debug them, to coverage driven and formal verification using assertions. This includes the language clearly identified rules, and many tables and figures annotated with comments.

Second it offers many concrete examples. Examples are fresh air for engineers when diving into complex topics and this book has plenty, including the mapping between natural language and the corresponding SVA implementation.

Third, it contains guidelines on what to use and what to avoid, based on experience with both SVA and UVM. Knowing and following best practices are essential to engineers these days, when work pressure doesn't leave much time to carefully digest all the implications of the highly sophisticated means we use on a daily basis.

This is a book every engineer should keep handy!

Technorati Tags: SVA,Assertions,SystemVerilog Verilog EDA