Re: FW: [vhdl-200x] Call for Vote on Group Organization and PAR

Hi Ben,
Oh yes, I agree with your proposals in that email. My lack of knowledge in
SystemVerilog does not allow me a comparison between the two languages, but
your proposals sound useful (I especially like the dynamic arrays and
constrained random generation).

I am wondering if we can use an existing VHDL pseudo-random generator for
this purpose? Maybe "uniform" from math_real?
Also, I was thinking maybe it is good to make it easier for designers to
design checkers/verifiers? Like a simple interface or method to input rules
as to when a set of outputs meet expectations and when they do not? Probably
by having an easy way of specifying tolerances/ranges. Perhaps SV already
has all these features, I'm just not aware of it.

Regards,
Daniel

On Mon, Dec 20, 2010 at 10:32 AM, ben cohen <hdlcohen@gmail.com> wrote:

> *<The rationale is clear, Verilog/SV needs very comprehensive verification
> (I even hear of great emphasis on lab bench verification and FPGA emulation
> - for ASIC designers) to counter for their weak typing, while VHDL being
> strongly-typed, does not require such comprehensive verification
> capabilities.>*
> [Ben] I totally disagree with that rationale as to why SystemVerilog
> testbench and verification effort needs to be more comprehensive for
> SystemVerilog designs over vhdl designs.
> I am very knowledgeable in both languages, and wrote several books on both.
> The typing is not the real issue. One of the reasons SystemVerilog
> testbench are more comprehensive today is because of the design complexities
> as the technology allows for much denser and complex designs. The growth
> of integrated circuit complexity has driven the verification effort required
> beyond all reason Thus, there is a need for more comprehensive testbenches
> with constrained-random testing. Famework technologies, such as
> VMM/OVM/UVM, allows you to quickly create a fast, reusable,and extendable
> testbenches using SystemVerilog that is a language that supports constructs
> needed for the verification of those complex designs.
> In my email response to [vhdl-200x] Request for Input
> I enumerated the several constructs that are needed for verification of
> such complex designs.
> Please take a look at that email.
> IMHO, VHDL, SystemVerilog, Verilog, C, are just languages. The complexity
> of the testbench is not the result of a language. However, some languages
> are richer than others, and are better suited for certain tasks.
> Ben Cohen SystemVerilog/us
>
> On Sun, Dec 19, 2010 at 5:54 PM, Daniel Kho <daniel.kho@gmail.com>wrote:
>
>> Hi Stephen and all,
>> I have been waiting for this sort of discussion in the SG, and thanks to
>> Steve, we can finally discuss our direction.
>>
>> I have to agree with some of Steve's points, including the declining use
>> of VHDL. However, I think that we can do something to stop this trend (of
>> people using non-VHDL design and verification languages). Perhaps instead of
>> doing the same things that SV has been doing over these years, we could
>> think of other things that could make VHDL more appealing.
>>
>> My belief is that VHDL usage in Europe, Australia (and probably most of
>> the Commonwealth) remains strong. I don't have statistics though, but I am
>> one example of a VHDL-only user designing for a European application. One of
>> the really good thing about VHDL is that we don't really need such a
>> comprehensive verification package (like that used by Verilog / SV), the
>> reason being that VHDL is already very strongly typed - this means less
>> verification.
>>
>> I hear VHDL designers say "If it works in simulation, it works on
>> silicon", but I don't hear the same from Verilog/SV designers. Instead they
>> would talk a lot about verifying their designs. The rationale is clear,
>> Verilog/SV needs very comprehensive verification (I even hear of great
>> emphasis on lab bench verification and FPGA emulation - for ASIC designers)
>> to counter for their weak typing, while VHDL being strongly-typed, does not
>> require such comprehensive verification capabilities.
>>
>> I currently write everything in plain old VHDL - from the core designs to
>> even the testbenches. And I feel the language is sufficient for both
>> purposes (this perhaps is because my designs aren't as complex as some of
>> yours).
>>
>> My humble opinion is that we should not try to do the same things those SV
>> guys have been doing (I agree with Steve on this), but instead focus our
>> energy on things that make VHDL easier to use, such as simplifying type
>> conversions, and friendlier packages.
>>
>> I would propose that we make some of VHDL's core packages to easily work
>> together with one another. One simple example I can think of is in the use
>> of literals:
>>
>> signal i: integer := x"ab";
>>
>> where in this case, I can use the hex notation to express an integer
>> instead of writing out 16#ab#.
>>
>> I further propose for certain packages to be synthesisable, such as the
>> math_real package (this would ease designers from having to write their own
>> fixed-point or floating-point packages).
>>
>> Also, for certain constructs in the core language to be synthesisable,
>> such as "assert" or "report", which currently is exclusively used only in
>> simulation. I can think of something like a generic "debug interface" or
>> "verification interface", which can be synthesised to a real interface
>> reserved for debugging/verification purposes. And this interface allows for
>> the use of constructs such as "report" and "assert", while having
>> capabilities such as queuing of "reports" (or logs), and bus arbitration
>> (for multiple verification interfaces).
>>
>> I am positive that with great minds as all of you, the SG/WG will be able
>> to brainstorm such great ideas to set the direction for the next revision of
>> VHDL.
>>
>> Regards,
>> Daniel
>>
>>
>> On Mon, Dec 20, 2010 at 4:35 AM, Bailey, Stephen <
>> stephen_bailey@mentor.com> wrote:
>>
>>> I have submitted my negative vote on the PAR to Jim. I am now
>>> forwarding the comments that document why I am voting Negative.
>>>
>>> -Steve Bailey
>>>
>>> The SG has spent all of its time discussing the organization of the WG
>>> as individual or entity/Corporate. I don't see anything in the minutes
>>> identifying the requirements for this revision. The recent flurry of
>>> emails has me concerned that the WG will duplicate significant work that
>>> has gone into SV by putting similar functionality into VHDL. I cannot
>>> support the waste of tens to hundreds of man-years to achieve that
>>> output with the only outcome being that people can do what they can do
>>> today only in 2 different languages instead of 1 (actually 4 different
>>> languages instead of 3 when you include e and Vera).
>>>
>>> VHDL usage was on the decline prior to SV. SV has accelerated that
>>> decline. I don't see a way to change the current course of the
>>> EDA/language trends. They are too strong and the cost to change them
>>> are prohibitive.
>>>
>>> Data which the SG may find useful. The data is from a recent blind
>>> survey commissioned by Mentor and conducted by Wilson Research Group.
>>> This data is from North America. The rest of the world portion of the
>>> survey was recently completed and the combined results not yet
>>> available.
>>>
>>> VHDL design usage declined from 37% in 2007 to 27% in 2010 with
>>> respondents projected a further decline to 23% in the next 12 months.
>>> That's a loss of nearly 40% of the design user base for VHDL.
>>>
>>> Verilog usage has declined from 81% to 78% and projected to go to 71%.
>>> SystemC, C/C++ and other design languages have also declined from 2007
>>> to 2010.
>>>
>>> SV has increased from 10% to 34% today and projected to reach 47% in the
>>> next year. That's a nearly 5x increase in usage.
>>>
>>> In verification, VHDL usage is down to 21%, from 27%, and projected to
>>> fall further. In fact, there are only two languages that have increased
>>> usage in verification: SystemVerilog usage in verification more than
>>> doubled to 50% and is projected to increase significantly in the next
>>> year. C/C++ has seen a respectable increase from 2007 but is projected
>>> to decline slightly in the next year. Even SystemC usage in
>>> verification is down slightly from 2007 -- call it steady at about 17%.
>>>
>>> The survey included FPGA and ASIC designs and respondents from all
>>> industries/markets. Although data from the rest of the world might
>>> soften a bit what is being reported in NA, based on my personal
>>> experience, I don't expect it to be meaningful in any area except maybe
>>> SystemC, which has historically higher use in Europe and Japan than in
>>> the U.S.
>>>
>>> In the next year, 80% (4 of every 5) of designers and verification
>>> engineers will use a language that is not VHDL. Most of them will be
>>> using SV or Verilog.
>>>
>>> The SG needs to ask itself these questions: Can you stop a tsunami?
>>> What can you offer that would overcome a projected 3x+ advantage that SV
>>> will have over VHDL in verification usage within the next year; and
>>> surely greater than that 2 or 3 years from now. If the plan is to
>>> survive the tsunami, what will you do to survive it when EDA vendors
>>> clearly know where the market is going? Until these questions are
>>> addressed in a manner that reflects reality, my vote will remain No on
>>> another VHDL language revision.
>>>
>>>
>>> --
>>> 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.