[sv-champions] SV-AC responses - resend

It appears that Majordomo had a problem with the original
email. I rearranged the first paragraph to try to work around
the problem.



-------- Original Message --------
Date: Wed, 13 Feb 2008 03:26:10 -0800 (PST)
To: neil.korpusik@sun.com, sv-champions@server.eda.org
Cc: sv-ac@server.eda.org, ieee1800@server.eda.org
From: John Havlicek <john.havlicek@freescale.com>



In the SV-AC meeting 2008-02-12, the committee voted to approve the following
responses to Champions negative feedback.
The vote for each response was 8y/0n/0a.


Champions Major Negative Feedback on 1995:

This proposal is essentially creating a generate block within a
procedural context. I'm fine with limiting this to assertion
statements for now, but that does alleviate addressing all the issues
surrounding generated code. For example each assertion statement is
replicated in the loop (including nested loops) and a generate block
label needs to be created for every instance of each. The loop
iterator should be treated as a genvar constant within each instance
of the assertion statement.

SV-AC Response:

This is incorrect.  The assertion is not being rewritten, and therefore
no artificial generate block is created.  The only effect is that the
assertion is executed several times during the same time slot.  Erik
sent the following clarification:

    ... this proposal was specifically written (with help from your
    co-worker Gord) to *not* treat these as generate loops, and thus avoid
    the (very valid) issue you mention.  Can you please re-review, in
    consultation with Gord?  Thanks!

Champions should review this.


Champions Major Negative Feedback on 1728:

It seems very odd that the let statement is allowed on an immediate
assertion, which is no more complex than a 'if' statement, but not
allowed in any Boolean expression. I understand the SV-AC rush to add
features to the language and limiting those features to assertions,
but limited this kind of feature to assertions does not serve the end
user and the language very well. If there are issues preventing wider
adoption of this feature, let then be flushed out now.

SV-AC Response:

The original intent of SV-AC was to make this construct general, but
since other committees did not have sufficient time budget for
reviewing it, it was decided to limit it for assertions only.  The
proposal is formulated in the way that it can be extended in the
future for additional areas of usage, and it is safer to publish first
a limited version of the proposal than to come with an insufficiently
elaborated general proposal.  We believe that this feature is
essential for building assertion libraries and for doing formal
verification.  SV-AC is already responsible for elaboration of
templates for concurrent assertions (sequence and property
constructs), and we see it as reasonable for SV-AC to provide a
template for immediate assertions (let construct).


Champions Major Negative Feedback on 1900

This proposal needs to be addressed when it can have the full
attention of all the committees as effects every part of the language.
Otherwise, I feel that this enhancement goes beyond the level of
enhancements authorized by the P1800 PAR in embedding a new language
with SV. The number of keywords and statements being introduced can
not be thoroughly reviewed with the resources we have for the current
par.

SV-AC Response:

This proposal was a focal point of SV-AC this year. It generalizes the
notion of a concurrent assertion and is a gating capability for
building assertion libraries and for doing formal verification in
SystemVerilog.  We believe that the main application of checkers
belongs to the SV-AC area, though this construct is also useful for
coverage collection, and therefore it is within the bounds of the
P1800 PAR.  The number of introduced keywords is relatively small:

-          checker/endchecker

-          [free] checkvar

-          initial_check/always_check

If the time required for reviewing this proposal is not sufficient, we
believe that this issue should be addressed by the WG to extend the time
line in order to allow proper reviewing of this proposal and addressing
the reviewers' comments.

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


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