Subject: Additional Issues List
From: Erich Marschner (erichm@cadence.com)
Date: Tue Jun 04 2002 - 06:50:00 PDT
At the last System Verilog meeting I was asked to collect a list of issues for discussion as part of the 3.1 development effort. The following is a list of issues that may not have been included already in Dave Kelf's list.
The issues below are from the following sources:
Cadence (Paul Graham, Steven Sharp, Stuart Swan, Erich Marschner)
National Semiconductor (Kevin Cameron)
Morotorola (Shalom Bresticker)
Lest anyone misunderstand, all of these issues are being raised specifically and only to help ensure that the System Verilog 3.1 document will be as robust as possible. Because some of us (from Cadence) have joined this group only recently, we are not aware of all the discussion that has gone on in the past, so it is possible (in fact, likely) that some of the items listed below have already been discussed and resolved to the satisfaction of the rest of the committee. If the committee feels that a given issue below has already been addressed, then there is probably no need to discuss that issue further other than to reiterate the resolution.
The following list is my attempt to summarize more extensive explanations by the contributors. More detail will be provided when and if these issues are discussed.
Additional issues may yet remain to be identified. (This list is not thought to be exhaustive.) Also, more detailed description of the issues already on Dave's list may be needed.
Regards,
Erich
Additional Issues to be Discussed for System Verilog 3.1
General - The current specification is ambiguous (Steve/Cadence)
- needs to be more complete, or needs a reference implementation
General - Backward compatibility problems (Steve/Cadence)
- many new keywords will be an issue as these features are merged into IEEE 1364 Verilog
General - Need to specify PLI extensions to access new constructs (Steve/Cadence)
Section 2 - Issues with Literals (Steve/Cadence)
- width/signedness of an unsized literal without a base specifier?
- legal constructs within an array or structure literal?
- legal use of array or structure literals?
Section 3 - Issues with new data types and keywords (Steve/Cadence)
- actual utility of char, shortint, longint, byte, shortreal
- non-orthogonality of definitions
- inconsistent with C definitions
- void type - is it necessary?
Section 3 - Data packing issue (Kevin/NSC)
- it is impossible to implement "union" from the current LRM description
- there are many ways to do it which are not compatible
- encoding of logic types is a factor, and "big-endian" vs. "little-endian"
- unions should have either all logic or all bit as the base type of all elements
- if packing is defined then 'packed' union syntax is redundant
- may be desirable to state the packing/alignment explicitly for software compatibility
Section 3 - Type use before definition (Steve, Paul/Cadence)
- forces type checking to be post-elaboration
- cause unnecessary complication of analysis, particularly separate analysis
- useful only with pointer types
Section 3.1 - Parameterized data types (Stuart/Cadence)
- nice, but difficult to use because they cannot be resolved until elaboration
- (can we improve this to better support separate compilation?)
Section 3.4.1 - Issues with Time data type (Steve/Cadence)
- need to detail the rules for mixed expressions, scaling, etc.
Section 3.6 - Implications of Enum type I/O (Steve/Cadence)
- need to detail what is expected of Verilog I/O routines to support this
Section 3.7 - Definition of "masked" and "unmasked" (Steve/Cadence)
- apparently not defined?
Section 3.7 - Size requirement(?) on members of a packed union (Steve/Cadence)
- should say "must be the same size", not "are the same size" (?)
Section 3.7 - Passing large structs/arrays (Stuart/Cadence)
- can this be done by reference instead of value (which would be inefficient)?
Section 3.8 - Conversion of shortreals to 32 bits (Steve/Cadence)
- "bit pattern is preserved" is inconsistent with other conversions
- should use $realtobits if the intent is to transfer the bit pattern
Section 4.2 - Packed array of signed (Erich/Cadence)
- conflict between signed elements and signed whole array
Section 5.3 Constant expression (Paul/Cadence)
- need to define precisely what can/cannot appear in a constant expression
Section 6.1 Attribute syntax (Paul/Cadence)
- should factor syntax to improve readability
Section 9 - Process execution efficiency when calling C (Kevin/NSC)
- LRM doesn't say much about calling C from Verilog processes
- should require that C functions can't suspend
Section 9.1 - Interleaving of exection (Stuart/Cadence)
- allowing arbitrary interruption is error-prone
- should only allow interruption at synchronization points
Related - Verilog 2001 - Scheduling Algorithm (Shalom/Motorola)
- allows interleaving of processes that need to be atomic
- conflicts with requirement that non-blocking assignments execute in order of appearance
- potential problem with scheduling of PLI calls
Section 9.1 - Issues with dynamic processes (Stuart/Cadence)
- need the ability to suspend/resume/abort child processes
- need process handles to support this
Section 13 - Interfaces vs. Modules (Stuart/Cadence)
- interfaces and modules are almost the same
- should make them so and simplify definition
Section 13.1 - Interfaces restrictions (Stuart/Cadence)
- should allow an interface to contain other modules
- would allow wrapping of a module with an interface
Section 13.1 - Scheduling issues (Stuart/Cadence)
- interfaces allow non-deterministic behavior due to scheduling order
- need ability to control scheduling order
Section 13.2.3 - Interface usage issues (Stuart/Cadence)
- 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
Section 13.4 - Modports issues (Stuart/Cadence)
- 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
Section 13.5.4 - Issue with extern forkjoin task (Stuart/Cadence)
- not necessary (at least for the example)
- unnecessarily inefficient - there are better methods
- need to be able to specify that some tasks/members of an interface are private
-------------------------------------------
Erich Marschner, Cadence Design Systems
Senior Architect, Advanced Verification
Phone: +1 410 750 6995 Email: erichm@cadence.com
Vmail: +1 410 872 4369 Email: erichm@comcast.net
This archive was generated by hypermail 2b28 : Tue Jun 04 2002 - 06:51:19 PDT