Re: [vhdl-200x] VHDL Testbench Enhancements

Jim,

Since you quote me twice, I'd better comment back.  =8^)

Yes, I was there from the University of Maine (Orono, Maine) meeting onward.  So were a great deal of the then current EDA industry.  Even at that time there were those who though, "Why not put all elements of abstract programming into one language?"  It is a matter of where you draw the line.  When is an HDL not an ESL or a general purpose algorithmic language?  And when do you flow from one language form to another?  I ***do*** give credit to those who have kept the HDL an HDL.

I understand the limitations of VHDL then as now.  Where does one draw the line?  When do you end up with an ESL or GP language language that can not be second sourced?  Yes, VHDL was designed to be a language to guarantee second source components.  The industry caught up and second sourcing isn't impossible without a total redesign.  This is a good thing.  No one vendor's capability was to be the core  capability and so far the language has stayed that way.  God knows, many, many have tried over the years to make extensions work just for them.

My bottom line is an HDL is an HDL, it is not a general purpose algorithmic language, nor is it a parameterized test macro language.  That being said, I like the organization, modularization, and parameterization extensions added to the language that have aided in the scope control, component reuse, and adaptability given to design engineers.

In truth, my only concern is crossing through that gossamer-thin veil and ending up with an HDL that isn't.  Hence why I call for clean escapes from one language system to another, thus giving each representation it's power without having to loose any due to "compatibility."

I hope this better explains my comments made prior.

Cheers,
Richard Wallace


-----Original Message-----
From: Jim Lewis <Jim@synthworks.com>
To: vhdl-200x@eda.org
Sent: Mon, 28 May 2007 2:46 pm
Subject: Re: [vhdl-200x] VHDL Testbench Enhancements


All, 
I wanted to respond to a number of comments raised recently. 
 
> Where can I find any documentation on this effort? Please see my other post titled, "IEEE, Accellera, ..." 
If you have problems getting signed up, send me an email 
and I will help. I think the administrator gets lots of 
SPAM and many emails (especially from gmail and like accounts) 
get filtered out. 
 
> From Richard Wallace 
> Looking at the proposals from both the long term (I was at AFWAL > as the Project Engineer that gave birth to VHDL, ... 
> ... I can't imagine any > good coming from a mash-up of different lexical and semantic issues 
> from a disjunct of purposes expressed in one highly bastardized syntax. 
 
I think you need to give the original designers (and yourself?) a little 
more credit. VHDL was created from the beginning to be more than an 
RTL language and it is. Consistency is what the VHDL community 
demands from a language and I think the Accellera VHDL extensions 
committee has a great start at getting us there. 
 
I encourage you to take a look at the proposals. We are not far 
from having the features we need. The VHDL-2000 language revision 
brought protected types into the language. A protected type is 
like a class without inheritance and polymorphism. So it is 
natural to extend protected types into a class. The other 
extension needed to make extended protected types/classes 
effective is to allow shared variables as ports. 
 
Classes are a core language feature that will be used for higher level 
modeling abstraction, not just verification. Consistent with VHDL 
language design, the class extension is a general language capability 
rather than point features. From these one can build data structures 
(memory models, linked lists, scoreboards,... ), communication mechanisms 
(mailboxes, ...), transaction level models, algorithm design/exploration, 
 ... 
 
Since the proposed implementation of classes is a extension to protected 
types, many things can be prototyped with the current language revision - 
a number of these I have already done. 
 
> Extracted liberally from Daniel Kho & Tim Schneider 
> The only issues are: 
> * to address the security of the attributes (somewhat like public, 
> protected, or private attributes in object-oriented languages. 
> 
> - methods (functions/tasks/procedures) that operate on the objects 
> 
> - inheritance (extensions of previously defined objects 
> into new objects, derived from the original) 
> 
> - handles/pointers to objects 
 
All addressed in the current OO/Class proposal 
 
> From Sukrit Shankar 
> I believe that testbench and verification related enhancements need not 
> be made to VHDL, if the verification flow cannot be modeled so as to 
> have powerful links with the system level design flow. 
 
Agreed. We talk alot about verification to make sure people know we 
are addressing it, however, I think it is also important to address the 
system level issues - some of which I think will be well addressed with 
classes. I saw a paper at DVCon that convinced me that 
we need to be careful about how this done so as to avoid some of the 
issues with SystemVerilog interfaces. Keep in mind when you read the 
proposals that SystemVerilog uses the word "interface" differently than 
other OO languages. 
 
> From Daniel Kho 
> [WRT: Object orientation & Classes] ... My view at present is that 
> this is not really necessary, as we already have a strong 
> entity-architecture syntax structure, which is very similar to object 
> orientation. [So extend entity/architecture rather than protected types.] 
That would be another view of OO and it was explored 
in earlier proposals (somewhere around 1998-1999?). 
 
Creating a class as a type also leverages existing features: protected 
types. Hence, we end up with a class implementation that is similar to 
software and other verification languages and as a result can use similar 
methodologies. 
 
I think we also need the object to be port of a design. For a type 
this only requires extending ports to allow shared variables. I am 
not sure how this would be done with entities as a class. By having 
shared variable ports, it is easy to keep a classical hierarchical 
decomposition of a system using entities - just like we currently do 
with RTL design. This means we don't need to do run time elaboration 
except for systems that require a different number of models 
for each different execution of a testbench. Thus we avoid being 
cornered into a largely sequential modeling style which would 
increase the challenge of modeling complex statemachines, 
particularly for someone transitioning from RTL to testbench modeling. 
 
> From Daniel Kho 
> I would suggest that if we were to decide that we add verification 
> features, we add them as another VHDL extension, ... 
 
One of the biggest benefits of VHDL is its consistency though 
out the language. An extension without VHDL (or PSL) consistency 
would be bad. Hence, I am not sure the advantage to doing the 
specification separately. 
 
Classes need to be core language features so they can extend the 
type system and preserve the type safety of the language, not break it. 
 
What makes randomization so powerful is the ability to write one 
set of constraints in a package and then extend them in an 
architecture or as the randomization is being called. As a result, 
if your core testbench is in VHDL, then the randomization constraints 
need to be used as if they were a direct part of the language. 
Since randomization needs a container and it would be convenient 
if that container were a class (due to the OO), it would be 
advantageous to specify both classes and randomization in the same 
standard. 
 
What makes coverage powerful is the ability to react to it. 
Again if the core of your testbench is VHDL, then the coverage values 
need to be able to be read directly in VHDL. Since PSL is 
integrated into VHDL, it may make sense to integrate this into 
either VHDL or PSL. 
 
> From Richard Wallace 
> My industry does not want a language that resembles: "/One Ring to rule 
> them all, One Ring to find them, One Ring to bring them all, and in the 
> darkness bind them." / What we do want is clear escapes from one form 
> to another allowing the right tools to be used at the right times. I 
> can't imagine any good coming from a mash-up of different lexical and 
> semantic issues from a disjunct of purposes expressed in one highly 
> bastardized syntax. 
I take it you have seen SystemVerilog. I think SV is a good 
demonstration of what happens when different point capability is 
integrated into a language without significant re-work of the syntax 
to achieve consistency with the base language. 
 
It would seem that if I had an escape to some other tool/language 
that I would end up with the same mashed-up inconsistent syntax, 
without the benefit from the tight integration. 
 
I think we can get OO/classes, randomization, and functional 
coverage into VHDL without ruining the language or creating a 
syntax mess. 
 
Cheers, 
Jim 
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
Jim Lewis 
Director of Training mailto:Jim@SynthWorks.com 
SynthWorks Design Inc. http://www.SynthWorks.com%c2%a0
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. 
 


________________________________________________________________________
AOL now offers free email to everyone.  Find out more about what's free from AOL at AOL.com.

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