>From: Gordon Vreugdenhil <gordonv@model.com> >I think if you read "evaluating" as "becomes active" you get >the idea of what we have in mind. > >If a process "becomes active" prior to a deferred unique violation >being reported, that violation is tossed. That is pretty well defined, though as you say, there are situations where it could lose real violations. I'm not fond of the extra overhead of keeping track of "activations" for any process that might execute a unique/priority construct, even if it never does. >> As with fork..join_none in functions, there are problems because >> functions can be called from constructs that may require subprocesses >> to implement, but which are not formally recognized as processes by >> the LRM. That leaves their behavior ill-defined under your process-based >> proposal. The issue was avoided with fork..join_none by making it an >> error to execute the fork..join_none from any of these constructs. Would >> you propose the same restriction for unique/priority? Note that trying >> to define what a process is for these situations may get into contentious >> issues based on how different tools have implemented them. > > >I think that we will have to discuss continuous assigns here (I assume >that is the scenario that you are really worried about). Actually, I don't think continuous assigns are that worrisome. The LRM sort of acknowledges that they are processes. It appears to me that they would be well-behaved. Yes, there is the issue that it is not well-defined exactly when they will evaluate, as long as they evaluate "enough". But I don't think that is a problem here. If they evaluate extra times in an implementation, they will presumably get the same result as the previous time. If there was a violation both times, the earlier one would get thrown away and the second one kept. If there is no violation the second time, then it was a glitch and the earlier one should be thrown away. Is there a consideration I am missing here? The scenarios I am worried about are the more unusual ones: procedural continuous assigns, nonblocking assigns, $monitor, and so forth. The only one that seems likely to come up in reasonable designs are the nonblocking assigns, but the behavior has to be specified for everything. >I would support the same semantics for continuous assigns, but >would certainly consider other alternatives that were well formed. >Would you suggest treating unique/priority violations in the >current immediate manner in such scenarios and differently in >true "process" contexts? No, I don't think it would make sense to treat them differently. As I said, I think it would be well-behaved. And I'm not happy about having to treat violations differently in the same function depending on what kind of process it was called from. 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 Thu Oct 11 15:50:30 2007
This archive was generated by hypermail 2.1.8 : Thu Oct 11 2007 - 15:50:42 PDT