I wrote here
Matt and I need your feedback on what SV-BC subscribers consider to be their #1 SV-BC enhancement priority for the next revision, and why. We’ll roll it up into a short presentation to the Working Group.
According to Surya Saha
Ideally there should be a proper balance of users and language implementors both in the language committee. But the problem is – most of the committee members are language implementors here in SV. So many features added in SV are very rarely used. And I got feedback from many designers/users that SV is huge, and the people getting frightened to digest the whole. That should not be the case if we ask designer/user’s feedback more frequently when SV is developed. Though I am not sure how to execute it.
And we need feedback not just from SystemVerilog users, but also from non-users.
According to Shalom Bresticker
I have not found time to do a systematic review of existing SV-BC enhancement requests, but I tried to think of what first comes to mind. This relates only to enhancements, not to corrections or clarifications, and not to SV-EC areas.
- One issue that comes up frequently among the designers I support is the lack of variable part-selects (Mantis 2684). I understand that in general, SV has well-defined expression sizes. Nevertheless, it would be very helpful to support this. Even if the construct were limited to specific contexts, such as being alone on the RHS of an assignment, it would be very useful. Today, one typically works around this using a combination of left- and right-shifts, which is difficult to understand and error-prone.
- Parameterized functions and structures (Manti 696, 1504). The SV-2009 “let” construct certainly helps, but it is only partial solution.
- Macro/generate enhancements. (various Manti) Both macros and generate constructs have limitations. Generate constructs are limited to complete statements. Macros don’t have loops, for example. It would be good to bring them closer. Adopting a good existing pre-processor as standard instead of having special language compiler directives could be one way to help that might be relatively easy to do.
- Variable numbers of arguments for tasks and functions, macros, etc.(Mantis 1566)
- Out of bounds array write checking (Mantis 1144, 2680).
According to Gordon Vreugdenhil
I think that BC needs to take a serious look at issues such as the macro language, the composition of configurations in the presence of library management, the concept of libraries as applied to configurations and “-v” or similar pragmatic realities, and the entire concept of separate compilation and what that might mean.
The above issues (and others) cause real issues in non-trivial design flows and there is definite vendor divergence. Some of these are “easier” than others in the sense that they are pure “in language” issues versus the much more difficult flow composition issues which are probably already intractable.
According to Mark Hartoog
I think the question of binding interfaces, interface ports and virtual interface variables with multiple libraries and configurations is a hole in the current LRM that is [affecting] customer designs.
Definitely. As most of you know, one of my big soap-boxes is how users should expect various aspects of SV to compose in realistic environments. Mark’s list is a big part of that as are things like assertions, etc. Some of the nastier bits will likely need wider AC/EC discussion, but I think that some of the core questions (and directions) should at least be initiated by BC.
I asked him
What are the core questions?
The more general questions (core questions) are things like:
- how does the concept of a library apply to SV design units?
- what kind of design unit locality and safety applies globally/locally to “compilation” and “elaboration”?
- how does an IP model and encryption interact with compilation, modularity, and test infrastructure?
With respect to how this applies to Mark’s issues, here are at least some specific questions:
- what is the relationship of a package to a configuration?
- can configurations impact instances created by a bind?
- can configurations impact the type of a virtual interface variable?
- what happens if a package of a particular name is in multiple configuration “libraries”?
- what is the meaning of $unit with respect to configured design elements?
The list can probably go on for quite a while longer; those are just the immediate questions that I came up with in a couple of minutes.
Aside: Regarding the power of questions, see here. I agree with an opinion I read somewhere that the central goal of an education should be learning to ask and answer fundamental questions.
According to Dave Rich
There is a wide divergence in SystemVerilog support and users are restricting themselves to a subset of what is supported uniformly across most implementations.
and the issues which
clarify existing features of the standard and lead towards consistent implementations should have highest priority. If as a result of that process we need to add a new feature, that is fine. But we should not be leading off the process with a new feature in mind.
In my opinion, the industry wants a bolder move at this time. On the other hand, Dave interacts with a lot of users. According to me
That metric won’t pay the bills, because users quickly figure out ways to work around vendor oddities
Well that is not always so. Sometimes it is difficult to understand where and why and how vendors diverge, and working around them is not always quick. That is in fact some of my current work.
I do think that there are certain ambiguities where implementations diverge and seriously impact users. I suggested in the past that as part of the priority-setting, we try to identify those ambiguities that cause the most problems for users, and get those clarified.
But he agreed with my claim that
What they are demanding today are solutions to the design productivity gap.
and added that
One type of complaint that I see frequently is “I am used to doing X in VHDL/e, it is useful and it is easy in VHDL/e, why does SystemVerilog make it so hard??”
I am not saying that we should blindly adopt VHDL or e features, but these complaints do indicate some productivity obstacles in SV, and we should relate to these seriously.
According to Alex Gran, his customers are trying to
limit themselves to code constructs that work and work the same in most if not all of the major simulation implementations. Therefore, at least in the SV-BC space I think its worth putting at least some effort into the areas that are causing implementations to diverge on functionality
and he suggests as a specific priority
macros and other preprocessor stuff. Specifically mantis 1537.
That item was filed by Shalom, who responded
Intel code uses macros extensively. Macros get a lot of criticism, but the fact is that users find them very important. Since, as we saw last time, getting macros expansions to be unambiguous and bug-free is very difficult, one approach that I had suggested considering is officially adopting a well-known preprocessor such as CPP or M4.
My limited experience with SystemVerilog is that it is frustratingly complicated and poorly supported, when comparing tool functionality with the full Std. It’s a “heap big” Std!
I think “enhancing” a language by just adding new ways to accomplish the same result (in simulation or synthesis) creates a less well designed and less usable language in the end.
Reducing the complexity of SystemVerilog by any means would increase its acceptance by designers and project managers. Reorganizing the document would be one way of doing this.
But I don’t see any way around the backward compatibility constraint. If someone builds a better mousetrap, we can’t simply forbid the old mousetraps. Plus sometimes the old ways still have their advantages. There are good reasons why first responders use pagers instead of cell phones.
According to Surya Saha
I think the committee gives more emphasis on new enhancements rather than consolidation of current features which are already there. There are many ambiguities in the LRM for many features. And if new enhancements added, the number of ambiguities will be more. So I think it is best time to resolve the ambiguities of the existing feature so that all tool vendors work in similar way unless they have bugs. The ambiguities can be collected from the various open Mantis items. I am not against the new features, but we should not be that much proactive, if to resolve one ambiguity a new feature is required, then it should be allowed.
Not only the ambiguities, I can see some features are too difficult to implement that no tool vendors are yet too support though those are part of SV 2005. Or maybe the designers do not have that much interest to use them. One example is operator overloading. So we should look into those areas too.
Forget the past to win the future.
I would agree with Shalom’s response
But we should make sure that the enhancements are the right ones, the ones that will give the greatest benefits to the users.
If we take operator overloading, for example, then it is true that it is not very much implemented, but neither have I heard users complaining about it very much.
Hopefully, the current process will give us insight into what users really need.
According to David Jones
I’ve looked through the few Mantis open for SV-BC. In terms of productivity, I feel that most of these items are minor.
The one thing that we can do is improve the standard: make it a rigorous description of the language and explicitly call out places where vendors may diverge (in informative sections). The preprocessor has already been mentioned as a candidate for a more precise description. I like the description of the ANSI C preprocessor given in K&R.
But really, for end-user productivity, I feel that the onus is now on the vendors. The base language (for which I am excluding the SV-EC verification constructs) is fairly complete. There are a few areas for improvement (VHDL-style configurations, for example) but in terms of day to day productivity, here’s what slows me down:
[compile times, diagnostics, language support]
None of these areas are things that SV-BC (or SV-EC) can readily fix. Instead, it’s up to the vendors to improve their implementations.
Instance-specific type identities for the non-class (i.e. purely structural) types was a serious mistake. Specialization-specific identities suffice to make these types safe and far more portable.
[…] synthesis systems (which so far lack dynamic, classed, objects) only implement specialization-specific type identities. If SV is ever to be about design reuse, we need a way to instantiate interchangeable parts of a common structural type. This cannot be done if the types themselves are unique to each instance in which they occur.
According to Mirek Forczek
New directions for language expansion could be:
- addition of power related syntax and semantics (similar as UPF in example, filed Mantis 2964)
- addition of transaction syntax and semantics [no Mantis yet]:
unlike as in Mantis 1037 (where PLI style enhancement is proposed for transactions recording [PDF]), I would suggest to express transaction and related semantics explicitly in the language. One possible form could be: a protocol grammar (from transactions scenarios to signals sequences). This could reuse syntax of from ‘randsequence’ (the grammar) and ‘assertions’ (the sequences). The possible utility functions would be:
- binding protocol grammar to the bus,
- encapsulation of implementation protocol clients/interfaces (actions for grammar productions),
- monitoring activity on the bus and reporting any violations of the grammar,
- automatically matching activity with grammar productions -> recognizing transactions (and sub-transactions) and their boundaries,
- automatically recording transactions stream.
Other issues are around keeping symmetry in language:
- same syntax capabilities for subroutine argument passing as for port connection (Mantis 2957),
- same as above but for sequence/property (Mantis 2958 filed for SV-AC), [see also 96 and 98]
- wider usage of :: operator (Mantis 2959)
Also I would like to confirm priority for already mentioned topics and filed mantis:
- preprocessor improvement: a good idea of adoption CPP or M4 preprocessor, for CPP option – consider also replacement of ‘`’ character with ‘#’ and drop of ‘`’ character at macro substitution, sources formatted this way could be processed with already existing implementations of CPP,
- naming convention for unnamed blocks – critical since they may contain declarations (Mantis 2167),
- parametrized structures, again: symmetry in language (Mantis 1504)
Also according to Gord
I am not opposed to enhancements that are on the edge of the clarification line. Some examples would be the following Mantis:
This is not complete nor even necessarily my top priorities, but are simply a few examples of things that really clarify/extend some of the discussed intent from the last PAR.
My personal opinion? I’d rather listen to the users. But one common complaint that would be challenging to get right are the “parameterized functions and structures” mentioned earlier. Some other discussions of it are here and in the comments section of here. The solution wouldn’t need to be copied from VHDL, but probably it ought to be copied from somebody, instead of re-inventing the wheel.