Re: [sv-dc] RE: Revised proposal for 3398 and response to Shalom's comments

On 8/23/2011 1:33 AM, Bresticker, Shalom wrote:
>
> Hi,
>
> I still have a problem with the sentence in 6.7, "The default
> initialization value for a net shall be the value z."
>
> Maybe you should add a qualifier to that sentence, like the proposal
> does in 7.2.2.
>

We had originally tried to use a qualified term (atomic net)
so that we didn't run into such things. Is 6.7 your only
objection? I really don't want to go through the entire
LRM to scrub every use of the word "net". It is clear
in context that existing text is talking about "legacy"
nets while the text in 7.2.2 clearly breaks out the case
of nets with user defined nettypes. The same kind of
thing is happening with the "type" rules -- 6.7 gives the
type rules for a traditional "net" while 7.2.2 is refining
those rules for the specific case of net with a user
defined netttype.

I really don't think that it is a good idea to try to unify
this -- keeping the rule sets separate does make it clear
(particularly for a new feature) that there is nothing
changed in the existing rules for legacy nets and this
is simply adding rules that are specific for the new
functionality.

> What happens if a net with a user-defined nettype has no resolution
> function?
>
> What is its initial value?
>

The default value of the underlying data type. We said that:
       The default initialization value for a net with a user-defined
nettype
       shall be the default value defined by the data type.

> Say, for example, that the nettype is simple logic.
>
> The difference is between Z, like a regular net, and X, as specified
> in Table 6-7.
>
> If it is X, then what happens when the driver is not driving?
>

Well, what happens with a uwire?

> Is the resulting value Z or X?
>

Z. The X stems from a *transition* to X vaguely based on a
resolution call.

> What happens if a resolution function does not assign a value to the
> function in some case?
>

That is not possible -- non-void functions always have a return value.

> Does it return the default initial value for a variable of the
> function data type?
>

Exactly -- just as a normal function would. That is existing SV semantics
and should not be described here.

Gord.

> Regards,
>
> Shalom
>
> *From:*owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] *On Behalf Of
> *Bresticker, Shalom
> *Sent:* Sunday, August 21, 2011 1:48 PM
> *To:* Francoise Martinolle; sv-dc@eda.org
> *Subject:* [sv-dc] RE: Revised proposal for 3398 and response to
> Shalom's comments
>
> Hi, so far I think the new version is much tighter than the original.
>
> However, I still have a problem with the following issue.
>
> The text in 6.7 starting, "Certain restrictions apply to the data type
> of a net. A valid data type for a net shall be one of the following,"
> does not say that it only applies to nets of non user-defined data types.
>
> Regards,
>
> Shalom
>
> *From:*Francoise Martinolle [mailto:fm@cadence.com]
> *Sent:* Tuesday, August 02, 2011 7:53 PM
> *To:* sv-dc@eda.org
> *Cc:* Bresticker, Shalom
> *Subject:* Revised proposal for 3398 and response to Shalom's comments
>
> The following text in 6.7 needs to change:
>
> "A valid data type for a net shall be one of the following:
>
> a) A 4-state integral type, including a packed array or packed structure.
>
> b) A fixed-size unpacked array or unpacked structure, where each
> element has a valid data type for a net.
>
> The effect of this recursive definition is that a net is composed
> entirely of 4-state bits and is treated accordingly. In addition to a
> signal value, each bit of a net shall have additional strength
> information.
>
> ...
>
> The default initialization value for a net shall be the value z."
>
> */./*
>
> This only applies to nets of non user-defined nettypes. Next sections
> 6.7.1 and 6.7.2 will define the legal datatypes for nets of user
> defined nettype
>
> and their default initialization value. I added text at the end of
> section 6.7.2 to describe the legal data types for a net with a
> user-defined nettype.
>
> ---------------------------------------------------------------------
> 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* <http://www.mailscanner.info/>, and is
> believed 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* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.