System Verilog
Testbench donation
Open Review Issues
20-Mar-03
	Status Key:	Open -> Accepted -> Closed (in LRM) -> Verified
		Rejected
		Deferred
		Transferred (to another committee)
		Returned (to orginal committee)
ID	Short name:	Description:	Person	Discussions:	Resolution:	Status
REV-1	$cast_assign	Static casting in SV? Why not a compiler issue instead of call?	Kevin C	Supports run-time checks with dynamic warnings and check before doing casting. Does not replace static checks. Does the syntax need changed? Does it overlap with assertion? Mainly used with assignments. May need a new assignment operator such as ":="	Related to 21/22	Closed
REV-2	Array shorthand	Conflict with existing call		Conflicts with existing Verilog	Remove shorthand notation	Closed
REV-3	Built-in string methods	Resolve class versus task syntax		Predefined classes are a new concept.	Accept	Closed
REV-4	Forward reference with typedef	General implication		Should be applied to other places as well (it is). This is a bad idead in SV for non-pointers (which do not exist). Heavily used for classes.	Accept	Closed
REV-5	Extern withdrawal	Impact		Not in donation. May be required in future.	In progress within SV-BC.	Closed
REV-6	Class issues	super, extends, local/private, virtual, protected etc... Use of : instead of extends. Use braces instead of "EndCase".	Kevin C	Java vs C++.  Braces vs "End Class". Resolve issue of C++ bias versus Java bias	Use of "End Class" is to be compatible with SV use for all other scoping contexts. Only use of braces is with struct. The use of extends is inconsistent with Verilog-AMS. Will address during LRM review.	Closed
REV-7	General use of Class	How general		Not synthesizable due to dynamic allocation. Problem is that adding classes would like to have methods on structs (which is synthesizable)	Keep this in mind but allow classes to be general.	Closed
REV-8	Virtual class vs interface	How do these relate		Abstract data created with class how related to an interface with no ports (can an interface have no ports)?	There is some overlap between concepts of virtual class and interface with no ports. Major difference is that class is dynamic and interface is static. Will keep distinction for now due to interface being a hardware construct and class being software.	Closed
REV-9	Predefined constants	Keywords versus pre-defined constants		What is difference between them? Namespace is an issue? May be handled by changing the implementation of things using them. (implement as classes).	Not clear what the data type really is or if it is a data type. This is not closed. Decided to use keywords and new method syntax.	Closed
REV-10	Mailboxes and semaphores	Mailbox and semaphores vs channels and queues in SV		Looks like similar requirement to data channels.	Mailboxes do not require all of the flexibility that channels provide. They do not require synchronization between different clock domains	Closed
REV-11	Mailboxes and semaphores	Implemented as classes		Look into implementing as classes instead of language features.	For efficiency it is better to implement the mailboxes as language features instead of classes.	Closed
REV-12	Program block	Reconcile with verilog module		Is it still required since it is not going through PLI but is integral to the language? Is cycle semantic required? Remove non-determinism of HDL code and keep execution of testbench clean (clock synchronized). Stefen disagrees that cycle based is required (use non-blocking assignment).	Long discussion on requirement for Program block and clocking domain. Need to have a clear definition of what is legal/illegal in Program block and how it is unique wrt Module. Mehdi will review. Closed with acceptance of clocking domain and program.	Closed
REV-13	Clocking_domain	ports defined in multiple clock domains: questions of out1 = 1 and d1.out = 1 (out1 defined in two domains)		Is it still required since it is not going through PLI but is integral to the language? Is cycle semantic required? Remove non-determinism of HDL code and keep execution of testbench clean (clock synchronized). Stefen disagrees that cycle based is required (use non-blocking assignment).	See above. The discussion in the committee is that it is still required and unrelated to PLI requirements. New simulation semantics clearly identify ability to support.	Closed
REV-14	wait_var	Extend '@' for wait_var	Kevin C	wait_var and wait_child should be rolled into '@'.	Reconcile use of @ for variables in SV and use of wait_var in program. Why is it different? Mehdi to investigate. Closed with acceptance of CH-12 and events.	Closed
REV-14.1	wait_child	use join instead of wait_child	Kevin C	I'd prefer to have autonomous threads named (by identifiers on the fork/process statement) so that you can say "join <identifier>" instead of wait_child().	This is really part of the discussion on process control (Proposal from Kevin). Will close it here since it is covered somewhere else.	Closed
REV-15	fork/join none vs process	Keep both process and fork separate	Kevin C	process is different from fork in that it refers to a single statement and fork refers to a group of statements (1 or more). This makes a difference if you want to identify a thread uniquely by name, so I'd rather keep the seperate process statement.	"fork ... join none" is equivalent to "process fork ... join". Why do we need to have two different ways of doing the same thing. Options are: remove "fork ... join none", remove "process", or support both. Will resolve when reviewing LRM. Resolved. Program is gone. fork ...join_none supported	Closed
REV-16	$sync/$trigger	Extend -> and @ to include	Kevin C	I'd prefer to see these rolled into the -> and @ syntax e.g.     $tigger(ONE_BLAST,evt); becomes:     ONE_BLAST -> evt; The $sync task appears to create an event out of other events so could be replaced by special event function for the ORDER and CHECK versions. E.g.     $sync(ORDER,lookupchk_evnt,queue_event); becomes:     @(ordered(lookupchk_evnt,queue_event)); Which can be used with other events e.g.:     always @(posedge clock and ordered(lookupchk_evnt,queue_event)) begin      ...      end (Is there an alternative syntax for ordered events in the assertions stuff already?)	just a cleanup, suggested adding the to the event operation. Will get to review it with the doc and LRM when presented	Closed
REV-17	alloc	Replace alloc with new style syntax	Kevin C	alloc' appears to be used to create various objects dynamically. As with other Vera system tasks I presume it was done this way for ease of implemetation through PLI. For SV I would offer to create new  types for these objects and use a 'new' style syntax for creating  them dynamically. E.g.     module foo;         mailbox      s_mbx, // permanemt mailbox                     var v_mbx; // mailbox reference         initial begin               v_mbx = new;   // dynamic mailbox         end         ...         [NB: I don't think we have a donation covering references and/or pointers yet. Is one in the pipeline?] The mailbox_put/get tasks can be replaced regular reads and writes as outlined in the channel proposal (http://www.eda.org/sv-ec/hm/0107.html) since channels and mailboxes are almost the same (I'll rehash the proposal to cover the extra functionality later).  Semaphores should also become a proper part of the language e.g.:      <semaphore declaration> ::= semaphore <identifier>["["<sema. count>"]"["["<key count>"]"]]  You could overload the assignment operators to replace semaphore_put/get  functions e.g.:      module foo;         semaphore s1;         // counts default to 1         integer   key_idx;         always...       key_idx  <= s1; // returns -1 if key not available       ...                     key_idx   = s1; // blocks until key available       s1[0][key_idx] = 0; // release key             // and/or        s1++;     // blocks until key available       s1--;           // returns a key'alloc' appears to be used to create various objects dynamically. As         with other Vera system tasks I presume it was done this way for ease         of implemetation through PLI. For SV I would prefer to create new         types for these objects and use a 'new' style syntax for creating         them dynamically. E.g.             module foo;                 mailbox      s_mbx, // permanemt mailbox                          var v_mbx; // mailbox reference                 initial begin                     v_mbx = new;   // dynamic mailbox                 end                 ...         [NB: I don't think we have a donation covering references and/or         pointers yet. Is one in the pipeline?]         The mailbox_put/get tasks can be replaced regular reads and writes  as outlined in the channel proposal (http://www.eda.org/sv-ec/hm/0107.html)  since channels and mailboxes are almost the same (I'll rehash the proposal  to cover the extra functionality later).  Semaphores should also become a proper part of the language e.g.:      <semaphore declaration> ::= semaphore <identifier>["["<sema. count>"]"["["<key count>"]"]]  You could overload the assignment operators to replace semaphore_put/get  functions e.g.:      module foo;   semaphore s1;         // counts default to 1     integer   key_idx;     always...       key_idx  <= s1; // returns -1 if key not available       ...                     key_idx   = s1; // blocks until key available       s1[0][key_idx] = 0; // release key             // and/or        s1++;     // blocks until key available       s1--;           // returns a key The static declarations of mailboxes and semaphores should be more friendly to synthesis tools.The static declarations of mailboxes and semaphores should be more friendly to synthesis tools.	Lots of discussion. No resolution. Indication that latest work uses new, get, put, and retrieval. Closed in discussion within detailed review.	Closed
REV-18	Clocking_domain	Change syntax	Kevin C	To avoid making CLOCK a keyword I'd be tempted to change the syntax        to something like:     clock_domain <domain name> [@(<clock expression>)] You could just use <domain name> instead of <domain name>.CLOCK to pick up the clock signal.	This has been changed to clocking. No problem	Closed
REV-19	Cast_assign	Is $cast_assign bi-directional?	Erich Marschner	Is $cast_assign bi-directional?  (I.e, can it convert either from enum to int, or vice versa)?  If not, why not?	This is a good point. $cast_assign is and should be bi-directional; it converts from integer to enum and vice-versa.	Closed
REV-20	Cast_assign limit	$cast_assign on assignment	Erich Marschner	Why is the casting (apparently) done only on assignment?  It should be possible to convert an enum to an integer in a subexpression, use the integer in a computation, and convert the result back to an enum value before any assignment occurs.  It should also be possible to convert in an expression being passed as a parameter, not just in assignments.	See Arturo's Response	Closed
REV-21	Argument passing	Pass-by-reference vs pass-by-value	Erich Marschner	Is pass-by-reference or pass-by-value always controlled by the user?  Or is the tool free to select one or the other (e.g., depending upon the characteristics of the data type)?  Whatever the answer is, what is the rationale for the decision?	Resolved in Arturo's email	Closed
REV-22	Cast_assign derivation	Superclass instance to a derived class	Erich Marschner	Why is $cast_assign required for assigning a superclass instance to a derived class instance - why is this not inherent in assignment?	Resolved in Arturo's email	Closed
REV-23	Mailboxes	Strict fifo?	Erich Marschner	Are mailboxes - i.e., FIFOs - accessible strictly in-order?  If so, is that generally sufficient?	See Arturo's Response	Closed
REV-24	Keyword vs system task	Guidelines	Erich Marschner	Why should System Verilog define new features as system tasks rather than as keyword-based constructs?  What principle should be followed to pick one approach or the other?	Use of system tasks just moves the namespace problem. Need ability to define context sensitive keywords.	Closed
REV-25	Use of system tasks versus new operators	New system tasks	Committee	Provide new operators instead of new system tasks.	Same as 24	Closed
REV-26	Use of var vs ptr	Lack of syntax to indicate pass by reference on calling task/function	Kevin C	Email containing issue	Email containing response	Closed
REV-27	Use of [*] instead of []	C/C++ uses [], why use [*]	Kevin C	Email containing issue	Email containing response	Closed
REV-28	Task/Function for cast	Task/Function for cast definition conflicts with task/function name space issues.	Arturo	Email containing issue	Email containing response	Closed