| |
|
|
|
8.1 Introduction
With the mixed-use of digital and analog simulators, a common terminology is needed. This section provides the core terminology used in this LRM and highlights the behavior of the mixed-signal capabilities of Verilog-AMS HDL.
Verilog-AMS HDL provides the ability to accurately model analog, digital, and mixed-signal blocks. Mixed-signal blocks provide the ability to access data and be controlled by events from the other domain. In addition to providing mixed-signal interaction directly through behavioral descriptions, Verilog-AMS HDL also provides a mechanism for the mixed-signal interaction between modules.
Verilog-AMS HDL is a hierarchical language which enables top-down design of mixed-signal systems. Connect modules are used in the language to resolve the mixed-signal interaction between modules. These modules can be manually inserted (by the user) or automatically inserted (by the simulator) based on rules provided by the user.
Connect rules and the discipline of the mixed signals can be used to control auto-insertion throughout the hierarchy. Prior to insertion, all net segments of a mixed-signal shall first be assigned a discipline. This is commonly needed for interconnect, which often does not have a discipline declared for it. Once a discipline has been assigned (usually through use of a discipline resolution algorithm), connect modules shall be inserted based on the specified connect rules. Connect rules control which connect modules are used and where are they inserted.
Connect modules are a special form of a mixed-signal module which provide significant power in accurately modeling the interfaces between analog and digital blocks. They help ensure the drivers and receivers of a connect module are correctly handled so the simulation results are not impacted.
This section also details a feature which allows analog to accurately model the effects the digital receivers for mixed signals containing both drivers and receivers. In addition, special functions provide access to driver values so a more accurate connect module can be created.
The following subsections define these capabilities in more detail.
8.2 Fundamentals
The most important feature of Verilog-AMS HDL is it puts capabilities of both analog and digital modeling into a single language. This section describes how the continuous (analog) and discrete (digital) domains interact together, as well as the mixed-signal specific features of the language.
8.2.1 Domains
The domain of a value refers to characteristics of the computational method used to calculate it. In Verilog-AMS HDL, a variable is calculated either in the continuous (analog) domain or the discrete (digital) domain every time. The potentials and flows described in natures are calculated in the continuous domain, while register contents and the states of gate primitives are calculated in the discrete domain. The values of real and integer variables can be calculated in either the continuous or discrete domain depending on how their values are assigned.
Values calculated in the discrete domain change value instantaneously and only at integer multiples of a minimum resolvable time. For this reason, the derivative with respect to time of a digital value is always zero (0). Values calculated in the continuous domain, on the other hand, are continuously varying.
8.2.2 Contexts
Statements in a Verilog-AMS HDL module description can appear in the body of an analog block, in the body of an initial or always block, or outside of any block (in the body of the module itself). Those statements which appear in the body of an analog block are said to be in the continuous (analog) context; all others are said to be in the discrete (digital) context. A given variable can be assigned values only in one context or the other, but not in both. The domain of a variable is that of the context from which its value is assigned.
8.2.3 Nets, nodes, ports, and signals
In Verilog-AMS HDL, hierarchical structures are created when higher-level modules create instances of lower level modules and communicate with them through input, output, and bidirectional ports. A port represents the physical connection between an expression in the instantiating or parent module and an expression in the instantiated or child module. The expressions involved are referred to as nets, although they can include registers, variables, and nets of both continuous and discrete disciplines. A port of an instantiated module has two nets, the upper connection (vpiHiConn) which is a net in the instantiating module and the lower connection (vpiLoConn) which is a net in the instantiated module, as shown in Figure 81. The vpiLoConn and vpiHiConn connections to a port are frequently referred to as the formal and actual connections respectively.
A signal is a hierarchical collection of nets which, because of port connections, are contiguous. If all the nets which make up a signal are in the discrete domain, the signal is a digital signal. If all the nets which make up a signal are in the continuous domain, the signal is an analog signal. A signal which consists of nets from both domains is called a mixed-signal.
Similarly, a port whose connections are both analog is an analog port, a port whose connections are both digital is a digital port, and a port whose connections are analog and digital is a mixed port.
If a signal is analog or mixed, then it is associated with a node (see 3.4), while a purely digital signal is not associated with a node. Regardless of the number of analog nets in an analog or mixed-signal or how the analog nets in a mixed-signal are interspersed with digital nets, the analog portion of an analog or mixed-signal is represented by a single node. This guarantees a mixed or analog signal has only one value which represents its potential with respect to the global reference voltage (ground).
8.2.4 Mixed-signal and net disciplines
One job of the discipline of a continuous net is to specify the tolerence (abstol) for the potential of the associated node. A mixed-signal can have a number of continuous nets, with different continuous disciplines and different abstols. In this case, the abstol of the associated node shall be the smallest of the abstols specified in the disciplines associated with all the continuous nets of the signal.
If an undeclared net segment has multiple comparable disciplines connected to it, a connect statement shall specify which discipline to use during discipline resolution.
8.3 Behavioral interaction
Verilog-AMS HDL supports several types of block statements for describing behavior, such as analog blocks, initial blocks, and always blocks. Typically, non-analog behavior is described in initial and always blocks, assignment statements, or assign declarations. There can be any number of initial and always blocks in a particular Verilog-AMS HDL module. However there can only be one analog block in that module.
Nets and variables in the continuous domain are termed continuous nets and continuous variables respectively. Likewise nets, regs and variables in the discrete domain are termed discrete nets, discrete regs, and discrete variables. In Verilog-AMS HDL, the nets and variables of one domain can be referenced in the other's context. This is the means for passing information between two different domains (continuous and discrete). Read operations of nets and variables in both domains are allow from both contexts. Write operations of nets and variables are only allowed from the context of their domain.
Verilog-AMS HDL provides ways to:
· access discrete primaries (e.g., nets, regs, or variables) from a continuous context
· access continuous primaries (e.g., flows, potentials, or variables) from a discrete context
· detect discrete events in a continuous context
· detect continuous events in a discrete context
The specific time when an event from one domain is detected in the other domain is subject to the synchronization algorithm described in 8.3.6 and Section 9. This algorithm also determines when changes in nets and variables of one domain are accessible in the other domain.
8.3.1 Accessing discrete nets and variables from a continuous context
Discrete nets and variables can be accessed from a continuous context. However, because the data types which are supported in continuous contexts are more restricted than those supported in discrete contexts, certain discrete types can not be accessed in a continuous context.
Table 81 lists how the various discrete net/variable types can be accessed from a continuous context.
The syntax for a Verilog-AMS HDL primary is defined in Syntax 81.
Examples:
The following example accesses the discrete primary in from a continuous context.
module onebit_dac (in, out);
input in;
inout out;
wire in;
electrical out;
analog
if (in == 0)
V(out) <+ 0.0;
else
V(out) <+ 3.0;
endmodule
8.3.2 Accessing X and Z bits of a discrete net in a continuous context
Discrete nets can contain bits which are set to X (unknown) or Z (high impedance), Verilog-AMS HDL supports comparisons which take account of X and Z bits in the continuous context. The specific features are:
· the case equality operator (===)
· the case inequality operator (!==)
· the case, casex, and casez statements
· binary, octal and hexadecimal numeric constants which can contain X and Z as digits.
The case equality and case inequality operators have the same precedence as the equality operator.
All operators, functions, and statements are allowed in continuous contexts, except for case-equality, case-inequality, case, casex, and casez, which shall report an error if the expressions they operate on contain X or Z bits.
The syntax for the features which support X and Z comparisons in a continuous context is defined in 2.5 and 6.5. Support for X and Z is limited in the analog blocks as defined above.
Note: Consult IEEE 1364-1995 Verilog HDL for a description of the semantics of these operators.
8.3.3 Accessing continuous nets and variables from a discrete context
All continuous nets can be probed from a discrete context using access functions. All probes which are legal in a continuous context of a module are also legal in the discrete context of a module. Therefore for Verilog-AMS HDL, the definition of IEEE 1364-1995 Verilog HDL's primary is shown in Syntax 82.
Examples:
The following example accesses the continuous net V(in) from the discrete context is.
module sampler (in, clk, out);
inout in;
input clk;
output out;
electrical in;
wire clk;
reg out;
always @(posedge clk)
out = V(in);
endmodule
Continuous variables can be accessed for reading from any discrete context in the same module where these variables are declared. Because the discrete domain can fully represent all continuous types, a continuous variable is fully visible when it is read in a discrete context.
8.3.4 Detecting discrete events in a continuous context
Discrete events can be detected in a Verilog-AMS HDL continuous context. The arguments to discrete events in continuous contexts are in the discrete context. A discrete event in a continuous context is non-blocking like the other event types allowed in continuous contexts. The syntax for events in a continuous context is shown in Syntax 83.
Examples:
The following example shows a discrete event being detected in an analog block.
module sampler3 (in, clk1, clk2, out);
input in, clk1, clk2;
output out;
wire clk1;
electrical in, clk2, out;
analog begin
@(posedge clk1 or cross(V(clk2), 1))
vout = V(in);
V(out) <+ vout;
end
endmodule
8.3.5 Detecting continuous events in a discrete context
In Verilog-AMS HDL, monitored continuous events can be detected in a discrete context. The arguments to these events are in the continuous context. A continuous event in a discrete context is blocking like other discrete events. For Verilog-AMS HDL, the definition of IEEE 1364-1995 Verilog HDL's event_expression is shown in Syntax 84.
Examples:
The following example detects a continuous event in an always block.
module sampler2 (in, clk, out);
input in, clk;
output out;
wire in;
reg out;
electrical clk;
always @(cross(V(clk) - 2.5, 1))
out = in;
endmodule
8.3.6 Concurrency
Verilog-AMS HDL provides synchronization between the continuous and discrete domains. Simulation in the discrete domain proceeds in integer multiples of the digital tick. This is the smallest value of the second argument of the `timescale directive (see section 16.7 in IEEE 1364-1995 Verilog HDL). Thus, values calculated in the digital domain shall be constant between digital ticks and can only change at digital ticks.
Simulation in the continuous domain appears to proceed continuously. Thus, there is no time granularity below which continuous values can be guaranteed to be constant.
The rest of this section describes synchronization semantics for each of the four types of mixed-signal behavioral interaction. Any synchronization method can be employed, provided the semantics preserved. A typical synchronization algorithm is described in 9.2.
8.3.6.1 Analog event appearing in a digital event control
In this case, an analog event, such as cross or timer, appears in an @() statement in the digital context.
Examples:
always begin
@(cross(V(x) - 5.5,1))
n = 1;
end
When it is determined the event has occurred in the analog domain, the statements under the event control shall be scheduled in the digital domain at the largest digital time tick smaller than or equal to the time of the analog event. This event shall not be schedule in the digital domain earlier than the current digital event (see 9.2.3).
8.3.6.2 Digital event appearing in an analog event control
Examples:
analog begin
@(posedge n)
r = 3.14
end
In this case, a digital event, such as posedge or negedge, appears in an @() statement in the analog context.
When it is determined the event has occurred in the digital domain, the statements under the event control shall be executed in the analog domain at the time corresponding to a real promotion of the digital time (e.g., 27 ns to 27.0e-9).
8.3.6.3 Analog primary appearing in a digital expression
In this case, an analog primary (variable, potential, or flow) whose value is calculated in the continuous domain appears in a expression which is in the digital context; thus the analog primary is evaluated in the digital domain.
The expression shall be evaluated using the analog value calculated for the time corresponding to a real promotion of the digital time at which the expression is evaluated.
8.3.6.4 Digital primary appearing in an analog expression
In this case, a digital primary (reg, wire, integer, etc.) whose value is calculated in the discrete domain appears in an expression which is in the analog context; thus the analog primary is evaluated in the continuous domain.
The expression shall be evaluated using the digital value calculated for the greatest digital time tick which is less than or equal to the analog time when the expression is evaluated.
8.3.7 Function calls
Analog functions can only be called from a continuous context. Digital functions can only be called from a digital context.
8.4 Discipline resolution
In general a mixed-signal is a collection of nets, some with discrete discipline(s) and some with continuous discipline(s). Additionally, some of the nets can have undeclared discipline(s). Discipline resolution assigns disciplines to those nets whose discipline is undeclared. This is done to control auto-insertion of connect modules, according to the rules embodied in connect statements.
The assignments are based on: discipline declarations, `default_discipline directives (see 3.6), and the hierarchical connectivity of the design. Once all net segments of every mixed-signal has been resolved, insertion of connect modules shall be performed.
8.4.1 Compatible discipline resolution
One factor which influences the resolved discipline of a net whose discipline is undeclared is the disciplines of nets to which it is connected via ports; i.e., if multiple compatible disciplines are connected to the same net via multiple ports only one discipline can be assigned to that net. This is controlled by the resolveto form of the connect statement; the syntax of this form is described in 8.7.2.
If disciplines at the lower connections of ports (where the undeclared net is an upper connection) are among the disciplines in discipline_list, the result_discipline is the discipline which is assigned to the undeclared net. If all the nets are of the same discipline, no rule is needed; that discipline becomes the resolved discipline of the net.
Examples:
In the example shown in Figure 82, NetA and NetB are undeclared interconnects. NetB has cmos3 and cmos4 at the lower connection ports, while it is an upper connection.
The first connect statement resolves NetB to be assigned the discipline cmos3.
NetA has cmos1, cmos2 and the resulting cmos3 from module twoblks at the lower connection ports; based on the second connect statement, it resolves to be assigned the discipline cmos1.
8.4.2 Connection of discrete-time disciplines
Ports of discrete-time disciplines (ports where digital signals appear at both upper (vpiHiConn) and lower (vpiLoConn) connections) shall obey the rules imposed by IEEE 1364-1995 Verilog HDL on such connections.
In addition, the real-value nets shall obey the rules imposed by 3.5.
8.4.3 Connection of continuous-time disciplines
Ports of continuous-time disciplines (ports where analog signals appear at both upper (vpiHiConn) and lower (vpiLoConn) connections) shall obey the rules imposed in 3.8. It shall be an error to connect incompatible continuous disciplines together.
8.4.4 Resolution of mixed-signals
Once discipline declarations and the `default_discipline compiler directive have been applied, if any mixed-signal nets are still undeclared additional resolution is needed. This section provides an additional method for discipline resolution of remaining undeclared nets (to control the auto-insertion of connect modules).
There are two modes for this method of resolution, basic (the default) and detail, which determine how known disciplines are used to resolve these undeclared nets. For the entire design, undeclared nets shall be resolved at each level of the hierarchy where continuous (analog) has precedence over discrete (digital). The selection of these discipline resolution modes shall be vendor-specific.
More than one conflicting discipline declaration from the same context (in or out of context) for the same hierarchical segment of a signal is an error. In this case, conflicting simply means an attempt to declare more than one discipline regardless of whether the disciplines are compatible or not.
Sample algorithms for the complete discipline resolution process are listed in Annex C.
8.4.4.1 Basic discipline resolution algorithm
In this mode (the default), both continuous and discrete disciplines propagate up the hierarchy to meet one another. At each level of the hierarchy where continuous and discrete meet for an undeclared net that net segment is declared continuous. This typically results in connect modules being inserted higher up the design hierarchy.
Examples:
In the example shown in Figure 83, NetA, NetB, NetC, and NetD are undeclared interconnects.
Using the basic mode of discipline resolution and the specified resolveto connect statements for this example results in the following:
· NetB resolves to cmos3 based on the first resolveto connect statement.
· NetA resolves to cmos1 based on the second resolveto connect statement.
· NetC resolves to electrical based on continuous (electrical) winning over discrete (cmos2).
· NetD resolves to electrical based on continuous (electrical) winning over discrete (cmos1).
8.4.4.2 Detail discipline resolution algorithm
In this mode continuous disciplines propagate up and then back down to meet discrete disciplines. Discrete disciplines do not propagate up the hierarchy. This can result in more connect modules being inserted lower down into discrete sections of the design hierarchy for added accuracy.
Examples:
In the example shown in Figure 84, NetA, NetB, NetC, and NetD are undeclared interconnects.
Using the detail mode of discipline resolution for this example results in the following:
· Continuous up: NetC resolves to electrical based on continuous (electrical) winning over discrete (cmos2).
· Continuous up: NetD resolves to electrical based on continuous (electrical) winning over undeclared.
· Continuous down: NetA resolves to electrical based on continuous (electrical) winning over undeclared.
· Continuous down: NetB resolves to electrical based on continuous (electrical) winning over undeclared.
Note: The specified resolveto connect statements are ignored in this mode unless coercion (see 8.8.1) is used.
8.4.4.3 Coercing discipline resolution
Connect module insertion can be affected by coercion i.e., declaring disciplines for the interconnect in the hierarchy. If an interconnect is assigned a discipline, that discipline shall be used unless the resolveto connect statement overrides the discipline.
Examples:
The example in Figure 85 shows several effects of coercion on auto-insertion.
Case1: NetB is declared as cmos3 (the others are undeclared)
cmos3 top.digital_blk.twoblks.NetB
discipline resolution basic: Same as without coercion.
discipline resolution detail: NetB stays cmos3; NetA, NetC, and NetD become electrical.
Case2: NetA is declared as cmos1 (the others are undeclared)
discipline resolution basic: NetA stays cmos1, NetB is assigned cmos3, and NetC and NetD become electrical.
discipline resolution detail: Same as basic mode.
Case3: NetC is declared as cmos2 (the others are undeclared)
discipline resolution basic: NetC stays cmos2, NetB is assigned cmos3, NetA is assigned cmos1, and NetD is assigned cmos1.
discipline resolution detail: Same as basic mode.
8.5 Connect modules
Connect modules are automatically inserted to connect the continuous and discrete disciplines (mixed-nets) of the design hierarchy together. The continuous and discrete disciplines of the ports of the connect modules and their directions are used to determine the circumstances in which the module can be automatically inserted.
The connect module is a special form of a module; its definition is shown in Syntax 85.
8.6 Connect module descriptions
The disciplines of mixed-nets are determined prior to the connect module insertion phase of elaboration. Connect module declarations with matching port discipline declarations and directions are instantiated to connect the continuous and discrete domains of the mixed net.
The port disciplines define the default type of disciplines which shall be bridged by the connect module. The directional qualifiers of the discrete port determine the default scenarios where the module can be instantiated. The following combinations of directional qualifiers are supported for the continuous and discrete disciplines of a connect module:
continuous
discrete
input
output
output
input
inout
inout
Examples:
Example 1
connectmodule d2a(in, out);
input in;
output out;
logic in;
electrical out;
// insert connect module behavioral here
endmodule
can bridge a mixed input port whose upper connection is compatible with discipline logic and whose lower connection is compatible with electrical, or a mixed output port whose upper connection is compatible with discipline electrical and whose lower connection is compatible with logic.
Example 2
connectmodule a2d(out, in);
output out;
input in;
logic out;
electrical in;
// insert connect module behavioral here
endmodule
can bridge a mixed output port whose upper connection is compatible with discipline logic and whose lower connection is compatible with electrical, or a mixed input port whose upper connection is compatible with discipline electrical and whose lower connection is compatible with logic.
Example 3
connectmodule bidir(out, in);
inout out;
inout in;
logic out;
electrical in;
// insert connect module behavioral here
endmodule
can bridge any mixed port whose one connection is compatible with discipline logic and whose connection is compatible with electrical.
8.7 Connect specification statements
Any number of connect modules can be defined. The designer can choose and specialize those in the design via the connect specification statements. The connect specification statements allow the designer to define:
· specification of which connect module is used, including parameterization, for bridging given discrete and continuous disciplines
· overrides for the connect module default disciplines and port directions
· resolution of incompatible disciplines
The syntax for connect specifications is shown in Syntax 86.
The two forms of the connect specification statements and their syntaxes are detailed in the following subsections.
8.7.1 Connect module auto-insertion statement
The connect module insertion statement declares which connect modules are automatically inserted when mixed nets of the appropriate types are encountered, as shown in Syntax 87.
This specifies the connect module connect_module_identifier is used to determine the mixed-nets of the type used in the declaration of the connect module.
There can be multiple connect module declarations of a given (discrete - continuous) discipline pair and the connect module specification statement specifies which is to be used in the auto-insertion process. In addition, parameters of the connect module declaration can be specified via the connect_attributes.
Connect modules can be reused for different, but compatible disciplines by specifying different discipline combinations in which the connect module can be used. The form is
connect connect_module_identifier connect_attributes discipline_identifier , discipline_identifier ;
where the specified disciplines shall be compatible for both the continuous and discrete disciplines of the given connect module.
It is also possible to override the port directions of the connect module, which allows a module to be used both as a unidirectional and bidirectional connect module. This override also aids library based designs by allowing the user to specify the connect rules, rather than having to search the entire library. The form is
connect connect_module_identifier connect_attributes direction discipline_identifier ,
direction discipline_identifier ;
where the specified disciplines shall be compatible for both the continuous and discrete disciplines of the given connect module and the specified directions are used to define the type of connect module.
8.7.2 Discipline resolution connect statement
The discipline resolution connect statement specifies a single discipline to use during the discipline resolution process when multiple nets with compatible discipline are part of the same mixed net, as shown in Syntax 88.
where discipline_list is the list of compatible disciplines and discipline_identifier is the discipline to be used.
8.7.3 Parameter passing attribute
An attribute method can be used with the connect statement to specify parameter values to pass into the Verilog-AMS HDL connect module and override the default values. Any parameters declared in the connect module can be specified.
Examples:
connect a2d_035u #(.tt(3.5n), .vcc(3.3));
Here each parameter is listed with the new value to be used for that parameter.
8.7.4 connect_mode
This can be used to specify additional segregation of connect modules at each level of the hierarchy. Setting connect_mode to split or merge defines whether all ports of a common discrete discipline and port direction share an connect module or have individual connect modules.
Examples:
connect a2d_035u split #(.tt(3.5n), .vcc(3.3));
Here each digital port has a separate connect module.
8.8 Automatic insertion of connect modules
Automatic insertion of connect modules is performed when signals and ports with continuous time domain and discrete time domain disciplines are connected together. The connect module defines the conversion between these different disciplines.
An instance of the connect module shall be inserted across any mixed port which matches the rule specified by a connect statement. Rules for matching connect statements with ports take into account the port direction (see 8.8.1) and the disciplines of the signals connected to the port.
Each connect statement designates a module to be a connect module. When two disciplines are specified in a connect statement, one shall be discrete and the other continuous.
Examples:
module dig_inv(in, out);
input in;
output out;
reg out;
logic in, out;
always begin
out = #10 ~in;
end
endmodule
module analog_inv(in, out);
input in;
output out;
electrical in, out;
parameter real vth = 2.5;
real outval;
analog begin
if (V(in) > vth)
outval = 0;
else
outval = 5 ;
V(out) <+ transition(outval);
end
endmodule
module ring;
dig_inv d1 (n1, n2);
dig_inv d2 (n2, n3);
analog_inv a3 (n3, n1);
endmodule
connectmodule elect_to_logic(el,cm);
input el;
output cm;
reg cm;
electrical el;
logic cm;
always
@(cross(V(el) - 2.5, 1))
cm = 1;
always
@(cross(V(el) - 2.5, -1))
cm = 0;
endmodule
connectmodule logic_to_elect(cm,el);
input cm;
output el;
logic cm;
electrical el;
analog
V(el) <+ transition((cm == 1) ? 5.0 : 0.0);
endmodule
connectrules mixedsignal;
connect elect_to_logic;
connect logic_to_elect;
endconnectrules
Here two modules, elect_to_logic and logic_to_elect, are specified as the connect modules to be automatically inserted whenever a signal and a module port of disciplines electrical and logic are connected.
Module elect_to_logic converts signals on port out of instance a3 to port in of instance d1. Module logic_to_elect converts the signal on port out of instance d2 to port in of instance a3.
8.8.1 Connect module selection
The selection of a connect module for automatic insertion depends upon the disciplines of nets connected together at ports. It is, therefore, a post elaboration operation since the signal connected to a port is only known when the module in which the port is declared has been instantiated.
Auto-insertion of connect modules is done hierarchically. The connect modules are inserted based on the net disciplines and ports at each level of the hierarchy. The connect_mode split and merged are applied at each level of the hierarchy. This insertion supports the ability to coerce the placement of connect modules by declaring the disciplines of interconnect.
Examples:
Figure 86 shows an example of auto-insertion with coercion.
Case1: All interconnects are undeclared
discipline resolution basic:
merge: d2a at top.mix.blk2 and d2a at top.digital_blk (two connect modules).
split: Same as merged.
discipline resolution detail:
merge: d2a at top.mix.blk2, d2a at top.digital_blk.(blk1-blk2), and d2a at top.digital_blk.twoblks (three connect modules).
split: d2a at each of the five cmos1 blocks.
Case2: If NetB is declared as cmos1 and the remaining interconnect is undeclared
discipline resolution basic:
merge: d2a at top.mix.blk2 and d2a at top.digital_blk (two connect modules).
split: Same as merged.
discipline resolution detail:
merge: d2a at top.mix.blk2, d2a at top.digital_blk.(blk1-blk2), and d2a at top.digital_blk.twoblks (three connect modules).
split: d2a at top.mix.blk2, d2a at top.digital_blk.blk1, d2a at top.digital_blk.blk2, and d2a at top.digital_blk.twoblks (four connect modules).
8.8.2 Signal segmentation
Once a connect module has been selected it can not be inserted until it can be determined whether there should be one connect module per port or one connect module for all the ports on the net of a signal which match a given connect statement. Inserting multiple copies of the same connect module on one signal (i.e., between the signal and the multiple ports) has the effect of creating distinct segments of the signal with the same discipline at that level of the hierarchy.
This segmentation of the signal which connects ports is only performed in the case of digital ports (i.e., ports with discrete-time domain or digital discipline). For analog (or continuous-time domain) disciplines, it is not desirable to segment the signal between the ports; i.e, there shall never be more than one analog node representing a signal. However, it can be desirable for the simulator's internal representation of the signal to consist of various separate digital segments, each with its own connect module.
Examples:
Figure 87 shows how to model the loading effect of each individual digital port on the analog node.
8.8.3 connect_mode parameter
This parameter can be used in the connect statement to direct the segmentation of the signal at each level of the hierarchy, which can occur while inserting a connect module. It can be one of two predefined values, split or merged. The default is merged.
The connect_mode indicates how input, output, or inout ports of the given discipline shall be combined for the purpose of inserting connect modules. It is applied when there is more than one port of discrete discipline on a net of a signal where the connect statement applies.
8.8.3.1 merged
This instructs the simulator to try to group all ports (whether they are input, output, or inout) and to use just one connector module, provided the module is the same.
Examples:
Figure 88 illustrates the effect of the merged attribute.
Connection of the electrical signal to the ttl inout ports and ttl input ports results in a single connector module, bidir, being inserted between the ports and the electrical signal. The ttl output ports are merged, but with a different connect module; i.e., there is one connector module inserted between the electrical signal and all of the ttl output ports.
8.8.3.2 split
If more than one input port is connected at a net of a signal, using split forces there to be one connect module for each port which converts between the net discipline and the port discipline. In this way, the net connecting to the ports is segmented by the insertion of one connect module for each port.
Examples:
Example 1
connect elect_to_logic split;
This connect statement specifies the module elect_to_logic shall be split across the discrete module ports:
· if an input port has logic discipline and the signal connecting to the port has electrical discipline, or
· if an output port has electrical discipline and the signal connecting to the port has logic discipline.
Example 2
In Figure 89, the connections of an electrical signal to ttl output ports results in a distinct instance of the d2a connect module being inserted for each output port. This is mandated by the split parameter.
Connection of the electrical signal to ttl input ports results in a single instance of the a2d connect module being inserted between the electrical signal and all the ttl input ports. This is mandated by merged parameter. This behavior is also seen for the ttl inout ports where the merged parameter is used.
Example 3
This example:
connect cmosA2d split #(.r(30k) input electrical, output cmos02u;
performs three functions:
1. connects an instance of cmosA2d module between a signal with electrical discipline and the input port with cmos02u discipline, or an output port with electrical discipline and the signal with cmos02u discipline;
2. sets the value of the parameter r to 30k; and
3. uses one module instance for each input port.
If there are many output ports where this rule applies, by definition there is no segmentation of the signal between these ports, since the ports have discipline electrical (an analog discipline).
Example 4
This last example:
connect cmosA2d merged #(.r(15k) input electrical, output cmos04u;
does three things:
1. connects an instance of cmosA2d module between a signal with electrical discipline and an input port with cmos04u discipline, or an output port with electrical discipline and a signal with cmos4u discipline;
2. sets the value of the parameter r to 15k; and
3. uses one module instance regardless of the number of ports.
8.8.4 Rules for driver-receiver segregation and connect module selection and insertion
Driver-receiver segregation and connect module insertion is a post elaboration operation. It depends on a complete hierarchical examination of each signal in the design, i.e., an examination of the signal in all the contexts through which it passes. If the complete hierarchy of a signal is digital, i.e., the signal has a digital discipline in all contexts through which is passes, it is a digital signal rather than a mixed-signal. Similarly, if the complete hierarchy of a signal is analog, it is an analog signal rather than a mixed-signal. Rules for driver-receiver segregation and connect module insertion apply only to mixed-signals, i.e., signals which have an analog discipline in one or more of the contexts through which they pass and a digital discipline in one or more of the contexts. In this case, context refers to the appearance of a signal in a particular module instance.
For a particular signal, a module instance has a digital context if the signal has a digital discipline in that module or an analog context if the signal has an analog discipline. The appearance of a signal in a particular context is referred to as a segment of the signal. In general, a signal in a fully elaborated design consists of various segments, some of which can be analog and some of which can be digital.
A port represents a connection between two net segments of a signal. The context of one of the net segments is an instantiated module and the context of the other is the module which instantiates it. The segment in the instantiated module is called the lower or formal connection and the segment in the instantiating module is the upper or actual connection. A connection element is selected for each port where one connection is analog and the other digital.
The following rules govern driver-receiver segregation and connect module selection. These rules apply only to mixed-signals.
1. A mixed-signal is represented in the analog domain by a single node, regardless of how its analog contexts are distributed hierarchically.
2. Digital drivers of mixed-signals are segregated from receivers so the digital drivers contribute to the analog state of the signal and the analog state determines the value seen by the receivers.
3. A connection shall be selected for a port only if one of the connections to the port is digital and the other is analog. In this case, the port shall match one (and only one) connect statement. The module named in the connect statement is the one which shall be selected for the port.
Once connect modules have been selected, they are inserted according to the connect_mode parameter in the pertinent connect statements. These rules apply to connect module insertion:
1. The connect mode of a port for which a connect module has been selected shall be determined by the value of the connect_mode parameter of the connect statement which was used to select the connect module.
2. The connect module for a port shall be instantiated in the context of the ports upper connection.
3. All ports connecting to the same signal (upper connection), sharing the same connect module, and having merged parameter shall share a single instance of the selected connect module.
4. All other ports shall have an instance of the selected connect module, i.e., one connect module instance per port.
8.8.5 Instance names for auto-inserted instances
Parameters of auto-inserted connect instances can be set on an instance-by-instance basis with the use of the defparam statement. This requires predictable instance names for the auto-inserted modules.
The following naming scheme is employed to unambiguously distinguish the connector modules for the case of auto-inserted instances.
1. merged
In the merged case, one or more ports have a given discipline at their bottom connection, call it BottomDiscipline, and a common signal, call it SigName, of another discipline at their top connection. A single connect module, call it ModuleName, is placed between the top signal and the bottom signals. In this case, the instance name of the connect module is derived from the signal name, module name, and the bottom discipline:
SigName__ModuleName__BottomDiscipline
2. split
In the split case, one or more ports have a given discipline at their bottom connection and a common signal of another discipline, call it TopDiscipline, at their top connection. One module instance is instantiated for each such port. In this case, the instance name of the connect module is
SigName__InstName__PortName
where InstName and PortName are the local instance name of the port and its instance respectively.
Note: The __ between the elements of these generated instance names is a double underscore.
8.9 Driver-receiver segregation
If the hierarchical segments of a signal are all digital or all analog, the signal is not a mixed-signal and the internal representation of the signal does not differ from that of a purely digital or an analog signal.
If the signal has both analog and digital segments in its hierarchy, it is a mixed-signal. In this case, the appropriate conversion elements are inserted, either manually or automatically, based on the following rules.
· All the analog segments of a mixed-signal are representations of a single analog node.
· Each of the non-contiguous digital segments of a signal shall be represented internally as a separate digital signal, with its own state.
· Each non-contiguous digital segment shall be segregated into the collection of drivers of the segment and the collection of receivers of the segment.
In the digital domain, signals can have drivers and receivers. A driver makes a contribution to the state of the signal. A receiver accesses, or reads, the state of the signal. In a pure digital net, i.e., one without an analog segment, the simulation kernel resolves the values of the drivers of a signal and it propagates the new value to the receivers by means of an event when there is a change in state.
In the case of a mixed net, i.e., one with digital segments and an analog segment, it can be useful to propagate the change to the analog simulation kernel, which can then detect a threshold crossing, and then propagate the change in state back to the digital kernel. This, among other things, allows the simulation to account for rise and fall times caused by analog parasitics.
Within digital segments of a mixed-signal net, drivers and receivers of ordinary modules shall be segregated, so transitions are not propagated directly from drivers to receivers, but propagate through the analog domain instead. In this case, the drivers and receivers of connect modules shall be oppositely segregated; i.e., the connect module drivers shall be grouped with the ordinary module receivers and the ordinary module drivers shall be grouped with the connect module receivers.
Thus, digital transitions are propagated from drivers to receivers by way of analog (through using connect module instances). Figure 810 and Figure 811 show driver-receiver segregation in modules having bidirectional and unidirectional ports, respectively.
8.10 Driver access and net resolution
Access to individual drivers and net resolution is necessary for accurate implementation of connect modules (see 8.5). A driver of a signal is a process which assigns a value to the signal, or a connection of the signal to an output port of a module instance or simulation primitive. The driver access functions described here only access drivers found in ordinary modules and not to those found in connect modules. Driver access functions can only be called from connect modules.
A signal can have any number of drivers; for each driver the current status, value, and strength can be accessed.
8.10.1 $driver_count
$driver_count returns an integer representing the number of drivers associated with the signal in question. The syntax is shown in Syntax 89.
The drivers are arbitrarily numbered from 0 to N-1, where N is the total number of ordinary drivers contributing to the signal value. For example, if this function returns a value 5 then the signal has five drivers numbered from 0 to 4.
8.10.2 $driver_state
driver_state returns the current value contribution of a specific driver to the state of the signal. The syntax is shown in Syntax 810.
driver_index is an integer value between 0 and N-1, where N is the total number of drivers contributing to the signal value. The state value is returned as 0, 1, x, or z.
8.10.3 $driver_strength
driver_strength returns the current strength contribution of a specific driver to the strength of the signal. The syntax is shown in Syntax 811.
driver_index is an integer value between 0 and N-1, where N is the total number of drivers contributing to the signal value. The strength value is returned as two strengths, Bits 5-3 for strength0 and Bits 2-0 for strength1 (see IEEE 1364-1995 Verilog HDL, sections 7.10 and 7.11).
If the value returned is 0 or 1, strength0 returns the high-end of the strength range and strength1 returns the low-end of the strength range. Otherwise, the strengths of both strength0 and strength1 is defined as shown in Figure 812 below.
strength0 strength1 Bits
Bits
B5
B2
B4
B1
B3
B0
8.10.4 driver_update
The status of drivers for a given signal can be monitored with the event detection keyword driver_update. It can be used in conjunction with the event detection operator @ to detect updates to any of the drivers of the signal.
Examples:
always @(driver_update clock)
statement;
causes the statement to execute any time a driver of the signal clock is updated. Here, an update is defined as the addition of a new pending value to the driver. This is true whether or not there is a change in the resolved value of the signal.
8.10.5 net_resolution
net_resolution sets the value of the net as seen by receivers of the net during driver-receiver segregation; it can only be used in a connect_module. The syntax is shown in Syntax 812.
The port_identifier specifies the name of the digital port in the connection module. The digital_expression is the value that is seen by the receivers of the net.
1. The default is equivalent of assign d = d;
2. Anything else is done explicitly, such as:
assign d = out;
net_resolution( d, out);
8.10.6 Connect module example using driver access functions
Using the example shown in Figure 813, a connect module can be created using driver access functions to accurately model the effects of multiple drivers on an interface.
The connect module below takes advantage of much of the mixed-signal language including driver access functions. This module effectively adds another parallel resistor from output to ground whenever a digital output connected to the net goes high, and another parallel resistor from output to rail (supply) whenever a digital output connected to the net goes low. If this is used as the connect module in Figure 813, not only is the delay from digital outputs to the digital input a function of the value of the capacitor, for a given capacitance it takes approximately half the time (since two gates are driving the signal rather than one).
connectmodule c2e(d,a);
cmos1 d;
electrical a;
input d;
inout a;
reg out;
ground gnd;
branch pull_up(rail,a);
branch pull_down(a,gnd);
branch power(rail,gnd);
parameter real impedence0 = 120.0;
parameter real impedence1 = 100.0;
parameter real impedenceOff = 1e6;
parameter real vt_hi = 3.5;
parameter real vt_lo = 1.5;
parameter real supply = 5.0;
integer num_ones, num_zeros;
net_resolution(d, out);
always @(driver_update(d)) begin
num_ones = 0;
num_zeros = 0;
for ( i = 0; i < $driver_count(d); i++ )
if ( $driver_state(i) == 1 )
num_ones = num_ones + 1;
else
num_zeros = num_zeros + 1;
end
always @(cross(V(a) - vt_hi, -1) or cross(V(a) - vt_lo, +1))
out = 1`bx;
always @(cross(V(a) - vt_hi, +1))
out = 1;
always @(cross(V(a) - vt_lo, -1))
out = 0;
analog begin
// Approximately one impedence1 resistor to rail per high output
// connected to the digital net
V(pull_up) <+ 1/((1/impedence1)*num_ones+(1/impedenceOff)) *
I(pull_up);
// Approximately one impedence0 resistor to ground per low output
// connected to the digital net
V(pull_down) <+ 1/((1/impedence0)*num_zeros+(1/impedenceOff)) *
I(pull_down);
V(power) <+ supply;
end
endconnectmodule
8.11 Supplementary driver access functions
The following driver access functions are provided for access to digital events which have been scheduled onto a driver but might not have matured by the current simulation time.
These functions can be used to create analog waveforms which cross a specified threshold at the same time the digital event matures, thus providing accurate registration of analog and digital representations of a signal. This assumes there is at least as long a delay in the maturation of the digital signal as the required rise/fall times of the analog waveform.
Note: Because the scheduled digital events can be scheduled with an insufficient delay or cancelled before they mature, be careful when using these functions.
8.11.1 $driver_delay
$driver_delay returns the delay, from current simulation time, after which the pending state or strength becomes active. If there is no pending value on a signal, it returns zero (0). The syntax is shown in Syntax 813.
driver_index is an integer value between 0 and N-1, where N is the total number of drivers contributing to the signal value. The returned delay value is an integer.
8.11.2 $driver_next_state
$driver_next_state returns the pending state of the driver, if there is one. If there is no pending state, it returns the current state. The syntax is shown in Syntax 814.
driver_index is an integer value between 0 and N-1, where N is the total number of drivers contributing to the signal value. The pending state value is returned as 0, 1, x, or z.
8.11.3 $driver_next_strength
$driver_next_strength returns the strength associated with the pending state of the driver, if there is one. If there is no pending state, it returns the current strength. The syntax is shown in Syntax 815.
driver_index is an integer value between 0 and N-1, where N is the total number of drivers contributing to the signal value. The pending strength value is returned as an integer between 0 and 7.
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|