RE: [sv-ec] 1900 mantis (checkers): checker in package ?

From: Mirek Forczek <mirekf_at_.....>
Date: Thu Apr 17 2008 - 06:15:48 PDT
Hi Dmitry,
 
I consder: 'module', 'program', 'interface', and 'checker' as constructs of
the same category in language structure:
 
module M;
endmodule
 
program P;
endprogram
 
interface I;
endinterface
 
checker C;
endcheck
 
 
currently LRM forbids having 'module', 'program', 'interface' in 'package',
but 1900 mantis claims for having 'checker' in 'package' anyway:
 
package P;
 
/*  illegal
 
    module M;
    endmodule
 
    program P;
    endprogram
 
    interface I;
    endinterface
*/
 
// legal
 
    checker C;
    endcheck
  
endpackage
 
this looks for an inconsistency in a language for me.
 
 
 
Possible solutions:
 
option 1) all above units shall be legal in package:
 
package P;
 
//  legal
 
    module M;
    endmodule
 
    program P;
    endprogram
 
    interface I;
    endinterface
 
// legal
 
    checker C;
    endcheck
  
endpackage
 
 
option 2)  none of the 'units' declarations shall be allowed in a package, 
 
  
package P;
 
/*  all illegal
 
    module M;
    endmodule
 
    program P;
    endprogram
 
    interface I;
    endinterface
 
    checker C;
    endcheck
*/  
endpackage
 
this way a 2005 LRM line will be kept, no need for extra exceptions such as:

 
25.2 Package declarations
 
REPLACE
 
Packages must not contain any processes.
 
WITH
 
Packages may contain processes inside checkers only.
 
 
BTW, why Packages must not contain any processes ?
 
 
 
Currently following 1800-2005: 
 
21.2 Libraries
"A library is a named collection of cells. A cell is a module, macromodule,
primitive, interface, program, package, or configuration."
IMHO 'checker' shall belong to that list.
 
19.2 Packages
"SystemVerilog packages provide an additional mechanism for sharing
parameters, data, type, task, function, sequence, and property declarations
among multiple SystemVerilog modules, interfaces, and programs."
That's fine, no changes required.
 
This way an utility building blocks would be grouped within packages, a
design cells (this includes testbench, verification, and other units as
well) would be grouped within libraries.
 
I've reconsidered my last remark about having same set of checker-specific
declarations allowed in property/sequence instead - and unfortunatelly it
would not be a good direction.
 
But still I believe that the need for organizing checkers into assertions
libraries can be satisfied with hierarchical checkers instantations (checker
in checker)  + the 'package' (lower-level grouping) and the 'library' (upper
level grouping) constructs of the language,
without need to having 'checker' in 'package' directly.
 
Regards,
Mirek
 
  _____  

From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] 
Sent: 17 kwietnia 2008 09:11
To: Mirek Forczek; sv-ec@server.eda.org
Cc: sv-ac@server.eda.org
Subject: RE: [sv-ec] 1900 mantis (checkers): checker in package ?



Hi Mirek,

 

I don't know the reason why there are limitations on modules, interfaces
etc. in packages. I am not sure I understand your second suggestion. Could
you be more specific and provide an example?

 

Thanks,

Dmitry

 

  _____  

From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Mirek Forczek
Sent: Wednesday, April 09, 2008 5:35 PM
To: Korchemny, Dmitry; sv-ec@server.eda.org
Cc: sv-ac@server.eda.org
Subject: RE: [sv-ec] 1900 mantis (checkers): checker in package ?

 

Hi Dmitry,

 

I'm not against allowing checker declarations in packages - in general.

 

But still I will keep the following position:

 

    the 'checker' belongs to the 'units' category along with 'module',
'program', 'interface', etc.

 

 

To keep language consistent I would see only 2 possible situations:

 

1) let's allow checkers declarations in packages, but then other 'units'
declarations shall be allowed in package too ..

 

2) none of the 'units' declarations are allowed in a package, (this way a
2005 LRM line will be kept), 

 

why 'checker' shall be exceptional here ?

 

 

The need for organizing assertions library in a package could be satisfied
with properties and sequences declarations (already allowed in package), if
only property and sequence could contain same set of seb-declarations as the
checker can (i.e.: checkvar declaration - why not to allow it inside
property/sequence ?).

 

Does the lack of 'module', 'program', 'interface' declarations in package
stops people from organizing their design/testbenches libraries in a package
?

(mayby indeed it stops them, or there is some coding pattern to take benefit
from package anyway - could it be applied with assertions and checkers too
?)

 

Mirek

 

  _____  

From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] 
Sent: 9 kwietnia 2008 15:50
To: Mirek Forczek; sv-ec@server.eda.org
Cc: sv-ac@eda.org
Subject: RE: [sv-ec] 1900 mantis (checkers): checker in package ?

Hi Mirek,

 

I think that it is natural and important to allow checker declarations in
packages. One of the main checker goales is to serve an assertion library
checker (sorry for confusion because of different use of the word
"checker"). The people will certainly want to organize their assertion
library in a package, and I don't why this should be forbidden.

 

Thanks,

Dmitry

 

  _____  

From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Mirek Forczek
Sent: Monday, April 07, 2008 3:18 PM
To: sv-ec@server.eda.org
Subject: [sv-ec] 1900 mantis (checkers): checker in package ?

 

The "25 Package declarations" section allows to declare checker in a
package.

 

 

Till now I've considered checker as a unit - similar to the other units such
as: module, interface, program, etc.

 

 

Once the module, interface, program, etc. are not allowed to be declared in
a package, there should be no room for checker in a package too, IMHO.

 

Allowing check in package seems to be inconsistent with the rest of the
package-related language rules, it constitute a special exception for
checker only, and will probably result in a chain of special exceptions for
checker only.

The first one is already in a proposal:

 

The 1800-2005 containes rule:

 

    Packages must not contain any processes.

 

which will be broken now with:

 

    Packages may contain processes inside checkers only.

 

 

As for me: the 1800-2005 statement is an one more argument for:

 

- not to allow check declaration in package,

 

or to:

 

- (consider to) allow checker and other units delcarations in package ...

 

 

 

It is also possible that the original motivation for allowing checkers
declarations in package was to allow (other than sequence and property)
declarations specific for checkers (i.e.: checkvars) - to be part of the
package encapsulated definitions.

 

In such case a move of these definitions from checker scope to the sequence
/ property scope shall be considered.

(The sequence and property declarations are already allowed in package. And
they have full parametrization capabilities, so they can be easily connected
with checker interface at the instantiation place.)

 

A checker itself - as a grouping construct - similar to the other grouping
constructs (module, interface, program) do not deserve to be in a package if
the other ones do not deserve the same.

 

 

Regards,

Mirek

---------------------------------------------------------------------
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  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 

---------------------------------------------------------------------

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  <http://www.mailscanner.info/> 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.
Received on Thu Apr 17 06:19:38 2008

This archive was generated by hypermail 2.1.8 : Thu Apr 17 2008 - 06:21:09 PDT