[sv-ac] Comments on 2858 and 1551:

Below are some comments in preparation to our meeting.
*2858: Clarify the rules for assigning a value to a non-checker variable
from within a checke**r.*
 1) *Comments*: LRM 17.2 shows an example of a checker declaration within a
module declaration.
     Yet, I understand that some simulators do not (as of today) support
nested declarations, be it checker within checker
     and module, or module within a module. Interestingly though, I tried
another simulator that supports nested declarations,
     such as a inner module within an outer module. That is probably
irrelevant to the LRM, as it represents an implementation.
     But, if a vendor does not support such a feature, it could mean that
their customers are not so enamored with this concept.
     Of course, it could mean that the vendor has not yet supported that
feature.
 *2) Should a non-checker variable be readable from within a checker? *
    Yes. The LRM does that alewady with the default cocking and disable.

*3) Should a non-checker variable be writable from within a checker? *
    I see our committee moving into the direction of providing to the
checker all (or most) of the features
   currently supported by modules, including of interfaces, class instances,
loop statements in always,
   hierarchical referencing, etc...
   I question the application of very complex checkers that need all these
features. It seems to me that if you have such a complex checker that need
non-checker variable assignment, that checker would most likely be
instantiated statically (instead of procedurally), and thus could easily be
replaced with a module. This would give this verification unit all the
features of a checker, but without the procedural instantiation.
From my simple experience with checkers, I see them as being relatively
small verification unit, each targeted to specific sub-functions, and
instantiated where needed. A great percentage of those checkers will be
instantiated statically (my perspective, I maybe wrong).

Thus, the main question in my mind is, how much more complexity do we want
to introduce? Assigning values to non-checker variables also has the
danger of causing side-effects to the DUT. The original intent of the
checker was to ensure separation and non-interference with synthesis (i.e.,
the verification code will not interfere with the performance of the DUT,
and will not be synthesized.

I recommend that we DO NOT allow the assignment of values to outside the
checker. Thus, no assignment to non-checker variables, and no output ports.
 *Rationale*: A checker should remain passive, and should not risk having
side effects to the DUT. Providing this out of checker writing capability
opens the door to this possibility. Considering the original intent of the
checker, we should maintain that mission. As an alternative, a user can
always use a module if he wants such complexity (with teh static
instantiation of that verification module).

*1551: Make disable iff sampled.*
*"**It makes simulation inconsistent with FV": *From what I saw, formal
verification vendors do not have an issue with this.
I vote for no change.
*
*

On Mon, Apr 26, 2010 at 12:37 PM, Korchemny, Dmitry <
dmitry.korchemny@intel.com> wrote:

> Hi all,
>
>
>
> You can find the spreadsheet here<https://spreadsheets.google.com/ccc?key=0AgfncMbEn369dFl3cXRndWl3TDRwTXF3SkJvWklseHc&hl=en>.
> Everybody can view this document, but only those people who sent me your
> account names may edit it.
>
> The document has the following format:
>
> · Issue description from Mantis
>
> · Category, e.g., checker usability, sampling, etc.
>
> · For every committee member there are three fields: Importance,
> Priority, and Comments.
>
>
>
> I inserted only clarification/errata with medium or high effort, and *all*enhancements.
>
>
>
> Please, review the categories and send me your suggestions/comments. You
> are also welcome to add more issues, but they have to be uploaded to Mantis
> first.
>
>
>
> We will discuss the prioritization discipline at the tomorrow’s meeting. My
> suggestion is that everybody inserts his/her importance mark and priority to
> the relevant issues. The issues that are not important to you may be left
> unranked.
>
>
>
> In our prioritization we should take into account the recommendations of
> P1800 WG. Here are the recommendations along with their priorities that are
> relevant to SV-AC:
>
> · Cleanup and Ambiguity Resolution
>
> o Rationalize the type system
>
> · AOP (This is definitely relevant for SV-AC, but there is no
> proposal related to it).
>
> · Connections to Analog
>
> o Verilog AMS
>
> o RF
>
> · Assertions & Checkers
>
> o The letter “t” (?)
>
> o Real value assertions
>
> · Interfaces (We have one Mantis items about passing interfaces to
> checkers)
>
> · Covergroups
>
> · Deprecating Features
>
> · Links to SystemC 1p (1p) (Not clear)
>
>
>
> However, some of these items have only a marginal relation to SV-AC, and
> they should be a focus of other committees.
>
>
>
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

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