Re: [vhdl-200x] Request for Input

Jim, Hans,
The use of transaction-based testbenches is a method that is currently
implemented in VHDL, but not with classes or the VMM/OVM/UVM framework.
 However, I know of organizations that use their own framework across their
designs, and are able to achieve in VHDL reuse and configurations. My point
here is that even though the use of classes offers several advantages, they
require the user an advanced knowledge of software; this is something that
many hardware designer lack. You can do a good testbench design that is
reusable and extendable, and uses the transaction-based approach, and uses
the current VHDL standard (even VHDL'87 or '93).

However, what I feel is lacking in VHDL are constructs available in
SystemVerilog, but cause some grief for users of testbenches. Here is a
list of constructs that I see are needed. I am listing them with the
P1800-2009 section references.

*7.5 Dynamic arrays*
A dynamic array is an unpacked array whose size can be set or changed at run
time.

*7.8 Associative arrays, 7.9 Associative array methods, 7.10 Queues,
7.11 Array querying functions, 7.12 Array manipulation methods*
Dynamic arrays are useful for dealing with contiguous collections of
variables whose number changes dynamically. When the size of the collection
is unknown or the data space is sparse, an associative array is a better
option. Associative arrays do not have any storage allocated until it is
used, and the index expression is not restricted to integral expressions,
but can be of any type.

*18. Constrained random value generation*
*[Ben] This is most important, and should be of highest priority. *
— Random variables
— Constraint blocks
— Randomization methods
— Disabling randomization
— Controlling constraints
— Scope variable randomization
— Seeding the random number generator
— Random weighted case statements
— Random sequence generation

*19. Functional coverage*
*[Ben] This is also very important*
— Defining coverage groups
— Defining coverage points
— Defining cross coverage
— Coverage options
— Coverage system tasks and system functions
— Coverage computation

*20. Utility system tasks and system functions*
*21. I/O system tasks and system functions*
*[Ben] Will have to pick those that are needed and best suited for VHDL. *
*
*
*8. Classes*
*[Ben] Classes are important, but if you start bringing this into VHDL, then
you would be talking about VMM/OVM/UVM, and this is another can of worms.
 If classes are implemented, then we need to consider the frameworks, or at
a minimum, see how they are used so that VHDL can adopt the important
features. I see great uses of classes in randomization. The point here
is that they should not be discarded. *
*
*
*25. Interfaces*
*[Ben] I like the SystemVerilog interfaces, but users have not adopted them
that much for synthesis (maybe a tool issue). In any case, interfaces are
used in VMM/OVM/UVM. *
*I believe that interfaces were addressed before in VHDL 2008. *
Ben Cohen SystemVerilog.us

On Sun, Dec 19, 2010 at 2:19 AM, Hans <hans64@ht-lab.com> wrote:

> ----- Original Message -----
>
> *From:* ben cohen <hdlcohen@gmail.com>
> *To:* Jim Lewis <Jim@synthworks.com>
> *Cc:* vhdl-200x@eda.org
> *Sent:* Saturday, December 18, 2010 7:47 PM
> *Subject:* Re: [vhdl-200x] Request for Input
>
> Jim,
> Ideally, it would be great if VHDL can implement full OO for use of
> frameworks like UVM.
> However, in order for that to be successful, I believe that a full
> implementation a la SystemVerilog would be needed so that all the libraries
> already implemented in VMM/OVM/UVM could be reused with a simple program
> translator. Partial implementation is troublesome, as it would be
> expensive to manually translate those libraries.
>
>
> I fully agree with Ben. Lets be honest, the EDA industry is not particular
> supportive of VHDL. This is partly because of the 20/80 rule were 20% of the
> big (ASIC) Verilog customers generate 80% of the revenue, and partly
> ignorance of EDA companies as to what is happening outside of the US. So in
> order for the next VHDL standard to be successfull we have to make sure this
> is not going to require high R&D investment. A good example is PSL/SVA
> were Accellera put in a lot of effort to make them very similar which I am
> sure contributed to EDA companies adopting PSL.
>
>
> Also, attempting to implement in VHDL the full OO a la SystemVerilog is
> troublesome because we would be talking about differences in syntax and the
> implementation of zones where objects are updated. That VHDL
> implementation would be lagging far behind all the years where SystemVerilog
> made a lot of ground in that field.
>
> Yes, it took the EDA industry many years to implement the SV standard and
> they are still working on it. As we all know this is solely because the
> standard is so incredible huge and "diverse". We should focus on basic
> language capabilities and implement anything like mailboxes etc in IEEE
> packages.
>
>
> I strongly believe that a better approach would be to create an
> API/interface/package that allows interfacing VHDL to SystemC and/or
> SystemVerilog/UVM.
>
> Currently the SystemVerilog LRM has no mention of VHDL; however, tool
> vendors have adopted conventions to allow mixed level simulations. I would
> like to see something more formal in integrating VHDL and SystemVerilog.
>
>
> As you mentioned the EDA vendors have already sorted this out and adding
> VHDL to an OVM framework is not difficult (at least not in Questa). This
> does hamper porting a bit but I don't believe by much. Formalising it would
> be a waste of resources since our objective should be to make VHDL as
> capable as SystemVerilog so that users don't have to use SystemVerilog to
> verify their 100M gate ASIC :).
>
> Studying the OVM/UVM to see what language constructs are required is a good
> starting point for the next VHDL standard. The biggest issue will be adding
> OO to VHDL. Other issues such as constraint random, TLM, functional coverage
> etc can already be partly done in VHDL/PSL and/or are added by EDA vendors.
>
> To get the OO ball rolling we should team up with the Ada group as they
> have not only successfully added OO but also made it such that it passes the
> stringent military/safety critical requirements (were
> verification/validation is king).
>
> http://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation
>
> We should also investigate any intermediate solutions. I am sure that
> VHDL2008 would have been more successful if we had a (free) VHDL2008 to
> VHDL2001 translator. Creating an OO to non-OO translator would not(?) be
> possible but at least we should have a VHDL (UVM) Wiki site to start
> collecting ideas and packages.
>
> Regards,
> Hans
> www.ht-lab.com
>
>
>
> --------------------------------------------------------------------------
>
> Ben Cohen (831) 345-1759
> http://www.systemverilog.us/ ben@systemverilog.us
> * SystemVerilog Assertions Handbook, 2nd Edition, 2010 ISBN
> 878-0-9705394-8-7
> * A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
> * Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004,
> ISBN 0-9705394-6-0
> * Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
> 0-9705394-2-8
> * Component Design by Example, 2001 ISBN 0-9705394-0-1
> * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 ISBN
> 0-7923-8474-1
> * VHDL Answers to Frequently Asked Questions, 2nd Edition ISBN 0-7923-8115
> --------------------------------------------------------------------------
>
>

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