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

Hi,

> >My suggestion is to document a policy for setting priorities
> in the next PAR.
>
> I'm all for that, as in
>
> http://www.eda.org/sv-ieee1800/hm/0936.html

I agree with most of what you wrote there.

>
> >Those that clarify existing features of the standard and lead
> >towards consistent implementations should have highest priority.

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.

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

> even if they grumble
> as they do so.
>
> What they are demanding today are solutions to the design
> productivity gap.

Yes, I agree with 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.

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