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

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.

Shalom

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Brad Pierce
> Sent: Thursday, January 28, 2010 8:06 AM
> To: sv-bc@eda.org
> Subject: RE: [sv-bc] Please respond with your #1 SV-BC
> enhancement priority (due by end of January)
>
> Surya,
>
> I'm reminded of a recent interview in CACM with Prith
> Banerjee, the director of HP Labs,
>
> http://cacm.acm.org/magazines/2010/1/55745-qa-hps-running-man
>
> Q: How do you inspire your researchers to think big?
>
> A: Unless I engage with the researchers on a regular basis,
> the passion will not be there, the intensity will not be
> there. I say, "What are you trying to build? Can we not do
> something bigger?" Then I say, "The specific research you are
> doing, how will it make that dream come true?" There's an
> unrelenting pressure that I want to be able to feel -- that
> if we don't do it, someone else will.
>
> Q: Before you joined HP, you spent more than 20 years in
> academia. Did you find the transition difficult?
>
> A: Many people warned me, "Prith, you will not survive."
> Fortunately, my experience in academia was not in only one
> position. I also took two exits into the world of startups,
> and what I learned from those startups are things I've tried
> to preach and practice at HP Labs.
>
> Q: Such as?
>
> A: In academia, professors can work and work and refine their
> papers to the last word. The world of startups doesn't give
> you that luxury. I learned how to deliver fast. I learned how
> to run -- I am always running. I try to convey that to my
> colleagues at HP Labs -- you have to find the right
> trade-off. I want you to document your work. I want you to
> advance the state of the art, but don't just keep on
> publishing and refining -- run, right? Start making stuff, as well.
>
> -- Brad
>
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Surya Pratik Saha
> Sent: Wednesday, January 27, 2010 8:31 PM
> 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,
> Regarding this discussion, I want to add few more points. 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.
>
> Regards
> Surya
>
>
>
> -------- Original Message --------
> Subject: Re:[sv-bc] Please respond with your #1 SV-BC enhancement
> priority (due by end of January)
> From: John Michael Williams <john@svtii.com>
> To: sv-bc@eda.org <sv-bc@eda.org>
> Date: Thursday, January 28, 2010 4:48:27 AM
> > 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
> >>
> >>
> >>
> >
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>
---------------------------------------------------------------------
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.