Re: [vhdl-200x] 1076 Working Group Par Vote

See inline below

> Jim,
> My 2 cents on the issues below:
> *Victor also requested that the study group further elaborate*
> *on the purpose of the revision/PAR. To address this, I
> requested that the study group to further elaborate
> on the purpose to the par and specifically:
> What is intended by Verification enhancements?
> 1) Create an API/interface/package that allows interfacing
> VHDL to SystemC and/or SystemVerilog/UVM
> vs
> 2) It could also mean we implement full OO and UVM-like
> stuff in VHDL.*
> [Ben] I am strongly in favor of option 1 because:
> - OO is already built into SystemVerilog, and reinventing the wheel is
> too time consuming for this group, and is too expensive for tool vendors who
> already have SystemVerilog and SystemVerilog/VHDL tool solutions. In
> addition, VMM/OVM/UVM frameworks are already written, and have maturity.
> You don't want to rewrite them into VHDL.
>
>
> [Hans] Sorry Ben, I disagree. The problem with mixing one powerful
> language with a "verification-weaker" one is that at some point companies
> will decided to ditch one language and focus on just one of them (I don't
> have to tell you which one). I am not arguing against a decision like this
> since it makes perfect sense from a cost point of view (vendors charge for
> each language feature) but it will lead to the erosion/demise of the VHDL
> user base.
>
>
 [Ben] I am seeing companies ditching VHDL in favor of SystemVerilog. The
ditching is sometimes partial in that RTL is done in VHDL and verification
is in SystemVerilog. But I agree with you that this split transition lends
itself to a total transition, not only because of tool cost savings, but
also manpower savings (training, less confusion in dealing with 2
languages). That ditching is occurring because 1) vendors are supporting
mixed-level simulation, 2) advancements in SystemVerilog with regards to
closer rapprochement to VHDL (e.g., stronger typing, configurations,
packages), OO support), 3) emergence of frameworks for verification (VMM,
OVM, UVM). The point here is whether you create (or not create) an
API/interface/package, the above reality exists.
For *"2) It could also mean we implement full OO and UVM-like stuff in VHDL"
* to be successful it must designed such that an automatic translation or
integration (better solution) of the current SystemVerilog frameworks into
VHDL be supported. I kind of like the idea of somehow linking the
SystemVerilog framework libraries into VHDL. That would ease the issues of
code maintenance, documentation, etc.

>
>
 [Hans] We should also not be limited by what we think vendors are willing
> to spend money on. There are always companies that will break the trend to
> get into the market, an example is Aldec who implemented (part of) VHDL2008
> (including VHPI) since 2008.
>

[Ben] That is true, but vendors are also (and should be) part of the
committees as they understand the languages, and the nuances and
implications of the proposals, thus coming up with better solutions. The
other side of the coin is that they also can have a negative vote on items
that they would not want to implement. A negative vote on a proposal by one
voting member kills that proposal.
Ben Cohen systemverilog.us

>
>
>
> *There are many in the study group who believe that creation of
> direct C interface is a worthy task to do.
> The study group had mixed opinions on things like OO/classes,
> data structures (syntax or package based), functional coverage,
> constrained random, and/or interfaces, so the
> 1076 working group will need to trade-off/explore what
> to do about these if anything.*
> [Ben] The PI/interface/package that allows interfacing VHDL to SystemC
> and/or SystemVerilog/UVM will provide for all these features at a very low
> cost for implementers.
> In fact, the Binding SystemVerilog to VHDL components (with SV bind) is
> already implemented by vendors; however, taht feature is not in the
> SystemVerilog or VHDL LRM.
>
>
> I am all in favour of formalising the interfaces in the SV/VHDL LRM
> provided it doesn't distract time and effort from the main goal of improving
> the VHDL language itself. As you mention most (if not all) tool vendors
> allow you to mix languages with no or some minor issues so formalising the
> interfaces is not going to do much for the average VHDL/SV engineer except
> improving portability.
>
> Regards,
> Hans.
> www.ht-lab.com
>
>
>
> Ben Cohen Ben@systemverilog.us
>
> On Thu, Jan 6, 2011 at 1:01 AM, Jim Lewis <Jim@synthworks.com> wrote:
>
>> Hi,
>> This is to document the results of the VHDL/1076 study group
>> vote on group organization and the PAR.
>>
>> Item 1: Working group organization.
>> Total votes:
>> 26 Individual
>> 5 Corporate
>> 3 Abstain
>>
>> Item 2: 1076 PAR.
>> http://www.eda-twiki.org/vasg/p1076_2014_draft_par.pdf
>> Total votes:
>> 31 Approve
>> 1 Negative
>> 2 Abstain
>>
>> The study group has approved the working group to be
>> individual based membership and approved the PAR.
>> Detailed voting records are here:
>> http://www.eda-twiki.org/vasg/voting/110105_PAR_VOTE.pdf
>>
>>
>> ---------
>>
>> Victor also requested that the study group further elaborate
>> on the purpose of the revision/PAR. To address this, I
>> requested that the study group to further elaborate
>> on the purpose to the par and specifically:
>> What is intended by Verification enhancements?
>> 1) Create an API/interface/package that allows interfacing
>> VHDL to SystemC and/or SystemVerilog/UVM
>> vs
>> 2) It could also mean we implement full OO and UVM-like
>> stuff in VHDL.
>>
>> This email is at: http://www.eda-twiki.org/vhdl-200x/hm/1091.html
>>
>> There are many in the study group who believe that creation of
>> direct C interface is a worthy task to do.
>> The study group had mixed opinions on things like OO/classes,
>> data structures (syntax or package based), functional coverage,
>> constrained random, and/or interfaces, so the
>> 1076 working group will need to trade-off/explore what
>> to do about these if anything.
>>
>> Best Regards,
>> Jim
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Jim Lewis
>> Director of Training mailto:Jim@SynthWorks.com
>> SynthWorks Design Inc. http://www.SynthWorks.com
>> 1-503-590-4787
>>
>> Expert VHDL Training for Hardware Design and Verification
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> --
>> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.