Functional Verification - All Comments

Backward compatibili ...

JL Gray — Fri, 19 Mar 2010 13:15:52 GMT

Backward compatibility will likely be maintained with OVM 2.0.3... not OVM 2.1. As an example, it was agreed that some changes will be made to the end of test mechanism from what was implemented in 2.1 before adding that code to the UVM. Therefore, that feature will not work in the same way with the UVM. Other similar issues may come up before the UVM 1.0 is complete.

JL, I quite delib ...

tomacadence — Fri, 19 Mar 2010 11:28:49 GMT

JL,

I quite deliberately said "apparently decided" because I had not heard anything about the TSC formally voting to use OVM 2.1 as the base rather than 2.0.3 so indeed the details could change. But adding callbacks and end of test (plus bug fixes) in the initial UVM release would get the essence of OVM 2.1 included. Of course, you already know my strong opinion that any modifications that might be made to callbacks, end of test, or anything else already in OVM x.xx must be backwards-compatible for the benefit of the enormous user base.

Tom A.

Built-in Message Logging – Part 2 of 2

Functional Verification — Thu, 18 Mar 2010 10:25:59 GMT

[Team Specman welcomes back guest blogger, Michael Avery from our Services Group in the UK] Building

Built-in Message Logging – Part 2 of 2

Functional Verification — Thu, 18 Mar 2010 06:47:58 GMT

[Team Specman welcomes back guest blogger, Michael Avery from our Services Group in the UK] Building

Built-in Message Logging – Part 2 of 2

Functional Verification — Thu, 18 Mar 2010 06:47:57 GMT

[Team Specman welcomes back guest blogger, Michael Avery from our Services Group in the UK] Building

Tom, Obviously yo ...

JL Gray — Thu, 18 Mar 2010 04:13:12 GMT

Tom,

Obviously you're stretching things just a bit with the title of this post. The UVM is to be based on the OVM 2.0.3 with portions of the OVM 2.1 such as bug fixes included (as decided at the F2F). But not everything from 2.1 will be incorporated or even incorporated as-is. For example, callbacks and end of test may be modified. from the 2.1 release.

Sorry, but I can't a ...

tomacadence — Fri, 12 Mar 2010 11:23:36 GMT

Sorry, but I can't agree with your statement that "standards are now being driven by the EDA companies, not the users" at least in the case under discussion. The UVM is being standardized by an Accellera Technical Subcommittee (TSC) that has two "user" chairs and more members from "user" companies than EDA companies. Of course we EDA vendors care deeply about this standard and are working both within the TSC and outside of it (my blogs) to argue for what we believe is the right outcome. But I don't buy the argument that we are in the driver's seat; the users will determine the UVM.

I have no idea what you mean by "supporting them [customers] to have seats on the standards committees." Users certainly do not need the permission or support of EDA vendors to participate in standards bodies. Many such groups allow individual participation, and those that require company membership welcome "user" companies just as openly as EDA companies.

You sound as if you have some strong opinions and provocative ideas for evolution of design and verification languages. I encourage you to participate in Accellera, IEEE, OSCI, or other organizations dealing with standards in this field. It an be intellectually stimulating, personally rewarding, and even fun!

Tom A. (former standards participant as a user in Accellera, IEEE, VSIA, PCI SIG, USB IF, 1394 TA, etc.)

The problem that I o ...

Anonymous — Fri, 12 Mar 2010 05:54:47 GMT

The problem that I observe is that the standards are now being driven by the EDA companies, not the users, so the drive is by marketing Hype and Profit rather than the advancement of the standard, to provide the end clients with a Right first time solution.

Techniques which have been known about, by some of us, for over 15 yrs have still not arrived in the standards.

Lets start with fundamentals, engineers design in bits and fields, no available system EDA tools supports bit slicing and field manipulation to the level required at system design, never mind true transaction interface definition. The definitions all seem to be done to suite the software engineer and they are byte orientated by definition. We do not need software design tools, what we are attempting to support is Hardware definition, at a system level, in a world where time matters, in more than one sense.

Lets make for more use of strongly typed languages to save introduction of errors in the first place. This include the management of data file used for testing, which should support enumerated types, as field values, for example.

Once we arrive at the actual system testing phase, UVM is still well behind the curve for a methodology, if I had only had what UVM will offer I'm sure I would not have achieved another right first time system device. System verification needs to concentrate more on not putting errors into the design in the first place rather than testing to remove them.

My list goes on.

Maybe its time to actually start listening to your customers, or even better supporting them to have seats on the standards committees, rather than second guessing my requirements.

Hi all. I thought I ...

_temp_8dd39738-85b2-4e5b-8c84-011b6ea73d79 — Mon, 08 Mar 2010 20:20:35 GMT

Hi all.

I thought I d say a word regarding this "provider lock" Bryan mentions.

If you take a step back, you can easily realize 3 things

- First, this objection to e has nothing to do with technical aspects. Those who, recently or years ago, made the choice to base their verification on e, all understood its technical superiority and benefit, and this took over the fact that they would have to pay for it every year.

In other terms, they all consider the gain on productivity is still superior.

- Second, being an active user of ovm SystemVerilog as well as e, I would say the superiority of e is less relying today on the language than on the features in the Specman tool enabled by the e language. It would take me around the same time to create a verification environment in e or SV, but to debug it and to be able to maintain it, there is no comparison on the time you gain by using Specman. Use the command line interactively in a simulation to query your verification environment, visualize objects, reload the testbench without recompiling the design and relaunch the test, have a unique generation debugger... all of those features are possible only in Specman and possible only with the e language. Also Cadence realized how much bad impact debug time has on projects, and is working on new technologies around this.

- The last point is harder to realize, but is true : Specman is the only real interroperable tool to any simulator. I ve heard many time people telling that their reason for choosing SystemVerilog was to have a language that would work with any simulator. For those who had to port SV environments from another vendor to IES or vice versa, they could easily tell you that this no effort portability is purely theorical. Even if you arrange your files to get syntaxes as basic as able to compile and elaborate correctly in all simulators, the tests themselves, based on randomness will anyway finish up being different as there is no algorithm set for random generation. In parallel, for those who switched simulator with a Specman environment, the effort was minimal as you have a dedicated tool for verification, completely agnostic to the simulator it interacts with. Still, you have to pay Cadence for it, but again, compare the money you spend against the time you pay your engineers to work without the best tools.

My 2 eurocent.

Patrick

Unfortunately, that ...

Anonymous — Sat, 06 Mar 2010 11:02:28 GMT

Unfortunately, that online conversation was from nearly 2.5 years ago. The only recent info about e support from a Cadence competitor that I could find was this:

www.synopsys.com/.../evcs_ntb.html

A service to migrate from e to SystemVerilog. Not very promising. Like I said, I want to be able to give e a chance... Maybe there is something Cadence could do to foster broader adoption and support among vendors of this standard. ;-)

Thanks so much for t ...

tomacadence — Sat, 06 Mar 2010 07:59:59 GMT

Bryan, thank you for the thoughtful comments. The single-vendor argument may not apply; there has been much online discussion about one of our simulation competitors supporting e as well (for example, see http://tinyurl.com/yzyvdef or http://tinyurl.com/ydo2och).

As for pricing, it's certainly true that a customer buying Specman from Cadence and a simulator from another vendor is spending more than they would if they bought just that same simulator. However, note that Cadence Incisive Enterprise Simulator XL (IES-XL) runs SystemVerilog and e (and SystemC) all for the same price. We don't charge "extra" for one verification language over another.

Finally, I agree with you on the value of the OVM SystemVerilog source code; note that we also provide open-source libraries for OVM e and OVM SystemC in the Community Contributions area of OVM World.

Tom A.

I'll bite. I'm pret ...

Anonymous — Sat, 06 Mar 2010 05:50:35 GMT

I'll bite. I'm pretty much in the camp of unwilling to consider e. My biggest concern is that, despite being touted as an IEEE standard language, there is still only one vendor that supports it. Nobody publishes prices, but I hear through the grapevine that it's a pretty pricey single-vendor solution as well. I'd hate to get myself and my team locked in to that kind of a tool. Knowing we can run our SystemVerilog design with any of the big simulators is very comforting. Having the source code to the OVM is also a huge benefit for debugging, reuse, and portability of our design.

All that being said, I did watch a brief video from DVCON about e[1] and thought about posting this comment there, but I didn't know if it would be an appropriate place to gripe. I agree with the principles stated in that video, that excessive use of design patterns is generally a sign that your language isn't giving you all the power of what you need[2], and so my curiosity about e has been piqued, but not enough that I'd consider submitting to single-vendor lock-in.

1. www.cadence.com/.../why-oop-falls-short-for-verification.aspx

2. The "function" and "loop" design patterns of assembly programming became built-in features of the c language, the pattern of encapsulating data and function pointers inside structs in C programming became classes in C++, and so on

Hi Tom, Opinion f ...

Anonymous — Fri, 05 Mar 2010 18:12:47 GMT

Hi Tom,

Opinion from engineers definitely would be interesting to learn, however more important is the opinion of the decision maker on why he/she didn't realize the power of e over any other language.

Hello Alok, The r ...

Anonymous — Thu, 25 Feb 2010 08:11:43 GMT

Hello Alok,

The reference link you provided is for the Mentor Register Package. This package does not include an XML parser and I don't know about support for backdoor acess.

Please feel free to download the latest Cadence OVM Register Package (ovm_rgm) from: www.ovmworld.org/contributions-details.php

It includes an XML parser at $OVM_RGM_HOME/builder/ipxact/ovmrgm_ipxact2sv_parser.jar

The backdoor access mechanisim is provided to do exactly what you would like. It allows access to a register/signal directly in the RTL design via a hdl_path.

Please have a look at the ovm_rgm package.

I hope this helps!

Kathleen

hi, Ronen, Your a ...

Efrat — Thu, 25 Feb 2010 00:00:50 GMT

hi, Ronen,

Your assumption is correct.

"on event" is just like a method. It's not a TE.

No performance penalties.