Korchemny, Dmitry wrote: > Hi Gord, [...] > Could you clarify the following sentence: "Some of the special routines > (for example those related to enables) for checkers really need to be > explained in terms of how they relate to the outer language > constructs."? Consider the use of $inferred_enable. What does it produce in a type sense? Can I use it with an untyped formal? With such a formal, can I do coverage on it? What if the inferred enable is a condition that relates to a loop variable? Are all combinations checked in that context as well? What if the enable is automatic? Is that legal? Clearly (from 16.18.4) you expect $inferred_enable to be able to produce a sequence and be able to use a non-sequence expression in that inferred role. Is there anything else that the $inferred_enable can produce? After looking at LRM 16.14.5, Mantis 1674 and 1648, it still isn't clear to me what the combination of rules implies. 16.14.5 says that for a concurrent assertion, an inferred enable can't occur in a loop. Does that apply to a checker as well? What if the inferred_enable isn't actually used in an assertion in the checker? Would that be legal? I would like to move beyond a narrow discussion of specific rules at some point -- no one has addressed my larger concerns about consistency and regularity of the various constructs. One can make the overall LRM as convoluted as necessary to deal with all the cases that one can imagine, but then one has to re-examine all of those special cases and rules with any future change. I don't think that is a good direction and have said as much for quite a while now with no response from anyone in AC -- the only focus has been on adding new rules and covering specific cases that I am raising. My basic concern is that it just shouldn't be this much work -- is it not possible to devise a simpler set of more consistent abstractions for interaction between the assertions constructs and the rest of the language? Gord. -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Mar 6 02:42:06 2008
This archive was generated by hypermail 2.1.8 : Thu Mar 06 2008 - 02:44:55 PST