[sv-ac] 2005 review

Hi Erik,

 

I had an action item to review your proposal. Here are my comments:

 

*         Motivation section

 

o        "For example, the following implementation of a MUX gate will
execute the always block twice when a changes."

It should depend on the specific simulation algorithm, there may be no
glitch here. I would use "may" instead of "will"

o        Same sentence

Code should be in courier 9 (this note relates to the rest of the
proposal as well), "a" should not be in bold

o        The item "Immediate assertions can be placed ..." should not be
part of the list of the situations where a concurrent assertion cannot
be used in place of an immediate assertions; it has a different subject.

o        "Deferred assertions can be used in any place an immediate
assertion is permitted." The proposal also allows specifying them in the
structural context.

o        "The Observed region is the point at which the deferred
assertion reports are deemed "mature". Once mature, any associated
action block code shall execute in the following Reactive region." It
seems to be a reasonable definition versus reporting in the Postponed
region, but I am not 100% confident that this definition won't result in
a glitch behavior for well-formed designs.

 

*         16.4 Deferred Assertions

o        Only the first letter should be capital in the heading:
"Deferred assertions". This note relates to all other headings as well.

o        The proposal talks about deferred assertions only. It should
also mention deferred assume and cover statements.

o        Syntax diagram: assert #0 - # should not be in bold. All
terminals, even new should be in red. This note also relates to
subclause A.6.10.

o        I think that the parentheses around the event should not be
part of the syntax: is "assert @clk (expr)" illegal?

o        If the action blocks are evaluated in the Reactive region, why
are there limitations on the action blocks subroutine that it should not
contain output and inout ports?

 

*         16.4.1

o        "If a deferred assertion flush point (see 16.4.1)", should be
16.4.2

o        "the appropriate process's deferred assertion report queue" -->
"the appropriate process' deferred assertion report queue"

o        The code should be rendered in courier 9.

o        "or $error" --> "or $error, if the assertion fails and no
action_block is present". Also assert cover does not have "$error" by
default.

 

*         16.4.2

o        The bullet should be "*", also in 16.4.4.

o        " ... twice -- once...", should be " ... twice - once ..."

o        "A failure will be reported ..." - see the first note to the
"Motivation" section.

o        "always @(a or b)" "@" should not be in bold,  "or" should.

o        The numbering of assertions in their names should be
continuous: there comes a5 after a2. This comment applies to all the
sections, e.g., in the next subclause the assertion name is a99. Also,
the assertion names need not be unique if they belong to different
subclauses or even to different examples.

 

*         16.4.4 Add a reference to 9.6.2

 

*         16.4.5

o        There are redundant spaces, e.g., "delay.  Such". There are
many such cases in this subclause and throughout the proposal.

o        "pre-scheduled" --> "prescheduled"?

o        The scheduling algorithm for deferred assertions with events is
not completely clear to me. As far as I understood it, it is not
race-free. Consider the example from the proposal:

module fsm(...);

function bit foo(...)

                  ...

                  a42: assert @(posedge clk) (a == b);

                  ...

end

...

always_comb begin : b1

                  next_state = foo(x,y) ? ...

                  ...

end

endmodule

 

Assume that at the current simulation tick both a and clk change. If the
assertion a == b is violated at the current tick and its violation is
detected before the clk change then its violation will be reported at
the current simulation tick. If the clk changes before the violation has
been detected at the same simulation tick, the violation will be
reported (if at all) on the next rising clk only.

o        "the following edge-it will not" --> "the following edge - it
will not"

 

*         16.4.6 Code should be in courier 9. Check the fragment
starting from "Suppose simulation executes..." until the end of the
subclause.

 

*         Need to add VPI diagrams.

 

Thanks,

Dmitry

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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