Download
1 / 17
170 likes | 309 Views
Item 1. DirectC interface includes as a minimum the capability to call non-SV functions and void functions (i.e. functions that return no result) from SV code. Such functions will be hereinafter refered to as external functions (xf).
E N D
Item 1 • DirectC interface includes as a minimum the capability to call non-SV functions and void functions (i.e. functions that return no result) from SV code. Such functions will be hereinafter refered to as external functions (xf). • Note: A symmetrical functionality, i.e. the capability of calling SV functions and tasks from a non-SV domain is not precluded; it's merely not addressed in this proposal.
Item 2 • xf executes in 0 time. In other words, no simulation time passes during the execution of xf. Xf must not contain timing control. • Note: The above property does not preclude calling foreign tasks, i.e. functions with timing control. Such functionality is simply not addressed in this proposal and may be added as a next feature.
Item 3 • The usage and syntax for calling xf is identical as for native SV functions and tasks. (a) any xf can be called as a void function, i.e. its call may occur as a statement, and a result, if any, will be discarded. (b) xf may have zero or more formal arguments. (c) xf may have input, output and inout formal arguments. (Types of a result and formal args will be discussed later.) (d) The evaluation order of formal args follows general SV rules (is unspecified)
Item 4 • xf may access only SV data objects explictly passed as actual arguments to a xf call (must not acces data objects that have been not passed explicitly as arguments of the particular call)
Item 5 • Each xf must be declared. Such declaration will be further refered to as external declarations. (a) An external declaration specifies function name, optional function result and types and directions of formal args. It may also provide optional names for formal args. Formal arg names serve only as comments and are otherwise meaningless. (b) Escaped names are not allowed for xf.
Item 6 • A scope of an external declaration is the whole design. External declarations may occur anywhere in $root scope, ie. outside of modules, interfaces, functions and tasks. A name of xf should not classh with any name declared in $root scope. An external declaration of xf need not to precede an invocation of that xf. Regular name resolving rules apply to xf. Therefore local names declared inside a module (or interface) will obscure xf name; $root.xf_name may be used to resolve to global name.
Item 7 • xf may have multiple declarations as long as they are all equivalent. Two declarations are equivalent if they specify the same function result type, the same number of formal args, and for each arg respectively, the same direction and type.
Item 8 • Syntax of an external declaration An external declaration follows SV rules: arg direction defaults to input, direction may be specified for a group of args.
Item 9 • Arguments passing for xf is ruled by WYSIWYG principle: What You Specify Is What You Get. (The possible exceptions for packed and unpacked ranges will be discussed later.)
Item 10 • For the SV side of the interface, the semantics of arguments passing is as if input args were passed by "copy-in", output args were passed by "copy-out" and inout args were passed by "copy-in, copy-out". The actual implementation of argument pasing is transparent and irrelevant to the SV side of the interface. (a) xf must not modify the values of its input args (b) The initial values of formal output args are unspecified and may be implementation dependent. (c) For output and inout args the value propagation (i.e. value change events) happens as if an actual arg was assigned a formal arg immediately after control returns from xf.
Item 11 • As the minimum the following basic types are allowed for function result type and formal arguments: - basic types: int, real, byte, type, short. - scalars of types bit, logic - new primitive types, to be introduced to SV: pointer, string These are the minimal requirements; other types will be discussed later.
Item 12 • New primitive types: pointer, string.
Item 13 • DirectC interface should not impose any constraints on how SV data types are actually implemented. • We may specify that the layout of SV structs should be the same as the layout used by a C compiler on the corresponding C structs. • We shouldn't specify the layout of 2- or 4-state vectors, as this may be platform dependent.
Item 14 • I propose to restrict the types allowed for formal args and func result - in addition to the basic types listed in (22) - to: - scalars of type bit and logic - packed 1-dimensional vectors of type bit/logic - unpacked 1-dimensional arrays of the above.
Item 15 • All vectors/arrays will be normalized to [n:0] regardless of the original range and increasing or decreasing order of indexing. For example [1:8], [8:1], [7:0] will be equivalent declarations of the size of packed a vector or unpacked an array.
Item 16 • For the convenience, the size of the packed dimension or the unpacked dimension or both dimension may remain unspecified; such cases will be refered to as open vectors and open arrays.
Item 17 • I propose to further restrict the types of function result to "small" values: logic, bit, or bit [n:1], n<=32, plus basic types discussed earlier.
