System Verilog
		Testbench donation
		Open Review Issues
	Short name:	Description:	Person	Discussions:	Resolution:
REV-1	$cast_assign	Static casting in SV? Why not a compiler issue instead of call?		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 ":="
REV-2	Array shorthand	Conflict with existing call		Conflicts with existing Verilog	Remove shorthand notation
REV-3	Built-in string methods	Resolve class versus task syntax		Predefined classes are a new concept.	Accept
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
REV-5	Extern withdrawal	Impact		Not in donation. May be required in future.	Delay
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
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.
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)?
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).
REV-10	Mailboxes and semaphores	Mailbox and semaphores vs channels and queues in SV		Looks like similar requirement to data channels.
REV-11	Mailboxes and semaphores	Implemented as classes		Look into implementing as classes instead of language features.
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).
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).
REV-14	wait_var/wait_child	Extend '@' for wait_var and wait_child.	Kevin C	wait_var and wait_child should be rolled into '@'. 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().
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.
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?)
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.
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.