RE: [vhdl-200x] Requirements to do verification

I am ignorant of the BIST and DFT markets. However, I would've thought that if they could benefit from language support, I would have heard something from the DFT team here at Mentor.

In any case, if you have ideas there, I'll be much more in education/review mode and will be happy to ask people from the DFT team to be involved.

-Steve

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Daniel Kho
Sent: Tuesday, April 26, 2011 12:17 PM
To: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] Requirements to do verification

Hi Steven,
I agree that many organisations have separate verification teams which use their own methodology for verification. A long time ago, I was doing software design using C++, Java, and even HTML/Javascript, and I really loved those OO concepts employed by those software languages.

However, things change as I became more interested in digital/RTL design. And I slowly began to love hardware design methodologies, and re-learning those VHDL techniques which I "briefly" learned in school. I delved deep into VHDL, and got myself really interested in using these techniques and really designing digital hardware.

One thing I still find difficult to do with any HDL verification language out there is to design BiST or DFT circuits, in real hardware. I don't think I would want to go back to using my OO methods to design such BiST or DFT hardware circuits. A BiST/DFT circuit is basically another hardware design. I would very much prefer to stick with plain 'ol VHDL, of course using some of the more useful verification and testbench features in VHDL-2008 (or newer), when designing such systems.

I notice an increasing need for designers not just to verify their designs through simulation, but also to prove their designs on real hardware prototypes (to at least show to management that some real hardware is working, not just some software model).

That said, I would want to be able to easily convert my simulation testbench to a hardware BiST circuit, probably either in the same FPGA/ASIC, or as another separate tester IC or PC board. I begin to notice that as new products are being designed, the testers for the same products are also designed concurrently, either by the same company, or by others. For now, I find myself doing both the core design and also the tester (or testbench) design.

And I don't have a lot of time in my hands to write a C++/Java/SystemC/Python/etc. verification model, and having to re-write the same model again in VHDL (or other HDL) to create my tester/BiST.

Regards,
Daniel
On Wed, Apr 27, 2011 at 1:44 AM, Bailey, Stephen <stephen_bailey@mentor.com<mailto:stephen_bailey@mentor.com>> wrote:
Daniel, et al,

There's a difference in language usage for design and usage for verification. Vera and e were used for verification with VHDL before SV existed. Although all designers do some amount of verification, many organizations and projects have dedicated verification teams.

The requirement to use the same language in both areas is loose or minimal. In fact, ask any experienced Verilog designer who moved into verification and they will tell you that using SV for verification is like having to learn a new language. Syntactic familiarity is of minimal help as the mental concepts and thought processes in using dynamic classes and objects, factories (and other UVM objects) have no corollary in static, Verilog RTL design.

In the languages-are-tools category, I will also point out that, from my experience, most people doing TL and ESL design and verification use C/C++ for design and C/C++ or SystemC for verification. Neither 100% in either case. Some use SystemC for design (where users actually write SC code) and there is a company that offers solutions for SV use in TL design. For SoC verification, we see many users writing C code to test integration of blocks and system-level functionality.

What need in the market (target market needs explicit identification too) is VHDL going to address better than anything currently available as a language tool?

-----------
Stephen Bailey

On Apr 26, 2011, at 10:36 AM, "Daniel Kho" <daniel.kho@gmail.com<mailto:daniel.kho@gmail.com>> wrote:
Hi Ben,
"but they felt that OVM is superior to what they had before in the design of their testbench in VHDL, and thus the total switch."
Yes, I see this trend happening in my place as well, but that's because there are quite a significant number of US-based design centres in my place, and probably you're seeing things from the US perspective.

I see yet another trend happening at my place, which is more European companies setting up their design centres (many new buildings in construction). That would mean more VHDL jobs in future (and more VHDL usage). Hopefully, Australia would do the same thing too (I know VHDL is pretty strong in Australia).

Also, though I know many US companies have switched to SystemVerilog, I have heard some who would rather stick with VHDL.

Well, there will come a time when companies will just get tired of switching languages, as HDLs compete with one another and after some time, a lagging HDL will again lead the market and usage space. This is one of the reasons why I would rather not re-learn a new language that can do the same thing. Whatever that could be worked around, I'll live with that first while I wait for a newer revision of the standard to emerge, and start pushing tool vendors to support those new features.

I think the same thing happened with Verilog about the 2002~2005 timeframe, where they probably had almost the same kinds of discussions we are having now. And they did come up with SystemVerilog 2005, which will lead the market for some time, but I'm going to wait till VHDL-2008 starts leading the market again. Well, I see this cycle repeating itself, and I don't see it as a bad thing, because that means we progress with better and more usable HDL standards.

Regards,
Daniel Kho

--
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<http://www.mailscanner.info/>, 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.