[sv-bc] statement labels

From: Feldman, Yulik <yulik.feldman_at_.....>
Date: Thu Mar 09 2006 - 05:49:23 PST
Hi,

 

I just wanted to bring the attention of SV-CC committee to the issue
described in Mantis 1348 "10.8,9 don't say that statement labels create
named blocks" (http://www.eda.org/svdb/bug_view_page.php?bug_id=0001348)
and the proposed solution. 

 

The LRM and the proposed solution suggest that a statement with label
implies creation of named block around the statement with a name
corresponding to the name of the label. The bugnote I've just added to
the ticket is:

 

I'm not sure whether a statement as "the optional statement label
creates a named block around the statement" is an appropriate statement
for LRM. The ambiguity comes when you think of what data should be
accessible when the model is observed through VPI. Should the model
contain the statement with a label or should it contain the named block?
Or should it contain the statement with a label wrapped in a named
block? But, leaving aside the ambiguity itself, none of the options
seems to be good:

1. If the model should contain the statement with a label, then it is
not clear what the creation of the named block means

2. If the model should contain the named block, then it is not good as
the original information is lost, and the algorithm accessing the model
through VPI (or any other custom implemented API) can't make decisions
based on the original representation. 

3. If the model should contain both, then still the access to the
original information is not clean (i.e. one should explicitly check
whether the named block is an artificial named block, if he wants to
avoid it, and that complicates the algorithms).

Maybe it will be better if the semantics of the label would be explained
in other words, without referring to the "creation of a named block".
Maybe just somehow explaining that the semantics of the statement with a
label is similar to the semantics of the statement wrapped in a named
block, with all the consequences. 

 

 

Thanks,

            Yulik.
Received on Thu Mar 9 05:49:42 2006

This archive was generated by hypermail 2.1.8 : Thu Mar 09 2006 - 05:51:00 PST