Questa AVM

[knight]

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

thanks
knight

 

[KJ]

"knight" <krsheshu@gmail.com> wrote in message
news:5fae0ade-6a15-488c-b7dc-bce7950ce40e@b1g2000pra.googlegroups.com...

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

KJ

 

[HT-Lab]

"knight" <krsheshu@gmail.com> wrote in message
news:5fae0ade-6a15-488c-b7dc-bce7950ce40e@b1g2000pra.googlegroups.com...

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

Questa is Modelsim-SE + Assertions + Functional Coverage + Testbench
automation + SystemC

Hans
www.ht-lab.com

also whether any demo is available...?

thanks
knight

 

[Mike Treseler]

knight wrote:

Hi is there anybody using questa...?

No. I have to struggle just to keep
the SE licenses in the budget.

Ive attended a seminar on questa by mentor graphics 2 days back...

Oh no. I'll be getting more web-seminar email soon.

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

Are you sure you sure you weren't a presenter at the seminar?
Unless you have already mastered vcom and vsim
the extra sizzle they are pitching now won't mean a thing.

does it support synthesis...?

No, but since I worked out my design templates,
I spend very little time on synthesis.
It just works for verified code.


-- Mike Treseler

 

[JK]

I attended Modelsim Questa AVM seminar yesterday. It was part of
XILINX PSI 2007.

Hans guessed correctly. It was a combined Questa/Catapult/Precision
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.

And finally, the presentor asked seriously to look for some other
preofession if we are not thinking of updating ourselves with
SystemVerilog.

Regards,
JK

 

[Thomas Stanka]

Hi,

On 14 Dez., 06:18, JK <krishna.januman...@gmail.com> wrote:

Hans guessed correctly. It was a combined Questa/Catapult/Precision
presentation.

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.

bye Thomas

[1] in fact only part of a big group

 

[JK]

On Dec 14, 11:20 am, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
wrote:

Shame on the presenter, if you couldn't even answer basic questions
yourself after the presentation.

Thomas,

Just a correction. Its not me, who couldn't answer basic questions
after presentor.
This thread is of knight...

As I also attended this seminar yesterday, I wanted to share how the
presentation went on...

Regards,
JK

 

[HT-Lab]

"JK" <krishna.janumanchi@gmail.com> wrote in message
news:ca9aee7c-9209-42f8-8a4e-e14f73939576@s12g2000prg.googlegroups.com...

I attended Modelsim Questa AVM seminar yesterday. It was part of
XILINX PSI 2007.

Hans guessed correctly. It was a combined Questa/Catapult/Precision
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.

And finally, the presentor asked seriously to look for some other
preofession if we are not thinking of updating ourselves with
SystemVerilog.

"JK" <krishna.janumanchi@gmail.com> wrote in message
news:ca9aee7c-9209-42f8-8a4e-e14f73939576@s12g2000prg.googlegroups.com...

I attended Modelsim Questa AVM seminar yesterday. It was part of
XILINX PSI 2007.

Hans guessed correctly. It was a combined Questa/Catapult/Precision
presentation.

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>

Hans
www.ht-lab.com

Regards,
JK

 

[knight]

In that case I suspect knight dosed off when they changed presenters

Sure,
but this discussion is turning to be so valid and
interesting......

knight

 

[Mike Treseler]

JK wrote:

And finally, the presentor asked seriously to look for some other
preofession if we are not thinking of updating ourselves with
SystemVerilog.

Ahh, glad to hear that fear was covered
as well as uncertainty and doubt

The presenter better hope someone believes,
or he may be exploring career options.


-- Mike Treseler

 

[Mike Treseler]

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

 

[Petter Gustad]

"HT-Lab" <hans64@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.

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?

 

[Thomas Stanka]

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

 

[HT-Lab]

"Thomas Stanka" <usenet_nospam_valid@stanka-web.de> wrote in message
news:e5da7219-0b39-4b02-95f9-856e154c3002@r29g2000hsg.googlegroups.com...

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_public/download.php/905/Randomization-V1.pdf

Hans.
www.ht-lab.com

bye Thomas

 

[Petter Gustad]

Thomas Stanka <usenet_nospam_valid@stanka-web.de> 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?

 

[KJ]

"Petter Gustad" <newsmailcomp6@gustad.com> wrote in message
news:877ijdd65c.fsf@gustad.com...

Thomas Stanka <usenet_nospam_valid@stanka-web.de> 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

 

[Marcus Harnisch]

"KJ" <kkjennings@sbcglobal.net> 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)

 

[KJ]

"Petter Gustad" <newsmailcomp6@gustad.com> wrote in message
news:87d4t5h0vg.fsf@mediacenter.home.gustad.com...

"KJ" <kkjennings@sbcglobal.net> 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

 

[Petter Gustad]

"KJ" <kkjennings@sbcglobal.net> 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/engineering/circuits+&+systems?SGWID=4-40604-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?

 

[Marcus Harnisch]

"HT-Lab" <hans64@ht-lab.com> 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)