RE: Call for Final Vote on Assertion Spec (version 1.8)


Subject: RE: Call for Final Vote on Assertion Spec (version 1.8)
From: Tom Fitzpatrick (fitz@co-design.com)
Date: Mon Apr 08 2002 - 10:14:46 PDT


Hi Adam,

You bring up an interesting point, and I would submit that this is beyond
the scope of a basic assert construct. I beleve you're starting to move up
to higher levels of abstraction, as Bassam mentioned, and this is where the
"procedural OVL" library comes in. As Vassilios has pointed out, our 3.1
discussions will include developing a way of providing such capability as
you requested, which I believe belongs in a library (which I believe is the
way you have implemented it).

That makes the assert construct, as defined, a very useful building block to
allow a lot of utility to designers, which is what it is intended for. I
look forward to your insights into how to add these more abstract
capabilities as we move forward.

Thanks,
-Tom

> -----Original Message-----
> From: owner-assertion@server.eda.org
> [mailto:owner-assertion@server.eda.org]On Behalf Of Adam Krolnik
> Sent: Friday, April 05, 2002 5:38 PM
> To: David Lacey; Accellera Assertion
> Subject: Re: Call for Final Vote on Assertion Spec (version 1.8)
>
>
>
>
> Good afternoon David;
>
> I would ask that the vote be postponed until next week. It does
> not seem that enough of the committee members will vote
> on the final version.
>
> If no, I am going to vote against the final spec for the
> reason of consumption I brought up.
>
> Assertions would not work where a variable time window
> is required. Typically when you have a variable time window
> you have some amount of pipelining (usually limited to a
> maximum amount) that assertions would appear to work in this
> capacity but would then fail to detect a problem.
>
> I seems that to then write the correct assertion an unreasonable
> amount of code would be required from the designer. This kind
> of code is unreasonable because of it's size.
>
> I have been able to convince designers to use assertions mainly
> on the points of:
>
> A. They are very easy to write - one (or a few) line statements.
> B. They cut your debug time by 50%.
>
> The proposed model would define a capability that may not be easily
> extendable should we find out that we should have another model
> instead.
>
> I do like the rest of the specification - the current methodology
> that I run would fit nicely if Verilog had this assertion feature
> or if I switched to SystemVerilog.
>
> Thanks.
>
> Adam Krolnik
> Verification Mgr.
> LSI Logic Corp.
> Plano TX. 75074
>



This archive was generated by hypermail 2b28 : Mon Apr 08 2002 - 10:16:10 PDT