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

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

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