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

Anyway, the point was that SV-CC should not implement a change that relates to this case unless SV-BC has decided that it is legal and what its semantics are. That likely involves adding a clarification to the LRM.

Regards,
Shalom

> -----Original Message-----
> From: Peter Flake [mailto:flake@elda.demon.co.uk]
> Sent: Sunday, November 20, 2011 6:40 PM
> To: Bresticker, Shalom; 'SV-BC'
> Subject: RE: [sv-bc] SV-BC Meeting Notice: November 21, 2011 9am PST
>
> Agreed. We can continue the restriction to avoid changing the specification
> in the scalar instance case, and just clarify what happens in the array of
> instances case.
>
> Peter.
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Bresticker, Shalom
> Sent: 20 November 2011 15:27
> To: Peter Flake; 'SV-BC'
> Subject: 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.
>
>
>

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