Subject: Expected capability for driver access functions
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Mon May 13 2002 - 10:32:12 PDT
Since auto-inserted D2A converter modules cannot tell what kind of design they have been inserted into there is a standing proposal that the simulator should provide some information about what kind of drivers a signal has. The three major types of driver are behavioral, primitive and SDF. Behavioral drivers can be assumed to have innaccurate timing and probably little look-ahead, uni-directional primitive drivers (e.g. outputs of nand and nor gates) may have more accurate timing and would be expected to provide look-ahead the same as the gate delay - i.e. if a nand gate as a '#5' delay then it will always provide 5 units of look-ahead. Bi-directional primitives (e.g. a pass transistor) have drivers that are dependent on the values of other drivers, and should pass through that information if possible (the driver information function should return a flag indicating the fact the driver is of this type). SDF drivers are created by the insertion of delay elements in the design due to back-annotation, they can be assumed to be accurate and provide a reasonable amount of look-ahead (equivalent to the added delay). SDF drivers can also be considered as being like the bi-directional primitive drivers in that they filter other drivers which can be primitive or behavioral drivers, so that information should be supplied in addition to the SDF flag.
A compliant simulator should support driver look-ahead for standard uni-directional primitives and SDF, look-ahead support in behavioral code will be vendor (and optimization) dependent. Simulators should indicate a driver is behavioral if the proper functionality is not supported.
Kev.
This archive was generated by hypermail 2b28 : Mon May 13 2002 - 10:35:37 PDT