Hi Gord-- Thanks for your comments. I have read them now, and have some followup questions: (1) "A preceding statement shall not invoke a task call that contains a timing control on any statement." This would now require a full analysis through hierarchical task call chains of whether a task *actually has* such a delay. Either that or a sim time check that will impact performance. Why can't just void functions be used and avoid this entirely new kind of analysis? I don't quite understand how void functions would be used to replace this statement. Can you give a concrete phrasing that would describe this limitation in terms of void functions? (2) The loop restrictions use the term "constant". That implies "constant expression" and full elaboration knowledge. If you want to have separate compilation, any restructuring of the design in the manner indicated is going to be an issue. Aren't there already numerous parts of the language that require constants? For example, in table 10-1, the LHS of a procedural assignment is required to contain a "constant part-select". Why is it uniquely bad in this case? (3) A foreach may have very general bounds based on the fully elaborated design. It can also refer hierarchically to the array (see Mantis 888). So the bounds are not "constant" in the assumed manner. What about a foreach over a dynamic array? An associative array? With a class handle index type? .... We do already forbid associative arrays. But with the variety of issues reported for 'foreach' loops, I'm thinking the best thing may be to remove them from this proposal, and just concentrate on 'for' loops, which is the common case. Ed, Dmitry-- does that sound OK, or are you attached to supporting foreach? (4) The naming scheme says: ... loop iteration indices in square brackets shall be appended to each element of the hierarchical name that specifies a loop This is similar to the old 2001 language for hierarchical names which is entirely bogus and required a major rewrite for 2005. Such a specification could allow mixes of names from different loops since the indices are described as part of the *name*. A generate is similar to an arrayed instance with a *base name* and index *expressions*. Not describing it as such admits all sorts of questions about use of constant expressions in indices, etc. Does this fix it: "A loop iteration index expression shall be appended to each base name of the hierarchical name that specifies a loop"? Or do we need a more complex rewrite of this description? (5) Is it now the case that one could now hierarchically reference through a *sequential* block and find a generate block? What is the relationship in terms of authoritative hierarchical names between the sequential block structure and the inferred generate? How does the pli reach these new generate blocks? Are they really in the same scope? If so, how does the pli safely deal with the different lifetime/scheduling assumptions? These new generate blocks are not "real" generate blocks, but just show how the individual instances of assertions are determined from a loop of assertions. So if hierarchically referencing or using the VPI, the assertions would appear just as if the loop had been unrolled and there are a set of individual assertions, one for each loop iteration. Can you suggest an addition/change to the description to make this clearer? Or do you see a conceptual difficulty with looking at it this way? (6) Are concurrent assertions supposed to be legal in automatic contexts? If so, what do they capture and how does one know that such capture is valid? Note that one can have automatics declared inside *any* sequential block including an initial or always. (7) There is no statement about the enabling condition being side-effect free, non-automatic, etc. Is that stated elsewhere? What assumptions are being made about glitching behavior in the conditions? If the enable is only considered as the sampled value, won't this yield very surprising and non-intuitive results for virtually all loops with loop-variable based conditions? I think items (6)-(7) relate to the same root cause: the *only* change we are attempting to make in this proposal is to allow the assertion within a loop. So it must be the case that for any loop containing a concurrent assertion, that same assertion would be legal in that location in the code if there were no loop present. I guess I was assuming this is implied, but maybe we need to state it more explicitly? Again, any phrasing suggestion would be much appreciated. Also, we are assuming that there can be no glitching behavior, as the latest proposal draft has very stringent requirements on the loop: " the loop iteration assignment shall modify the iterator by a constant nonzero value, and the loop iterator may not be modified within the body of the loop." Actually, I'm thinking you may not have been CCed on the current draft we have been playing with; perhaps it addresses this issue, so I have attached it. Thanks! -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
This archive was generated by hypermail 2.1.8 : Mon Nov 05 2007 - 10:52:30 PST