Item 1

1
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.

2
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.

3
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)

4
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)

5
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.

6
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.

7
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.

8
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.

9
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.)

10
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.

11
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.

12
Item 12

• New primitive types pointer, string.

13
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.

14
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.

15
Item 15

• All vectors/arrays will be normalized to n0
  regardless of the original range and increasing
  or decreasing order of indexing. For example
  18, 81, 70 will be equivalent
  declarations of the size of packed a vector or
  unpacked an array.

16
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.

17
Item 17

• I propose to further restrict the types of
  function result to "small" values logic, bit, or
  bit n1, nlt32, plus basic types discussed
  earlier.