RE: [P1800] Draft PAR for initial discussion in December 10, 2009 P1800 Meeting

I agree with Dave's list of frustrations, but I would add another one:

5. SV does not have (or still does not have) extremely useful features that other hardware design/verification languages have (notably VHDL on the design side and e on the verification side). This causes users migrating from such other languages to feel that they are moving backwards instead of advancing forwards. The language should enable them to do what they want/need to, without getting in the way and making things hard for them.

From this point of view, enhancements are of tremendous importance. (For example, some groups in Intel have noted coverage limitations as being severe enough to cause them to be unwilling to use SV for coverage.) Waiting 2 years just to start working on enhancements will cause even more frustration. So I think it is neverthelss necessary to work on enhancements in parallel. Maybe we can have 2 parallel PARs, a short-term one for corrections and clarifications and a longer-term one for enhancements.

Shalom

________________________________
From: owner-ieee1800@server.eda.org [mailto:owner-ieee1800@server.eda.org] On Behalf Of Rich, Dave
Sent: Wednesday, December 09, 2009 10:19 AM
To: Brad Pierce; IEEE 1800
Subject: RE: [P1800] Draft PAR for initial discussion in December 10, 2009 P1800 Meeting

Brad,

The current frustrations are:
1.       Not having an LRM for the past 5 years that describes how the "standard" is supposed to behave. Do you know how often people ask what a pure virtual method is?
2.       Having to use the least common denominator of SV support based on what the weakest tool in their flow supports. For some people this includes not being able to use V2K configurations.
3.       Not having the same interpretation of the LRM across different implementations, producing different results. A number of features have at least 3 interpretations in 3 different implementations. (mixed ansi/non-ansi ports, default arguments on extern methods.)
4.       Having what is supposed to be a single HDVL language look like three or more different languages with different terminology throughout.

I have my own hot list of enhancements I'd like to see in SV; multiple interface/virtual inheritance for example, but that does nothing to mitigate the existing frustrations, it only adds to them. That's not to say that the lack of a feature is not a frustration; bugs and enhancement requests should be prioritized together. I'm also not saying there should be no more enhancements to the language. I'm just suggesting that the prioritization of an enhancement should be based on resolution of an existing ambiguity or needed clarification. For example, the local:: prefix was an enhancement in 1800-2009 to resolve some the name resolution ambiguities with randomize().

I think this is in line with what Shalom and Françoise have just suggested as well. Another way of presenting this is to have a 2-year errata and clarification period, followed by 2-3 year updated revision, instead of having another 5 year PAR.
Dave
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.