[sv-ac] comments on Mantis 2804

Hi Erik:

I thought about your comments in Mantis 2804. I think we agree on your
last point. My responses to your first two points are below.

J.H.

- "It could be that a formal event arguement appears as the entire event
expression for the purposes of c)1), thus apparently satisfying the
condition, but there is some problem satsifying c)1) after substituting
the actual -- say the actual is "ev1 or ev2", where ev1 and ev2 are
themselves event variables. I'm not sure what the proposal says to do in
this situation."

[ES] Why are you unsure? The proposal explicitly states that the
checking is done sequentially-- first check before the substitution,
then (only if that failed) check after. "If the procedure is inside a
checker, and the event control did not satisfy this condition before the
substitution of actual values for any event arguments to the checker, it
shall be checked again after this substitution." So in your example, the
first check would find that (ev1 or ev2) meets the condition, and will
be the inferred clock. If I remember right, we phrased it that way
specifically for cases like this, to allow an event expression to be
passed in as the 'clock' for a checker.

[JH] Suppose that "event e" is the checker formal argument and the event
control for the procedure is "@(e)". The first check of c)1) passes
provided we interpret "e" itself as an event variable. I don't know
that checker formal arguments are considered to be variables, so that is
a point that seems to need clarification. I don't think that the
second check of c)1) after substitution passes.

I am uneasy with the way the determination of whether the clock is
inferred depends on the way the checker is instantiated. What is an
example where the first check of c)1) fails, but the second check after
substitution passes? Can different actuals for the checker instance
cause the second check of c)1) to pass sometimes and fail other times?
Such code seems more difficult to manage.

When is the check of c)2) performed? If it is after substitution of
actuals, then there can be collisions that cause it to fail even though
the check would have passed before substitution.

- "Another concern is the meaning of the phrase "in such a way as to
affect the state of the variables assigned in the procedure, other than
as a clocking event". Can this condition be made simpler, such as "on
the lefthand or righthand side of an assignment in the procedure"?"

[ES] You may have a point there. But do we have an explicit enumeration
somewhere of the ways to affect state? I'm a little worried that the
language is so complex that we may miss something if we phrase this more
explicitly. Off the top of my head, I can think of assignment RHSs and
functions with side effects.

[JH] Isn't the point here to try to select the right edge expression
when there is more than one, as in "@(posedge clk or negedge rst)"? Can
this be achieved with a crisper condition? I don't think we have an
effective definition of the ways to affect state, and this is basically
my concern.

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