RE: [vhdl-200x] VHDL Testbench Enhancements

Dear Jim,

please find below my personal comments:

* Definitely, VHDL needs testbench support. A VHDL internal
implementation would be nice,
  but it might be much too late for that.
* I have my doubts, if this can be done without breaking VHDL principles
(e.g. access to 
  internal objects, 0-delay non deterministic communication, AOP, ...). 
* Independent from that a DPI as available in Systemverilog, but also
usable for
  C++ would be very helpful.


Kind Regards,
Wolfgang


 

-----Original Message-----
From: owner-vhdl-200x@server.eda.org
[mailto:owner-vhdl-200x@server.eda.org] On Behalf Of Jim Lewis
Sent: Tuesday, April 03, 2007 9:45 PM
To: vhdl-200x@server.eda.org
Subject: [vhdl-200x] VHDL Testbench Enhancements

Hi,
The VHDL standards community has been considering whether to enhance
VHDL to add advanced testbench features.

If you are a VHDL user,
   Do you want these features added to VHDL?
   Would you rather adopt a verification language that
   already supports these (SystemVerilog, SystemC, E, Vera).

I think VHDL needs to enhance testbench capability to stay competitive.

The current plan in the VHDL working group is to make these features
similar to other verification languages while at the same time keeping
the nature of VHDL.

We need your to voice your support.  You can post here, send your reply
to me (let me know if I can use either your name and/or company name
when I tally the results for the Accellera VHDL TSC), or join the
Accellera VHDL TSC (which you can do as a non-Accellera member by
registering) and post your reply there.

More on the politics of the situation are below.

Thanks,
Jim Lewis
VHDL Evangelist
SynthWorks VHDL Training



P.S.
One of the simulator vendors has indicated that will only implement new
features if the user community demands them.  Business wise, this makes
sense - you don't build something unless someone will buy it.

If you fail to voice your support, they may be able to successfully
block these proposals from going forward.

If we let this opportunity to add these features to the standard pass, I
do not think we will have to opportunity to add them later - hence you
will be stuck with using some other language for advanced verification
features.

This work is work in progress and below is the current status.
Keep in mind too that your interest/support of this work will help raise
the focus and inspiration of those doing the work.

   Classes / OO:
     Classes are useful for creating verification data structures,
     transaction communication, and grouping for transaction based
     randomization (building relationships between separate data
     items).  Many of the data structures (such as scoreboards,
     memories, and linked structures) can already be created, however,
     classes give you the ability to hide all pointer manipulations.
     For example, using a memory would require a declaration with
     initialization of the memory data structure, then MemWrite and
     MemRead would allow a user to store and retrieve items from the
     data structure.  Pointers and allocation of the sparse data
     structure are handled by MemWrite and MemRead and the
     user would not need to be aware of it.
     Status:
     Peter Ashenden submitted a class proposal last year and
     provided updates to it this year at DVCon.  Currently
     he plans on finishing an updated draft soon.

   Randomization:
     Randomization is useful for designs that have numerous configurable
     features.  Testing features individually in an isolated manner is
     typically straightforward. However, testing how these features
     interact can be a large verification space - one that may not be
able
     to be simulated completely. It is also may be difficult to predict
     all of the corner cases.  Randomization has been used to sequence a
     test in a non-deterministic way to get reasonably good coverage of
     this verification space.
     While I do not share the thought that randomization should be
     adapted to work for all verification problems, I do believe it
     to be a valuable technique for some problems.

     I wrote a draft of the randomization proposal and it is ready
     for review.

   Functional Coverage:
     Tool/structural coverage can tell you that you did a FIFO
     read or that the the FIFO went empty, but it can't tell
     you that you did a read while the FIFO was empty.

     Functional coverage constructs allow you to track this.
     Some functional coverage capability will come from assertions
     (since PSL has been integrated into VHDL).  Additional constructs
     will be added to allow data binning (coverage groups) and
     correlation between different coverage items (cross coverage).

     I have started working on this - anyone else who is interested
     is welcome to contribute as much as they would like.


With a focused effort, like the one to finish the Accellera 3.0 draft of
the standard, I think we can be done with these by September.

Although some have expressed doubt, it is clear that vendors will do
what their user community asks them to do - otherwise, someone else will
and, as a result, will earn your business.


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, and is
believed to be clean.