Re: [sv-bc] inconsistency on port connections type rules

From: Steven Sharp <sharp_ f rom>
Date: Tue Feb 15 2005 - 11:18:23 PST
>I cannot understand the last exception. What are two dissimilar net types?
>Are we talking
>
>about a size mismatch which would have been generated it it had been a
>normal named port connection?

I assume that we are talking about (for example) connecting a wand to
a wor, or a supply0 to a supply1.  These produce a warning.

>This is turned into an error for a .name connection?

The idea was presumably that the connection was more likely to be a
mistake if it was done implicitly.  However, I must say that I don't
agree with this.  If the implicit connections are supposed to be
shorthand for the explicit connections, then they should behave the
same way, rather than using a bunch of special-case rules.

In the same way, I agree with you that the connections should be
made if the port is assignment compatible.  This would be allowed
for an explicit named connection, and the implicit connection should
act like a shorthand for the explicit one.


>Section 19.12.5 unpacked array ports and array of instances also talks about
>type matching.
>
>"If the size and type of the port connection match the size and type of a
>single instance port, the connection shall
>
>be made to each instance in an array of instances."
>
>Shouldn't this be changed to if the type of the port connection is
>assignment compatible with
>
>the type of the instance port...:

No.  Instance arrays must match widths exactly.  There are two different
schemes for connecting them, depending on the relationship between the
width of the port and the width of the port expression.  If you did not
require exact matches, it could be ambiguous which scheme to use.   If
you allowed this with rules to resolve the ambiguity, a slight mismatch
in widths could completely change how the port is connected.

Steven Sharp
sharp@cadence.com
Received on Tue Feb 15 11:18:28 2005

This archive was generated by hypermail 2.1.8 : Tue Feb 15 2005 - 11:18:43 PST