RE: [sv-ac] [Fwd: Mantis 1995 - concurrent assertions in loops]

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
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.