The problem is the hierarchical paths to names, the uniqueness of names, and their authority. It is not Ok to just disregard those issues. If the user does a rewrite, the user is responsible for the sanity of the names -- no collisions, referential consistency, etc. If the LRM *defines* such a rewrite, the LRM adopts all of that responsibility. The current proposal is attempting to define something in a sequential loop that is "generate like" but is still sequential. There is no basis for any such hybrid in the LRM. Gord. Eduard Cerny wrote: > Hi, > > I am trying to understand why it is such an issue given all the > restrictions imposed in the proposal on the for loops. With these > restrictions, it is just a question of extracting it out into a generate > block. The user could do it manually. This proposal just allows the user > to have it done automatically, as convenience. It is particularly useful > in RTL code where assertions are inserted directly by the designers. > Given their usual reticence of doing "more than the design", providing > this automatic feature makes designers more willing to insert assertions > to facilitate verification. > > Best regards, > ed > > >> -----Original Message----- >> From: Gordon Vreugdenhil [mailto:gordonv@model.com] >> Sent: Wednesday, November 07, 2007 12:00 PM >> To: Seligman, Erik >> Cc: Korchemny, Dmitry; Eduard Cerny; sv-ac@eda-stds.org >> Subject: Re: [sv-ac] [Fwd: Mantis 1995 - concurrent >> assertions in loops] >> >> Yes it does. >> >> Hierarchical structure and naming relies on constantness >> of indexing and the only way to think about that in your >> proposal is to flatten out the structure and impose some >> form of naming and/or to describe it as a generate. Both >> approaches are flawed in terms of the overall language model. >> >> A non-indexed scope is not a big deal -- it doesn't matter >> whether the scope name is "generated" or not. So concurrent >> assertions in non-loop contexts don't really break the >> overall assumptions of the rest of the language (assuming >> that automatics, etc. are restricted and/or dealt with >> in a proper manner). But for indexed scopes it matters a >> great deal. >> >> For synthesis, the issues go away since everything is >> flattened out to structure. But the simulation side cannot >> assume that and trying to impose such a flattening on the >> normal sequential loop structure is what I am objecting to. >> >> Gord. >> >> >> Seligman, Erik wrote: >>> Thanks Gord-- >>> >>> Please keep in mind that, aside from the loop, a concurrent >> assertion is >>> *already* allowed in procedural code. I agree there are basic >>> challenges with concurrent asserts in procedural code (as >> you taught me >>> very well in the virtual F2F). You may not be too happy >> with what's >>> currently in the LRM... but that's a different issue. >>> >>> Here we are talking about cases where, other than a loop, concurrent >>> asserts are already allowed. So the question is now, given that we >>> already have concurrent assertions in procedural code in >> certain cases, >>> does allowing them in loops really change anything fundamentally? >>> >>> >>> >>> -----Original Message----- >>> From: Gordon Vreugdenhil [mailto:gordonv@model.com] >>> Sent: Monday, November 05, 2007 3:38 PM >>> To: Seligman, Erik >>> Subject: Re: [sv-ac] [Fwd: Mantis 1995 - concurrent >> assertions in loops] >>> >>> Erik, >>> >>> I'll try to respond in the next day or so but right now >> what time I have >>> for SV committees must be BC/EC dedicated due to the >> respective dates >>> for completion. >>> >>> I don't think we are at all on the same page on this >> proposal -- as with >>> the early issues I raised with the glitch-free proposal, >> there are just >>> serious problems in trying to describe this as any sort of a >>> structural/generate rewrite. That just poses very >> substantial problems >>> on various fronts and is simply not a good way to write up >> the proposal. >>> I know what you want in terms of the synthesis side but all of these >>> proposals end up getting down to "do structural flattening like >>> synthesis does" and that is just not acceptable to me in >> the wider LRM >>> context. >>> >>> Gord >>> >>> >>> >>> Seligman, Erik wrote: >>>> 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! >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> -- >>> -------------------------------------------------------------------- >>> Gordon Vreugdenhil 503-685-0808 >>> Model Technology (Mentor Graphics) gordonv@model.com >> -- >> -------------------------------------------------------------------- >> Gordon Vreugdenhil 503-685-0808 >> Model Technology (Mentor Graphics) gordonv@model.com >> >> -- -------------------------------------------------------------------- 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 Wed Nov 7 10:41:18 2007
This archive was generated by hypermail 2.1.8 : Wed Nov 07 2007 - 10:41:27 PST