RE: [sv-bc] expressions not allowed in RHS or continous assign or on port connection list

Dave,

I don't think you understood me.

I have no problem with this particular restriction. I don't think it prevents something terribly useful.

What I don't like is where a restriction is made very wide because in a particular case, it could make a problem. Such a wide restriction would be to forbid functions in continuous assignments entirely because in certain cases, they could make problems. As Steven pointed out, this was not done because they are too useful to restrict that way.

However, there have been some attempts to make such wide restrictions in other constructs, and in some cases, restrictions have been there from the beginning or have not been been relaxed from such considerations. What I am saying is that where such restrictions have a significant price for the user, in making his code much more awkward or complex, or preventing him entirely from doing something, that price needs to be given significant weight when making a decision.

I agree that people really want interoperability. I do too. A lot of my current work involves porting code from one tool to another. But while some of that involves nondeterministic behavior or varying interpretations of LRM ambiguities, a lot of it also comes from (1) tools that don't implement LRM constructs that others do implement, and (2) tools that allow constructs that the LRM does not. Yes, I am aware that some of cases of (2) have come from demands of users from the company I work for (not my group...). Others go back as far as Verilog-XL...

Regards,
Shalom

> -----Original Message-----
> From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> Sent: Thursday, April 08, 2010 10:11 AM
> To: Bresticker, Shalom; Steven Sharp; john@svtii.com; sv-bc@eda.org
> Subject: RE: [sv-bc] expressions not allowed in RHS or
> continous assign or on port connection list
>
> Shalom,
>
> This particular case was not just about writing bad code, but writing
> bad code that performs equally badly across all
> implementations. People
> really, really want interoperability. They do not want features whose
> results are "implementation dependant". Sometimes, language
> restrictions
> are there for future removal until their results can be made
> deterministic. That may or may not ever happen.
>
> If we don't put in this particular restriction, then users
> start writing
> code dependant on implementation A. Other users start writing code
> dependant on a different implementation B, which might be incompatible
> implementation A. Then we're stuck trying to put this into the LRM.
>
> Dave
---------------------------------------------------------------------
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.