Edit Proposal | Edit Class, Environment, or Release |
Number | 120
|
Category | errata
|
Synopsis | vpiAutomatic property problems
|
State | proposal
|
Class | errata-ptf
|
Arrival-Date | Sep 16 2002
|
Originator | sharp@cadence.com
|
Release | 2001b: 26.6.20
|
Environment |
|
Description |
The diagram in 26.6.20 shows a property called vpiAutomatic. This is the same name as the tag to get from the frame to the variable declarations, which is presumably a problem. The property vpiAutomatic does not appear to be listed anywhere for tasks and functions, which makes it tough for VPI to determine whether they were declared automatic (other than looking at their variable declarations). The property appears on parameters, but it is not clear what this means. Parameters are constants, inherently static. They aren't different between frames. Presumably a parameter should never be considered automatic, even if declared inside an automatic task or function. So is there some reason why they have this property? |
Fix |
Part I: In "26.6.18 Task, function declaration", propose boolean property vpiAutomatic be a valid property of task and function objects: Underneath the "task func" class object, add: -->automatic bool : vpiAutomatic Part II: In "20.6.20, Frames", propose use of "vpiAutomatic" as a method be eliminated, and that the object diagram be modified to be the following: Note: Only the "frame" object and the objects of the unnamed class which are currently linked by the vpiAutomatic arc are shown below. No other objects nor arcs are changed by this proposal. /---------------------\ /-------\ |/-------------------\| | frame |<-------------+---------->>|| reg || \-------/ | |\-------------------/| ->validity | | | bool: vpiValid | |/-------------------\| ->active +---------->>|| reg array || bool: vpiActive | |\-------------------/| | | | | |/-------------------\| +---------->>|| variables || | |\-------------------/| | | | | |/-------------------\| +---------->>|| named event || | |\-------------------/| | | | | |/-------------------\| +---------->>|| named event array || |\-------------------/| \---------------------/ ->validity bool: vpiValid ->automatic bool: vpiAutomatic This proposal does the following: 1) The "parameter" object has been removed. Parameters are not automatic, they are static. Parameter handles of an automatic task or function can be obtained from the task/function handle itself. 2) The objects "reg", "reg array", "variables", "named event", "named event array", "parameter" are still grouped in an unnamed class, but there are now individual arcs from "frame" to each of the above object types, with no "tag". Thus, instead of using "vpiAutomatic" to traverse these arcs, one would use the specific object types instead. This change is motivated to make "frame" objects consistent with other objects containing declarations such as "module" objects (in 26.6.1) and "scope" objects (in 26.6.3), and also to eliminate use of "vpiAutomatic" as a "method", leaving its use solely as a "property". Part III: In addition to being shown in the new diagram for "frame" in Part II above, the vpiAutomatic property should be shown on each of the object diagrams for "reg" and "reg array" in 26.6.7, "variables" in 26.6.8, and "named event" and "named event array" in 26.6.11. ISSUES STILL TO RESOLVE: 1) Should "memory" objects be included in the "frame" object diagram? One can presumably already access memories using "reg array" objects. 2) Can a "frame" contain nested "scope" or "frame" objects? |
Audit-Trail |
|
Unformatted |
|
Hosted by Boyd Technology