Modeling Analog Devices using SV-RNM

Mariam Maurice
Siemens EDA, Cairo-Egypt, [email protected]
I. INTRODUCTION
Nowadays, both analog and digital system blocks are located on the same chip. Most digital design engineers
want to verify digital modeled blocks along with analog models for ensuring the functionality of both systems
together. The most familiar language for digital design engineers to model analog blocks in the digital environment
is SystemVerilog-Real Number Modeling (SV-RNM). RNM uses real number values to model the voltage and the
current behaviors of the analog parts. This paper illustrates important definitions in RNM, like user-defined resolved
nets, boundary elements, and interconnects. This paper also describes how analog devices such as DACs, ADCs,
LDOs, Filters, and Image Sensors can be modeled with these definitions. Debugging and visualization of RNM
constructs are important during the integration of a complete analog device and during connecting an analog device
modeled with the SV-RNM language to a digital one.

II. DEFINITIONS AND RNM DEBUGGING

A. User-Defined Net-types and Resolved Nets
The usage of User-Defined Nets (UDN) increased because they can hold more than one value. As mentioned in
[1], digital design engineers use UDN to hold the values of voltage, current, and resistance in only one net. This
paper demonstrates a new modification to the UDN in [1], which also supports the capacitance value. So now the
User-Defined Type (UDT) structure consists of five real data types (V, V_prev, I, C, R) and the UDN holds five
values. Digital design engineers modify the UDN to be resolved by summation or averaging functions, which are
very simple functions. But the idea of this part is to highlight that the resolved nets can have new technical
improvements to achieve better functionality for the resolved nets. The example shown in Fig. 1, illustrates that
these nets will be resolved by an impedance voltage division. The User-Defined Resolution (UDR) function takes
any UDT input connected to the User-Defined Resolved Net (UDRN) from the values of voltages, capacitances, and
resistances. And then it presents the value resolved after considering the effect of impedance between the driven
input voltage and the output that the user is waiting to see its resolved value. The output voltage and the current are
resolved by the equations in (1).

Figure 1. Impedance Voltage Division.

(1)

This resolved net can model a Low Pass (LP) filtering effect, a High Pass (HP) filtering effect, a resistance-
voltage divider effect, a capacitance-voltage divider effect, a resistance-voltage effect, and a capacitance-voltage
effect. Table I. shows which capacitor and resistor need to be set for reaching the desired effect. Fig. 2 shows the
effect of low and high filtering using this resolved net. Also, it can model the effect of loading at any node. It can
model the load effect of wires connected between sub-blocks of an analog system where the short wire can be
modeled as a small capacitance equivalent to effect ‘5’ in Table I. and the load effects at I/O port pins of an analog
system such as ADC/DAC and LDO analog devices as these ports will be connected to other devices.
 TABLE I
THE COMPONENTS OF THE RESOLVED NET THAT NEED TO BE SET

Figure 2. HP & LP filtering effect using resolved Net.

B. Debugging User-defined Net-types and Resolved Nets

It’s important in the resolved nets to understand the functionality of the resolution function, and this is done
when the debugging tools can distinguish between UDN and UDRN. Debugging tools should declare the resolution
function as a variable of the UDRN that will help in debugging the functional correctness of the resolution function
as illustrated in Fig. 3, the UDRN has a resolution function while a UDN does not so debugging begins with
tracking and understanding the functionality of this variable which is the resolution function.

Figure 3. Difference between UDN & UDRN.

The debug tool needs to have a strong builder expression that can construct complex functions equivalent to the
functionality of the resolution function because this helps in comparing the outputs from the resolution functions to
those generated from the builder expression. These expressions generated from the builder expression can be saved
in do files (files to save the executed commands, so expressions are saved in the form of executed commands rather
than being rebuilt again) and then the parameters of the generated expressions can be easily changed according to
the resolved net parameters. Every input signal will be affected by the generated expressions without having to
create modules with the same functionality of the resolution function and without having to change the parameters
of the modules. The example in Fig. 4, shows the LP filtering effect values generated from the resolved net (UDRN)
are compared with the LP filtering effect values created from the builder expression (Fx) and if the numbers are
approximately equal that means the values generated from UDRN are correct as illustrated in the red box during
charging time (~0.95) and in the blue box during discharging time (~0.02). Building expressions on real data is not
something easy at all, it needs a strong debug tool that can create such complex expressions.

Figure 4. Values of LP filtering effect from UDRN and created expression.

C. Boundary Elements
Most analog system blocks like serial links, image sensors, ADC & DAC can contain digital sub-blocks within
the analog system itself such as encoders/decoders, serializers/de-serializers, latches & registers. In a digital
environment, data that goes from an analog island (real variable) to a digital island (logic variable) must have some
sort of an element to be inserted to convert between them. The element responsible for converting real var to logic
var or vise-versa can be called Boundary Element (BE) or Adapter or Connect Modules. The net that shows the
inserted BE is called MaSter-Net (MS-Net) because this net connects different data types (real & logic). The BEs are
also used to convert power supplies in Analog Mixed Signals (AMS) systems. HDL models the high-supply digital
logic with a ‘1’ and low-supply digital logic with a ‘0’. In any IC design, the power supply is always real data so the
easiest way to convert it to logic is to insert a BE that can convert a high-supply analog value to logic ‘1’ and a low-
supply analog value to logic ‘0’. In the past, HDL designers used to write Verilog code responsible for converting
from Real to Logic (R2L) or from Logic to Real (L2R). But now most simulators support the automatic insertion of
BEs by providing the MS-Net hierarchical path. The inserted BE can be defined as a 1-bit ADC (in the case of R2L)
or as a 1-bit DAC (in the case of L2R) and it is expected in the future that EDA tools will insert n-bit ADC/DAC
automatically. Inserting n-bit ADC/DAC automatically can eliminate modeling analog sub-blocks of ADC and DAC
with specific topologies in the digital environment especially if the user is not interested in modeling undesirable
effects of ADC/DACs and just wants to ensure the functionality of the system. The n-bit generic ADC/DAC, generic
meaning without a specific topology to ADC/DACs, can be supported by the following functionality in (2). The
SystemVerilog code that supports an n-bit ADC/DAC is shown in Table II.

(2)

TABLE II
SYSTEM VERILOG CODE FOR N-BIT GENERIC ADC/DAC
n-bit ADC.sv n-bit DAC.sv
// n to befine resolution (accuray) // n to befine resolution (accuray)
// number of levels = 2**n // number of levels = 2**n
// delta = (high supply voltage) / (number of // delta = (high supply voltage) / (number of
levels) levels)

module R2L #(parameter n = 3) module L2R #(parameter n = 3)

(input real R, output wire [0:(n-1)] L); (input wire [0:(n-1)] L, output real R);

parameter real vsup = 2.5; parameter real vsup = 2.5;

parameter real vsuplow = 0; parameter real vsuplow = 0;
parameter real nlevels = 2**n; parameter real nlevels = 2**n;
parameter real delta = vsup / nlevels; parameter real delta = vsup / nlevels;

reg [0:n-1] R_conv; real L_conv;

always @ (R) begin always @ (L) begin

if (R >= vsup) if (L == '1)
R_conv = '1; L_conv = vsup;
else if (R == vsuplow) else if (L == '0)
R_conv = '0; L_conv = vsuplow;
else if ((vsuplow < R) && (R < vsup)) else if (('0 < L) && (L < '1))
R_conv = R / delta; L_conv = L * delta;
else else
R_conv = 'X; L_conv = `wrealXState;
end end

assign L = R_conv; assign R = L_conv;

endmodule endmodule

D. Debugging Boundary elements (BEs)

The first thought while debugging BEs is about finding the desired BE to be debugged, so the tool should define
it as a separate instance. This helps to know how many BEs are inserted, what type of the BE is inserted (R2L, L2R),
and where they are inserted. When the BE is defined as a separate unique instance, the search can start to find it as a
statement type as shown in Fig. 5.
 Figure 5. Searching for an instance BE.

After selecting the desired BE that needs to be debugged, the BE parameters must be well understood because
the designer can change the default values of the BE inserted through configurable files and these values will be
propagated through all the design. Table III. may simplify the BE parameters whose values need careful debugging.
TABLE III
BE PARAMETERS

It is easy to visualize the highest and the lowest values but the values between need smart schematic tools to
simply give hints when the ‘x’ happens. And then change the time and trace when the BE output becomes ‘x’ as
shown in Fig. 6.

Figure 6. Schematic guiding tools to trace ‘x’.

Adding the inserted BE input and output to a window that can show its changes over time will be very helpful.
Since for any R2L instance there are a lot of real values changed to logic ‘1’, some can be changed to logic ‘0’ and
some can be changed to ‘x’. These windows can be a wave window or a smart window for debugging event-driven
orders. In the example shown in Fig. 7, from the event order window, R (real) will be changed to ‘1’ at 4.837 ns
until the next event which is 7.667 ns where R will be changed to ‘0’ that means R equals ‘1’ from time 4.837 ns to
time 7.667 ns or can be understood that R is converted at time 4.667 ns to logic ‘1’ and to logic ‘0’ at time 7.667 ns.
R changed to ‘2.5’ at time 4.837 ns, and a delta ‘3’ in the red box means that R is the third signal to be changed in
the database file at time 4.837 ns. R (real) converted to L =1 (logic) at time 4.837 ns, and delta ‘5’ in the green box
which means that L is the fifth signal to be changed in the database file at time 4.837 ns.
 Figure 7. The event order for a ‘real’ variable.

E. Interconnects
Some devices are structurally wire-based or the extracted netlist connections of a device can be wire-based
which means that the wire type will be used to connect the sub-blocks of that system. If the system has analog (real)
ports and the connection between its sub-blocks of wire net type, then there will be incompatibility errors during the
simulation process as the real data type is connected directly with the wire net type. One can think that the solution
is to insert two BEs, one R2L and one L2R, so that the wire is between the two inserted BEs (real --- R2L --- wire ---
L2R --- real). This solution will result in a huge information loss and the real data will not be received as the desired
value. Only two real values for the highest and lowest data will be received. Another solution to be considered is
including n-bit ADC and n-bit DAC. Also, this solution will have information loss according to the number of levels
of conversion. It is a hard solution if the tool does not support the automatic insertion of n-bit ADC/DAC and will
also change the design hierarchy. The Best solution is to convert these wires to interconnect. From [2], since the
interconnect is a type-less net and it can hold any value according to the type of data connected to it. Therefore, the
best solution is to convert these wires that connect a real data type into interconnect as shown in Fig. 8.

Figure 8. Wire to interconnect.

F. Debugging Interconnects
The tool must differentiate between interconnects implicitly defined by the tool and those explicitly defined by
the user because those implicitly defined by the tool convert the wire to interconnect as these wires are connected to
real port data. Fig. 9 shows that the interconnect is implicitly defined in the Variables window as interconnect while
the designer defined it in the Source window as wire. The debugger here can understand that the tool changes the
wire to interconnect.

Explicit Interconnects

Figure 9. Implicit Interconnects.

 Since the interconnects can connect any type of data whether it is user-defined or not, the tool should highlight
the data type driven by the interconnect. The red box in Fig.9, shows the data type that will be driven by the
interconnect between brackets ‘()’. As shown in Fig.9, that one interconnect will drive a real data type and the other
will drive ‘EE_struct’ which is likely to be a UDT. Select ‘w_reslv(EE_struct)’ as shown in Fig. 10, to show its
drivers. There is an active driver, the status of Active is “Y”, then show the variables of this driver. You can also
show the receivers of this driver, and then notice that this interconnect connects UDRN because the datatype of the
port has a resolution function.

Figure 10. Debugging drivers and receivers of an interconnect.

III. DUT (DEVICE UNDER TEST)

The purpose of this section is to show that there are a lot of analog devices that can be modeled with all the
definitions defined in the previous sections from UDNs, BEs, and interconnects. These devices can be generators,
ADCs, DACs, LDOs, Image Sensors, and Filters.
A. Generators
The function generator is used to generate electrical waves such as sine, square, sawtooth, and triangular waves.
These waves can be modeled according to (3). Any of these waves will be connected to another analog block, for
that reason considering its loading effect could be important. From Fig. 11, the waveform can provide information
about frequency, max/min amplitude, and the offset of the wave. The random Generator can be useful for modeling
the noise input wave or adding an amount of noise to the input wave.

Figure 11. Waves and getting info from their waveforms.

 (3)

B. ADCs/DACs
The DUT shown in Fig. 12, has the following devices: two Generators, two ADCs of 4-bit FLASH_ADC
topology in [3], Logical Unit (LU), Arithmetic Unit (AU), one DAC of 4-bit R_STRING DAC topology in [4], and
4-bit generic DAC which is explained in part [II.C]. The inputs (wave1 and wave2) to the ADC (Analog to Digital
Converter) can be real sine, triangular, sawtooth, square, or random voltage wave which is explained in part [III.A].

Figure 12. Analog-Mixed Signal DUT.

Wave1 and wave2 are driven by resolved net-types to model the load effect at the analog part, and this loading
can reduce the value of the analog voltage that will be driven by the ADC. The reduction in these values can cause
the ADC to convert an undesired analog voltage to digital. The system engineers can then re-design or re-model the
loading effect from the generator part or the ADC part. Fig. 13 shows the structure of the FLASH_ADC. Inside the
FLASH_ADC there are BEs inserted of R2L type, to convert the real output voltage value of the comparator to the
digital input logic value of the encoder. The ADC sub-blocks are structurally wire-based connections, so a
conversion from wire to interconnect is needed to receive the desired real data between the sub-blocks. The outputs
of the two ADCs will go through the Logical Unit (LU) and the Arithmetic Unit (AU) which are purely digital
devices.

Figure 13. The structure of FLASH_ADC.

Then, the LU output will go through the R_STRING_DAC and the DAC’s output is a resolved net. Fig. 14
shows the structure of R_STRING_DAC. Inside the DAC there are BEs inserted of L2R type. The DAC sub-blocks
are structurally wire-based connections, so a conversion from wire to interconnect is required. The AU output will
go through the n-bit generic DAC which is explained in part [II.C] and its output is also resolved net.

Figure 14. The structure of R_STRING_DAC.

 Table IV. has the SystemVerilog code for FLASH_ADC sub-blocks, to explain the functionality of each sub-
block and how to think about creating its behavioral model.

TABLE IV
SYSTEM VERILOG CODE FOR FLASH ADC
resis_div.sv comparator.sv encoder.sv

module resis_div #(parameter n = 4) module comparator (vref1, … vref15, D1, … , D15, module ENCODER_16_TO_4 (D1, …, D15, sel, Q);
(vref1, … , vref15, vref, GND); VIN, sel, vref); logic [3:0] Q_a;
always @(vref) begin if ((0 <= VIN) && (VIN < vref1)) begin always @(D1, … , D15, sel) begin
vref1 = (1*vref) / (2**n); D1 = 0; sel = 0; Q_a[3] = D8 | D9 | D10 | D11 | D12 | D13 | D14 | D15;
vref2 = (2*vref) / (2**n); end Q_a[2] = D4 | D5 | D6 | D7 | D12 | D13 | D14 | D15;
… … Q_a[1] = D2 | D3 | D6 | D7 | D10 | D11 | D14 | D15;
vref15_temp = (15*vref) / (2**n); else if ((vref15 <= VIN) && (VIN <= vref)) begin Q_a[0] = D1 | D3 | D5 | D7 | D9 | D11 | D13 | D15;
end D15 = vref; sel = 0; end
endmodule end assign Q[3:0] = Q_a;
… assign Q[4] = sel;
else if ((-vref1 >= VIN) && (VIN > -vref2)) begin endmodule
D1 = vref; sel = 1;
end
…
endmodule

To check whether this loading effect is desirable or not, the designer can use a builder expression or a calculator
to take the effect of the quantization noise on the net that will be affected by the load. Taking the worst quantization
noise on this net will show how much the voltage on this net should be lowered or increased. In Fig. 15, the
expression ‘Output_Checked’ means if this check gives a value of zero, all the values in the red box must be
redesigned.

Figure 15. Build an expression to ensure the modeling effect is correct or not.

Therefore, there is something to change in modeling the loading effect of this net. For correction there are two
ways, change the load effect of the DAC or change the load effect that will be connected to the DAC. Changing the
DAC load means more complexity for the buffer sub-block specification of the DAC. Changing the load effect of
the device to be connected to the DAC, means more complexity of the specifications of the connected device. After
changing the load effect of the connected device to DUT. The ‘Output_Checked’ value is now all ‘1’ values as
shown in Fig. 16.

Figure 16. After changing the load effect.

C. LDOs
The concept of LDO (Low Drop-Out voltage) can be simply modeled as a resistive voltage divider. Since there
is only one supply battery in any IP, the LDO model will be designed to reduce the value of the supply battery to the
required supply voltage for each analog system. Also, it can be modeled with UDRN which is explained in part
[II.A]. Fig. 17 shows that the supply voltage battery is decreased to two values: ‘1.8’ and ‘1.2’.

Figure 17. LDO.

D. Image Sensors
A digital image sensor circuit can be simply modeled as a PhotoDiode (PD) followed by an ADC that will
convert the PD's analog output into a digital output. The PD can be modeled as a current source with approximate
infinity resistance (rsh) and a small capacitor due to the effect of the materials (cs). The PD will be connected to a
trans-impedance amplifier that converts its current output into voltage. The trans-impedance amplifier has an
impedance effect of a capacitance parallel to a resistance (cf//rf). Fig. 18 shows the PD output when the input to PD
is a pulse wave.
PhotoDiode.sv
module beh_pd (vout, vin);
output vout; input vin;
real vout; real vin;
real vout_prev; real vin_prev;
// Parameters of photodiode
parameter real id = 50E-6;
parameter real cs = 100E-12; // series capacitance
parameter real rsh = 1E9; // shunt resistance
// Parameters of feedback
parameter real rf = 20E3; // feedback resistance
parameter real cf = 10E-12; // feedback capacitance
//
parameter real TS = 1;
parameter real TU = 1E-9;
real dt = TS * TU;
// Constants
real A, B, C, D;
always @(vin, samplying_clock) begin
A = 1/rf; B = 1/rsh; C = cf/dt; D = cs/dt;
vin_prev = vin;
vout_prev = vout;
vout = (1/(A+C)) * ( ((A+C+B+D) * vin) + (-(D+C) *
vin_prev) + (C * vout_prev) + id );
end
endmodule
Figure 18. Photodiode and its SystemVerilog code.

IV. Conclusion
Many analog devices can be modeled using the SV-RNM language. In the future much of the technical thinking
will be towards modeling analog complex devices in the digital environment and will be supported by the EDA tools
to enable simulation, debugging, and verification of such complex devices. Future work will be on how to verify
these devices with UVM-based verification, assertions, and functional coverage.

REFERENCES
[1] John Brennan, Thomas Ziller, Kawe Fotouhi, Ahmed Osman, “The How To’s of Advanced Mixed-Signal Verification”, pp. 34-38, 2015.
[2] Stuart Sutherland, and Tom Fitzpatrick, “Keeping Up with Chip — the Proposed SystemVerilog 2012 StandardMakes Verifying Ever-
increasing Design Complexity More Efficient”, pp. 5, February 28 – March 1, 2012
[3] K.Sai Kumar, K.Lokesh Krishna, K. Sampath Raghavendra, K.Harish, “A High Speed Flash Analog to Digital Converter”, pp.2, 2018.
[4] Jørgen Andreas Michaelsen, “Digital to Analog Converters”, pp. 9, spring 2013