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 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.Received on Mon May 28 13:55:49 2007
This archive was generated by hypermail 2.1.8 : Mon May 28 2007 - 13:58:01 PDT