Archive for March, 2010

23 March, 2010

At a recent SystemVerilog requirements gathering meeting,I was quite amused to see “deprecating features” come out as one of the top 10 user requested priorities for the next revision of the IEEE 1800 standard. Even more amazing was that this request came out without listing which features were to be considered for deprecation.

P1800 Requirements Gathering Meeting 2/27/2010

P1800 Requirements Gathering Meeting 2/27/2010

I’m sure most people don’t understand the meaning of the word deprecate. I thought I understood until I looked it up in a dictionary. According to Merriam-Webster:

Deprecate:

1 a archaic : to pray against (as an evil) b : to seek to avert <deprecate the wrath…of the Roman people — Tobias Smollett>
2 : to express disapproval of
3 a : play down : make little of <speaks five languages…but deprecatesthis facility — Time> b : belittle, disparage<the most reluctantly admired and least easily deprecated of…novelists — New Yorker>

In computer science standards and documentation, deprecation has come to mean to supersede or discourage use of a feature. It does not mean a feature has to be removed to be compliant with the standard. You can’t remove a feature from an existing standard; you can only remove a feature from being documented in a future standard. No vendor is going to immediately remove a feature from a tool that it has already implemented and in widespread use without ample warning and without providing a practical alternative to the user. Typically, a deprecated feature is never removed from support in a tool unless in the rare case it’s needed to allow for a future enhancement.

The current standard lists in Annex C.4 the defparam and the procedural continuous assignment statements as candidates for deprecation. Listing candidates for deprecation seems to be almost the same as actually deprecating them without removing the LRM. No tool will remove support for these statements regardless of whether they are candidates or actually removed from the LRM.

Q: So why go though the trouble of deprecating a feature in a standard?
A: Well, to discourage use of that feature.

Q: And why is that a good thing to do?
A: It makes learning the language and maintaining existing code much easier.

Take an example from the current Verilog and SystemVerilog LRMs. The logic data type was added to supersede the reg data types; they both have the same semantics. Anyone with a history of Verilog will understand the change in keywords, but someone new to SystemVerilog will be left wondering why there are two keywords for the same thing. And then there is the issue of trying to maintain the LRM so that all references to reg also include logic and the other way around. If someone misses that in one place, people will begin to think the two keywords have different behaviors.

It seems it’s always easier to add new features than to remove them. There are many places to create lists of your favorite enhancements. At the same time, people complain about the size of the Language Reference Manual – it’s over 1200 pages. Doug Smith of Doulos writes “Will this language ever stop exploding?

So here is my list for deprecation, as well as a place for other to add their list by commenting here.

  1. Program blocks
  2. Reg data type – see above
  3. Wildcard associative array index types
  4. Un-typed mailboxes
  5. Dynamic array copy A = new[]B redundant with A = B
  6. always @(*) – superseded by always_comb

, ,

22 March, 2010

Download OVM 2.2.1 from OVM World

logo_OVM An important OVM update is now available for download and production use.  Several bugs have been corrected, features altered to improve performance, documentation issues addressed and miscellaneous items improved.

A list of OVM 2.1.1 items from the Release Notes is shown below.  And if you ever have a use issue with OVM and want to contact the OVM Team about it, you can always do so online.

Bug Fixes

  • ovm_report_enabled() method now also tests the configured action as well as its verbosity when determining whether to process the report. If a report’s action is configured to OVM_NO_ACTION, or if its verbosity is higher than the configured verbosity, ovm_report_enabled() returns 0.  Because the `ovm_* report macros use ovm_report_enabled(), they too benefit from this performance improvement.
  • Verbosity was not being ignored for fatals, errors, and warnings. This is now fixed.
  • Added is_locked() method to ovm_sequence_base.
  • Fixed ovm_queue #(T) to not assume its parameter, T, was an object.
  • A FATAL report is issued if an attempt is made to connect() ports at or after the end_of_elaboration phase.
  • Fixed multi-field configuration matching for ovm_field macros. In OVM 2.1 only the first matching field in a component was applied, now all matching fields are applied.
  • Sequence arbitration was broken when in strict_fifo or strict_random modes.  When used in conjunction with is_relevant() or is_blocked(), the priority queue was incorrectly determined, resulting in blocked or irrelevant sequences potentially being chosen. This has been fixed.
  • Fixed bug in transaction recording that was resulting in nested objects not being recorded.
  • Fixed ovm_field_int_*_unsigned macros by removing unnecessary attempt to cast to ‘int unsigned’.
  • Added force_stop() method to ovm_test_done_objection that forces a stop despite outstanding objections. This effectively cancels an objection.   By default, the objection state is printed if there are outstanding objections at the time of the call.
  • Fixed ovm_sequence’s kill() and ovm_sequencer’s stop_sequences() behavior whereby a killed/stopped sequence’s post_body method was allowed to execute.  Now, calls to kill() or stop_sequences() will absolutely kill the affected sequence(s) and leave the sequence in the STOPPED state.

Documentation Fixes

  • Corrected documentation for (un)pack_string.
  • Fixed HTML documentation ‘search’ engine to include macros. It was not properly handling the macros’ leading backtick (`).
  • Changed macro documentation to be consistent: The backtick is included, whereas the arguments are not.
  • Documented do_kill_all() method as a means of recursively killing the processes forked during a component’s run phase. The objection and stop mechanisms remain the preferred way to end the run phase.

Miscellaneous

  • Turned off auto-config for all port objects.
  • ovm_sequencer_base::get_seq_kind() was changed to issue a WARNING instead of an FATAL if the named sequence is not found. This allows users to check if a specifically named sequence is registered. A return value of -1 indicates the sequence does not exist.
  • Removed an old, unnecessary ifdef INCA in the ovm_component::find() code.
  • Changed internal macros in ovm_object_defines.svh to use m_ to provide visual indication that the macros are for internal use only.
  • ovm_port_base::connect() and resolve_bindings() were made virtual to allow their override in port derivatives.
  • Made sequence registration methods protected and virtual to allow internal tools to work with them.

,

15 March, 2010

For those of you who didn’t make it to DVCon this year, you missed one of the things that makes the conference worth attending – the free goodies in the registration packet. Clearly the most interesting and informative such item was the February edition of our Verification Horizons newsletter (for which this blog was named). As both the editor of VH and the General Chair of DVCon, I could not have been more pleased.

You can see the online version at http://www.nxtbook.com/nxtbooks/mentor/verificationhorizons_201002/

Here’s a list of the articles:

  • Page 6…Using inFact with OVM Sequences
    by Jay O’Donnell, SLE Division, Mentor Graphics
  • Page 10…A Strong Foundation for Design, Verification, and Firmware Requires an Automation Tool for Register Management
    by Francois Xavier Duthu @ Mentor Emulation Division, Mentor Graphics, France and Anupam Bakshi, Agnisys
  • Page 14…Transaction-Based Testbench Methods Speed Veloce Hardware Acceleration
    by Jim Kenney, Marketing Director, Emulation Division Mentor Graphics
  • Page 18…Verification Management Eases Those Re-spin Worries
    by Darron May, Product Manager, DVT Division, Mentor Graphics
  • Page 22…What’s New with the Verification Academy?
    by Harry Foster, Chief Verification Scientist, Design Verification Technology, Mentor Graphics
  • Page 24…Reuse in the Real World— Proving the Accellera VIP Interoperability Kit
    by Manoj Kumar Manu – LMTS, Ashish Kumar, Lead Application Engineer, and Adam Erickson, Verification Technologist, Mentor Graphics
  • Page 27…Converting from VMM to OVM: A Case Study
    by Damien Melville, Chipright Ltd
  • Page 33…Agile Transformation in IC Development
    by Bryan Morris and Neil Johnson, Xtreme EDA

It’s hard for me to pick a single article that I’d recommend, so you’ll just have to go read the whole thing. Please use the comments section to let me know what you think.

Thanks for your support,
-Tom

7 March, 2010

EDA & VLSI Standards Focus Meeting on 12 March 2010

 As part of its continuing program to reach out to global technologists, the IEEE Standards Association will be conducting a series of outreach sessions throughout Bangalore from 10-12 March 2010. The IEEE-SA will also visit key governmental agencies in Delhi this week as well.  While there is a focal technical point for each outreach session, the outreach sessions will address technical subjects in a general manner.

The use of IEEE standards in India, like IEEE 1800™ (SystemVerilog), is quite strong.  In a SystemVerilog Users Group meeting I participated in and blogged about last year, we had 100’s of users at both the Noida and Bangalore events participate.  Given the large number of users of IEEE standards to do electronic design and verification in India, it is fitting that the IEEE come and share the standards development process and update the community of users on the current status of many areas in a series of outreach meetings.

Not only are there a large number of users in India, many people in India contribute to the development of EDA standards as well.  It is also fitting that the IEEE recognize the importance of the large community of standards supporters and developers in India.

The EDA & VLSI standards focus outreach is scheduled for Friday morning, 12 March 2010 at the IBM’s Embassy Golf Links location.  There are other outreach meetings scheduled that cover Networking and Communication, Industrial Electronics, Power/Smart Grid, Academic research and standardization, and lastly, Security and Software standardization.  For more information about the other outreach meetings, click here.

IEEE-SA Open Seminar: “Global Standards at IEEE”

To begin the week the IEEE-SA Corporate Advisory Group will present “Global Standards at IEEE ” on Tuesday, 9 March 2010, in Bangalore, India at the Royal Ballroom, Leela Palace Hotel.

The seminar is a premier event for those in industry and government who are involved in the advancement of technology and interested to learn more about the global impact of IEEE standards. It will provide an overview of several technical areas undergoing standardization at IEEE, as well as illustrate how local entities can participate in and make use of IEEE’s standards and best practices.

Leaders from industry will provide their insight through presentations and case studies on areas such as smart grid, software life cycle, IEEE 802®, and electronic design automation.

If you want to attend any of the meetings, please register.  I look forward to see many familiar faces this coming week in India.

, , , ,

@dennisbrophy Tweets

  • Loading tweets...

@dave_59 Tweets

  • Loading tweets...

@jhupcey Tweets

  • Loading tweets...