$display("unsigned out(%%d): %0d", outSumUs); $display("unsigned out(%%b): %b", outSumUs); end endmodule
xcelium
1 2 3 4 5 6 7
xcelium> run signed out(%d): -12 signed out(%b): 10100 unsigned out(%d): 20 unsigned out(%b): 10100 xmsim: *W,RNQUIE: Simulation is complete. xcelium> exit
vcs
1 2 3 4 5 6
Compiler version S-2021.09-SP2-1_Full64; Runtime version S-2021.09-SP2-1_Full64; May 7 17:24 2022 signed out(%d): -12 signed out(%b): 10100 unsigned out(%d): 20 unsigned out(%b): 10100 V C S S i m u l a t i o n R e p o r t
observation
When signed and unsigned is mixed,
the result is by default unsigned.
Prepend to operands with 0s instead of extending
sign, even though the operands is signed
LHS DONT affect how the simulator operate on the
operands but what the results represent, signed or unsigned
Therefore, although outSumUs is declared as signed, its
result is unsigned
subtraction example
In logic arithmetic, addition and subtraction are commonly used for
digital design. Subtraction is similar to addition except that the
subtracted number is 2's complement. By using 2's complement for the
subtracted number, both addition and subtraction can be unified to using
addition only.
$display("unsigned out(%%d): %0d", outSubUs); $display("unsigned out(%%b): %b", outSubUs); end endmodule
1 2 3 4 5 6
Compiler version S-2021.09-SP2-1_Full64; Runtime version S-2021.09-SP2-1_Full64; May 7 17:46 2022 signed out(%d): -3 signed out(%b): 11101 unsigned out(%d): 29 unsigned out(%b): 11101 V C S S i m u l a t i o n R e p o r t
1 2 3 4 5 6
xcelium> run signed out(%d): -3 signed out(%b): 11101 unsigned out(%d): 29 unsigned out(%b): 11101 xmsim: *W,RNQUIE: Simulation is complete.
$display("unsigned out(%%d): %0d", outSubUs); $display("unsigned out(%%b): %b", outSubUs); end endmodule
1 2 3 4 5 6
Compiler version S-2021.09-SP2-1_Full64; Runtime version S-2021.09-SP2-1_Full64; May 7 17:50 2022 signed out(%d): 13 signed out(%b): 01101 unsigned out(%d): 13 unsigned out(%b): 01101 V C S S i m u l a t i o n R e p o r t
1 2 3 4 5 6 7
xcelium> run signed out(%d): 13 signed out(%b): 01101 unsigned out(%d): 13 unsigned out(%b): 01101 xmsim: *W,RNQUIE: Simulation is complete. xcelium> exit
Verilog has a nasty habit of treating everything as unsigned unless
all variables in an expression are signed. To add insult to injury, most
tools won’t warn you if signed values are being ignored.
If you take one thing away from this post:
Never mix signed and unsigned variables in one
expression!
Chronologic VCS simulator copyright 1991-2021 Contains Synopsys proprietary information. Compiler version S-2021.09-SP2-2_Full64; Runtime version S-2021.09-SP2-2_Full64; Nov 19 11:02 2022 Coordinates (7,7): x : 00000111 7 y : 00000111 7 Move +4: x1: 00001011 11 *LOOKS OK* y1: 00001011 11 Move -4: x1: 00010011 19 *SURPRISE* y1: 00000011 3 V C S S i m u l a t i o n R e p o r t Time: 60 CPU Time: 0.260 seconds; Data structure size: 0.0Mb
reference
Lee WF. Learning from VLSI Design Experience [electronic Resource] /
by Weng Fook Lee. 1st ed. 2019. Springer International Publishing; 2019.
doi:10.1007/978-3-030-03238-8
With implict sign extension, the implementation of
signed arithmetic is DIFFERENT from
that of unsigned. Otherwise, their implementations are
same.
The implementations manifest the RTL's behaviour correctly
add without implicit sign
extension
unsigned
rtl
1 2 3 4 5 6 7
module TOP ( inputwire [2:0] data0 ,inputwire [2:0] data1 ,outputwire [2:0] result ); assign result = data0 + data1; endmodule
synthesized netlist
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
///////////////////////////////////////////////////////////// // Created by: Synopsys DC Ultra(TM) in wire load mode // Version : S-2021.06-SP5 // Date : Sat May 7 11:43:27 2022 /////////////////////////////////////////////////////////////
module TOP ( data0, data1, result ); input [2:0] data0; input [2:0] data1; output [2:0] result; wire n4, n5, n6;
module TOP ( inputwiresigned [2:0] data0 ,inputwiresigned [2:0] data1 ,outputwiresigned [2:0] result ); assign result = data0 + data1; endmodule
synthesized netlist
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
///////////////////////////////////////////////////////////// // Created by: Synopsys DC Ultra(TM) in wire load mode // Version : S-2021.06-SP5 // Date : Sat May 7 11:48:54 2022 /////////////////////////////////////////////////////////////
module TOP ( data0, data1, result ); input [2:0] data0; input [2:0] data1; output [2:0] result; wire n4, n5, n6;
module TOP ( inputwire [2:0] data0 // 3 bit unsigned ,inputwire [1:0] data1 // 2 bit unsigned ,outputwire [2:0] result // 3 bit unsigned ); assign result = data0 + data1; endmodule
synthesized netlist
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
///////////////////////////////////////////////////////////// // Created by: Synopsys DC Ultra(TM) in wire load mode // Version : S-2021.06-SP5 // Date : Sat May 7 12:15:58 2022 /////////////////////////////////////////////////////////////
module TOP ( data0, data1, result ); input [2:0] data0; input [1:0] data1; output [2:0] result; wire n4, n5, n6;
///////////////////////////////////////////////////////////// // Created by: Synopsys DC Ultra(TM) in wire load mode // Version : S-2021.06-SP5 // Date : Sat May 7 12:21:51 2022 /////////////////////////////////////////////////////////////
A power spectrum is equal to the square of the absolute value of
DFT.
The sum of all power spectral lines in a power spectrum is equal to
the power of the input signal.
The integral of a PSD is equal to the power of the input
signal.
power spectrum has units of \(V^2\)
and power spectral density has units of \(V^2/Hz\)
Parseval's theorem is a property of the Discrete
Fourier Transform (DFT) that states: \[
\sum_{n=0}^{N-1}|x(n)|^2 = \frac{1}{N}\sum_{k=0}^{N-1}|X(k)|^2
\] Multiply both sides of the above by \(1/N\): \[
\frac{1}{N}\sum_{n=0}^{N-1}|x(n)|^2 =
\frac{1}{N^2}\sum_{k=0}^{N-1}|X(k)|^2
\]\(|x(n)|^2\) is instantaneous
power of a sample of the time signal. So the left side of the equation
is just the average power of the signal over the N
samples. \[
P_{\text{av}} = \frac{1}{N^2}\sum_{k=0}^{N-1}|X(k)|^2\text{, }V^2
\] For the each DFT bin, we can say: \[
P_{\text{bin}}(k) = \frac{1}{N^2}|X(k)|^2\text{,
k=0:N-1, }V^2/\text{bin}
\] This is the power spectrum of the signal.
Note that \(X(k)\) is the
two-sided spectrum. If \(x(n)\) is real, then \(X(k)\) is symmetric about \(fs/2\), with each side containing half of
the power. In that case, we can choose to keep just the
one-sided spectrum, and multiply Pbin by 2
(except DC & Nyquist):
rng default Fs = 1000; t = 0:1/Fs:1-1/Fs; x = cos(2*pi*100*t) + randn(size(t)); N = length(x); xdft = fft(x); xsq_sum_avg = sum(x.^2)/N; specsq_sum_avg = sum(abs(xdft).^2)/N^2;
where xsq_sum_avg is same with
specsq_sum_avg
For a discrete-time sequence x(n), the DFT is defined as: \[
X(k) = \sum_{n=0}^{N-1}x(n)e^{-j2\pi kn/N}
\] By it definition, the DFT does NOT apply to
infinite duration signals.
Different scaling is needed to apply for amplitude spectrum, power
spectrum and power spectrum density, which shown as below
\(f_s\) in Eq.(13) is sample
rate rather than frequency resolution.
And Eq.(13) can be expressed as \[
\text{PSD}(k) =\frac{1}{f_{\text{res}}\cdot
N\sum_{n}w^2(n)}\left|X_{\omega}(k)\right|^2
\] where \(f_{\text{res}}\) is
frequency resolution
We define the following two sums for normalization purposes:
where Normalized Equivalent Noise BandWidth is
defined as \[
\text{NENBW} =\frac{N S_2}{S_1^2}
\] and Effective Noise BandWidth is \[
\text{ENBW} =f_{\text{res}} \cdot \frac{N S_2}{S_1^2}
\]
For Rectangular window, \(\text{ENBW}
=f_{\text{res}}\)
This equivalent noise bandwidth is required when the
resulting spectrum is to be expressed as spectral density (such as
for noise measurements).
plot(Fx1,10*log10(Pxx1),Fx2,10*log10(Pxx2),'r--'); legend('PSD via Eq.(13)','PSD via pwelch')
window effects
It is possible to correct both the amplitude and energy content of
the windowed signal to equal the original signal. However, both
corrections cannot be applied simultaneously
power spectral density (PSD)\[
\text{PSD} =\frac{\left|X_{\omega}(k)\right|^2}{f_s\cdot S_2}
\]
We have \(\text{PSD} =
\frac{\text{PS}}{\text{ENBW}}\), where \(\text{ENBW}=\frac{N \cdot
S_2}{S_1^2}f_{\text{res}}\)
linear power spectrum\[
\text{PS}_L=\frac{|X_{\omega}(k)|^2}{N\cdot S_2}
\]
usage: RMS value, total power \[
\text{PS}_L(k)=\text{PSD(k)} \cdot f_{\text{res}}
\]
Window Correction Factors
While a window helps reduce leakage (The window reduces the jumps at
the ends of the repeated signal), the window itself distorts the data in
two different ways:
Amplitude – The amplitude of the signal
is reduced
This is due to the fact that the window removes information in the
signal
Energy – The area under the curve, or
energy of the signal, is reduced
Window correction factors are used to try and
compensate for the effects of applying a window to data. There are both
amplitude and energy correction factors.
Window Type
Amplitude Correction (\(K_a\))
Energy Correction (\(K_e\))
Rectangluar
1.0
1.0
hann
1.9922
1.6298
blackman
2.3903
1.8155
kaiser
1.0206
1.0204
Only the Uniform window (rectangular window), which is equivalent to
no window, has the same amplitude and energy correction factors.
In literature, Coherent power gain is defined show
below, which is close related to \(K_a\)\[
\text{Coherent power gain (dB)} = 20 \; log_{10} \left( \frac{\sum_n
w[n]}{N} \right)
\]
With amplitude correction, by multiplying by two, the peak
value of both the original and corrected spectrum match. However
the energy content is not the same.
The amplitude corrected signal (red) appears to have more energy, or
area under the curve, than the original signal (blue).
Multiplying the values in the spectrum by 1.63, rather than 2, makes
the area under the curve the same for both the original signal
(blue) and energy corrected signal (red)
hanning's correction factors:
1 2 3 4
N = 256; w = hanning(N); Ka = N/sum(w) Ke = sqrt(N/sum(w.^2))
%% plot psd of two methods plot(Fx1,10*log10(Pxx1),Fx2,10*log10(Pxx2),'r--'); legend('PSD via Eq.(13)','PSD via pwelch') grid on; xlabel('Freq (Hz)'); ylabel('dB; V^2/Hz')
We may also want to know for example the RMS value of the signal, in
order to know how much power the signal generates. This can be done
using Parseval’s theorem.
For a periodic signal, which has a discrete
spectrum, we obtain its total RMS value by summing the included signals
using \[
x_{\text{rms}}=\sqrt{\sum R_{xk}^2}
\] Where \(R_{xk}\) is the RMS
value of each sinusoid for \(k=1,2,3,...\) The RMS value of a signal
consisting of a number of sinusoids is consequently equal to the
square root of the sum of the RMS values.
This result could also be explained by noting that sinusoids of
different frequencies are orthogonal, and can therefore
be summed like vectors (using Pythagoras’ theorem)
For a random signal we cannot interpret the spectrum in the same way.
As we have stated earlier, the PSD of a random signal contains all
frequencies in a particular frequency band, which makes it
impossible to add the frequencies up. Instead, as the PSD is a
density function, the correct interpretation is to sum the area under
the PSD in a specific frequency range, which then is the square of the
RMS, i.e., the mean-square value of the signal \[
x_{\text{rms}}=\sqrt{\int G_{xx}(f)df}=\sqrt{\text{area under the
curve}}
\] The linear spectrum, or RMS
spectrum, defined by \[\begin{align}
X_L(k) &= \sqrt{\text{PSD(k)} \cdot f_{\text{res}}}\\
&=\sqrt{\frac{\left|X_{\omega}(k)\right|^2}{f_{\text{res}}\cdot
N\sum_{n}\omega^2(n)} \cdot f_{\text{res}}} \\
&= \sqrt{\frac{\left|X_{\omega}(k)\right|^2}{N\sum_{n}\omega^2(n)}}
\\
&= \sqrt{\frac{|X_{\omega}(k)|^2}{N\cdot S_2}}
\end{align}\]
The corresponding linear power spectrum or
RMS power spectrum can be defined by \[\begin{align}
\text{PS}_L(k)&=X_L(k)^2=\frac{|X_{\omega}(k)|^2}{S_1^2}\frac{S_1^2}{N\cdot
S_2} \\
&=\text{PS}(k) \cdot \frac{S_1^2}{N\cdot S_2}
\end{align}\]
So, RMS can be calculated as below \[\begin{align}
P_{\text{tot}} &= \sum \text{PS}_L(k) \\
\text{RMS} &= \sqrt{P_{\text{tot}}}
\end{align}\]
DFT averaging
we use \(N= 8*\text{nfft}\) time
samples of \(x\) and set the number of
overlapping samples to \(\text{nfft}/2 =
512\). pwelch takes the DFT of \(\text{Navg} = 15\) overlapping segments of
\(x\), each of length \(\text{nfft}\), then averages the \(|X(k)|^2\) of the DFT’s.
In general, if there are an integer number of segments that cover all
samples of N, we have \[
N = (N_{\text{avg}}-1)*D + \text{nfft}
\] where \(D=\text{nfft}-\text{noverlap}\). For our
case, with \(D = \text{nfft}/2\) and
\(N/\text{nfft} = 8\), we have \[
N_{\text{avg}}=2*N/\text{nfft}-1=15
\] For a given number of time samples N, using overlapping
segments lets us increase \(N_{avg}\)
compared with no overlapping. In this case, overlapping of 50% increases
\(N_{avg}\) from 8 to 15. Here is the
Matlab code to compute the spectrum:
1 2 3 4 5 6 7 8
nfft= 1024; N= nfft*8; % number of samples in signal n= 0:N-1; x= A*sin(2*pi*f0*n*Ts) + .1*randn(1,N); % 1 W sinewave + noise noverlap= nfft/2; % number of overlapping time samples window= hanning(nfft); [pxx,f]= pwelch(x,window,noverlap,nfft,fs); % W/Hz PSD PdB_bin= 10*log10(pxx*fs/nfft); % dBW/bin
DFT averaging reduces the variance \(\sigma^2\) of the noise spectrum by a
factor of \(N_{avg}\), as long as
noverlap is not greater than nfft/2
fftshift
The result of fft and its index is shown as below
After fftshift
1 2 3 4 5
>> fftshift([123456])
ans =
456123
dft and
psd function in virtuoso
dft always return
To compensate windowing effect, \(W(n)\), the dft output should
be multiplied by \(K_a\), e.g. 1.9922
for hanning window.
psd function has taken into account \(K_e\), postprocessing is
not needed
Rapuano, Sergio, and Harris, Fred J., An Introduction to FFT and Time
Domain Windows, IEEE Instrumentation and Measurement Magazine, December,
2007. https://ieeexplore.ieee.org/document/4428580
Heinzel, Gerhard, A. O. Rüdiger and Roland Schilling. "Spectrum and
spectral density estimation by the Discrete Fourier transform (DFT),
including a comprehensive list of window functions and some new at-top
windows." (2002). URL: https://holometer.fnal.gov/GH_FFT.pdf
Jens Ahrens, Carl Andersson, Patrik Höstmad, Wolfgang Kropp,
“Tutorial on Scaling of the Discrete Fourier Transform and the Implied
Physical Units of the Spectra of Time-Discrete Signals” in 148th
Convention of the AES, e-Brief 56, May 2020 [ pdf,
web
].
Manolakis, D., & Ingle, V. (2011). Applied Digital Signal
Processing: Theory and Practice. Cambridge: Cambridge University
Press. doi:10.1017/CBO9780511835261
In T* DRC deck, it is based on the voltage recognition CAD layer and
net connection to calculate the voltage difference between two
neighboring nets by the following formula:
\[
\Delta V = \max(V_H(\text{net1})-V_L(\text{net2}),
V_H(\text{net2})-V_L(\text{net1}))
\]
where \[
V_H(\text{netx}) = \max(V(\text{netx}))
\] and \[
V_L(\text{netx}) = \min(V(\text{netx}))
\]
The \(\Delta V\) will be
0 if two nets are connected as same potential
If \(V_L \gt V_H\)on a
net, DRC will report warning on this net
Voltage recognition CAD
Layer
Two method
voltage text layer
You place specific voltage text on specific drawing layer
voltage marker layer
Each voltage marker layer represent different voltage for specific
drawing layer
voltage text layer has higher priority than voltage
marker layer and is recommended
voltage text layer
For example M3
Process Layer
CAD Layer#
Voltage High
Voltage High Top (highest priority)
Voltage Low
Voltage Low Top (highest priority)
M3
63
110
112
111
113
where 63 is layer number,
110 ~ 113 is datatype
voltage marker layer
Different data type represent different voltage, like
class uvm_reg_map extends uvm_object; // Function: add_submap // // Add an address map // // Add the specified address map instance to this address map. // The address map is located at the specified base address. // The number of consecutive physical addresses occupied by the submap // depends on the number of bytes in the physical interface // that corresponds to the submap, // the number of addresses used in the submap and // the number of bytes in the // physical interface corresponding to this address map. // // An address map may be added to multiple address maps // if it is accessible from multiple physical interfaces. // An address map may only be added to an address map // in the grand-parent block of the address submap. // externvirtualfunctionvoid add_submap (uvm_reg_map child_map, uvm_reg_addr_t offset);
// Function: add_mem // // Add a memory // // Add the specified memory instance to this address map. // The memory is located at the specified base address and has the // specified access rights ("RW", "RO" or "WO"). // The number of consecutive physical addresses occupied by the memory // depends on the width and size of the memory and the number of bytes in the // physical interface corresponding to this address map. // // If ~unmapped~ is TRUE, the memory does not occupy any // physical addresses and the base address is ignored. // Unmapped memories require a user-defined ~frontdoor~ to be specified. // // A memory may be added to multiple address maps // if it is accessible from multiple physical interfaces. // A memory may only be added to an address map whose parent block // is the same as the memory's parent block. // externvirtualfunctionvoid add_mem (uvm_mem mem, uvm_reg_addr_t offset, string rights = "RW", bit unmapped=0, uvm_reg_frontdoor frontdoor=null); endclass: uvm_reg_map
Control-oriented coverage uses SystemVerilog Assertion (SVA) syntax
and the cover directive. It is used to cover sequences of signal values
over time. Assertions cannot be declared or "covered" in a class
declaration, so their use in an UVM verification environment is
restricted to interface only
Covergroup for
data-oriented coverage
CAN be declared as a class member and created in class
constructor
Data-oriented coverage uses the covergroup construct.
Covergroups can be declared and created in classes, therefore they are
essential for explicit coverage in a UVM verification environment.
Interface Monitor Coverage
covergroup new constructor is called
directly off the declaration of the covergroup, it does
not have a separate instance name
1
collected_pkts_cq = new();
The covergroup instance must be created in the class
constructor, not a UVM build_phase or other phase
method
Routing - packets flow from input ports to all legal outputs
latency - all packets received within speicied delay
The module UVC monitor receives data from the interface monitors via
analysis ports, so the implementation of the analysis write function is
a convenient place to put coverage code
Blocking methods are defined with
get() or put()tasks to allow
them to consume time
Non-blocking methods are defined with
try_get() or try_put()functions as they execute in zero time
Uni-Directional TLM
Methods Reference
Method
Description
Syntax
put()
Blocking put
virtual task put(iput TR t);
try_put()
Nonblocking put -return 1 if successful -return 0 if
not
virtual function bit try_put(input TR t);
can_put()
Nonblocking test put -return 1 if put would be
successful -return 0 if not
virtual function bit can_put();
get()
Blocking get
virtual task get(output TR t);
try_get()
Nonblocking get -return 1 if successful -return 0 if
not
virtual function bit try_get(output TR t);
can_get()
Nonblocking test get -return 1 if get would be
successful -return 0 if not
virtual function bit can_get();
peek()
Blocking peek
virtual task peek(output TR t);
try_peek()
Nonblocking peek -return 1 if successful -return 0 if
not
virtual function bit try_peek(output TR t);
can_peek
Nonblocking test peek -return 1 if peek would be
successful -return 0 if not
virtual function bit can_peek();
The peek() methods are similarly to the
get() methods, but copy the transaction
instead of removing it. The transaction is not
consumed, and a subsequent get or peek
operation will return the same transaction
Selected Connector and
Method Options
put
try_put
can_put
get
try_get
can_get
peek
try_peed
can_peek
uvm_put_*
✓
✓
✓
uvm_blocking_put_*
✓
uvm_nonblocking_put_*
✓
✓
uvm_get_*
✓
✓
✓
uvm_blocking_get_*
✓
uvm_nonblocking_get_*
✓
✓
uvm_get_peek_*
✓
✓
✓
✓
✓
✓
uvm_blocking_get_peek_*
✓
✓
uvm_nonblocking_get_peek_*
✓
✓
✓
✓
in the connectors above, * can be replaced by
port, imp, or export
All the methods for a specific connector type MUST
be implemented. If you define an uvm_put connection between
two compoents, then the component with the uvm_put_imp
object must provide implementations of ALL three put
methods, put, try_put and
can_put, even if these methods are not explicitly
called
TLM FIFO
The TLM FIFO is a FIFO component wrapped in get and
putimp connectors. This has the benefit of
data storage as well as providing implementations of the communication
methods. Components connected to the TLM FIFO are in control of data
transfer and can simply defined port connectors to initiate read and
write operations on the FIFO
uvm_tlm_fifo
The TLM FIFO object is effectively a FIFO component instantiated
between and connected to two components. The FIFO contains
imp connectors for the standard TLM put and
get/peek interfaces, therefore the user does
not have to defineimp ports or communication methods and
the FIRO takes care of data storage
The advantages are:
The user does not need to define communication methods or
imp connectors
The FIFO provides data storage between the write
(put) and read
(get/peek) components
There are a number of built-in methods for checking FIFO status
The disadvantages are:
The user must now initiate both sides of the transfer (both
get/peek and put) to complete the
transaction
Two connections must be made (both sides of the FIFO) rather than
one
The put_export and get_peek_export
connection objects have alternatives which provide subsets of the full
connector. For example, blocking_put_export and
nonblocking_put_export can replace put_export.
blocking_get_export, nonblocking_get_export
and get_export (as well as others) can replace
get_peek_export.
built-in methods
Method
Description
Syntax
new
Standard component constructor with an additional third argument,
size, which sets the maximum FIFO size. Default size is 1.
A size of 0 is an unbounded FIFO
function new(string name, uvm_component parent=null, int size=1);
size
Return size of FIFO. 0 indicates unbounded
FIFO
virtual function int size()
used
Return number of entries written to the FIFO
virtual function int used();
is_empty
Return 1 if used() is 0, otherwise
0
virtual function bit is empty();
is_full
Return 1 if used() is equal to size,
otherwise 0
virtual function bit is_full()
flush
Delete all entries from the FIFO, upon which used() is
0 and is_empty() is
1
virtual funciton void flush();
1 2 3
class uvm_tlm_fifo #(type T=int) extends uvm_tlm_fifo_base #(T); ... endclass
virtualclass uvm_tlm_fifo_base #(type T=int)extends uvm_component; uvm_put_imp #(T, this_type) put_export; uvm_get_peek_imp #(T, this_type) get_peek_export; uvm_analysis_port #(T) put_ap; uvm_analysis_port #(T) get_ap; // The following are aliases to the above put_export uvm_put_imp #(T, this_type) blocking_put_export; uvm_put_imp #(T, this_type) nonblocking_put_export; // The following are all aliased to the above get_peek_export, which provides // the superset of these interfaces. uvm_get_peek_imp #(T, this_type) blocking_get_export; uvm_get_peek_imp #(T, this_type) nonblocking_get_export; uvm_get_peek_imp #(T, this_type) get_export; uvm_get_peek_imp #(T, this_type) blocking_peek_export; uvm_get_peek_imp #(T, this_type) nonblocking_peek_export; uvm_get_peek_imp #(T, this_type) peek_export; uvm_get_peek_imp #(T, this_type) blocking_get_peek_export; uvm_get_peek_imp #(T, this_type) nonblocking_get_peek_export; functionnew(string name, uvm_component parent = null); super.new(name, parent); put_export = new("put_export", this); blocking_put_export = put_export; nonblocking_put_export = put_export; get_peek_export = new("get_peek_export", this); blocking_get_peek_export = get_peek_export; nonblocking_get_peek_export = get_peek_export; blocking_get_export = get_peek_export; nonblocking_get_export = get_peek_export; get_export = get_peek_export; blocking_peek_export = get_peek_export; nonblocking_peek_export = get_peek_export; peek_export = get_peek_export; put_ap = new("put_ap", this); get_ap = new("get_ap", this); endfunction
Analysis FIFO
uvm_tlm_analysis_fifo
uvm_tlm_analysis_fifo is a specialization of
uvm_tlm_fifo
Intended to buffer write transactions between the UVC monitor
analysis port and scoreboard
It has the following characteristics:
Unbounded (size=0)
analysis_export connector replaces
put_export
Support the analysis write method
By declaring the FIFO in the scoreboard, we can get
directly from the FIFO output.
However the write side connection of the FIFO to the interface UVC
monitor analysis port must be made (usually) in the testbench which has
visibility of both UVC and scoreboard components. The connection is made
using a connect method call inside the connect phase method
class uvm_tlm_analysis_fifo #(type T = int) extends uvm_tlm_fifo #(T);
// Port: analysis_export #(T) // // The analysis_export provides the write method to all connected analysis // ports and parent exports: // //| function void write (T t) // // Access via ports bound to this export is the normal mechanism for writing // to an analysis FIFO. // See write method of <uvm_tlm_if_base #(T1,T2)> for more information.
// Function: new // // This is the standard uvm_component constructor. ~name~ is the local name // of this component. The ~parent~ should be left unspecified when this // component is instantiated in statically elaborated constructs and must be // specified when this component is a child of another UVM component.
functionnew(string name , uvm_component parent = null); super.new(name, parent, 0); // analysis fifo must be unbounded analysis_export = new("analysis_export", this); endfunction
functionvoid write(input T t); void'(this.try_put(t)); // unbounded => must succeed endfunction
endclass
Analysis Port Broadcast
Analysis ports can (uniquely) be connected to any number of
imp connectors, including zero
The analysis port in component yapp_monitor will be
connected to both monitor_one and monitor_two
components. Each of the receiving components has an analysis imp
object and a write communication method declared. The write method
must have the same signature - i.e., they must be void functions called
write with a single input argument of type yapp_packet, but
their implementations can be completely different.
When the send_yapp port is connected to both
mone_in and mtwo_in imps, then a single write call
from yapp_monitor executes both write implementations in
monitor_one and monitor_two
For non-analysis connections
the TLM object must be connected to a single destination only, i.e.,
each non-analysis object has exactly one connect call.
An object may be used multiple times as the argument to a
connect, but exactly once as the caller. This is called
many-to-one connection. For example, many ports can be
connected to a one imp connector
For analysis connections
a TLM object can be connected to any number of destinations i.e.,
one analysis object can call connect many times. This is called
one-to-many connection. For example, one port can be
connected to many imp connectors. one-to-many is only
allowed for analysis connections. An analysis connection can also
NOT call connect. An unconnected TLM object is also only
allowed for analysis connections
Bi-Directional TLM
Transport Connection
Connector syntax
1 2 3
uvm_blocking_transport_XXX #(type REA, type RSP) uvm_nonblocking_transport_XXX #(type REQ, type RSP) uvm_transport_XXX #(type REQ, type RSP)
FIFO/analysis FIFOs do not perform any cloning on input transactions.
Therefore, you will need to check that the UVC monitors collect every
transaction into a different instance to avoid overwriting data in the
FIFOs
imp and port connectors are sufficient for
modeling most connections, but there is third connector,
export, which is used exclusively in hierarchical
connections.
Normally hierarchical routing is not required. A port on
an UVC monitor can be connected directly to an imp in a
scoreboard by specifying full hierarchical pathname (e.g.,
env.agent.monitor.analysis_port). The structure of an UVC is fixed and
so the user knows to look in the monitor component for the analysis
ports.
However the internal hierarchy of a module UVC is more arbitrary, and
it may be convenient to route all the module UVC connectors to the top
level to allow use without knowledge of the internal structure.
On the initiator side
ports are routed up the hierarchy via other port instances
On the target side
only the component which defines the communication method is allowed
to have an imp instance. So we need a third object to route
connections up the target side hierarchy - export
The hierarchical route must be connected at each level in the
direction of control flow:
1
initiator.connect(target)
Connection rules are as follows:
port initiators can be connected to port,
export or imp targets
export initiators can be connected to
export or imp targets
imp cannot be connection initiator. imp is
target only and is always the last connection object on a route
uvm_analysis_port
1 2 3
class uvm_analysis_port # ( type T = int ) extends uvm_port_base # (uvm_tlm_if_base #(T,T))
uvm_analysis_port
1 2 3
class uvm_analysis_port # ( type T = int ) extends uvm_port_base # (uvm_tlm_if_base #(T,T))
uvm_analysis_imp
1 2 3 4
class uvm_analysis_imp #( type T = int, type IMP = int ) extends uvm_port_base #(uvm_tlm_if_base #(T,T))
QA
What are the three distinct functions of a scoreboard?
Reference model, expected data storage and comparison
To how many consumer components can an analysis port be
connected?
Any number, including zero
What are the names of the two declarations made available by the
following macro:
1
`uvm_analysis_imp_decl(_possible)
Subclass uvm_analysis_imp_possible
Method write_possible
Why should a scoreboard clone the data received by a
write method?
The write method only sends a reference, therefore if
the sending component uses the same reference for every data item,
overwriting of data in the storage function of the scoreboard is
possible without cloning.
