RE: [sv-bc] assignment to input

Steven,

There is no rule that says you can't change the LRM if it is warranted.
That is why we have a committee. In this case, some change is warranted
be cause the behavior of 'input bit clk' is not semantically defined.

I'm not in favor of eventually making all data types valid for wire
kinds. I think they should be left to the bit-stream types. I also don't
think we should be letting people declare wires on types that aren't
currently defined and letting implementations diverge on their
semantics.

Wires should only be used for multiply driven signals, and changing the
default back to a var kind will also solve the issue of assigning to
input ports that was recently raised.

Dave


> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Thursday, September 21, 2006 4:17 PM
> To: shalom.bresticker@intel.com; sv-bc@eda-stds.org; Rich, Dave
> Subject: 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