Writing Bidirectional Model Behavior

You can use the $cds_get_external_drivers system task in module definitions to model bidirectional behavior like pass gates, for nets with user-defined nettypes (UDNs). For example, you may use $cds_get_external_drivers in module definitions to model the bidirectional behavior of WTRAN models with SV-wreal nettypes.

You can also use the abbreviated name, $cged instead of $cds_get_external_drivers.

The use model is similar to the connect modules that support SIE with the following differences:

The module cannot contain any analog ports
The module is not limited to just two ports like the SIE connect modules

The module can have an arbitrary number of digital ports. All inout ports that have a $cds_get_external_drivers call associated with them receive additional SIE processing to create shadow networks. All ports that do not have a $cds_get_external_drivers call associated with them receive normal SystemVerilog port processing.

The module cannot have a $cds_get_external_drivers call associated with a port that is not declared (or has default direction) as inout. Also, all ports that have a $cds_get_external_drivers calls associated with them must be nets; $cds_get_external_drivers cannot be called on a var port. However, normal ports that do not get SIE processing can have any legal port kind, type, or direction. Also, module/UDP instantiation inside SIE model is not supported.

Starting with Xcelium 19.09, bidirectional behavior of WTRAN models is supported with mixed-language (Verilog/VHDL) net connections also. So, you can instantiate Verilog SIE model inside VHDL (VHDL on parent and Verilog SIE model on child).

Following is an example of a wreal1driver pass gate model that can be modeled with SIE ports:

import cdn_rnm_pkg::*;
module wreal1driver_pass_gate(inout wreal1driver a, inout wreal1driver b, wire en);
real aVal, bVal;
real aOut, bOut;
initial
begin
$cds_get_external_drivers(a, aVal);
$cds_get_external_drivers(b, bVal);
aOut = `wrealZState;
bOut = `wrealZState;
end

always @(aVal, bVal, en)
begin
//en is high so the pass gate is open
if(en===1)
begin
if(aVal === `wrealZState)
begin
// a is Z so we pass b to a
aOut = bVal;
bOut = `wrealZState;
end
else if(bVal === `wrealZState)
begin
// b is Z so pass a to b
bOut = aVal;
aOut = `wrealZState;
end
else
begin
// both a and b are nonZ so we have contention and output X
aOut = `wrealXState;
bOut = `wrealXState;
end
end
else if(en===0)
begin
// en is low so we aren't passing values. just drive Z
aOut = `wrealZState;
bOut = `wrealZState;
end
else
begin
// en is X or Z so output X
aOut = `wrealXState;
bOut = `wrealXState;
end
end
// assign the pass values to the port so they are visible to external receivers
assign a = aOut;
assign b = bOut;
endmodule

In the above example, if the enable is high and only one of the model ports is driven, that value is passed to the other side. For cases where both ports are driven and the enable is high, both sides of the pass gate resolve to wrealXState. If the enable is low, both sides of the pass gate are isolated from each other (the pass gate drives out `wrealZValue). If the enable is X or Z, both sides resolve to `wrealXState.

Following is an example of a WTRANIF1 model that can be modeled with SIE ports:

import cds_rnm_pkg::*;
 
module wtranif1(inout wreal4state a, inout wreal4state b, input var bit en);
real a_val;
real b_val;
wreal4state a_ord;
wreal4state b_ord;
real Zval;
real Xval;
 
initial
begin
Zval = `wrealZState;
Xval = `wrealXState;
$cds_get_external_value(a, a_ord);
$cds_get_external_value(b, b_ord);
end
/* disable full resolution on the shadow net */
assign a_ord = (en!==1)? Xval : Zval;
assign b_ord = (en!==1)? Xval : Zval;

assign #1 a = (en!==1'b1)? Zval : b_ord;
assign #1 b = (en!==1'b1)? Zval : a_ord;

endmodule // wtranif1

wreal4state is analogous to a digital 4-state wire and is the only type that can be used to model a WTRANIF gate.

The following figure illustrates a typical use scenario of the WTRANIF1 switch.

The $cds_get_external_value function is used to resolve the drive strength of A and B.

When enable EN=1
- If A is wrealZState and B is not, the value of B drives A

- If B is wrealZState and A is not, the value of A drives B

- If none of them are wrealZState, they resolve to wrealXState
When enable EN=0, A and B maintain their values

Modeling bidirectional behavior for WTRAN models may affect elaboration performance. You can use the xrun option, -amsie_task_perf, to optimize elaboration performance for such models.

Modeling arbitrary networks of pass gates may not be possible for every resolution function as the pass gate model relies heavily on the resolution behavior of the net. For some resolutions (like for instance wrealavg), it may not be possible to use this methodology to model pass gate like behavior (wrealavg ports may have different values on each port because the internal driver gets averaged with the external drivers, which may be different on each port in a multi-driver situation). Therefore, if you intend to model pass gate behavior, you should define the resolution function such that it supports your pass gate models.

Writing Bidirectional Model Behavior

Related Topics