Behavioral code (e.g. test benches) often ask for values which are not passed through ports (e.g. OOMRs) but may be in another domain in a mixed signal design (unknown to the testbench designer). These conversion requests are often just "probes" that need neither resolution or persistant state and are viewed as "light weight".
Light-weight conversion would be short-circuited if a signal is converted by a heavy-weight conversion - i.e. the output of the heavy-weight conversion is used instead of using the light-weight conversion function.
The syntax for specifying a light-weight "connect" would be similar too the heavy-weight:
connectfunction [real] <module_identifier> (<input_declaration>) endfunctionThe function overloads the connect module name in the connect rules - i.e. if the rules indicated the connect module to be inserted was "connectmodule foo", then in the case of light-weight conversion the routine used is "connectfunction foo". There may be more than one returning different output types for A2D or D2A (output is "real"), the input would be same as for the corresponding connect module.
If a connect rule has only matching connect-functions and no connect-modules then only light-weight connections are possible and vice-versa.