«

Thomas Stanka wrote:

> Questa seems to me as a big nice tool for someone who could affort the
> cost overhead, but it wont change market as long as it is siginificant
> more expensive than a SE license.
> The functionality is nice-to-have but not crucial for all designs I
> expect to work on in the next month or years.

I agree. Nice to have, but not of high value to me.

> A good question for testbench automatisation is the question of the
> time and effort needed to write a set of good and sufficient
> assertions in order to enable the testbench automatisation.
> I expect, that you could develop a lot of testbenches yourself in
> that time.

A very good question.
This seems to be a solution to
a problem that I don't have yet.
I would have to see a convincing example
on a real design to change my ways.

I'm semi-automated.
I update editor templates and collect
vhdl procedures and functions for verification
as I go.

> As long as SV for verification needs Questa licenses, only large
> companies will or could afford to change from VHDL to SV. A major
> commercial factor beside the license fee is the effort to change
> existing inhouse resources (tools, rtl-code, verification code,
> verification methodology) to SV.

The target audience seems to be ASIC designs in verilog.
VHDL is already competent for verification and
an FPGA provides a lower-cost system verification cycle.

-- Mike Treseler

"HT-Lab" <> writes:

> For those of you who are SystemVerilog evangelists (or VHDL
> evangelists for that matter), let me tell you that the language
> itself is only a minor part of the design process. Experience in
> design/verification, good coding style, knowledge of other languages
> and disciplines, knowledge of the target hardware etc etc is far
> more important than the language itself.

True. But having a standard way of specifying assertions, cover
metrics, and constraint-random test generation is very valuable. I
once worked on similar tools developed in-house. The cost of
maintaining the tools was high. Being able to do this in a standard
way and be able to obtain the tools from multiple vendors is extremely
valuable IMHO.

This is more supporting a verification methodology rather than than
just language syntax.

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On 15 Dez., 11:46, Petter Gustad <newsmailco...@gustad.com> wrote:
> "HT-Lab" <han...@ht-lab.com> writes:
> > For those of you who are SystemVerilog evangelists (or VHDL
> > evangelists for that matter), let me tell you that the language
> > itself is only a minor part of the design process. Experience in
> > design/verification, good coding style, knowledge of other languages
> > and disciplines, knowledge of the target hardware etc etc is far
> > more important than the language itself.
>
> True. But having a standard way of specifying assertions, cover
> metrics, and constraint-random test generation is very valuable. I
> once worked on similar tools developed in-house. The cost of
> maintaining the tools was high. Being able to do this in a standard
> way and be able to obtain the tools from multiple vendors is extremely
> valuable IMHO.

Do you use assertions in VHDL? WIth a bit effort you could even write
assertions within the rtl (with synthesis on/off) that trigger, if a
request will not be answered with an acknoledge within a few clock
cycles.

And if constraint randow was realy the thing everybody needed, why is
there no package constraint_random available in IEEE?
Would be no technical problem to use a standardised package, the
effort would be small compared to the effort necessary to invent a
complete new language like SV.

bye Thomas

"Thomas Stanka" <> wrote in message
news:e5da7219-0b39-4b02-95f9-...
> On 15 Dez., 11:46, Petter Gustad <newsmailco...@gustad.com> wrote:
...snip
>
> And if constraint randow was realy the thing everybody needed, why is
> there no package constraint_random available in IEEE?
> Would be no technical problem to use a standardised package, the
> effort would be small compared to the effort necessary to invent a
> complete new language like SV.

Hi Thomas,

The issue is that constraint solvers are very complex pieces of software and
you will not be able to capture this in a standard VHDL package. On top of
that you need some form of data introspection to be supported by the
language which unfortunately is not the case for VHDL (or verilog).

The only way to get constraint random in VHDL is for Accellera to specify,
IEEE to standardize it and for EDA companies to support it. Now were do you
think the bottleneck will be

http://www.accellera.org/apps/group_...ization-V1.pdf

Hans.
www.ht-lab.com

>
> bye Thomas

Thomas Stanka <> writes:

> On 15 Dez., 11:46, Petter Gustad <newsmailco...@gustad.com> wrote:
> > True. But having a standard way of specifying assertions, cover
> > metrics, and constraint-random test generation is very valuable. I
> > once worked on similar tools developed in-house. The cost of
> > maintaining the tools was high. Being able to do this in a standard
> > way and be able to obtain the tools from multiple vendors is extremely
> > valuable IMHO.
>
> Do you use assertions in VHDL? WIth a bit effort you could even write
> assertions within the rtl (with synthesis on/off) that trigger, if a
> request will not be answered with an acknoledge within a few clock
> cycles.

You can write assertions in any language, even plain old Verilog. My
point is having a *standard* way of specifying assertions (like SVA).
Then formal tools could read and easily (or at least easeier than
analyze assertions written in any HDL form) analyze the assertions in
conjunction with the coverage results and possibly generate vectors to
improve the coverage. Assertions used like this is more a
specification of protocols and interfaces rather than an error message
to tell you that something went wrong.

> And if constraint randow was realy the thing everybody needed, why is
> there no package constraint_random available in IEEE?

I think this would be quite difficult to implement in standard VHDL,
but I would like to be proven wrong.

Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

"Petter Gustad" <> wrote in message
news:...
> Thomas Stanka <> writes:
>
>> On 15 Dez., 11:46, Petter Gustad <newsmailco...@gustad.com> wrote:
>> > True. But having a standard way of specifying assertions, cover
>> > metrics, and constraint-random test generation is very valuable. I
>> > once worked on similar tools developed in-house. The cost of
>> > maintaining the tools was high. Being able to do this in a standard
>> > way and be able to obtain the tools from multiple vendors is extremely
>> > valuable IMHO.
>>
>> Do you use assertions in VHDL? WIth a bit effort you could even write
>> assertions within the rtl (with synthesis on/off) that trigger, if a
>> request will not be answered with an acknoledge within a few clock
>> cycles.
>
> You can write assertions in any language, even plain old Verilog. My
> point is having a *standard* way of specifying assertions (like SVA).
> Then formal tools could read and easily (or at least easeier than
> analyze assertions written in any HDL form) analyze the assertions in
> conjunction with the coverage results and possibly generate vectors to
> improve the coverage.

I'm kinda missing how an assertion statement is not *standard* and how it
would be any easier to parse some improved 'standard'. VHDL has had
assertions since 1987....and welcomes other languages to the assertions
club.

> Assertions used like this is more a
> specification of protocols and interfaces rather than an error message
> to tell you that something went wrong.

We must have completely different ideas of assetions then. An assertion (in
any form) is a statement of something that must by golly be true....if it is
ever not true an error has occurred. Plain old assertions are used to
specify protocols and interface behavior as well as very
design-specific-probably-of-no-use-to-anyone-else-but-this-design types of
things.

KJ

"KJ" <> writes:
> I'm kinda missing how an assertion statement is not *standard* and how it
> would be any easier to parse some improved 'standard'. VHDL has had
> assertions since 1987....and welcomes other languages to the assertions
> club.
>
> [...]
>
> We must have completely different ideas of assetions then. An assertion (in
> any form) is a statement of something that must by golly be true....if it is
> ever not true an error has occurred. Plain old assertions are used to
> specify protocols and interface behavior as well as very
> design-specific-probably-of-no-use-to-anyone-else-but-this-design types of
> things.

I guess so. When people talk about "assertion based verification" they
don't usually mean the VHDL "assert" statement. You are right in that
an assertion states what is the supposed behavior. However, the
expression that is evaluated differs significantly from what is tested
in a VHDL "assert" statement. Assertion languages like PSL, SVA or /e/
verify temporal behavior. Very similar to a regular expression applied
to characters of a text string, an "assertion" (or rather: "property")
matches behavior over time.[1]

As you are likely aware of, regular expressions are just syntactic
sugar for more or less compless finite automata. But we all enjoy the
sweetness, don't we. Much easier to read.

Regards
Marcus

Footnotes:
[1] My 1996 issue of the "Camel Book" ("Programming Perl") actually
uses the terms "assertion" and "property" in the chapter "Pattern
Matching".

--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]

(seen on http://www.veripool.com/verilog-mode_news.html)

"Petter Gustad" <> wrote in message
news:...
> "KJ" <> writes:
>
>
> SystemVerilog Assertions on the other hand is a language which looks a
> little cryptic at first, but it's very powerful to describe expected
> sequences etc.
Care to give an example to demonstrate how it is any more powerful than a
VHDL or PSL assertion? I'm guessing that it will turn out to be just
'different' and not any more powerful. Sequences and protocols are easily
expressed in VHDL. The equivalent code will likely just be a tad wordier in
VHDL, but not obnoxiously so...as it always seem to be when comparing to
Verilog and its variants.

KJ

"HT-Lab" <> writes:
> There is a lot of life and capability left in VHDL and I suspect that the
> majority of the VHDL users (me included) only using a fraction of the
> language.

Sorry, but this claim doesn't hold any water. Saying most features are
not used a lot (provided that your assumption is true to begin with),
cannot imply that other features might not be used either.

> Yes I agree that SystemVerilog has some nice OO, assertions, fixed
> point, a powerful constraint solver etc but most of these
> technologies are available today for VHDL (and Verilog) users
> without resorting to SystemVerilog.

Really? Of the four quoted features only one is available in VHDL (and
ironically neither in SV core or std package), none in Verilog. How's
that "most of these"?

Regards
Marcus

--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]

(seen on http://www.veripool.com/verilog-mode_news.html)

"KJ" <> writes:

> We must have completely different ideas of assetions then. An assertion (in
> any form) is a statement of something that must by golly be true....if it is
> ever not true an error has occurred. Plain old assertions are used to

That is an assert statement in VHDL or C or written as an if statement
in plain Verilog.

> specify protocols and interface behavior as well as very
> design-specific-probably-of-no-use-to-anyone-else-but-this-design types of
> things.

SystemVerilog Assertions on the other hand is a language which looks a
little cryptic at first, but it's very powerful to describe expected
sequences etc. This language can be interpreted by tools to improve
coverage and/or optimize logic.

A good book on SVA and assertion based verification is:

http://www.springer.com/west/home/en...-22-50493024-0

Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?