SV-EC Meeting Minutes 14 October 2002 (--a------) Adam Krolnik (LSI Logic) (---a-a---) Alec Stanculescu (Fintronic) (a-aaaa-aa) Cliff Cummings (Sunburst) (-aaa-----) Dave Kelf (Co-Design) (aaaaa-aaa) David Smith (Synopsys) (-aaa-a-aa) Dennis Brophy (ModelTech) (---aaa-a-) Francoise Martinolle (Cadence) (aa-aa----) Heath Chambers (HMC) (aaaaaaaaa) Karen Pieper (Synopsys) (aaa-aaaaa) Kevin Cameron (National) (---a-aa--) Kurt Takara (0-in) (--a--a-a-) Michael McNamara (Verisity) (aaaapaaaa) Mehdi Mohtashemi (Synopsys) (-aaaaaaaa) Neil Korpusik (Sun) (aaa------) Paul Graham (Cadence) (aapaa----) Peter Flake (Co-Design) (a--------) Roy Armoni (Intel) (aapa-a---) Simon Davidmann (Co-Design) (-aaaaaaa-) Stefen Boyd (Boyd Technology, Inc.) (aa---a---) Steven Sharp (Cadence) (-aaaaa--a) Tom Fitzpatrick (Co-Design) (-----a-a-) Tim Corcoran (WHDL) (-----a---) Stephen Meier (Synopsys) (-----a---) Arturo Salz (Synopsys) (-----a---) Zeev Kirshenbaum (Verisity) (-----aa-a) Brad Pierce (Synopsys) (--------a) Stu Sutherland a => Attended p => Attended by proxy - => Missed Action Items: 1) Kevin: Update proposal for Alias with committee feedback. David Smith took the minutes. 1. Review and approve minutes Proposal to accept minutes Proposed: Dennis B. Second: Tom F. seconded Passed unanimously 2. Reviewed open action items from last meeting Old Items: 1) Kevin referred to his August 19th email for the latest requirements. 2) David communicated with Stu and confirmed his availability for LRM work. 3) Kevin and Mehdi met and discussed reference. Agreed that Kevin's major issue is syntactical and that var is sufficient for pass-by-reference. Also discussed channel requirements. 4) Kevin submitted a modified proposal based on feedback. 5) Mehdi indicated that the current thinking from Synopsys is that we should support both the static and dynamic cast capability. User can use the dynamic cast when required. Will require minor modifications to LRM to support static cast on same objects as dynamic cast. 3. Extensions list discussion A. Separated Reference and Pointer. Only address Reference in 3.1. B. References: Kevin has the responsibility to handle the passing of arrays and other objects that are passed by reference to the C API as part of the SV-CC committee. Kevin is pushing to have an agreed upon definition of memory layout. David indicated that this is the responsibility of the SV-CC to define. Since the var solution is sufficient for the known requirements for pass by reference we will delay any further discussion until after all of the objects that can be passed is defined. This was suggested by Kevin. C. Alias proposal Kevin reviewed the current proposal. It consists of three parts. The first is simple alias of wires. The second is dealing with supporting alias of wires of different sizes in the same statement. The third is dealing with aliasing of wires and regs. Cliff: Should it be w instead of a in the second part? Kevin: yes. Cliff: What is the purpose of the ? Kevin reviewed why you may want to have different size wires/busses connected in the same statement. Cliff: Should all sizes of objects agree? The third example should be illegal. Kevin: This proposal was in response to a previous question from the last meeting. It tries to treat aliasing as if things were connected outside the module. Cliff: Makes sense to make it illegal to alias wire and reg. Regs do not contribute to the net. There is an implied assign at the port. Alias should be a mechanism to connect wires or groups of wires within in a module. I like the first part. I have to think about the second part. And the 3rd part should be illegal. Why do you want this? Kevin: If you want to do this then this is a way how. Cliff: I am beginning to think that it is a bad idea to allow this. Basic idea is to connect busses using something similar to this .*. Tom: Aliasing of different bits is supported W[0:7], B. Cliff: What if alias C[32] to W[32] and B[8]? Syntax is funky. Allows us to use 1 alias instead of 2 aliases. Tom: Intent is bidirectional assign. Kevin: It is a physical short circuit. Cliff: For the case where aliasing A, B, C, and D but C is only 8 bits wide and you have two aliases (one for all 32 bit and one for the 8 bit) do you have to list all 4 wires in each? David: Keep sizes the same within an alias. Support transitive "short circuit" based on all aliases. Tom: Queasy on comma separated list. Use = instead of comma. Karen: Do not like = since it looks like assignment. David: How about <=>? Cliff: Use comma instead. The desire is to have a single character to reduce typing. After discussion we decided that = was best. Kevin will update the proposal. 5. Issues from TB Donation REV-6: super, extends, local/private, virtual, protected etc... Use of : instead of extends. Use braces instead of "End Case". Kevin: Structs use {} why not use instead of end class for class definition? It is more C/C++ like. Mehdi: Decision was to make it more Verilog like. Stu: If something is being added from C/C++ then it should be kept the same as in C/C++ if possible. Kevin: In Verilog-AMS we use the colon for inheritance on types. Tom: Structure is the only place where {} is used. Class is more like a scope instead of a struct. In SuperLog we decided to keep it similar to Verilog and use end class. Stu: Classes are like stand-alone block of code right? Want more consistency. Go with keywords to be consistent with Verilog. David: Is the use of extends and local driven from Verilog? Mehdi: No. But would keep extends and local. Kevin: Should align with Verilog-AMS for extends. This would be more consistent. Mehid: Let's wait for the LRM to resolve. Issue closed until LRM is reviewed. REV-8: Abstract data created with class how related to an interface with no ports (can an interface have no ports)? David: Who asked this? Kevin? Kevin: Maybe but I do not think so. Neil: What is an interface with no ports? Stu: An interface with no ports can be used in a module by accessing the tasks. Kevin: Becomes like a static class. There is no static class in the testbench. Mehdi: There is no need for a static class for testbenches. The classes are only needed when used. Stu: There is overlap but interfaces are a model for hardware and classes are a software construct. David: Similar overlap as between modules and interfaces. Stu: Key difference between class and interface is that classes are dynamic and interfaces are static. Kevin: Why not static classes? Neil: They are not part of the donation. Kevin: Seems like lost of overlap. Can you inherit methods of a class in an interface? Mehdi: Keep these separate. Kevin: May not want to. Stu: Can extend latter. Kevin: But need to consider now so that the syntax is compatible. Mehdi: Classes are general enough that you can do anything you want. Kevin: With static classes can do anything. Stu: Modules and interfaces are hardware. Classes may be helpful. David: Intent is important. Even if there are multiple objects in the language with similar semantics the intended use can be sufficient to provide separate constructs. No change from this discussion. Item closed. REV-9: Keywords versus pre-defined constants Stu: What examples are predefined? Mehdi: Use of clock, and on/off in semaphore. String used in context senstive way. David: What type of data are they? Do they have a value? Mehdi: Could define as a macro or enum but with context sensitive usage. David: Sounds like context sensitive keyword. Discussion among attendees about where similar items exist (such as none in Verilog 1364-2001) Mehdi: This is not resolved. We will have to revisit. David: We need to discuss this with Verilog implementors. Keep open for now REV-10/REV-11: Mailbox and semaphores vs channels and queues in SV Look into implementing as classes instead of language features. Note that queues are not in SystemVerilog. Mehdi/Kevin: Channels are lower level than mailboxes. They can be synthesized. Provide 1st in and 1st out use. Used in embedded programming. Mehdi: No reason not to implement the mailbox as a class. Stu: May not be synthesizable. Kevin: If implemented as a class then what is the primitive used to move data? Mehdi: This sounds like data between 2 different clock domains that need to be synchronized. The mailboxes do not work like this. Stu: Are mailboxes always a FIFO. Mehdi: Yes. Built of list structures with FIFO semantics. Kevin: Could use channels. Mehdi: Mailboxes do not require channels. For efficiency the mailbox should be implemented as a language feature. Also better for ease of use. David: Would like to keep the issue of channels and mailboxes seperate. If a mailbox with channel-like semantics is required then it can be implemented in classes once channels are available. No change proposed and item closed. 7. Meeting closed.