RE: [sv-ac] 1900 Checkers

Hi Dmitry,

 

I have not completed a review of this yet but I thought I'd share the
comments I have so far:

 

1.	In the objectives, there is a typo "thedescription"
2.	In syntax 9-1, it references "four statements" but I'm not sure
where this count comes from.
3.	In 16.18.1 - "can be formally proved" -> can be formally proven
...
4.	16.18.2 -

	a.	 is it intentional that parameters are not allowed in
the syntax?
	b.	The let proposal changes concurrent_assertion
_item_declaration to assertion_item_declaration
	c.	Should the checker_item::= concurrent_assertion_item
actually reference the procedural_assertion_statement instead.  There is
a definition of procedural_assertion_statement in the syntax that is not
referenced. 
	d.	The subtitle references "Program declaration ..."
instead of "Checker declaration ..."

 

5.	Why can't a checker be declared in compilation unit scope?  In
fact, the "simple checker" example seems to use compilation unit scope.
6.	I think we should allow them to be declared in a package also (I
know you had this as future, but not sure why)
7.	"referred as checker action blocks"  -> "referred to as checker
action blocks"
8.	"Connections to checker formal arguments can be created by
similar means to module ports (see 16.12)"  Did you mean to say property
arguments.  That is what 16.12 references and I think it is more
appropriate, although I'm not sure how implicit connections and wildcard
port names apply.  What do you mean by implicit connections?  It would
be nice if the design and checker used the same signal names,  that you
would not have to type in the port list, like a PSL vunit.
9.	"The supported data types for checker formal arguments are the
same types as in case of properties"  -> suggest "Checker formal
arguments may have any data type that is legal for a property, and they
are processed is a similar way (see 16.12).
10.	"and have static lifetime"  -> suggest "and are static"
11.	"Clock and disable context are may be inherited from the scope
of the checker declaration (but see 16.8.3. for usage of context value
functions for passing the instantiation context to the checker)."
12.	I think it is going to be confusing to sometimes inherit the
context from where it is defined and sometimes from where it is
instantiated. I'm not sure I understand the user model for inheriting
values from where the checker is defined.  I don't see why  checkers
need to be defined in a module, program, ...
13.	page 30 do we need to add a reserved keyword initial_check?
14.	 I need to go over page 8-21 again, but I did not see anything
about bind.  I guess I have to put the checker in a module to be able to
bind to it?

 

I could use some more up front information on the use model. I thought
this was to be similar to OVL but get around the issues that result from
having it conform to a module definition.  But if it has to be defined
in a module, then how is it used as a general library element?  If I
define the checker in module a, then how do I reference it from module
b?  I feel like I'm missing something important.

 

lisa

 

________________________________

From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] 
Sent: Wednesday, September 19, 2007 5:28 AM
To: Lisa Piper; Thomas.Thatcher@Sun.COM
Cc: sv-ac@eda-stds.org
Subject: [sv-ac] 1900 Checkers

 

Hi Lisa, Tom,

 

I uploaded the updated version of the proposal ready for review. This
proposal does not contain a description of formal semantics yet.

 

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.