RE: [sv-bc] SV-BC Meeting Notice: November 21, 2011 9am PST

But .name has an error condition that .name(name) does not, namely, when the size (actually, type) of name is different from that of .name.

Shalom

> -----Original Message-----
> From: Peter Flake [mailto:flake@elda.demon.co.uk]
> Sent: Sunday, November 20, 2011 5:14 PM
> To: Bresticker, Shalom; 'SV-BC'
> Subject: RE: [sv-bc] SV-BC Meeting Notice: November 21, 2011 9am PST
>
> Hi,
>
> I agree that the wording of the LRM needs to be changed.
>
> Defining a .name connection to be the same as a .name(name) connection
> should allow both types of connectivity (replication and array).
>
> Regards,
>
> Peter.
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Bresticker, Shalom
> Sent: 20 November 2011 07:50
> To: Peter Flake; Maidment, Matthew R; 'SV-BC'
> Subject: RE: [sv-bc] SV-BC Meeting Notice: November 21, 2011 9am PST
>
> Hi,
>
> It is a little more complicated than that.
>
> .name/.* require that "the declarations on each side of the port connection
> shall have equivalent data types", while .name(name) does not.
>
> In an array of instances, a .name(name) connection is legal if 'name' has
> the same type as '.name', OR if 'name' is an array of N times a data object
> of type(name), where N is the size of the array of instances.
>
> If you strictly apply the definition of .name/.*, as you suggest, it would
> allow the first type of connection (type(name) == type(.name)), but not the
> second.
>
> I don't think this issue was ever discussed.
>
> Regards,
> Shalom
>
> > -----Original Message-----
> > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> > Peter Flake
> > Sent: Friday, November 18, 2011 6:24 PM
> > To: Maidment, Matthew R; 'SV-BC'
> > Subject: RE: [sv-bc] SV-BC Meeting Notice: November 21, 2011 9am PST
> >
> > Hi,
> >
> > I am afraid I will not be able to attend this meeting, so I am
> > commenting in this email.
> >
> > I think that the semantics of the .* connection are equivalent to a
> > .name connection for each port not explicitly in the connection list.
> >
> > A .name connection is equivalent to a .name(name) connection.
> >
> > A set of .name(expression) connections is equivalent to a set of
> > positional connections.
> >
> > The semantics of positional connections for an array of instances are
> > defined, so the semantics of all the above can be deduced for an array
> > of instances.
> >
> > Whether the VPI needs to be able to re-generate the exact source or
> > just the equivalent set of positional port connections is a requirements
> issue.
> >
> > Regards,
> >
> > Peter.
> >
> >
> > -----Original Message-----
> > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> > Maidment, Matthew R
> > Sent: 16 November 2011 06:38
> > To: SV-BC
> > Subject: [sv-bc] SV-BC Meeting Notice: November 21, 2011 9am PST
> >
> > Hi All.
> >
> > We need to meet on November 21, 2011 at 9AM to discuss Mantis 3423:
> >
> > http://www.eda.org/svdb/view.php?id=3423
> >
> > Shalom's feedback regarding this issue is:
> >
> > >> "This proposal discusses a .* connection to an instance array.
> > >> I
> > don't think
> > >> this has been discussed in SV-BC, I don't think it is defined
> > >> in the
> > LRM. It is
> > >> not clear to me that it is even legal, or if it is, what its
> > semantics are. I
> > >> think this has to be discussed in SV-BC first. (and also .name
> > connections to
> > >> instance arrays)."
> >
> > And Neil has requested that the SV-BC review.
> >
> > Please come prepared to discuss.
> >
> > Thanks.
> >
> >
> > Matt
> > --
> > Matt Maidment
> > mmaidmen@ichips.intel.com
>
> ---------------------------------------------------------------------
> 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.
>
>
>

---------------------------------------------------------------------
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.