Re: [vhdl-200x] Request for Input

From: Hans <>
Date: Sun Dec 19 2010 - 02:19:44 PST

----- Original Message -----
  From: ben cohen
  To: Jim Lewis
  Sent: Saturday, December 18, 2010 7:47 PM
  Subject: Re: [vhdl-200x] Request for Input

  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).

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.


  Ben Cohen (831) 345-1759
  * 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.
Received on Sun Dec 19 02:20:25 2010

This archive was generated by hypermail 2.1.8 : Sun Dec 19 2010 - 02:20:50 PST