review of analog assertion in Draft 3

All,

Yesterday I have started reading through the section 9.7.3 on assertions in
LRM 2.3 Draft 3 as this part was skipped at the last conference call. Here
are my review comments:

1.The analog immediate assertion is not a system task so should not appear
in chapter 9 of the LRM.

2.In the third paragraph of section 9.7.3 on page 217 the word "that"
should be replaced by "where". This sentence actually rules out the use of
an analog assert statement as the "statement" rule in the BNF in Annex A is
restricted to digital context.

3.The action block of an assert statement should have the same restrictions
as the analog statement inside an analog conditional statement as described
in section 5.8.4. This must be made explicit. As a consequence the
definition of the analog immediate assertion should be moved to section 5.8
while the definition of the assertion system tasks can remain in section 9,
but should be colocated with the definition of $display and $strobe.

4.To keep in line with the BNF in Annex A the assertion_identifier should
be renamed to an analog_assertion_identifier as that will resolve to an
analog_block_identifier as per BNF in section A.6.3.

5.On page 218 in the first paragraph the next-to-last line has a sentence
"The else statement can also be omitted". This is ambiguous as no else
statement has been defined -- if it refers to the else keyword that would
lead to ambiguous BNF; if it refers to the fail statement that would be
noncompliant with the SV definition of the immediate assertion statement
(IEEE 1800-2005, section 17.2, page 231, syntax box 17-1).

6.On page 217 the syntax box 9-7 rule for the action_block statement is
incomplete and wrong. Based on the description at the top of page 218 and
the definition in the IEEE 1800-2005 standard its actual definition should
be:

      analog_immediate_assert_statement ::=
             [ analog_assertion_identifier : ] assert ( expression )
analog_action_block
      analog_action_block ::=
             analog_statement_or_null
           | [ analog_statement ] else analog_statement

7.On page 218 in the second paragraph from the top the text between
parentheses "(or any other Verilog-AMS statement)" should be removed. The
part of the sentence afetr the closing parenthesis should be: "and shall be
part of any %m format specification used inside the action block."

8.The paragraph above syntax box 9-8 restricts the use of the assertion
system tasks to the analog_statement after the else keyword in the action
block. This is either an unnecessary restriction or a weak syntax
definition in syntax box 9-7.

9.In the same paragraph the severity level error is introduced without
referring to a prior description of available severity levels. These should
be introduced first if that has any meaning in the given context -- which
is questionable.

10.For consistency the syntax box 9-8 should restrict its description of
the system task arguments for the assertion system tasks in the same way as
in the syntax box 9-1 on page 207 for the display system tasks in an analog
block.

11.In the bulleted list below syntax box 9-8 the descriptions seem to imply
that only the $warning system task can be suppressed -- in fact all 3
non-fatal system tasks should be suppressable. This is already implied by
the second part of the last sentence of page 218.

12.In the same bulleted list the $fatal system tasks implies the running of
the $finish tasks -- in the recently discussed description of the $finish
task this means that $fatal cannot be used to bail out of simulation before
the analog final_step event is run. That is not sufficiently fatal for most
situations where a $fatal would be applied -- consider for instance the
range checking of indirect parameters in the analog initial block.

13.It seems reasonable to have an immediate assertion usable inside an
analog function or an analog initial block -- for range checking on
indirect parameters or function results. No comments are made in the text
to either allow or disallow this.

14.In non-transient types of analog or mixed-signal simulation it seems
unnecessary to require the output of the simulation time with each
assertion system task.

15.The bulleted list in the fourth paragraph from the bottom uses the name
"severity system tasks" - instead it should say "assertion system tasks".

16.The second bullet in the abovementioned bulleted list requires the
assertion statement to output the hierarchical reference to the assertion
statement. This may not always be desired if the relevant hierachical item
has a different hierarchical reference. The user should have the option to
provide an alternative name using a string parameter and to switch off this
default behavior.

17.On page 219 the first three paragraphs are repetitions of the last three
paragraphs of page 218. They can be removed.

18.The fifth paragraph adds no new information and can therefore be
removed.

19.The final paragraph of this section would improve by providing an
example.

At this moment the analog immediate assertion statement is just a glorified
analog conditional statement. I believe that nearly all intended behavior
as described in section 9.7.3 can be readily achieved by using existing
syntax. The only exception is the changed behavior of the %m modifier in
the display system tasks that would now output the named block hierarchical
reference, not the module hierarchical reference.

Be aware that a number of the above objections apply to the IEEE 1800-2005
standard as well as most of the text has been copied from there. This
shoudl probably lead to a Mantis item for SV assertions as well to clean up
the description.

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