Subject: RE: Special State
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Wed Jan 15 2003 - 09:38:47 PST
Michael,
what do you mean as the 'text description of a state'. There is currently
no such concept.
As to the other question, I am afraid that it is not (easily) possible to
know whether a stateID is valid or not. This question is only reasonable
from the perspective of a specific assertion instance and even in that case
it may be very inefficient (ie possibly requires full traversal of the
assertion to be answered).
Given the above, does providing such an interface provide any significant
value ? I am not sure that it would, given that there is not much applications
can do with a stateID: it is implementation specific, largely meaningless other
than for constructing debug views (and in that use, the only requirement is
that stateIDs be comparable to other stateIDs from the same assertion) and for
determining what "type" of state this is.
Joao
==============================================================================
Joao Geada, PhD Principal Engineer Verif Tech Group
Synopsys, Inc TEL: (508) 263-8083
344 Simarano Drive, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
-----Original Message-----
From: Michael Rohleder [mailto:michael.rohleder@motorola.com]
Sent: Wednesday, January 15, 2003 12:32 PM
To: Joao.Geada@synopsys.COM
Cc: Andrzej Litwiniuk; sv-cc@eda.org
Subject: Re: Special State
Fine with me, as long as you think about a third function
vpi_get(vpiStateDesc, stateID) => const char*
which provides a textual description of the state associated with StateID. const char*, because the related memory should belong to
SV and never be changed or free'd.
To permit checking for valid states you might also want to provide
vpi_get(vpiIsValidState, stateID) => true/false
-Michael
Joao Geada wrote:
> How about:
>
> vpi_get(vpiIsAcceptingState, stateID) => true/false
> vpi_get(vpiIsStartingState, stateID) => true/false
>
> NOTES: this method will only work correctly when supplied a valid stateID.
> Supplying this method to any other vpi handle may have unpredictable and/or
> erroneous behavior.
>
> Joao
> ==============================================================================
> Joao Geada, PhD Principal Engineer Verif Tech Group
> Synopsys, Inc TEL: (508) 263-8083
> 344 Simarano Drive, Suite 300, FAX: (508) 263-8069
> Marlboro, MA 01752, USA
> ==============================================================================
>
> -----OriginalMessage-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org]On Behalf Of
> Michael Rohleder
> Sent: Wednesday, January 15, 2003 11:44 AM
> To: Andrzej Litwiniuk
> Cc: sv-cc@eda.org
> Subject: Re: Special State
>
> a) Yes, this is also my favorite variant.
> b) As already said, I don't care about the naming convention as long as there is one. :-)
>
> - Michael
>
> Andrzej Litwiniuk wrote:
>
> > > * At a minimum we need to be able to _identify_ the start and any accepting state
> > > * I would further like to be able to distinguish different accepting states
> >
> > > - Start state is always encoded as 0
> > > - Accepting states can be identified by bool svaIsAcceptingState(StateID )
> >
> > I would vote for this variant.
> >
> > Andrzej
> >
> > PS. BTW, I used to think that the proposed naming convention for the assertions stuff
> > was: sva_is_accepting_state(StateID)
>
> --
>
> NOTE: The content of this message may contain personal views
> which are not neccessarily the views of Motorola, unless specifically stated.
>
> ___________________________________________________
> | |
> _ | Michael Rohleder Tel: +49-89-92103-259 | _
> / )| Software Technologist Fax: +49-89-92103-680 |( \
> / / | Motorola, Semiconductor Products, System Design | \ \
> _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_
> (((\ \>|_/ > < \_|</ /)))
> (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////)
> \ /_______________________________________________\ /
> \ _/ \_ /
> / / \ \
>
> The information contained in this email has been classified as:
> Motorola General Business Information (x)
> Motorola Internal Use Only ( )
> Motorola Confidential Proprietary ( )
>
> *** This note may contain Motorola Confidential Proprietary or
> Motorola Internal Use Only Information and is intended to be
> reviewed by only the individual or organization named above.
> If you are not the intended recipient or an authorized representative
> of the intended recipient, you are hereby notified that any review,
> dissemination or copying of this email and its attachments, if any,
> or the information contained herein is prohibited. If you have received
> this email in error, please immediately notify the sender by
> return email and delete this email from your system.
> Thank you! ***
--NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )
*** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! ***
This archive was generated by hypermail 2b28 : Wed Jan 15 2003 - 09:39:47 PST