RE: [sv-ac] Special assert syntax

Hi Surya:

There is always some negotiation and compromise in setting syntax in the
standards committee.

A number of proposed syntactic constructs have been rejected and changed
as a part of the process.

I think that implementing to non-standard syntax carries with it the
risk of incompatibility with the syntax that is eventually standardized.
People using the non-standard syntax as early adopters of features
should plan to mitigate this risk and look for ways to migrate over to
standard syntax whenever feasible.

J.H.  

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Surya Pratik Saha
Sent: Saturday, March 14, 2009 9:59 PM
To: sv-ac@server.eda.org
Cc: Korchemny, Dmitry; Kulshrestha, Manisha
Subject: Re: [sv-ac] Special assert syntax

Hi all,
Regarding this I want to share something. The design having this syntax
has come from a very big chip design company, and since this type of
non-standard syntax is supported by a simulator of another big company
(may be due to that the design is written using that syntax), so many of
our customers are forcing us to support this non standard items into our
analyzer. But none of other simulators passes the case. Though original
#0 standard syntax is supported by some of them.

So my point is - is there any plan to enhance the standard LRM to make
that non standard syntax as standard, so that other tools also can start
supporting this. If not, then I have a big question on the standard and
the committee why it is there. I can clearly see the design house and
the simulator company together are taking some privilege on other
companies over this point. I have many similar examples that I can
share. Hope the standard committee will think about it and make a clear
solution for this type of problem. Though I am not sure how.

Regards
Surya



-------- Original Message  --------
Subject: Re:[sv-ac] Special assert syntax
From: Korchemny, Dmitry <dmitry.korchemny@intel.com>
To: Kulshrestha, Manisha <Manisha_Kulshrestha@mentor.com>, Surya Pratik
Saha <spsaha@cal.interrasystems.com>, sv-ac@server.eda.org
<sv-ac@eda.org>
Date: Monday, March 09, 2009 3:54:07 PM
> The syntax in the LRM 09 is
>
> assert #0 (a) else $error ("Failed");
>
> Dmitry
>
> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] 
> On Behalf Of Kulshrestha, Manisha
> Sent: Monday, March 09, 2009 10:59 AM
> To: Surya Pratik Saha; sv-ac@server.eda.org
> Subject: RE: [sv-ac] Special assert syntax
>
> Hello Surya,
>
> The syntax you have mentioned is not in the standard. But the standard
has an equivalent feature called 'deffered assertions'. They are
described in 16.4. I am not aware about the exact differences but
deferred assertions were based on assert final concept.
>
> Manisha
>
> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] 
> On Behalf Of Surya Pratik Saha
> Sent: Monday, March 09, 2009 1:22 PM
> To: sv-ac@server.eda.org
> Subject: [sv-ac] Special assert syntax
>
> Hi,
> Recently I came across one particular assert syntax which supported by

> a standard simulator. This SVA feature involves so called "final
assertions".
> which have a form such as:
>
> assert final (a) else $error ("Failed");
>
> It appears that assertions of this type would be acceptable inside and

> outside procedural code.
>
> Though I did not see any such enhancements in SV 2009 draft LRM. Can 
> anybody let me know the details about this syntax.
>
> --
> Regards
> Surya
>
>
>
>
> --
> This message has been scanned for viruses and dangerous content by 
> MailScanner, and is believed to be clean.
>
>
> --
> This email was Anti Virus checked by Astaro Security Gateway. 
> http://www.astaro.com
>
> -- This message has been scanned for viruses anddangerous content by
MailScanner, and isbelieved to be clean.
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for 
> the sole use of the intended recipient(s). Any review or distribution 
> by others is strictly prohibited. If you are not the intended 
> recipient, please contact the sender and delete all copies.
>
>
>
>
>   




--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.