1) What are Assertions?

Ans: assertions are nothing but the checkers that are used to validate and check the
protocol violations of the design.
Sometimes the bug is at the output of the design or sometimes the bug is inside the
design,
Sometimes the bug is inside the design, but the bug is not propagated to the output, at
that time it is very difficult for us to find out the bug as there is no access to the design
for us, that’s where assertions comes into picture.
Assertions helps us in checking the bugs at the source or near the source of a problem.

If we consider a particular design as a Verification engineer, we do not have the

access to the design we can have access only to the input and output signals, but with
the help of assertions we can have the visibility to the white box that is visibility into
the design.
With the help of assertions we can easily trace the cause of the bug.

Advantages of assertions are:

We can debug the bugs sooner, so that we can save the time and reduce the cost.
We can achieve the complete coverage little faster.
Reusability for future design by developing parameterized assertions.

2) Types of assertions?
Ans: there are two types of assertions they are:
1) Immediate
Immediate assertions we can write them only in procedural blocks like initial
blocks or always blocks, these are type of test expressions that are evaluated like
any other Verilog expressions within a procedural block.

Immediate assertions are simply explained as if-else only.

Example
always
begin
a: assert (a && b);
end

here we have written an assertion with a condition like above, assertion get successful
only when a and b both are equal to 1, the assertion will fail if a and b are not high at
the same time.

2) Concurrent
Concurrent assertions we can write them in procedural blocks, modules, an
interface or with in a program definition.
These can be used with both static or dynamic verification.
 Example
a: assert property (@(posedge clk) not (a && b));

here we have written an assertion with the condition above, assertion will be
successful only when a and b are not high at the posedge of the clk , the assertion will
fail if a and b are high at the posedge of the clk.

Note:- if we are using simply assert keyword that indicates it is immediate type of
assertions.
If we use property key word along with assert keyword it reflects concurrent
assertions.

3)coverage
Coverage is defined as the percentage of verification objectives have been met.
There are two types of coverages:
1)code coverage
For example if we have written a 100 lines of code in an RTL design here the code coverage
will help us to understand whether all the 100 lines of code have been executed during
runtime.
Code coverage will make sure that each peace of code is covered.
May be the code coverage is 100 percent It doesn’t mean that the design is bug free as code
coverage do not check for the functionality.
Code coverage measures how much of the code or path or expression has been executed.
Branch coverage, statement coverage, expression coverage these comes under code coverage.
Code coverage is simulator dependent.
2)functional coverage
Functional coverage helps us to measures the quality of design verification and how much of
the design specification has been exercised whether the scenarios, conditions have been
observed validated and tested.
Functional coverage is achieved by cover group, cover point, cross and bins.
It is generated based on user defined coverage model.
Example:
Class example;
logic clk;
logic [7:0] address;
logic [2:0] opcode;
logic valid;
Covergroup cg_group; // defines the cover group
c1: coverpoint opcode; // defines the cover point c1
val: coverpoint address; // defines the cover point valid

c1_X_val : cross c1, valid; ; // defines the cross points c1_X_valid

endgroup :
function new();
cg_group = new; // instance of covegroup
endfunction :new
endclass

4)difference between IP and SOC?

IP
Generally IP is a functionality that can be reused as a building blocks in different designs.
We can see more and more system functionality are getting integrated into single chips which
is nothing but SOC, many IP’s together acts as building blocks of an SOC design.
Coming to the verification plan of an IP we use random test cases for verifying at the sub
system only we could randomize the scenarios as much as possible and make the IPs stable
and finding the bugs and achieving the more coverage as the complexity of the IPs is less
compared to SOC.
IP is the single block.
Some of the IPs are BLUETOOTH, UART, SPI, AHB, AXI etc…
SOC
SOC is an IC that integrates all the standardized protocols and components into a single chip.
As the SOC have a lot system functionality it is reusable across several designs
Coming to the verification plan we use directed test cases coming to the SOC as it is very
complex to verify, so we initially take the IPs that are stable and pre-verified, so we use
directed test cases for verifying SOC.
SOC is the integrations of several IPs.
Some of the SOCs are Qualcomm snapdragon 845, 865, 888.