Re: [sv-bc] RE: initialization of unpacked union in declaration

imho according to current LRM it is illegal to assign union with
assignment pattern (literal)
as per sentense: "If no initial value is specified in the declaration of
a variable of an unpacked union type" you can initialize union with
other union.

DANiel

On 8/7/2012 12:47 PM, Bresticker, Shalom wrote:
>
> Still, in the current LRM, there is nothing to even hint that an
> assignment pattern can be used to assign to an unpacked union.
>
> Nor that a non-qualified union name can be the LHS of an assignment,
> aside from the mysterious "If no initial value is specified in the
> declaration of a variable of an unpacked union type".
>
> Shalom
>
> *From:*Steven Sharp [mailto:sharp@cadence.com]
> *Sent:* Monday, August 06, 2012 23:54
> *To:* Greg Jaxon; sv-bc@eda.org
> *Cc:* Maidment, Matthew R; Bresticker, Shalom
> *Subject:* RE: [sv-bc] RE: initialization of unpacked union in declaration
>
> Also see existing Mantis 2311.
>
> *From:*owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org>
> [mailto:owner-sv-bc@eda.org] <mailto:[mailto:owner-sv-bc@eda.org]> *On
> Behalf Of *Greg Jaxon
> *Sent:* Monday, August 06, 2012 4:46 PM
> *To:* sv-bc@eda.org <mailto:sv-bc@eda.org>
> *Cc:* Maidment, Matthew R; Bresticker, Shalom
> *Subject:* Re: [sv-bc] RE: initialization of unpacked union in declaration
>
> On 8/6/2012 3:32 PM, Greg Jaxon wrote:
>
> The member name should be inside the assignment pattern!
>
> module bar();
>
> union {
>
> bit a;
>
> string b;
>
> } c = '{b:"Hello World"};
>
> endmodule
>
> It was never standardized, maybe never submitted, but the obvious
> extension/complement of the rule that you have to construct the entire
> structure (i.e. that all the struct members must be covered by some
> pattern) is that you must construct the entire union (i.e. at least
> one member must match a pattern element). The default: and type:
> patterns can match fields of the (self-determined, or) given type. Excess
> patterns of such sorts would be ignored, as they are for struct and
> array assignment patterns.
>
>
> On 8/6/2012 2:39 AM, Maidment, Matthew R wrote:
>
> The LRM is quite silent on the matter. That is the problem. We
> both know that.
>
> I was conjecturing based on the fact that you can do it in C like
> this
>
> http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Initializing-Union-Members
>
> These features were derived from C and the intention was to make
> the 2 languages somewhat harmonious to better enable DPI.
>
> Matt
>
> --
> Matt Maidment
> mmaidmen@ichips.intel.com <mailto:mmaidmen@ichips.intel.com>
>
> *From:*Bresticker, Shalom
> *Sent:* Monday, August 06, 2012 12:35 AM
> *To:* Maidment, Matthew R; sv-bc@eda.org <mailto:sv-bc@eda.org>
> *Subject:* RE: initialization of unpacked union in declaration
>
> Actually, I did not know the answer.
>
> Besides, it is not clear from the LRM that you can do an
> assignment to an unpacked union (which an initialization is),
> where the left-hand side is just the union name, not followed by a
> period and a member name. If it is not allowed in the general
> assignment case, how would one know that it is legal in the
> initialization case?
>
> Shalom
>
> *From:*Maidment, Matthew R
> *Sent:* Monday, August 06, 2012 10:29
> *To:* Bresticker, Shalom; sv-bc@eda.org <mailto:sv-bc@eda.org>
> *Subject:* RE: initialization of unpacked union in declaration
>
> I reviewed the LRM based on your question and realized you already
> knew the answer.
>
> Seems a mantis should be filed.
>
> --
> Matt Maidment
> mmaidmen@ichips.intel.com <mailto:mmaidmen@ichips.intel.com>
>
> *From:*Bresticker, Shalom
> *Sent:* Monday, August 06, 2012 12:21 AM
> *To:* Maidment, Matthew R; sv-bc@eda.org <mailto:sv-bc@eda.org>
> *Subject:* RE: initialization of unpacked union in declaration
>
> Maybe, but the LRM does not say so. It is silent.
>
> Shalom
>
> *From:*Maidment, Matthew R
> *Sent:* Monday, August 06, 2012 09:47
> *To:* Bresticker, Shalom; sv-bc@eda.org <mailto:sv-bc@eda.org>
> *Subject:* RE: initialization of unpacked union in declaration
>
> I would guess that it would be an aggregate expression of the type
> of the first member.
>
> module bar();
>
> union {
>
> bit a;
>
> string b;
>
> } c = '{1'b1};
>
> endmodule
>
> --
> Matt Maidment
> mmaidmen@ichips.intel.com <mailto:mmaidmen@ichips.intel.com>
>
> *From:*owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org>
> [mailto:owner-sv-bc@eda.org] <mailto:[mailto:owner-sv-bc@eda.org]>
> *On Behalf Of *Bresticker, Shalom
> *Sent:* Sunday, August 05, 2012 11:10 PM
> *To:* sv-bc@eda.org <mailto:sv-bc@eda.org>
> *Subject:* [sv-bc] FW: initialization of unpacked union in declaration
>
> Hi,
>
> I never got any response to this.
>
> I know some people are on vacation, but does no one have anything
> to say?
>
> Thanks,
>
> Shalom
>
> *From:*owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org>
> [mailto:owner-sv-bc@eda.org] <mailto:[mailto:owner-sv-bc@eda.org]>
> *On Behalf Of *Bresticker, Shalom
> *Sent:* Thursday, July 26, 2012 12:08
> *To:* sv-bc@eda.org <mailto:sv-bc@eda.org>
> *Subject:* [sv-bc] initialization of unpacked union in declaration
>
> Hi,
>
> The LRM says in 7.3,
>
> "If no initial value is specified in the declaration of a variable
> of an unpacked union type, then the variable shall be initialized
> to the default initial value for variables of the type of the
> first member in declaration order of the union type."
>
> Question: how **does** one specify an initial value of an unpacked
> union variable in its declaration?
>
> Thanks,
>
> Shalom
>
> Shalom Bresticker
>
> Intel LAD DA, Jerusalem, Israel
>
> +972 2 589 6582 (office)
>
> +972 54 721 1033 (cell)
>
> http://www.linkedin.com/in/shalombresticker
>
> ---------------------------------------------------------------------
> 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.
>
> ---------------------------------------------------------------------
> 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.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>,
> and is
> believed to be clean.
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
>
> --
> 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.

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