RE: [sv-bc] assignment to input

>From: "Rich, Dave" <Dave_Rich@mentor.com>

>I said in a later post that that it cannot default to a wire kind as the
>sentence you refer to demands.

Your saying this did not change what the sentence in the LRM demands.
Shalom's analysis is correct.


>We would have to either:
>
>1.	define all data types as valid for wire kinds
>2.	change the default not to be a wire kind for those types not
>supported for wire kinds
>3.	make it an error (not backwards compatible with all three
>previous Accellera standards)
>4.	Remove the special default kind for input and inout ports and
>have them match the default kinds everywhere else.

I would suggest that you look at Mantis item 578 for some of the history
of this.  I wrote a variety of proposals that got rejected.  I think
that included ones similar to your 2 and 4.  What got approved is what
is in the LRM.  The fact that it was not fully backward compatible with
the Accellera standards was known when it was approved.

I believe it is desirable to expand the data types allowed on nets, and
there seems to be agreement from others.  There was not time to get all
the issues resolved for the 2005 standard, so some types are still
illegal.  They may be allowed eventually.

It may be reasonable for an implementation to follow your 1 or 2 above,
as a nonstandard extension to get backward compatibility with the
Accellera standards.  There is some risk in doing so.  This might
not be compatible with the IEEE standard when it allows these.  Assuming
that these types are eventually allowed on nets, they would behave
slightly differently from an implementation that used variables, or one
that allowed nets of these types but with different semantics.  This
might not be a big risk.  The differences would be subtle or would
only show up in situations involving multiple drivers.  Most designs
might not care.

Steven Sharp
sharp@cadence.com