Minutes of the 11/15/02 SV-BC Meeting.

This is my list of attendees and voting status - please submit 
corrections:
(aaa--------) Johny Srouji (Intel)
(--aaa-aaaaa) Cliff Cummings (Sunburst Design) *
(--aaaaaaaaa) David Smith (Synopsys) *
(aaaaaaaaaaa) Karen Pieper (Synopsys) *
(aaaaaaaaa-a) Kevin Cameron (NSC) *
(aaaaaaaaa-a) Steven Sharp (Cadence) *
(-aaaaa-aaa-) Dennis Brophy (Model Technology) *
(a--a---aaaa) Tom Fitzpatrick (Co-Design) *
(aaaaaa----a) Gord Vreugdenhil (Synopsys)
(aaaaaa-----) Brad Pierce (Synopsys)
(aaa-a----aa) Francoise Martinolle (Cadence)
(-aa-------a) Don Mills (LCDM Engineering)
(---aa--aa--) Mike McNamara (Verisity)
(-----aaaaaa) Stefen Boyd (Boyd Technology)
(a-----aa---) Medi Mohtashemi (Synopsys)
(------aa---) Paul Graham (Cadence)
(a-----aaaaa) Peter Flake (Co-Design) 
(------aaaa-) Simon Davidmann (Co-Design) 
(------aa--a) Heath Chambers (HMC)
(-------aaa-) Dave Kelf (Co-Design) 
(a-------aaa) Vasisilios Gerousis (Seimens) 
(-a---------) Dan Jacobi (Intel)
(a----------) Stuart Swan (Cadence)
(a----------) Adam Krolnick
(a----------) David Rich (Synopsys)
(a----------) Yong Xiao (Synopsys)
(a----------) Jay Laurence (Cadence)
(a----------) Matt Maidment(Intel)
(a----------) Wolfgang Keil (Synopsys)

* indicates eligible to vote on consensus issues


Charter: To address issues exposed in SystemVerilog 3.0 Standard 
	through implementation.  Cannot re-define SystemVerilog 3.0.
	SystemVerilog 3.0 is an approved standard.
	The goal is to make sure we have:
        - Clear syntax
        - Clear semantics
        - Limited modification based on implementation

	On the extreme case:
	If there is something which will truly disable the language 
	or its usage, this should be considered carefully.  Allow 
	appropriate discussion and debvate with the different 
	experts and language architects.  Other SV committees are 
	basing their efforts on existing SystemVerilog 3.0.  We 
	cannot remove or add things unless they are based on clear 
	implementation issues.

(SV-BC16*) Interfaces                                                  

	See Peter's slides on interfaces
	Stuart: Is a fork/join task a slow implementation?  Peter: 
	It is a better model of hardware.  

	Steven: Are there restrictions on data use from 
	the interface?  

	Steven: Are the slaves required to export every task in a 
	modport as export?  Peter: Yes. Steven: We need to document 
	this and what the behavior is if a task is not defined.  
	There are two issues here.  Legality of modports to slaves 
	without the task define, and non-modport instantiation 
	without the task define.  In the second case, it is only 
	illegal if there is no slave with the task defined.  Can 
	these tasks be disabled? Yes.  The name of the task is the 
	name in the module where it is defined.  In the slave.  The 
	master doesn't have that name, so it cannot disable slave 
	processes except to disable the block that called the task.  

	Can assertions go in?  Yes.  OVL requires instantiation.  
	That may encourage spagetti-like design....  And, create 
	difficulty for elaboration.  There is no instantiation.  
	Jay:  We need to add specify blocks and instantiation to 
	express the delay represented by a bus.  

	Interface use without modports in Co-Design's implementation, 
	only instantiates ports used.  This behavior does not work 
	for a single module synthesis flow.  To refer to ports for 
	back annotation, they can be referred to as top.int.a and 
	top.mid.i.a, for interface i port a.  

	Do back annotations on ports that are assigned procedurally 
	get the delays from the ports?  Peter: No.  

	The point of interface is to reduce repetition of wires, 
	etc, and increase the maintainability of the code, also as 
	a testbench.

	You cannot backannotate variables (i.e. logic) only wires.  
	Can we fix the semantics so that you can backannotate?  
	There is no good answer currently.

	SV-BC16-?
	Stuart: given that we've just noted that interfaces need 
	specify blocks and instantiation, do you still believe that 
	they are not modules?  Peter: Yes.
	Phone: The big contribution here is adding scopes and 
	directions in ports.  Structs have the difficulty that the 
	directionality is always the same.  
	Tom: Interfaces are different from modules 

Section 13 - Interfaces vs. Modules (Stuart/Cadence) [Basic, System] 
- interfaces and modules are almost the same 
- should make them so and simplify definition 
I see no reason why "interfaces" and "modules" aren't exactly the same thing. 
Both can have ports, both can export tasks, both can be parameterized, both 
represent hierarchical structures, both can have "always" blocks and processes, 
etc. Making "interfaces" and "modules" be exactly equivalent would go a long way 
towards simplifying SystemVerilog. 

	Merge interfaces and modules: Stuart, Kevin, Steven, David
	Keep separate: Johny, Vassilios, Medi, Matt, Peter, Tom
	Abstain: Gord
	Closed with current charter.  Cadence will ask Vassilios 
	add an agenda item to allow presentation of alternatives 
	at December 4th meeting.

====================================================================== 
Section 13.1 - Interfaces restrictions (Stuart/Cadence) [Basic, System] 
- should allow an interface to contain other modules 
- would allow wrapping of a module with an interface 
Why can't an interface contain other modules? This would allow existing module 
implementations to be "wrapped" within an interface implementation and then 
instantiated just like any other interface. For example, I might have an RTL 
implementation of a FIFO. I might want to embed this within an interface 
implementation that implements write() and read() tasks. 

	Depends upon resolution of the first issue.  Peter believes
	this is a simplifying enhancement if we keep interfaces.
	We need to deal with semantic issues related to Back 
	annotation, etc. to delineate interfaces and modules or you 
	indicate that they are the same.
	
	Closed with current charter.
====================================================================== 
Section 13.1 - Scheduling issues (Stuart/Cadence) [Basic, System] 
- interfaces allow non-deterministic behavior due to scheduling order 
- need ability to control scheduling order 
Interfaces provide plenty of opportunities for users to create non-deterministic 
designs (i.e. designs whose behavior is dependent on the scheduling order that a 
particular simulator happens to use.) What are the rules and the capabilities 
that System Verilog will provide to enable users to create interfaces that do 
NOT result in non-deterministic designs? For example: Can the user model the 
equivalent of non-blocking delays & delta cycles within interfaces? Can the user 
do the equivalent of signal resolution for multiple processes that 
simultaneously update the state of an interface? 

	Stuart: This is a Verilog problem that becomes work in 
	SystemVerilog.  Should we go to a two phase execution in 
	Interfaces (the SystemC approach)?  

	This is an enhancement but should be fixed to support gate 
	level design.

	Moved to the enhancement committee?
====================================================================== 
Section 13.2.3 - Interface usage issues (Stuart/Cadence) [Basic, System] 
- need to be able to specify and enforce rules about interface usage 
- e.g., use of either Read or Write operation but not both 
- e.g., limits on number of modules/processes invoking a given interface 
operation 
- should be possible to define such rules in the interface itself without 
changing other code 
- need to check rules in a way that allows for separate compilation 
- need to be able to specify that some tasks/members of an interface are private 
"Generic" interfaces allow a module to be attached to different interfaces, but 
they do not convey to the reader or allow tools to enforce that the module must 
be connected to an interface that implements a specific set of tasks or has 
specific members. As a simple example, there may be several different interface 
implementations of a FIFO -- one might gather statistics, another might not. In 
both cases modules that might be connected to such FIFOs should have an 
interface declaration that clearly specifies the set of FIFO operations that 
must be supported. E.g. write() but NOT read(), or vice-versa. Given the 
current proposed scheme, it can only be determined at elaboration-time whether 
an interface binding in a particular case is legal or not. Instead I believe it 
ought to be possible to determine this legality at the time a single module or 
interface is compiled. 
It should be possible to do port registration checks for interfaces. For 
example, a user might want to implement a FIFO interface that enforces that it 
has exactly one module or process that writes to it, and exactly one module or 
process that reads from it. It should be possible for the designer to create 
such checks only within the interface, without forcing the code within modules 
attached to the interface to be modified. 
In SystemVerilog today all tasks and members of an interface are available to be 
used by modules attached to the interface. This will inevitably lead to designs 
or models that use tasks or members of an interface that were never intended to 
be used externally. Therefore I believe that it should be possible to make 
certain tasks and members private so that they cannot be accessed externally.

	Need to add tools to guarantee an interface is respected.
	
	Private and public variables -- Move to the enhancement 
	committee. 

	Modports need to be separable from an interface because 
	you cannot us a modport across multiple interfaces (PCI bus 
	with multiple interface implementations).  Inheritance of 
	abstract base classes. Separate definition of an interface 
	and the implementation of that interface.
	-- Move to the enhancement committee.

====================================================================== 
Section 13.4 - Modports issues (Stuart/Cadence) [Basic, System] 
- allow modports to be declared outside of interface/module, for reuse 
- allow (modules and) interfaces to specify which modport(s) they implement 
- import/export is confusing and unnecessary 
It appears that Modports can only be declared within an interface. Why not 
allow modports to be declared outside of interfaces and modules, so that more 
than one interface implementation can implement the same modport? This would be 
a less error-prone solution than "generic interfaces". 
The use of "import/export" within Modports is confusing and unnecessary. Instead 
I believe that modports should be declared separately from interfaces, and the 
tasks that a modport makes available should be declared within the modport. 
Then when an interface is to implement the tasks of a modport, it explicitly 
indicates this via a "implements mod_port_name" construct. Similarly, since I 
believe that modules and interfaces should be equivalent, a module that wishes 
to make tasks available to other modules or interfaces will simply specify that 
it "implements some_mod_port_name". 
Modules and interfaces should be able to implement multiple modports. 

	Modports need to be separable from an interface because 
	you cannot us a modport across multiple interfaces (PCI bus 
	with multiple interface implementations).  Inheritance of 
	abstract base classes. Separate definition of an interface 
	and the implementation of that interface.
	-- Move to the enhancement committee.

=
====================================================================== 
Section 13.5.4 - Issue with extern forkjoin task (Stuart/Cadence) [Basic, 
System] 
- not necessary (at least for the example) 
- unnecessarily inefficient - there are better methods 
"Extern forkjoin tasks" capability is highly specialized and unnecessarily 
inefficient. A much better approach to modeling the example within this section 
is to have the simple_bus be aware of the address map for the slaves attached to 
the bus -- then only the slave responsible for a particular address needs to be 
activated for any request. This would allow us to get rid of the "extern 
forkjoin task" construct altogether and have a much more straightforward and 
efficient solution.

	Removing it currently not in our charter
	Need to clarify the semantics.  Peter to propose 
	clarification.

ISSUE:  Parenthesis for ports are required on instances?

	The parentheses are required for backward compatiblilty 
	with Verilog.

ISSUE: Logic type 

	Adding resolution for multiply driven logic "wires" is 
	an enhancement.

	Logic variables passed through ports shall be assigned 
	either once through continuous assignments or assigned 
	purely procedurally.  This restriction is retained across 
	ports, creating an elaboration time error.

	Logic arrays can be bitwise restricted to continuous or 
	procedurally assigned.  It is not limited to the entire 
	array.  If there is an index variable that is assigned, that 
	constitutes an assignment to the entire variable.

	Structs can mix assignment types for different members.  
	Unions cannot be mixed in assignment forms.  Gord will 
	write up the description for the granularity of the error 
	checking for mixing assignment types.

	How do you use behavioral assignments to assign to wires 
	if the task doing the assignment is in an interface type?

	You may have multiple modules calling a static task within 
	an intereface.  If that task is intending to drive a wire 
	that is initially driven, each task needs to maintain their 
	own state.  Fixing this is an enhancement.

	Does logic type work with back annotation?  Karen to 
	create an issue.

SV-BC18f:  6. The logic type appears to be superfluous.  Its capabilities are
a subset of regs and nets.  The supposed flexibility of being able
to declare an object as logic and then change its usage between a
reg and a net is of limited value.  Changing the declaration when
the usage changes is trivial compared to the usage changes.  If
you are going to change between a continuous assignment and a
combinational always block, changing the output net to a reg is
a trivial part of the change.  In exchange for that minor convenience,
you have the confusion that two different objects that appear to
be the same type (logic) may actually behave differently (as a reg
or a wire).  Concerns about efficiency of nets, which have strength,
and logic used as a net, which doesn't, are misplaced.  Vector nets,
if used under the same restrictions as logic, can leave out the
strength and simulate just as efficiently.  And port collapsing makes
nets more efficient, but does not appear to be possible for logic
variables.

	Deletion is not supported by our charter.  Port 
	collapsing is acceptible.

SV-BC18g:  7. The logic type when used as a net has many of the properties of a
net.  However, it is not clear how similar it is.  For example, is
port collapsing possible, or must all port connections involving logic
variables be implemented with continuous assignments?  Can a logic
variable be connected to an inout port?  Can a continuous assignment
or port drive a bit select or part select of a logic variable?  Do port
directions get coerced for logic variables if they turn out to be wrong
for the location of the driver?  Can timing features such as path
delays or interconnect delays be applied to logic variables?

	Clarification on timing needed.  
	Logic can be inout.
	Need clarification that port directions must be 
	respected.  David Rich will make a proposal for language 
	describing this.

SV-BC18h:  8. When a logic variable is being driven by a port or continuous assign
(i.e. it is acting as a net), is it allowed to have an initializer, or
is that only allowed when it is used like a reg?  Note that a logic
"net" could pass through multiple levels of hierarchy and be initialized
with different values at each level.  This inconsistent state would
presumably remain until an event managed to propagate through the
hierarchy.

	Having an initializer requires that all assignments 
	be procedural.  Karen will propose some language.

SV-BC19i:  9. A logic variable can be driven by a primitive.  Does this include the
MOS switch primitives, which explicitly pass strength?  Does it include
tran and tranif primitives, which are bidirectional and pass strength?

	No it cannot.  Dave will write the language.

ISSUE: Type use before definition (SV-BC8-3)

Section 3 - Type use before definition (Steve, Paul/Cadence) [Basic] 
- forces type checking to be post-elaboration 
- cause unnecessary complication of analysis, particularly separate analysis 
- useful only with pointer types 
[This has been discussed before - no additional detail is involved.]

	Required for the testbench donation.

	Take it out: Yong, Brad, Steve, Stuart, Kevin
	Leave it alone: Peter, Tom, Gord, Karen, Johny
	Abstain: Matt

	Johny will check with the EC as to why they need it.  
	We can propose to the EC that restricting it or taking 
	it out had some backing in our committee. To discuss in 
	next meeting.

ISSUE: Time Precision and timescale (SV-BC2)

-Time precision and timescale in general - cleaning up the 
description 
 AI-Peter - will propose new wording for the 07/22 meeting

	for $root use timeunit and timeprecision as first thing 
	in the source 'timescale does not affect $root
	timeunit and timeprecision override 'timescale in their 
	module or interface definition 'timescale applies to any 
	subsequent module or interface

	Dave will develop the language to put in the standard.

ISSUE: Issues with Time datatype (SV-BC8-5)

Section 3.4.1 - Issues with Time data type (Steve/Cadence) [Basic] 
- need to detail the rules for mixed expressions, scaling, etc. 
The specification of the time data type (section 3.4.1) is extremely unclear. 
The examples are not particularly helpful, since they only involve simple time 
literals used as delays. There is no specification of what happens when a time 
literal is assigned to a time variable, or an integer or real value is assigned 
to a time variable, or a time value is assigned to an integer or real variable, 
or time and integer values are combined in an expression. It is so unclear that 
it is hard to even formulate a general question, so I will ask about examples. 
The answers will help clarify things, but what is really needed is a 
specification of the underlying rules that produce those answers. 
a. If I have the following code: 
`timescale 1ns/10ps 
time t; 
initial 
begin 
t = 1; 
#(t) $display(t); 
end 
What is the numerical value in the variable t? In normal Verilog, a time 
variable is just a 64-bit vector, so it would be 1. But the specification seems 
to indicate that a time variable is this new time data type, so it needs to be 
scaled. I would guess that this means multiplication by the ratio between the 
time unit and the time precision, or 100. Does this mean that t gets the scaled 
value of 100? What if some other module has a precision of 1ps, so that the 
overall time step for the simulation is 1ps? Does t still get 100 based on the 
local precision, or 1000 based on the smallest precision? What is the delay 
produced by the #(t)? 
b. If I have the following code: 
`timescale 1ns/10ps 
time t; 
initial 
begin 
t = 1ns; 
#(t) $display(t); 
end 
what is the numerical value in the variable t? Presumably it is 100, since that 
is the multiple of the time step. Again, does this depend on the local 
precision or the overall precision? What is the delay produced by the #(t)? 
One would hope it is 1ns. 
c. If I have the following code: 
`timescale 1ns/10ps 
integer i; 
initial 
begin 
i = 1ns; 
#(i) $display(i); 
end 
Is this legal? If so, what is the numerical value of the integer variable i? 
Does this produce a delay of 1ns? 
d. If I have the following code: 
`timescale 1ns/10ps 
time t; 
initial 
begin 
t = 1ns + 10ps; 
#(t) $display(t); 
#(1ns + 10ps) $display($time); 
end 
What is the value of t? Presumably both time literals get scaled and then 
added, so the result is 101. 
e. If I have the following code: 
`timescale 1ns/10ps 
time t; 
initial 
begin 
t = 1ns + 1; 
#(t) $display(t); 
#(1ns + 1) $display($time); 
end 
How are mixed expressions like this handled? Note that an integer expression 
would fully evaluate as an integer and then be scaled for the delay. But a time 
literal needs to be scaled to the time unit first, and can't be re-scaled again 
later. How and when are these scalings done? 
f. If I have the following code: 
`timescale 1ns/10ps 
time t1,t2; 
initial 
begin 
t1 = 0.1 + 0.1; 
#(t) $display(t); 
end 
What is the value of t? Presumably it is 20, and the #(t) delays by 200ps. But 
are those answers obtained by adding and then scaling, or scaling and then 
adding? Some further questions will expose differences between those. 
g. If I have the following code: 
`timescale 1ns/10ps 
time t; 
initial 
begin 
t = 0.004 + 0.004; 
#(t) $display(t); 
end 
What is the value of t? Are the two reals scaled and truncated to 0, and then 
added to get 0? Or are they added, then scaled and truncated, producing 1? 
h. One possible rule is that operands are all scaled and then combined. But 
this doesn't work for all types of operands. For example: 
`timescale 1ns/10ps 
time t; 
initial 
begin 
t = 1ns << 1; 
#(t) $display(t); 
end 
Clearly scaling the 1 by 100 before the shift is undesirable. Perhaps it only 
scales operands that are not self-determined. And what happens if we try to 
shift by 1ns? Is this legal? There are no specifications of where times are 
legal. 
i. Even scaling only operands that are not self-determined doesn't always work 
properly. Whenever dimensional analysis would result in units that are not 
times, this scaling falls apart. For example: 
`timescale 1ns/10ps 
time t; 
initial 
begin 
t = 1ns + 1 * 1; 
#(t) $display(t); 
end 
What is the value of t here? If both integer literals get scaled, then the 
scaling factor gets multiplied in twice. So apparently scaling needs to wait 
until the integer sub-expression is actually combined with a time (unlike the 
other integer type conversions in Verilog, which are applied to operands before 
any operations). But this is not specified anywhere.

	Time variable is a logic [63:0]
	Time literals are scaled when used as parameters
	Time expressions are rounded to the current time precision
	Only operators that are valid for reals can be used with 
	time literals

	Peter will check references to time literals in tasks in 
	other modules to determine if the time gets scaled.  He'll 
	also check static task arguments.
	Peter will develop language to address issues with time 
	variables and literals.
	
ISSUE: Strings as array and structure literals (SV-BC7c)

c. What is legal inside an array or structure literal (sections 2.7 and 2.8)? 
Can strings be used inside them? How precisely must the types match? One of 
the examples shows a real literal inside a structure literal being assigned to a 
shortreal element of a structure, which implies some implicit type conversion. 
And section 7.9 shows examples where the bit widths don't match, again implying 
conversions. And yet section 7.9 states that each element must match the type 
being initialized. Since the examples don't actually match exactly, it is not 
clear what degree of matching is required.

	A structure member or an array element should behave like 
	a scalar of the same type.
	A shortreal can be set to a real literal
	    shortreal a = 4.5
	An array can be set to a string.
	
	Steven will propose the wording to clarify the meaning 
	of "match"

ISSUE: Unions and 4-state members (SV-BC8-2b)

From the SystemVerilog 3.0 Document
Section 3.7, bottom of page 11.
A packed union contains members that are packed structures or arrays of the same size. This ensures that you can read
back a union member that was written as another member. If any member is 4-state, the whole union is 4-state. A
packed union can also be used as a whole with arithmetic and logical operators, and its behavior is determined by the
signed or unsigned keyword, the latter being the default.
AI - Peter - to reword for clarity the sentence, "If any member is 4-state, the whole union is 4-state." (define read and
write semantics)
Shall we permit packed unions with members of different sizes?
Opposed: Tom, Peter, David
Abstain: Stefen, Karen, Steve Sharp, Cliff
Favor: Kevin
Motion fails.

Proposal: If a packed union contains a 2-state member and a 
	4-state member, the union is 4 state.  There is an 
	implicit conversion from 4-state to 2-state 
        when reading and writing the bit member.

	Dave will write the language for the proposal. 

ISSUE: Definition of masked and unmasked (SV-BC8-7)

Section 3.7 - Definition of "masked" and "unmasked" (Steve/Cadence) [Basic/Doc] 
- apparently not defined? 
Section 3.7 refers to structure members as being masked or unmasked. These 
terms do not appear to be defined anywhere, and appear to refer to 4-state and 
2-state values. The terminology should be fixed.

	Masked means 4 state and unmasked 2 states.  This was 
	an editing  issue and requires a global replace.  This 
	is for Stu to implement.

ISSUE: Conversion of short reals to 32 bits (SV-BC9-10)

Section 3.8 - Conversion of shortreals to 32 bits (Steve/Cadence) [Basic/Doc] 
- "bit pattern is preserved" is inconsistent with other conversions 
- should use $realtobits if the intent is to transfer the bit pattern 
In section 3.8, it is stated that when a shortreal is converted to 32 bits, the 
bit pattern is preserved (instead of rounding). This is not consistent with the 
rest of Verilog. If a shortreal converts to int by rounding, then it should 
convert to 32 bits by rounding. The int type is equivalent to 32 bits. Also, a 
real converts to a reg by rounding, so a shortreal should do the same. Nothing 
is said about real transferring its bit pattern when converted to bits, just 
shortreal. Since the statement is made in the section on casting, it implies 
that this happens only when casting, and that a conversion on assigning to a 
variable of that type would behave differently. This statement in the document 
is a bizarre exception to all related situations. If a real needs its bit 
pattern transferred to a vector, Verilog provides $realtobits for this purpose. 
A similar function could be provided for shortreal. Alternately, a union of a 
shortreal and a bit vector, or a struct or ! 
union containing just a shortreal, could be used for conversion.

	The manual is incorrect.  Real and short real should be 
	cast to integer or 32-bits with rounding.  To get the same 
	bit pattern use union.

	Need a shortreal equivalent of $bitstoreal and $realtobits.  
	Gord to write the language.

ISSUE: Constant exprs; difference among decls (SV-BC12)

Section 5.3 Constant expression (Paul/Cadence) [Basic] 
- need to define precisely what can/cannot appear in a constant expression 
[This has been discussed before - no additional detail is involved.]


	A parameter or localparam can only be set to an expression 
	of literals, parameters or local parameters, or a constant 
	function of these

	A const in a static scope can also be set to an expression 
	containing a hierarchically named parameter or local param 
	or a non-hierarchally named previously defined constant. 

	A const in an automatic task or function can also be 
	set to an expression containing arguments to the task or 
	function. 

	Peter to determine where to put this language.

ISSUE: Always_comb

	Gord will write up language describing the implicit 
	sensitivity list. always_comb <statement> is equivalent 
	to always <statement> @ (sensitivity list that Gord 
	will define)

	always_comb can only call automatic functions.

ISSUE: Clarify auto-increment and decrement

When does the increment occur?  Any ambiguity can lead to problems in comparison between synthesis and formal verification.

Arturo's proposal:  Auto-increment and auto-decrement are implemented as an implicit function call.

Karen's proposal:  Add to the standard the sentence: No statement shall contain multiple assignments to the same variable.  (Or the exact wording now used in the C standard.)

Gord's proposal:  It is permissible to warn when a variable is assigned more than once.  When the increment occurs, is implementation dependent.

	Karen to develop language to discribe Gord's proposal.


Action items:

	Karen will create issues for:
		1.  Backannotation on interfaces
		2.  Backannotation on logic type
		3.  Need a definition of the exact use of 
			interfaces w/o modports Synthesis 
			tools would compile a module by module.

	Karen needs to move the following to the enhancement 
	committee:
		Scheduling control/delta cycles
		Private and public variables for interfaces
		Modports as separate entities from interfaces
		
	Peter will clarify extern fork/join semantics.  In 
	particular:
		Disabling calls for joined tasks needs to be clarified
		Need to document the behavior for modules that do not
			define interface tasks.	(SV-BC16)

	Gord will make a proposal to describe the granularity of 
	error checking on logic types in the presence of mixed
	continuous and procedural assignments. (SV-BC18)

	Dave Rich will make a proposal describing port directions
	and/or collapsing are possible with logic type and the
	associated restrictions. (SV-BC18g)

	Karen will propose some language indicating that when a 
	logic type has an initializer, all assignments must be 
	procedural. (SV-BC18h)

	Dave will propose some language indicating that logic 
	types cannot be driven by primitives that pass strength:
	MOS switches, etc. (SV-BC19i)

	Johny will check with the EC as to why they need type use
	before definition.  We will discuss this in our next 
	meeting. (SV-BC8-3)

	Dave will develop language to clarify the description of
	time precision and time scale. (SV-BC2)

	Peter will develop language to address issues with time
	variables and literals. (SV-BC8-5)

	Steven will develop language to clarify the meaning of 
	type "matching" in structural literals. (SV-BC7c)

	Dave will develop language to clarify the transition of
	2-state types to 4-state in packed unions. (SV-BC8-2b)

	Stu will implement the global replacement of masked with
	4-state and unmasked with 2-state. (SV-BC8-7)

	Karen will propose language correcting the standards 
	conversion between shortreal and integer.  (SV-BC9-10)

	Gord will propose shortreal equivalents of $bitstoreal
	and $realtobits (SV-BC9-10)

	Peter will propose language for what can and cannot
	appear in a constant expression. (SV-BC12)

	Gord will propose language describing the implicit 
	sensitivity list for always_comb, noting that always_comb
	is equivalent to always <statement> @(sensitivity)
	(SV-BC21)
	
	Karen will develop language for auto-increment. (SV-BC6)