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

Hi, John.

Stuart Sutherland suggested something similar at DAC 2004 (see http://www.sutherland-hdl.com/papers/2004-DAC_SystemVerilog_adoption_plan.pdf), but it did not catch on.

Regards,
Shalom

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of John Michael Williams
> Sent: Thursday, January 28, 2010 1:18 AM
> To: sv-bc@eda.org
> Subject: 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.
---------------------------------------------------------------------
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.