|
HOME
|
ABOUT
|
ARTICLES
|
ACK
|
FEEDBACK
|
TOC
|
LINKS
|
BLOG
|
JOBS
|
Tutorials
SystemVerilog
Verification
Constructs
Interface
OOPS
Randomization
Functional Coverage
Assertion
DPI
UVM Tutorial
VMM Tutorial
OVM Tutorial
Easy Labs : SV
Easy Labs : UVM
Easy Labs : OVM
Easy Labs : VMM
AVM Switch TB
VMM Ethernet sample
Verilog
Verification
Verilog Switch TB
Basic Constructs
OpenVera
Constructs
Switch TB
RVM Switch TB
RVM Ethernet sample
Specman E
Interview Questions
FUNCTIONAL VERIFICATION QUESTIONS 2
(Q
i
24)
o
e
What
i
are
o
the
q
advantages
r
e
and
i
disadvantages
o
q
j
of
r
e
State
i
machine
o
based
q
and task
z
based
u
y
verification
e
o
environment.
Ans:
state
i
machine
o
e
based
i
BFM
o
uses
q
a
r
e
state
i
machine
o
q
j
to
r
e
generate
i
the
o
bus
q
cycles. SM
z
would
u
y
generate
e
o
memory
z
x
read, memory write, I/O read, and I/O write cycles.
State
i
machines
o
e
are
i
also
o
good
q
at
r
e
handling
i
bursting
o
q
j
and
r
e
early
i
termination.
o
It
q
could also
z
be
u
y
setup
e
o
to
z
x
handle special cycles like interrupt acknowledge or shutdown.
Use
i
task
o
e
based
i
BFM
o
for
q
unit
r
e
testing.
i
Units
o
q
j
are
r
e
often
i
less
o
complex
q
than the
z
whole
u
y
system,
e
o
and
z
x
hence, do not need a robust test bench. A simple BFM can facilitate the early testing of a complex block especially if the unit has a simple interface or just one bus interface. The task based BFM is extremely efficient if the device under test performs many calculations but uses relatively few bus access cycles to keep it going. The reason for this is, the BFM is not looping through an idle state every clock cycle. The BFM does not toggle any signals when a task is not active. Nor, does it make any decisions based on input when a task is not active.
(Q
i
25)
o
e
In
i
a
o
packet
q
protocol,
r
e
where
i
the
o
q
j
packet
r
e
comparison
i
is
o
done?
Ans:
In
i
scoreboard.
www.testbench.in
(Q
i
26)
o
e
What
i
are
o
types
q
of
r
e
code
i
coverages
o
q
j
are
r
e
there?
Ans:
Click on the below link
http://www.testbench.in/TS_11_TYPES_OF_CODE_COVERAGE.html
(Q
i
27)
o
e
What
i
types
o
of
q
functional
r
e
coverages
i
are
o
q
j
there?
Ans:
Click on the below link
http://www.testbench.in/TS_20_FUNCTIONAL_COVERAGE.html
(Q
i
28)
o
e
Explain
i
about
o
driver
q
and
r
e
monitor
i
?
Ans:
Driver:
.....w.....w......w......t.....e.....s.....t......b.....e.....n.....c.....h......i.....n
The
i
drivers
o
e
translate
i
the
o
operations
q
produced
r
e
by
i
the
o
q
j
generator
r
e
into
i
the
o
actual
q
inputs for
z
the
u
y
design
e
o
under
z
x
verification. Generators create inputs at a high level of abstraction namely, as transactions like read write operation. The drivers convert this input into actual design inputs, as defined in the specification of the designs interface. If the generator generates read operation, then read task is called, in that, the DUT input pin "read_write" is asserted.
www.testbench.in
Monitor:
Monitor
i
reports
o
e
the
i
protocol
o
violation
q
and
r
e
identifies
i
all
o
q
j
the
r
e
transactions.
i
Monitors
o
are
q
two types,
z
Passive
u
y
and
e
o
active.
z
x
Passive monitors do not drive any signals. Active monitors can drive the DUT signals. Sometimes this is also refered as receiver. Monitor converts the state of the design and its outputs to a transaction abstraction level so it can be stored in a 'score-boards' database to be checked later on. Monitor converts the pin level activities in to high level.
(Q
i
29)
o
e
What
i
type
o
of
q
data
r
e
structure
i
is
o
q
j
used
r
e
to
i
implement
o
stimulus
q
storage?
Ans:
1)
i
In
o
e
SV,
i
Queue
o
is
q
best
r
e
to
i
do.
o
q
j
2)
i
In
o
e
vera
i
,
o
linked
q
list
r
e
is
i
the
o
q
j
best
r
e
one
i
to
o
use.
3)
i
Data
o
e
can
i
also
o
be
q
stored
r
e
in
i
external
o
q
j
files
r
e
also
i
using
o
fileIO
q
or external
z
language
u
y
interface.
www.testbench.in
I
i
like
o
e
point
i
3.
o
The
q
external
r
e
file
i
will
o
q
j
be
r
e
availabe
i
after
o
simulation.
q
So ,
z
this
u
y
file
e
o
could
z
x
be used for debugging.
(Q
i
30)
o
e
How
i
registers(configuration
o
registers)
q
are
r
e
verified?
Ans:
In
i
VMM,
o
e
read
i
about
o
RAL.
Read
i
this
o
e
topic
i
also:
Click on the below link
http://www.testbench.in/TB_32_REGISTER_VERIFICATION.html
(Q
i
31)
o
e
What
i
is
o
BFM?
.....w.....w......w......t.....e.....s.....t......b.....e.....n.....c.....h......i.....n
(Q
i
32)
o
e
What
i
is
o
shadow
q
register?
www.testbench.in
Ans:
Analogous
i
structure
o
e
of
i
o
DUT
q
configuration,
r
e
status,
i
interrupt
o
q
j
registers
r
e
are
i
implemented
o
in
q
testbench. These
z
are
u
y
called
e
o
shadow
z
x
registers.
These
i
are
o
e
required
i
for
o
register
q
verification.
r
e
In
i
normal
o
q
j
verification,
r
e
i
Testbench
o
requires
q
the DUT
z
u
y
register
e
o
information
z
x
for taking decisions.
(Q
i
33)
o
e
Explain
i
about
o
the
q
back
r
e
door
i
access
o
q
j
to
r
e
registers.
Ans:
DUT
i
Configuration,
o
e
status
i
and
o
interrupt
q
register
r
e
can
i
be
o
q
j
accessed
r
e
as
i
per
o
the
q
protocol.
To
i
access
o
e
these
i
registers
o
using
q
the
r
e
protocol
i
will
o
q
j
consume
r
e
cycles.
i
Generally
i
,
o
e
only
i
once
o
register
q
is
r
e
allowed
i
to
o
q
j
access
r
e
as
i
per
o
protocol.
www.testbench.in
To
i
over
o
e
the
i
above
o
mentioned
q
disadvantage,
r
e
i
hierarchal
o
q
j
path
r
e
can
i
be
o
used.
q
This is
z
called
u
y
backdoor
e
o
access.
While
i
verifying
o
e
the
i
registers,
o
a
q
write
r
e
operation
i
is
o
q
j
done
r
e
to
i
a
o
location
q
and then
z
a
u
y
read
e
o
is
z
x
done. Then the written data is compared against the read data to verify the access path.
But
i
what
o
e
if
i
the
o
address
q
decoder
r
e
and
i
encoder
o
q
j
has
r
e
the
i
same
o
bug
q
? To
z
find
u
y
out
e
o
this,
z
x
write operation is done as per the protocol and read is done using backdoor. Then the written data is compared against the read data to verify the access path.
(Q
i
34)
o
e
What
i
are
o
Reference
q
and
r
e
behavioral
i
models
o
q
j
?
Ans:
.....w.....w......w......t.....e.....s.....t......b.....e.....n.....c.....h......i.....n
The
i
term
o
e
'Reference
i
Model'
o
defines
q
what
r
e
it's
i
used
o
q
j
for,
r
e
whereas
i
'Behavioral
o
Model'
q
defines how
z
it's
u
y
been
e
o
implemented.
z
x
(Q
i
35)
o
e
What
i
is
o
the
q
use
r
e
of
i
linting
o
q
j
tool
r
e
?
Ans:
www.testbench.in
Linting
i
tools
o
e
are
i
the
o
tools
q
that
r
e
flag
i
suspicious
o
q
j
language
r
e
usage
i
and
o
error-prone
q
syntactical constructs.
z
Linting
u
y
tools
e
o
generally
z
x
perform static analysis of source code. Linting tools can help programmer find dangerous code before a compiler turns them into run-time bugs.
Sone
i
linting
o
e
tools:
i
Leda,
o
HDLint,
q
nLint,
r
e
Surelite
i
etc
(Q
i
36)
o
e
What
i
are
o
the
q
key
r
e
tools
i
for
o
q
j
functional
r
e
verification?
Ans:
Version
i
control
o
e
system
,
make
i
utility
,
o
scripting
q
languages
,
r
e
bug
i
tracker
,
o
q
j
Simulator
r
e
,
debugger
.
(Q
i
37)
o
e
i
What
o
does
q
Test
r
e
Automation
i
mean?
Ans:
Building
i
an
o
e
environment
i
that
o
tests
q
the
r
e
DUT
i
automatically
o
q
j
Instead
r
e
of
i
checking
o
the
q
DUT by
z
eye,
u
y
get
e
o
computers
z
x
to do the work for us.
www.testbench.in
(Q
i
38)
o
e
How
i
to
o
assure
q
your
r
e
verification
i
environment
o
q
j
is
r
e
correct/complete
i
?
Ans:
Im
i
not
o
e
sure.
i
If
o
u
q
know
r
e
send
i
me
o
q
j
answer
r
e
to
i
gopi@testbench.in
What
i
I
o
e
can
i
think
o
are:
.....w.....w......w......t.....e.....s.....t......b.....e.....n.....c.....h......i.....n
1)Connect
i
monitor
o
e
to
i
driver
o
such
q
that
r
e
driver
i
cycles
o
q
j
are
r
e
monitored
i
by
o
monitor.
q
Inject
z
error
u
y
from
e
o
driver
z
x
and check whether monitor an catch the error.
2)If
i
you
o
e
have
i
o
RTL,
q
then
r
e
change
i
some
o
q
j
lines
r
e
of
i
RTL
o
code
q
and see
z
whether
u
y
testbench
e
o
can
z
x
catch the errors.
(Q
i
39)
o
e
Who
i
should
o
do
q
the
r
e
rtl
i
debug
o
q
j
?
r
e
The
i
designer
o
?
q
The VE
z
?
Ans:
www.testbench.in
RTL
i
can
o
e
be
i
debugged
o
by
q
designer
r
e
or
i
verification
o
q
j
engineer.
r
e
I
i
personally
o
feel
q
that Verification
z
should
u
y
debug
e
o
RTL
z
x
issues.
Designer
i
can
o
e
debug
i
the
o
rtl
q
faster
r
e
than
i
Verification
o
q
j
engineer
r
e
as
i
the
o
designer
q
has more
z
knowledge
u
y
on
e
o
the
z
x
RTL architecture.
More
i
time
o
e
is
i
required
o
by
q
verification
r
e
engineer
i
to
o
q
j
debug.
If
i
Verification
o
e
engineer
i
is
o
debugging,
q
he
r
e
gets
i
chance
o
q
j
to
r
e
think
i
about
o
more
q
scenarios to
z
verify
u
y
the
e
o
RTL
z
x
by looking at RTL architecture.
Index
Functional Verification Questions
Functional Verification Questions 2
Test Your Systemverilog Skills 1
Test Your Systemverilog Skills 2
Test Your Systemverilog Skills 3
Test Your Systemverilog Skills 4
Test Your Sva Skills
Test Your Verilog Skills 1
Test Your Verilog Skills 2
Test Your Verilog Skills 3
Test Your Verilog Skills 4
Test Your Verilog Skills 5
Test Your Verilog Skills 6
Test Your Verilog Skills 7
Test Your Verilog Skills 8
Test Your Verilog Skills 9
Test Your Verilog Skills 10
Test Your Verilog Skills 11
Test Your Verilog Skills 12
Test Your Verilog Skills 13
Test Your Verilog Skills 14
Test Your Verilog Skills 15
Test Your Verilog Skills 16
Test Your Verilog Skills 17
Test Your Specman Skills 1
Test Your Specman Skills 2
Test Your Specman Skills 3
Test Your Specman Skills 4
Test Your Sta Skills 1
Test Your Sta Skills 2
Test Your Sta Skills 3
Test Your Sta Skills 4
Test Your Sta Skills 5
Test Your Sta Skills 6
Test Your Sta Skills 7
Test Your Dft Skills 1
Test Your Dft Skills 2
Test Your Dft Skills 3
Test Your Dft Skills 4
Test Your Uvm Ovm Skills
Report a Bug or Comment on This section
- Your input is what keeps Testbench.in improving with time!