Transcripts
1. Introduction: Hello, everyone. Welcome to the System Vlog UVM
interview question series. Today I'll be discussing about the common interview questions that students and professionals face when they attend digital verification VLSI
interviews. So let us begin. Before we start the course, let us look at some of
the course requirements. You need to have
a basic knowledge of digital verification. So system Verilog and UVM
knowledge would be helpful. If you're still a fresher and looking to get
into the industry, I would suggest you to take
my system Rog UVM step by step course before starting
with the interview series. Coming to the course structure, I'm covering a broad range
of interview questions, not only on system
log UVM but also on digital verification and some of the bus protocol questions that are commonly
asked in an interview. If you're following
my LinkedIn profile, I have been regularly publishing a daily interview
question series to help cover a broad
range of concepts. The course objective
here is to help students currently
having basic skills in UVM system Verilog or digital verification to ramp
up quickly for an interview. Let us not waste any time and begin the learning
journey. Thank you.
2. System verilog UVM Phase : Hello. Welcome back to the system log UVM
interview question. This is the P one of the
series. Let's get started. Coming to the first question of the series and one of the common questions that
is asked in the interviews. Why is facing used? What are the different
faces in UVM? So you should know that every component in UVM goes
through a facing mechanism. There are three main phases
that are executed the build, connect, and the run phase. The facing is used to
basically control the behavior of this simulation
in a systematic way. The next slide
explains in detail on how the facing
mechanism works. As we discussed in
the last slide, each UVM component goes through
the phase implementation. In this slide, we will try to understand what a UVM phase is. Once the run method is called, the UVM root component triggers and initiates
the UVM phasing forces. The build phase
executes in time zero. This basically builds all
the testbench components. The next phase is
the connect phase where all the testbench components are
connected together, it makes all the
TLM connections, assigns all the handles to
the test bench sources. Then we come to the run phase. The run phase is where
the stimulus gets generated and simulation
time advances. The build phase build and connect phase basically
runs in time zero. The run phase is
again subdivided into different smaller phases in the new UVM implementation. We will not go to this, but it is basically different implementation
on the pre reset phase, configure phase, pre
main phase main phase, and post main phase. Then we come to some
of the cleanup phases. The cleanup phase is used to extract results from
the scoreboard, check whether the test case passes or fails based
on some conditions. This may be, for example,
if all packets sent from an ethernet master or received
on an ethernet slave. Coming to the second question and another common
question that is asked, what is an active agent
and a passive agent? This is described in
detail in the next slide. Before we understand the
syntax of a UVM agent, we will try to understand
what are its components. If you see the diagram here, you basically have a
sequencer which produces data the sequencer is connected to a driver
through a special TLM port. The driver basically
gets the data and transfers the data
into pin level activity. The sequence or
driver interaction is at a transaction level and the driver breaks
the transaction into pin level activity
onto your design. How is the data
sent to your design through the virtual interface? And then there is
the monitoring part. You monitor keeps checking on your interface to basically
receive the data. You're converting your
pin level activity again back to a transaction. You're monitoring on your design for any new transactions. Once the transaction
is received, it is basically written written
through an analysis part onto the product scoreboard
or to any other TLM port, which is connected
to this monitor. The agent also has other
important information like the active passive and has
checks and has coverage. The active passive basically
tells whether the agent is being used to drive data
or only used to monitor. If it's an active agent, you will have the sequence or driver present in the agent. If it's a passive agent,
you will only have the monitoring
part of the agent. The agent also has methods
to basically disable checks. So you can disable
checks in your monitor or you can disable
coverage in your monitor. All this has to be reusab
coded in your agent. So what is the difference
between new and create? Nu is one of the
native constructs that existed even before UVM
came into existence. This was a part of the
system log language and is not UVM specific. When you create an
object using Nu, the object never gets
registered onto the factory. Object object is never
registered onto the factory, it cannot be overridden. In the next slide, I will
discuss a bit more on how factories is used to override component behavior
and type behavior. So in the last slide we
discussed about the UVM phasing. In this slide, we are going
to discuss another concept of UVM and what constitutes
UM. That is the factory. The factory basically is
used in the build phase. So factory has two different
types of override options. So you can override
any component in your environment using a
type or using an instance. If you see the example here, you have an APB master
driver that is being used. When you basically use
this in your test pens, the APB usar driver gets replaced by APB
new master driver. So all the components
which are using the APB master driver type gets changed to the APB
master driver type. This is really helpful in
developing reusable agents. Coming to question four, what is objection mechanism and how
to finish a testing UVM? In traditional test pinches, we use dollar finish after required step reset configure and all the data
transfers are complete. However, in UVM, a new
mechanism is used. This is called
objection mechanism. Basically, what does
objection mechanism do? We saw that in one of
the previous slides, each component in UVM goes
through a fixing mechanism. So every component also has an ability or every phase has an ability to
raise an objection. Assume there are
ten components in your UM peng each component during it run phase will
raise an objection, saying I'm starting a task and only stop the simulation after I complete a
particular task. Only when all the
ten components in your UVM says I have
completed my task, the simulation will
come to an end. So this is a way for
UVM to synchronize the verification activity
and to stop detest. Coming to the next
question, and this is a protocol question
that is commonly asked. What is the difference between an APB and an EHB protocol? APB protocol is used for connecting low
bandwidth peripherals. While AHB is used for connecting higher
bandwidth peripherals. APP is a non pipeline protocol and AHB has some
pipelining in place. APB is mainly proposed for
connecting simple peripherals. It is shown in the next slide. As shown in the slide here, you have an M processor and
you have a common AHB bus. You have these higher bandwidth
requirement peripherals connected onto the EHP bus. You have the on chepAm, the DMA, and the high bandwidth
external interface connected on the AHB. These require higher bandwidth
and these are on AHB. Then there are these
peripherals like UAT timer, keypad, PIO, which are low
bandwidth peripherals, and they do not require any
pipelining requirement. They are on a bridge, which converts an AHB
protocol to an APB protocol.
3. System verilog UVM factory: Hello. Welcome back
to the Part two of the system log interview
questions. Let us begin. Let's start the Part two of the CDs with a
protocol question. What is the difference between
ITC and an SPI protocol? ITC uses two pins, SDA and SCL, while SPI uses at
least three pins, the master out slave in, master in slave out, and SK. In terms of clocking, I two
C uses few standard clocks, 100 kilohertz, 400
kilohertz, et cetera. SPA on hand, can be used
anywhere below 10 megahertz. In terms of application, I two C is cheaper to
implement than SPI. We will see in detail in the next slide on the
basic differences. As seen in the
cajunction diagram here, you have a master device
and a slave device. The master needs to talk to the slave. How does this happen? You have a same clocking line
between I two C and SPA. Here it is called ACL and
here also it's called ACL. The clock is connected between the master and the slave device. The data in SPA is half
duplex communication. That means the master
and slave cannot talk to each other
at the same time. But in SPI point of view, you have a master device
clocking the slave device. You have separate chip
selex going to the slave. The slaves one will
have a chip select one and slave two will
have a chip select two. When the master sends
a frame on the Ms pin, the slave responds
on the meso pin. In the same frame, you can have the slave respond
to the master commands. SPI is faster in terms of speed. But in terms of hardware, it requires four wires and it is a bit costly to implement. Okay. Coming to question seven, this is a system log question. What are the different styles of fork can join in system log? There are three styles
of fork and join. Firstly, to understand for
can join, what does it do? This is basically used to spawn multiple threads when running
system log test bench. You will see how these
different flavors interact with each other
in the next slide. So these are the
three fork and join flavors that I discovered
in the last slide. You have the fork and join. Basically, this completes only when both of these
threads are complete. Here, what is the execution when the fork can
join of this happens, both A and B are displayed. Then you have work
and join N. This completes when any one
of D threads complete. Here, it displays A and it exits out of this fork and the
B is never displayed, and then it continues with
the next set of instruction. Then you have the
fork and join none. So what happens is
it will parallel for thread A and thread B. And after five
simulation cycles, A is printed and after
simulation cycle, ten simulation
cycles, B is printed. And after this
statement, assume if you had another display C here, the display C will
also be printed after five simulation cycles, so it will not wait for
completion of any thread. So these are the three
different variants of fork and join. Question eight. This is a UVM question and a common concept that
is used when using UVM. What is factory UVM? Why is it needed and what
is factory override? So the purpose of factory
in UVM is to change the behavior of a test bench
without any change in code. The factory is basically
like a lookup table. When you create objects, you basically register these
objects with a factory. See the syntax here, you have two agents
which are created. And when you use
the create method, you're creating the agent one and Agent two and registering
them with the factory. And then when you
want to overwrite these agents with a new agents, this is possible in UVM as
shown in the next slide. In the last slide, we
saw type O ride works. In this slide, we are
going to see how the instance Ort for
a factory works. Here you have a monitor that you want to replace
with a new type, but you don't want to replace all the components which are derived from APB master monitor. But you only want to replace a specific instance
of the monitor. You basically go down the text pench
hierarchy and you say, I want to replace
the apbt monitor, which is of the type
APB master monitor with a new type that is the
APB new master monitor. So when this gets executed
in the build phase, the testbench component
the architecture of the testbench changes with the PB monitor changes to
the APB new master monitor. Okay. Coming to question nine. This is again a protocol
question on the Amba protocol. What are the difference between
the AHP and AXI protocol? I think in one of the
previous lectures, we saw the difference between
AHB and an APB protocol. AHB is basically an advanced
high performance bus. But these are used
for connecting components that need higher
bandwidth on a shared bus. But if you look at AXI, it is useful for higher bandwidth and low
latency interconnects. This overcomes the limitation
of a shared bus protocol. AXI is basically an
enhancement from AHP. It supports multiple
outstanding data transfers, bus data types, and separate
read and write parts. We will see in detail
in the next slide. What you see in this slide is basically the Amba evolution. As the chips got complex, there was a requirement
for higher bandwidth and hence came the requirement
for new protocols. If you see 1995, there was only an APB protocol. But with rising complexity and higher bandwidth
requirement, they had to come up
with a AHB protocol. Then the AXI was an improvement in terms of
bandwidth requirement for an AHB then this was increased with the
AXI four and D CHI. The kind of architecture
you use depends on the products that you're making. So here we see AOC with
an ax interconnect. Here you can have
multiple masters connected onto the interconnect, and you can have
multiple slaves. You have an axe to APB bridge, like how we saw the
AHB to APB bridge. The course here can talk to different slaves and
it can basically have multiple outstanding requests
from the CPU core to the memory and CPU core onto
the external bus interface. So this kind of an
architecture supports higher bandwidth and low
latency requirements that is needed for
a system today. Coming to question ten. Explain transaction
level modeling in UVM. Transaction level
models represent components as a set of
communication process. You're basically abstracting
the different components and then using this higher
level of abstraction to send a transaction between
a producer and a consumer. If you take a design, you're probably wiggling
the ports at a dt level. But when you want
to send something from a component at a
UVM architecture level, you will probably send it
at a transaction level. This is very relevant when you think of a sequencer
and a driver. The sequencer and
driver are connected at a transaction level and the sequencer send a
transaction to a driver, the driver consumes this
transaction and then sends this data
onto your design. The same with the monitor and
the scoreboard interaction. The monitor basically captures the data that is coming from your design and sends this data for some
checks in a scoreboard. Transaction level modeling
is basically used to achieve this higher
abstraction. Thank you.
4. System verilog UVM sequence: We'll come back to the system UVM interview
question series. This is the part three of the
series. Let's get started. Question 11, what is the difference between
UART and SPI protocol? As you might know,
UART stands for universal asynchronous
receive and transmit. As you see in the name, it's
asynchronous in nature. That is, there is no clock there is no clock shared between the master
and the slave. In simple terms, you relies
on board rate agreement. You tell you basically need to have an agreement
between the master and slave on what bot rate the communication is
going to take place in. SPI, on the other hand, has a master clock which sets the clock rate
for the slave. We will discuss in detail in the next slide on
the differences. So in this slide, I have taken three serial
communication protocols and try to explain them and
the difference between them. The ITC, as you see, is a two line protocol. It is very cheap to maintain and it has a
clock and data line. The master drives the data
on a particular clock and the slave kind of agrees on this clock
and decodes the data. SPI on another hand is a serial protocol where
you have the clock, which is being driven
to all the slaves. A slave is selected based
on the chip select. If you want to
select device one, the master will pull the chip
select low for device one. The UAT on another hand, has an RX and TX
pin connected here. There is no clocking between
the master and the slave, and this is only based
on the agreement of bod rate between the master and the slave that the
transmission takes place. There's a start off frame which is usually a falling edge. When the falling edge occurs on TXin there is a botate calculation
and based on the bot rate, the frame is sampled. Question 12, how can sequence get exclusive
access to sequencer? What is the difference
between grab and lock? Basically, when you
have multiple sequences that are run on a sequencer, the sequencer arbrts
the grant access to each sequence on the
sequence item boundary. Sometimes a sequence might want exclusive access
to a sequencer, which can be performed
using a grab and lock. The basic difference
between a grab and lock is the grab on the sequencer is called it takes
immediate effect and the sequence will grab the
next sequencer arbitration. However, a lock sequence will wait until the sequence gets
its next available slot. The grab can be used for some of the sequences like the
interrupt sequence. Basically, when there
is an interrupt raised, you have to service the
interrupt service routine. You will probably
immediately grant access to the sequencer rather than waiting for every
sequence to complete. So here is an implementation of a sequence where a lock is used. Here you're locking
the child sequencer, saying I need exclusive access for this particular sequencer. If Sequence one wants
to send a transaction, it has to wait till all
the lock is unlocked. So if there are multiple
sequences locking the sequencer, they'll be arbitrated
and they will get access as per the request. But if you send a grab
request from this sequence, the request directly goes at
the top of the stack and it is granted once ongoing
sequence is complete. Okay. The next two questions are related to the gate
level simulation questions. Usually in an interview,
from my past experience, there have always
been gate level simulation questions if you are attending digital
verification interview. The question 13 is what is gate level simulation
and why is it necessary? Gate level simulation is used to boost the confidence
of the implementation. Basically, it is used as a
sign off for your design. Get level is very much important because the critical
timing parts of asynchronous design
are skipped by STA. These has to be caught in GLS. The constraints that is used in STA also needs to be verified. These are cross verified
against the GLS. If there is any black boxes
in your equivalence check, this cannot be caught
in any other way, so a GLS becomes necessary. If there are unintended initial
conditions, you need GLS. For switching activity
and power estimation, also sometimes GLS is used. I'll explain in detail in the next slide on the
flow that is used. So this is a typical
design flow. Let's try to
understand where gate level simulation
comes into picture. You have a higher
level RTL design. You basically do a
functional simulation to verify that your register
level abstraction is clean. Then this register abstraction goes through the synthesis flow. During synthesis, you
have constraints that are provided to your design. Once this synthesis is through, you get a gate level net list. The gate level next net list is also called a
synthesized Net list. Here you run zero delay or
unit delay simulation to check whether whether the intention matches with the actual design. Then in the flow, you basically take it
through the place and route and you get something
called an extracted net list. Here in the extracted Net list, you also get something
called SDF file, which is basically annotating
the delays of your nets. This is more of a
real time simulation, and this is used to check all the conditions
that I explained in the previous slide. For a GLS flow, you need
a gate level netlist, a library cell information, and the delay information. These are all provided
from the Ben team. You run the GLS. If GLS passes, that is a sign off
for your product. If GLS fails, there might
be genuine timing issues, which needs to be reported
to your backend team. They will generate a new
Netlist and SDF and you go through the flow till
all the timing is clean. But there are a few
challenges that are associated with running
a GLS simulation. Let us see what are
these challenges. Firstly, GLS is very slow. For Net li simulation
with timing check, you need to remove all
the synchronizers. Basically, the first flop of a synchronizer will
always be metastable. You need to disable timing for
this using a T check file. You also need to come up with an optimal list of
tests to ensure that your GLS is covering
most of your design. The engineers tend to get easily lost during ex
propagation debug. Also, as I mentioned, there is a constant
change with Net list and each Netlist release may need a lot of rework in terms
of force and other changes. GLS in itself is a very painstaking process
in the verification. But it's a necessary evil. This brings us to the
end of the first part of the system log
interview questions. Thank you for your time.
VLSI Interview questions, Teacher
