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>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> 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, and is believed to be clean.Received on Tue Apr 26 11:18:00 2011
This archive was generated by hypermail 2.1.8 : Tue Apr 26 2011 - 11:18:06 PDT