Ok. so this is forbidden - I just think that Shaloms proposal is good place to put this rule explicitly into LRM. DANiel -----Original Message----- From: Steven Sharp [mailto:sharp@cadence.com] Sent: Wednesday, April 02, 2008 1:05 AM To: shalom.bresticker@intel.com; sv-bc@eda.org; danielm@aldec.com.pl Subject: RE: [sv-bc] E-mail Ballot: Respond by 8am PDT, Tuesday, March 25 >From: "danielm" <danielm@aldec.com.pl> >The problem is what should happened when port kind is net (basing on >rules defined in yours doc) but data type is fobbidden for a wire (ie >all 2 val types and others) >I was asking about this before and as i remmeber it is not defined and >currently tool dependent - maybe this probposal is good place to make >this clear. It is currently illegal. It is just that certain tools do not enforce that, and have their own nonstandard ways of dealing with it. >There are 3 solutions: >- always forbid such code - syntax error That is the case now. >- allow 2val types to be a net. There was some discussion of this toward the end of the 2005 standard development. A lot of people seemed to think that this would be a good thing. However, there was not enough time to reach consensus and work out all the details. The effort did not resume after the 2005 standard. >- if port kind is not given explicitly in such cases change implicitly >the kind into variable. If kind is given explicitly print an error The problem with this is that we may eventually allow 2-state types on nets. Then we would either be stuck with this rule that no longer makes any sense, or would have to change the behavior, which would not be backward compatible. By making this case illegal for now, we can decide what to do with it later, without having to worry about backward compatibility. If we make a bad decision now, then we are stuck with it, or have to worry about backward compatibility. Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Apr 2 00:01:04 2008
This archive was generated by hypermail 2.1.8 : Wed Apr 02 2008 - 00:01:49 PDT