RE: [sv-ec] (following 1900 mantis: checkers) - the general general problem with the LRM text structure: repeated enumerations.

Hi,
 
Please see related Mantis 2278.
 
Shalom


________________________________

	From: owner-sv-ec@server.eda.org
[mailto:owner-sv-ec@server.eda.org] On Behalf Of Mirek Forczek
	Sent: Monday, April 07, 2008 11:49 AM
	To: sv-ec@server.eda.org
	Subject: [sv-ec] (following 1900 mantis: checkers) - the general
general problem with the LRM text structure: repeated enumerations.
	
	
	Hi,
	 
	After first reading of the 1900 mantis proposal (the checkers) -
I think it clearly demonstrates a general problem with the LRM text
structure.
	 
	There is a lot of repeated enumerations in a text, that make new
mantis more complex than it could be.
	 
	Please consider introduction of an abstract terms definitions in
LRM, to avoid repeated enumerations in a text.
	 
	This is a general issue (not only the checkers).
	 
	 
	See how this could work following 1900 mantis proposal:
	 
	 
	In 3.2 we have definition:
	 
	"A design element is a SystemVerilog module (see Clause 22),
program (see Clause 23), interface (see Clause 24), checker (see 16.18),
package (see Clause 25), primitive (see Clause 27) or configuration (see
Clause 32)."

	It would be convenient to have another few definitions, i.e.:
	 
	"A design hierarchy element is a SystemVerilog module (see
Clause 22), program (see Clause 23), interface (see Clause 24), checker
(see 16.18), or primitive (see Clause 27)."
	"A nonleaf design hierarchy element is a SystemVerilog module
(see Clause 22), program (see Clause 23), interface (see Clause 24),
checker (see 16.18)."
	 
	(these are just an examples)
	 
	 
	Now other 1900 mantis changes could be simplified, i.e.:
	 
	 
	3.3
	"Instantiations of other modules, interfaces, programs,
interfaces, checkers, and primitives"
	
	
	into:
	"Instantiations of other design hierarchy elements"
	 
	 
	3.9
	"The basic building blocks of modules, programs, interfaces,
checkers, and primitives are used to build up a design hierarchy."
	into:
	"The basic building blocks of design hierarchy elements are used
to build up a
	design hierarchy."
	 
	"Modules can instantiate other modules, programs, interfaces,
checkers and primitives, creating a hierarchy tree."
	into:
	"Modules can instantiate other design hierarchy elements,
creating a hierarchy tree."
	 
	 
	3.10
	"Elaboration is the process of binding together the components
that make up a design. These components can include module instances,
program instances, interface instances, checker instances, primitive
instances, and the top level of the design hierarchy."
	into:
	"Elaboration is the process of binding together the components
that make up a design. These components can include design hierarchy
element instances, and the top level of the design hierarchy."
	 
	and so on ...
	 
	 
	Assuming these abstract terms were introduce before 1900 manits,
it would be sufficient to have only 3.2 change proposal and (probably)
no changes at all in 3.3, 3.9, 3.10 (and other sections) and the 1900
mantis text could focus just on a checkers primary issues.
	I hope there is no need to rewrite the whole LRM text at once,
the abstract terms could be introduced and spread over the text
incrmentally.
	 
	Also note that the repeated enumerations often rise user doubts
- a very frequent question pattern to the comittee is: "was the X
omitted intentionally here or this is just a mistake ?".
	 
	 
	Regards,
	Mirek
	 
	 
	 
	 
	 

	-- 
	This message has been scanned for viruses and 
	dangerous content by MailScanner <http://www.mailscanner.info/>
, 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 MailScanner, and is
believed to be clean.