Advertisements

"knight" <> wrote in message
news:...
> Hi is there anybody using questa...?
>
> Ive attended a seminar on questa by mentor graphics 2 days back...
>
> can you tell me what all are the benefits of using questa and how can
> i enhance my simulation and save design time by using it..?
>
> does it support synthesis...?
> also whether any demo is available...?
>

One would think that if you had attended a seminar two days ago, that you
should be able to answer those questions....if it was a free seminar then it
appears you got your money's worth

Advertisements

"knight" <> wrote in message
news:...
> Hi is there anybody using questa...?
>
> Ive attended a seminar on questa by mentor graphics 2 days back...
>
> can you tell me what all are the benefits of using questa and how can
> i enhance my simulation and save design time by using it..?
>
> does it support synthesis...?

If you attended a seminar on Questa and asks if it supports Synthesis then
you were either asleep or Mentor gave a combined Questa/Catapult/Precision
presentation and decided to interleave the slides

Shame on the presenter, if you couldn't even answer basic questions
yourself after the presentation.
> What I could able to understand was -
> - As Hans said, Questa is Modelsim-SE + Assertions + Functional
> Coverage + Testbench automation + SystemC + "SystemVerilog".
> - Questa supports static verification which was not supported till
> Modelsim 6.2(support dynamic verification).
> - Questa come up with a new verification methodology.

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.

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.
> And finally, the presentor asked seriously to look for some other
> preofession if we are not thinking of updating ourselves with
> SystemVerilog.

This might be correct for pure Verilog-Companies. In VHDL-World, you
could expect benefit from SV only when using it as verification
language.
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.

I know only one company [1] in the German spoken area that switched
for all designs from VHDL to SV and this only for testing, the RTL
wont change to SV. I expect to see only few companies in europe
changing from VHDL to SV until 2010.

In that case I suspect knight dosed off when they changed presenters
>
> What I could able to understand was -
> - As Hans said, Questa is Modelsim-SE + Assertions + Functional
> Coverage + Testbench automation + SystemC + "SystemVerilog".
> - Questa supports static verification which was not supported till
> Modelsim 6.2(support dynamic verification).
> - Questa come up with a new verification methodology.
>
> And finally, the presentor asked seriously to look for some other
> preofession if we are not thinking of updating ourselves with
> SystemVerilog.

<rant on>
This I find very annoying and narrow minded. I might be just me but I get
the impression that "some" EDA companies are on a crusade to convince us
that changing to SystemVerilog will solve all our design and verification
problem. I suspect the main reason is simply engineering overheads and
perhaps a hint of arrogance.

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.

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

I am pretty sure that in many years to come complex designs will be created
and verified in VHDL and Verilog and SystemVerilog and SystemC and C/C++ and
Handel-C and schematics ....
<rant off>

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.

"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 <> wrote:
> "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.

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.

"Thomas Stanka" <> wrote in message
news:...
> On 15 Dez., 11:46, Petter Gustad <> 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

Thomas Stanka <> writes:
> On 15 Dez., 11:46, Petter Gustad <> 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 <> 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" <> 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.

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

"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; [...]

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

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!