[sv-bc] enhancement considerations

Hi,

We are soon to be asked to consider various enhancement requests for the next revision of SV.

Some of these requests have already been discussed and met with objections, particularly from tool implementors. (That's not an insult. Implementors have reasonable concerns. Why, some of my best friends are implementors...)

I would like to propose some principles for discussion of these objections that attempt to bring a balance between various considerations.
This is separate from the general discussion of whether (or how much) we should work on enhancements in the coming revision vs. working on clarifications and ambiguities and open issues, stabilizing the language, and giving implementors time to catch up with the standard.
Rather, these are considerations to be food for thought when discussing a particular enhancement proposal.

The questions come up particularly when the request is for a feature that is implemented in other HDLs, HVLs, or general purpose languages, and found useful. Then we have to ask why if it is possible there, it can not/should not be possible in SV.

The objections are typically one or more of the following types:

1. It will significantly hurt performance
        - Here it is necessary to distinguish between compilation, elaboration, and run-time. There is more willingness to pay in compile and elab time  than in run time.
        - Is the cost only where the feature is used and thus proportional to the degree of use of the feature, or does it hurt the performance of the entire design, even if the feature is not used much or even at all? If the cost is according to the degree of use of the feature, then maybe it is still worthwhile.
        - There can be a difference between general purpose software environments and the giant databases and run times of VLSI descriptions. What may be reasonable to do in a general purpose language or even in an HDL that is usually used with small models may not be reasonable to do in a language that has to be able to model a supercomputer.
        - Maybe a limited form of the feature is a reasonable compromise.

2. It is hard to specify fully and/or correctly.
        - If so, how do other languages do it? (Maybe they don't)
        - ROI (Return on Investment) - is it worth investing effort in? Maybe it is worth investing in, even if the effort is big. In that case, maybe the sooner we begin work, the better.
        - Maybe a limited form of the feature is a reasonable compromise.
        - It is important that different tools behave the same way.

3. It is hard to implement fully and/or correctly
        - same points as#2

3. It is dangerous for the user. He can easily shoot off his leg.
        - ROI: Maybe the risk is worth it to the user? We can warn the user, or place restrictions. Let the user decide?
        - Maybe some tool can do checking (It may be easier to do checking on design than on testbench).
        - Maybe a limited form of the feature is a reasonable compromise.

4. It is against the spirit or basic principles of the language.
        - If this basic principle keeps the user from being reasonably able to do something useful, maybe the time has come to bend the principle.
        - Maybe a limited form of the feature is a reasonable compromise.

Comments welcome.

Thanks,
Shalom

Shalom Bresticker
Intel LAD DA, Jerusalem, Israel
+972  2 589 6582 (office)
+972 54 721 1033 (cell)
http://www.linkedin.com/in/shalombresticker


---------------------------------------------------------------------
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.