Re: [sv-bc] Please respond with your #1 SV-BC enhancement priority (due by end of January)

Hi All.

I would like to see the Std document written to define
"usage levels" or some such idea.

For example, "core" usage might be verilog; "extended functional"
usage might be verilog, with C and C++ features. The different
usage levels should be separated explicitly in the Std. Every level
should be usable for simulation and include a synthesizable subset.

Another way of defining usage level might include a level
with only synthesizable constructs.

Yet another might include verilog with interfaces or assertions, etc.

The reason for this would be to permit tool vendors to
"ease into" SystemVerilog by well-defined stages of progress.
This would permit vendors to claim incomplete support for
SystemVerilog in precise, well-understood terms.

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!

Perhaps the Std project could be explicitly segmented, the way VHDL
has been?

A big handicap is the fact that the same result can be obtained in
so many ways: always and always_comb, for example. This is no
problem when a specific designer is developing his or her own
style, but it makes maintenance of the code difficult for
others who have become accustomed to a different subset of the
available SystemVerilog constructs.

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.

On 01/26/2010 01:00 PM, Brad Pierce wrote:
> Background 1: http://www.eda-stds.org/sv-ieee1800/hm/0956.html
> Background 2: http://bit.ly/7RDGox
> Background 3: http://tinyurl.com/sv-bc-enhancement-requests
>
> Because of the reasons in the above links, 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.
>
> The rules --
>
> 0) This a public process, so all replies go to the reflector, not just to Matt or me.
> 1) You must include the number of a Mantis item. If your #1 issue is not yet in Mantis, add it first, or get someone to add it for you.
> 2) You must include a reason why this enhancement is critical for users.
> 3) Replies due by end of January.
> 4) If you believe no SV-BC enhancements should be made in the next revision, that's an OK answer, but it needs a reason, too.
>
> Thanks for your help,
>
> -- Brad
>
>
>

-- 
      John Michael Williams
      Senior Adjunct Faculty
Silicon Valley Technical Institute
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.