Subject: action items from Tuesday meeting
From: Erich Marschner (erichm@cadence.com)
Date: Thu Sep 19 2002 - 14:42:29 PDT
Vassilios,
In the meeting on Tuesday, you asked me to send to the full committee (a) any questions I had on the VeraLite presentation, and (b) any suggestions I might have on quality metrics. Both follow.
A. Questions on VeraLite presentation:
(Some questions were answered during the meeting. I list here only those that I did not get a chance to ask.)
1. Is $cast_assign bi-directional? (I.e, can it convert either from enum to int, or vice versa)? If not, why not?
2. Why is the casting (apparently) done only on assignment? It should be possible to convert an enum to an integer in a subexpression, use the integer in a computation, and convert the result back to an enum value before any assignment occurs. It should also be possible to convert in an expression being passed as a parameter, not just in assignments.
3. Is pass-by-reference or pass-by-value always controlled by the user? Or is the tool free to select one or the other (e.g., depending upon the characteristics of the data type)? Whatever the answer is, what is the rationale for the decision?
4. Why is $cast_assign required for assigning a superclass instance to a derived class instance - why is this not inherent in assignment?
5. Are mailboxes - i.e., FIFOs - accessible strictly in-order? If so, is that generally sufficient?
General:
Why should System Verilog define new features as system tasks rather than as keyword-based constructs? What principle should be followed to pick one approach or the other?
B. Quality Thoughts
After further consideration, I think what is missing today is a process for reviewing specific feature proposals coming from different application areas in order to refine them and combine/converge them into a coherent set of language extensions. In effect, we need to look at requirements (such as for "things like a module", or "pointers/references") coming from each existing subcommittee and try to come up with the minimal set of language features that support the requirements efficiently. I'd suggest that we ought to have a group of people who have experience in language design to take responsibility for this refinement/merging process. In particular, we probably ought to identify individuals who could take responsibility for at least the following language areas:
1. Data Type System
2. Object Type System
3. Process Model
4. Inter-Process Communication Facilities
5. Critical Section Facilities
6. Error Handling Facilities
7. Elaboration Process
8. Simulation Cycle
9. Synthesizability
The individuals responsible for these areas would constitute a "language design" committee that would work in conjunction with the existing subcommittees.
This dissection of the problem reflects the language architecture rather than the application areas, so it is orthogonal to the current committee structure. This orthogonal layer to review and refine proposed features would ensure that the language extensions that result will work together effectively. Feedback from the language design committee to the existing subcommittees may be necessary to ensure that refined/merged language features still meet the application requirements, but having the above committee will ensure that the analysis and feedback occurs with as much structure as possible.
Regards,
Erich
-------------------------------------------
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 : Thu Sep 19 2002 - 14:50:30 PDT