Attendees: Dennis Brophy Kevin Cameron Cliff Cummings Peter Flake Jay Lawrence Matt Maidment Francoise Martinole Karen Pieper Brad Pierce Dave Rich David Smith Johny Srouji Gord Vreugdenhil Dan Jacobi Yong Xiao Arturo Salz Minutes of previous meeting Need to add pointer to the proposal to the auto-increment proposal email. Need to fix the date on the top of the minutes document Review of Charter Email voting proposal Chair/Co-chair is eligible to propose a topic for email voting. Based on complexity Presented or discussed before Motivation: resolve non-controversial issues quickly Members can ask for an email proposal Decision process Clear proposal, a second must be made One week to vote Only yes votes recorded Anyone can veto SV-BC7e Structure literals for packed assignments are concats not member assignment. Brad to clarify if necessary. VCD proposals are at risk. Dave moves that 18a be closed with no action as an issue. The SV-EC must have static to use in classes. The SV-BC issue is more that static is unnecessary, denied by 1364, etc. Brad seconds. Opposed: Jay, Francoise. Abstain: Dennis. Passes. Dave moves that BC-24 be closed with no action as an issue. Brad seconds. No opposed. No abstain. Passes. Dave moves that BC-25 be closed with no action as an issue. Brad seconds. No opposed. No abstain. Passes. SV-BC26-1: The SV-EC passed an alternative way to print the name of an enum. Kevin moves that we remove the following language from the draft: The format control string "%n" can be used to display the enumerated name. Any format control string which can be used to display an integer value can be used to display an enumerated value. Gord seconded. (Deleting previous fix for SV-BC10). Opposed: Jay, Peter, Cliff, Johny, Karen. Abstain: Francoise, Matt. For: Brad, Gord, Kevin, Dennis, Dave. Passes. Pick up at SV-BC 36. Dave's proposal for 18h and 18i. Variables on inout ports have shared variable semantics. Output ports driving a variable datatype are continuous assignments to that variable, implying net semantics; there cannot be any other driver on that net. (i.e. Ignore port directions on nets, but pay attention on variables.) Contentious issues left: multiple drivers (Cliff's issues), inout ports, and logic versus reg. Cliff wants a universal datatype that doesn't require declaration and distiction between net and variable types, and allows multiple drivers. Jay: Continuous assignments on variables has an sensitivity semantics (always_comb) but the scheduling semantics is the same as a continuous assignment. Note it can trigger evaluation of itself. Adding a shared (var?) port type to indicate shared variable semantics across ports straw poll: Against: None. Abstain: Peter. For: Everybody else. Straw poll to allow multiple continuous assignments to logic or SV variables in one given module. For: Cliff, Kevin. Abstain: Peter, Jay. Against: Everybody else. Continuous assignments to a variable can only assign to non-port variables or output ports. Straw poll: Against: Peter. Abstain: Cliff, Kevin. For: Everybody else This vote implies that Var ports can only have procedural assignments. The implications at the next level up is that there cannot be multiple continuous assignments to a single SV variable through submodules. The implication is that there is no requirement for resolution functions. Cliff's implicit datatype can now be implemented via a new 'default_nettype because local decisions can be made. However, we have not said that we would allow implicit declaration of procedurally defined variables. If Cliff wants to continue, he can make a proposal to EC. Jay moves that we include reg as a SV datatype. Gord seconds. Straw poll. Against: Cliff. Abstain: Kevin, Peter. For: Everybody else. Jay moves that we remove logic because it is now redundant with reg. Brad seconds. Straw poll. For: Brad, Gord, David, Yong, Jay, Francoise, Matt, Dennis. Against: Cliff, Peter, Dave, Kevin, Karen. Abstain: Arturo, Johny. Jay needs to consider if we should disallow reg inside complex SV datatypes and instead use logic. Dave will create a proposal reflecting these decisions. Peter's proposals. Email voting on them once Peter adds locations for the text. If an interface has extern fork-join tasks that aren't defined, it shall be a runtime error to call that task. Task prototypes must match exactly the declared type of the task. The definiition of match exactly is post- poned to SV-BC61. Time literals: Kevin would prefer time literals didn't scale. Constants and Parameters: Genvars can assign to parameters or local parameters as well. Specparams: An issue with specify parameter phrasing exists. Will use specparam. Constants: Need to add genvars here as well. Matt's proposal. Unpacked struct literals. Omission from original donation needed to simplify description for simple literals of unpacked struct literals. Before we figure out how to specify this, we need to determine the contexts where this applies. Peter will develop a proposal for both. Unpacked array type mismatch. nets are not assignment compatible with regs in structs. This creates another case of needing a type compatible discussion (SV-BC61a). Packed array of packed structs. you cannot create a packed array of packed structs. Dave: This is silly. All: we should fix this. Dave to propose. Unpacked variables and ternary operators. Currently, ?: only operates on packed data. Need to define the ?: for 2-state variables and unpacked data. Dave to propose. Email passed proposals: SV-BC44-3 self determination of assignment as expression - posted 12/26/02 by Dave Rich SV-BC44-9 behavior of disable - posted 12/26/02 by Dave Rich SV-BC44-15 removal of "changed" - posted 12/26/02 by Dave Rich Clarification of operations allowed on unpacked arrays: SystemVerilog allows certain operations on aggregate unpacked arrays. From LRM section 4.2, it allows read and writes as a whole or slice of an unpacked array, but not as part of an integer expression. From this wording, it is unclear as to whether or not a comparison of two unpacked arrays would be allowed. Karen proposed that we append a bullet to the first list of bullets that reads: -- Equality operations the array or slice of the array, e.g. A==B, A[i:j] != B[i:j] Also a small correction to the preceding paragraph Replace: The examples provided with these rules assume that A and B are arrays. With: The examples provided with these rules assume that A and B are arrays of the same shape and type.