On 23/04/11 5:04 AM, Jim Lewis wrote:
> All,
> If we are to make VHDL a viable verification language,
> what features do we require?
>
> I am thinking the main ones are functional coverage,
> randomization, data structures (ie: scoreboards,
> memories, fifos, ...) and interfaces.
>
> While I realize some have expressed concern about a language's
> ability to be suited for both design (RTL and above) and
> verification, I am not sure I agree.
I'd be more concerned about features that can cross over from verification
to hardware description and shouldn't necessarily. An example would be
something needing a different dispatch mechanism besides signal scheduling.
We seem to have backed away from that collectively a bit.
> I think a frugal
> implementation of all of the above is possible.
>
Someone once said something should be "as simple as needed and no simpler".
I'd find comparisons to efforts in other languages useful and those efforts
seem a good source for descriptions of what we mean by verification. I used
to work for an Italian company and engineering would get product specs that
would read 'just like so and so's...' It was quite frustrating, and doesn't
represent the end result. In digital design all levels of abstraction should
have equivalence, that may be true in standards efforts, too.
Foundational documentation might help match features to where they can be
used in what type of verification, point out holes, suggest how to look at
other efforts for inspiration.
Converting that V in VHDL to Verification implies at least one added
standard section. The effort could be expressed as a structured process.
I'm not seeing expressions of why for suggested new features, nor cohesive
description of the goals, so far. How about requirements and new features
against particular types of verification? Is this intended to support
system level simulation? Co-simulation?
A little documentation would go a long way and separates challenging
assumptions from addressing features.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sat Apr 23 18:28:48 2011
This archive was generated by hypermail 2.1.8 : Sat Apr 23 2011 - 18:29:14 PDT