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

The following is a forward of a 1995 response that I sent
last week that never showed up on the reflector.  I'm assuming
that nobody actually received it.

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.

attached mail follows:

I have taken a look over 1995 and have some of the same
"structural rewrite" concerns that I've raised before.

Here are some specific comments:

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

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

(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? ....


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

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


(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 don't think this proposal is nearly tight enough to be part
of the LRM yet.  There could be substantial impacts on assumptions
and requirements for naming in other areas that have not been
addressed at all.

Gord.
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com