PROJECT SEMESTER FINAL REPORT

(Project Semester 5th January 16 5th July 16)

Undertaken at
N.X.P-Freescale
NOIDA SECTOR-16 , FILM CITY

on
MAKING TEST PATTERNS SELF CHECKING USING
ASSERTIONS

Submitted by
P.V.N KARTIK
101206101

Under the Guidance of

Brijendra Dobriyal

HEMDUTT JOSHI BRIJENDRA DOBRIYAL

Name of the Faculty Coordinator Project Lead

Designation

EIED
 TABLE OF CONTENT

Content

1. Certificate04

2. Declaration 05

3. Acknowledgement.05

4. Abstract 07

5. Company Profile...09

6. Introduction..11

a) Property Specification Language18

b) System Verilog Assertion Language...20

c) VAMS EQUIVALENT TOOL ..24

7. Goal Outlook...27

a) TEAM Profile...27

b) Job Role.27

c) Project Layout28

8. BASIC CONCEPT LEARNT DURING THE COURSE..30

a) Linux / Bash.30

b) MOS Transistor Characteristics ..32

c) Verilog AMS Language ...35

d) Simvision .38

e) Irun ..44

e) Property Specification Language..45

f) ) System Verilog Assertions 52

g) Equivalent VAMS model 57

7. Observation...62

a) Issues found with P.S.L.....62

b) Issues found with VAMS equivalent model.63

c) Regression.64

d) System Verilog.65

8. Future planning.65

9. References66
 CERTIFICATE

DATE:

PLACE: Freescale-N.X.P , noida.

This is to certify that P.V.N KARTIK, 1012060101, B.E. Thapar University and technology,
Patiala Final year student has done 6 month Training in the Freescale-N.X.P on the Project Work
Making Test Patterns Self Checking through assertions under the guidance of project lead
Brijendra Dobriyal towards the fulfilment of the award of B.E in Electronics and
Communication during the period January 5th to July 5th.

Regards,
 DECLARATION

I hereby declare that the Final Report (Jan March 2016) entitled Self checking test patterns
through assertions is the project work I carried out at Freescale Semiconductor, Noida as
requirements of six months project semester (Jan June 2016) for the award of degree of B.E.
Electronics and Communication, Thapar university (Deemed University), Patiala, under the
guidance of industry mentor Brijendra Dobriyal.

(Signature of student)
Name of Student- P.V.N Kartik
Roll No-101206101

Date: 30/5/2016

Certified that the above statement made by the student is correct to the best of our knowledge
and belief.
 ACKNOWLEDGEMENT

I would like to express my deepest appreciation to all those who provided me the possibility to
complete this report. A special gratitude I give to our final year project Lead, Mr.Brijendra
Dobriyal, whose contribution in stimulating suggestions and encouragement, helped me to
coordinate my project especially in writing this report.

Furthermore I would also like to acknowledge with much appreciation the crucial role of the
staff of Analog Mixed Signal Verification Team, who gave the permission to use all required
equipment and the necessary materials to complete the task Self checking test patterns through
assertions.
A special thanks goes to my team mate, Nikhil Salwan, who help me integrate the tool woth the
NPI flow. Last but not least, many thanks go to the head of the project, Shubhra Singh whose
have invested her full effort in guiding the team in achieving the goal.

 ABSTRACT

The industry trend appears to be moving towards designs that integrate large digital circuits with
multiple analog/RF (radio frequency) interfaces. In the verification of these large integrated
circuits, the number of nets that need to monitored has been growing rapidly. Consequently the
mixed-signal design community has been feeling the need for AMS (Analog and Mixed Signal)
assertions that can automatically monitor conformance with expected time-domain behavior and
can help in debugging deviations from the design intent. The main challenges in providing this
support are (a) developing AMS assertion languages or AMS verification libraries, and (b)
instru- menting existing commercial simulators to support assertion verification during
simulation. In this paper, we report two approaches - the first extends the Open Verification
Library (OVL) to the AMS domain by integrating a new collection of AMS verification libraries,
while the second extends SystemVerilog Assertions (SVA) by augmenting analog predicates into
SVA. We demon- strate the use of AMS-OVL on the Cadence Virtuoso environment while
emphasizing that our libraries can work in any environment that supports Verilog and Verilog-A.
We also report the development of tool support for AMS-SVA using a combination of Cadence
NCSIM and Synopsys VCS. We demonstrate the utility of both approaches on the verification of
LP3918 - an integrated power management unit (PMU) from National Semiconductors. We
believe that in the absence of existing EDA (Electronic Design Automation) tools for AMS
assertion verification, the proposed approaches of integrating our libraries and our tool sets with
existing commercial simulators will be of considerable and immediate practical value.

Assertions are created in the unified verification methodology whenever time-based design or
architecture information is captured. These assertions are then used throughout the verification
process to efficiently verify the design. The use of assertions improves the speed and efficiency
of verification by bug catching and by enhanced testbench checking. Assertions also facilitate re-
use and provide data that is useful in evaluating functional coverage.
 Author: _________________________________________

Certified by
____________________________________________________________
(Name & Signature) (Industrial Coordinator / mentor)

Certified by
____________________________________________________________
(Name & Signature) (Faculty Coordinator / mentor)

Accepted by Mr. Vinay

Arora__________________________________________
(Name & Signature) (Project Semester Coordinator, CSED)
 COMPANY PROFILE

Freescale was one of the first semiconductor companies in the world, having started as a division
of Motorola in Phoenix, Arizona in 1948 and then becoming autonomous by the divestiture of
the Semiconductor Products Sector of Motorola in 2004. In 1955, a Motorola transistor for car
radios was the worlds first commercial high-power transistor. It was also Motorolas first mass-
produced semiconductor device.
In the 1960s, one of the U.S. space program's goals was to land a man on the moon and return
him safely to Earth. In 1968, NASA began manned Apollo flights that led to the first lunar
landing in July 1969. The Apollo program was particularly significant for hundreds of employees
involved in designing, testing and producing its electronics. A division of Motorola, which
became Freescale Semiconductor, supplied thousands of semiconductor devices, ground-based
tracking and checkout equipment, and 12 on-board tracking and communications units. An "up-
data link" in the Apollo's command module received signals from Earth to relay to other on-
board systems. A transponder received and transmitted voice and television signals and scientific
data.
Also that year, Motorolas technologies were used to introduce the first two-way mobile
radio with a fully transistorized power supply and receiver for cars.
Motorola has continued its growth in the networking and communications sector in later years,
providing the tools behind the radio transponder that delivered the first words from the moon in
1969, and going on to develop the first prototype of the first analog mobile phone in 1973.
The companys first microprocessor (MC6800 8-bit) was introduced in 1974, and was used in
automotive, computing and video game applications.
Motorolas next generation 32-bit microprocessor, the MC68000, led the wave of technologies
that spurred the computing revolution in 1984, powering devices from companies such
as Apple, Commodore, Atari, Sun, and Hewlett-Packard.
In the 1990s, Motorolas technology was the driving force behind intelligent power switches
for anti-lock brake systems, one of the first microelectromechanical systems (MEMS) inertial
sensor for automotive airbags, and Motorolas MPC5200microprocessor
deployed telematic systems for General Motors OnStar systems.
Since then, Freescale has continued to provide the technology behind consumer, medical,
networking and automotive products from microprocessors for the worlds first tubing-free
wireless insulin pump, to and automotive microcontrollers for efficient engine design.
Freescales motion-sensing accelerometer powers the interactivity of the Guitar Hero video
games. The number one provider of eReader processors worldwide is Freescale. In 2009,
Freescale demonstrated the world's lowest startup voltage single inductor DC/DC converter for
use in solar and thermoelectric energy harvesting applications.
In 2011, the company launched the industrys first multimode wireless base station processor
family that scales from small to large cells integrating DSP and communications processor
technologies to realize a true "base station-on-chip". In addition, a recent ABI Research market
study report states that Freescale owns 60% share of the radio frequency (RF) semiconductor
device market.
Also in 2011, Freescale announced the company's first magnetometer for location tracking
in smart mobile devices.With the partnership of McLaren Electronic Systems, they helped
the NASCAR Sprint Cup Series vehicles convert from carburetors to fuel injection starting in
2012.
On March 8, 2014, Freescale announced that 20 of its employees were passengers
aboard Malaysia Airlines Flight 370. That plane, carrying the Freescale employees, is currently
missing.
In March 2015, a merger agreement was announced through which Freescale Semiconductor
would be acquired by NXP Semiconductors and that the companies will be merged in a $40
Billion US-dollar deal. The acquisition closed on December 7, 2015.
 INTRODUCTION

Assertion-based verification (ABV) is a powerful verification approach that has been proven to
help digital IC architects, designers, and verification engineers improve design quality and
reduce time to market. But ABV has rarely been applied to analog/mixed-signal verification.
This article looks at challenges in analog/mixed-signal verification, evaluates how the ABV
concept can address some of those challenges, and shows how languages such as Property
Specification Language (PSL) and SystemVerilog Assertions (SVA) can be used to write
complex analog/mixed-signal assertions.

Assertions, by definition, capture the intended behavior of a design. In verification terminology,

ABV can be positioned both as a white-box and a black-box approach in that the user can create
properties (or asserted behaviors) that can monitor the design deep within the hierarchy, reaching
the internals of the design blocks as well as the interfaces of the design blocks.

Assertions are written both during development of the design and the verification environment.
Both designers and verification engineers can consequently be involved in identifying
requirements and capturing them as assertions.

So where do mixed-signal assertions fit in?

As design complexity increases, the verification tasks around an analog/mixed-signal (AMS)
system become more and more difficult to plan and execute. Some of these fundamental
difficulties
are:

There is no consistent language or methodology across the complete spectrum of discrete

event-driven systems, mixed-signal systems, and continuous time-varying systems to
express the verification intent in the form of assertions.
Since no such standard methodology exists, how does information expressed by one
group of design or verification engineers in the AMS domain flow to another group, or
from one level of design abstraction to another?
In the absence of a standard language and methodology to apply verification to a mixed-
signal system in its entirety, how can a verification plan include testing AMS blocks that
were tested in isolation in the context of the complete system? This challenge includes
verifying aspects such as power sequences, current leakages, and noise figures from the
AMS blocks as part of a full-system verification.

The availability of formal property specification languages, with their well-defined set of
semantics, has benefited the digital design and verification communities for some time, and in
view of the challenges mentioned above, it is natural to attempt to apply the same or similar
concepts to the AMS design and verification domains as well. It is with this goal that we show
how the standard PSL and SVA languages can be used to extend assertion-based verification to
the AMS domains.

But don't we already have checks and measures in analog?

In the analog verification domain, the idea of developing a specification that drives the need for
defining assertions is not a common notion. Nevertheless, analog designers and verification
engineers do set custom characterization checks to specify the safe operating conditions for the
devices that comprise a circuit. In the Cadence Virtuoso Multi-Mode Simulation
environment, for example, this is done by adding a special assert device to the circuit and by
associating a checklimit analysis to verify if the device-level conditions specified by the user
have been satisfied during the course of a simulation that the checklimit analysis corresponds to.

While the application of the assert device along with checklimit analyses is useful to verify the
device-level characteristics, there is currently no way to set up and verify more complex circuit
conditions that AMS verification tasks encounter. Some of these challenging operations include
the ability to predicate assertions on some time-varying circuit characteristics, or the ability to
check temporal properties of a circuit at intervals determined by complex clocking conditions.

Moreover, the current use model of using assert and checklimit creates an isolated solution?the
methodology only applies to pure analog or mixed-signal applications, and it neither leverages
nor makes itself visible to the much broader digital verification methodologies that currently
exist.

In contrast, the digital verification system has a well-established use model for assertion-based
verification (ABV). This use model is based on standard assertion languages, such as PSL and
SVA, and methodologies that have evolved over time to satisfy verification needs in the discrete
domain. An optimal mixed-signal verification system will need to leverage the existing
principles of ABV and extend them to satisfy the requirements that cannot be met by currently
available verification tools.

Along the same line, PSL and SVA will need to expand to accommodate the needs of complex
AMS verification challenges. This approach has several long-term benefits:

By extending PSL and SVA to work with mixed-signal languages and semantics, the
AMS verification methodology will be able to leverage the existing rich features that are
standard in ABV, such as coverage, in a natural way.
There is a growing need for AMS verification to be visible to the overall system
verification environment. Toward this end, verification engineers responsible for the
overall system need visibility into the verification tasks specified and covered in the
AMS subsystem. By using a consistent language and use model from the pure digital to
mixed-signal representation, such visibility and information sharing would be natural.
Using PSL with Verilog-AMS
The following sections take a brief tour of the various standard features of PSL and show how
these features can support analog and mixed-signal (AMS) expressions. Examples shown in this
section use standard PSL code and standard Verilog-AMS, and should be usable in any simulator
that supports these languages.

PSL assertions involving analog expressions

For the purpose of this discussion, analog expressions refer to the combination of legal Verilog-
AMS operators and operands as defined by the Accellera Verilog-AMS Language Reference
Manual. Analog expressions can appear in PSL assertions in Boolean expressions, clocking
expressions, and as actual arguments in property and sequence instances when there is a single
top-level clock defined either explicitly or via a default clock.

electrical sig;
reg a, b, clk;
// top-level clock specified in the assertion
// psl assert always (V(sig) -> next(b)) @(posedge clk);
// the default clock is inferred as the top-level clock
// psl default clock = (posedge clk);
// psl property P1 = always {a;V(sig1)>0.5} |=> {V(sig2)<1.2;b}; // psl assert P1;

The example above shows how the Boolean expression of a PSL assertion or a property can
contain a legal Verilog-AMS expression. For example, referring to the property P1 above, an
assertion is being made here that if a is high in the current clock tick and the voltage of node sig1
is greater than 0.5 in the next clock, then wait for one clock cycle and make sure that the voltage
of node sig2 is less than 1.2V followed by b being true in the succeeding clock tick.

Analog events for assertion clocking

The Verilog-AMS analog event functions of cross and above are supported as clocking
events in PSL assertions.

electrical sig1, sig2, sig3; reg a, b;

// psl assert always ({V(sig1)>0.5;a} |=> {V(sig2)<1.2;b}) @(cross(V(sig3)));

The example above illustrates that the assertion will be evaluated when the voltage of node sig3
crosses zero in the positive direction within the default time and voltage tolerance, thereby
replacing a conventional discrete clock with an object belonging to the continuous domain.

Support for wreal in PSL

The wreal net type represents a real-valued physical connection between structural entities in the
Verilog-AMS language. Expressions involving wreal type objects that are explicitly declared can
appear in PSL assertions in Boolean expressions, clocking expressions, and as actual arguments
in property and sequence instances. The following example shows how expressions involving
wreal nets myreal1 and myreal2 can appear inside a PSL assertion:

wreal mywreal1, mywreal2;

reg clk;
// psl assert always ({mywreal1 > 4.4; mywreal2 < 6.6}) @(posedge clk);

Module bound verification units

A verification unit (vUnit) is a side file that is linked to the design file for simulation. A vUnit
can be used for analog PSL assertions. This is a very useful feature if the source text of the
design block should not or cannot be modified. Thus, the design file remains untouched and the
assertion code is provided in the vUnit file, as shown below.

vunit myvunit(test) {
//psl assert (V(sig1) > 1.4) @(cross(V(sig3)));
}

Note that vUnits are mainly used to store the assertion code. However, they are not limited to
assertions only. If additional behavioral code is needed for the assertions, like storing some
values in variable/registers, it can be added to the vUnit as well. Consider using this feature as it
makes the coding of assertions much easier in some cases.
As shown below, verification units can be used to add assertions to Verilog/Verilog-
AMS/SystemVerilog, or VHDL instances.

vunit myvunit(test) {
// psl property P1 = ({V(sig1)} -> next (V(sig2)) @(cross(V(sig3)));
//psl assert P1;
}

Support for PSL built-in functions

Analog expressions are allowed within the prev PSL built-in sampled value function. It is an
error to have analog expressions as arguments to built-in sampled value functions other than
prev.

// psl assert always ({V(sigout) > 0.5} |=> {prev(V(sigout)) > 0.4}) @(cross(V(sigout)));

Coverage analysis for PSL assertions

Assertions are an important part of the coverage-driven verification environment. Coverage
points indicate whether the stimulus was able to create the conditions necessary to test the
design's behavior. This information is critical to ensuring that the design has been sufficiently
tested. This is typically achieved by defining signals and expressions that are being asserted on
as coverage points and also by defining the assertions themselves as coverage monitors.

Similar applications of coverage are expected to occur when using assertions in a mixed-signal
context. In particular, an assert directive, when comprising mixed-signal expressions in the
Boolean layer, will take part in the coverage report and therefore will provide valuable insight
into whether the assertions are adequately checking all the analog conditions through which the
design is passing. Similarly, creating coverage points for the actual expressions that make up an
assertion provide valuable insight into whether the assertion itself needs to be refined to verify
the design properly.

Using SystemVerilog assertions in a mixed-signal design

The SystemVerilog language allows a real type to be passed directly through ports. This is a
convenient way to bring analog quantities to SystemVerilog, thereby allowing powerful
testbench constructs to be developed with these real numbers. The Cadence Incisive Enterprise
Simulator, for example, allows such real valued ports to be connected to nets belonging to the
continuous domain by automatically inserting real-to-electrical and electrical-to-real converter
elements.

SystemVerilog Assertions (SVA) is a legal subset of the SystemVerilog IEEE P1800-2009

standard. In this standard version, the presence of real data types is not allowed in the Boolean
expression layer (although there is a proposal to remove this restriction at the SV-AC technical
subcommittee of the IEEE P1800 Working Group). At present, support of real data types in the
Boolean expression layer of SVA is limited to vendor-specific implementations. The Incisive
Enterprise Simulator allows this and thereby enables users to bring the analog quantity of interest
(node voltage, terminal current, etc.) to the SystemVerilog testbench as real numbers and then
build powerful SVA constructs using these real numbers. An example follows.
module top;
var real r, xr, wr;
assign xr = 3.14;
ams_electrical_src e_s1(r);
// causes insertion of Electrical2Real
// connection module
ams_electrical_dst e_d1(xr);
// causes insertion of
// Real2Electrical connection module
ams_wreal_src w_s1(wr);
// Coercion of SystemVerilog real variable
// to wreal
endmodule

module ams_electrical_dst(e);
input e; electrical e;
initial #10 $display("%M: %f", V(e));
endmodule

module ams_electrical_src(e);
output e; electrical e;
analog V(e) <+ 5.0;
endmodule
module ams_wreal_src(w);
output w; wreal w;
assign w = 2.5;
endmodule

The example above is a simplified hierarchical design that shows how a wreal net (w inside
module ams_wreal_src) can set a real valued variable in a SystemVerilog testbench (top, in this
example). It also shows how an object of type var real in SystemVerilog (r and xr) can drive and
be driven by objects in the electrical domain (e in ams_electrical_src and e in ams_electrical_dst
respectively) with the help of Electrical2Real and Real2Electrical connection modules.

Once a SystemVerilog real variable imports the AMS functionality as shown above, it can
appear in any SystemVerilog assertion statement that permits the use of real variables. The
simple example below shows how this is done.

simple_SVA_example: assert property (@(posedge(hold)) ((xr-wr) <= 2.5));

Using value fetch to apply assertions to pure analog characteristics

Fetching values of continuous-domain objects into the discrete domain is a common practice that
testbench methodologies use to account for mixed-signal effects. Value fetch requires the ability
to transcend language boundaries across arbitrary levels of hierarchy through discrete and
continuous domain language layers.

Another requirement of value fetch operations is to be able to work from pure digital languages
that do not understand continuous-domain syntax or semantics. Such fetch operations usually
require a broad spectrum of quantities that may need to be queried such as potential, flow,
power, and operating point parameter values. Unfortunately, current mixed-signal languages do
not offer such features.

Simulators must therefore provide special features to support such value fetch operations. The
Cadence Virtuoso AMS Designer Simulator, for example, has introduced a new system function
called $cds_get_analog_value and several helper functions that go with it. The function is used
like this:

real x;
always @(...) x = $cds_get_analog_value("top.sub.end.foo", "potential");

The user provides the hierarchical string to the object to be accessed and defines a quantity
specifier (in this case potential to the voltage), and the return value is a real number that
represents the analog voltage at the moment where the function is triggered.

The syntax of the cds_get_analog_value function is the following:

real $cds_get_analog_value(hierarchical_name [, optional index[, optional quantity
qualifier]])where:
 The index can be variable, reg, or parameters so long as their value evaluates to an
integer constant
The quantity qualifier can be potential, flow, pwr, or param. If none is specified, potential
is assumed

The object referred to by hierarchical_name must exist and must be owned by the analog solver.
It must be a scalar or a vector, and if the latter, the index must be specified such that the result
resolves to a scalar. The hierarchical_name can be a relative or absolute path.

Note: It is possible to check whether the object referred to by hierarchical_name meets these
conditions by using the helper functions cds_analog_is_valid, cds_analog_exists, and
cds_analog_get_width. These helper functions enable the user to create reusable testbenches
where the representation of the model containing the object that the value fetch routine points to
can change from digital to analog or vice versa.

The value fetch routine can be called from within Verilog, SystemVerilog, or Verilog-AMS.
The fetch routine needs to reference an analog object. It can reference into any analog language
including Verilog-AMS, VHDL-AMS, Spectre, SPICE, or Verilog-A (compiled as Verilog-
AMS or included by ahdl_include).
 P.S.L (Property Specification Language)

PSL Assertions Overview

Assertions play an important role in a unified verification methodology. Assertions allow the architect or
designer to capture his or her design intent and assumptions in a manner that can be verified in the
implementation. Assertions are captured during the development process and are continually verified
throughout the process. Assertions, working in a unified verification methodology, reduce the
verification time by detecting bugs earlier, isolating where a bug is located, and even detecting internal
protocol violations that may not cause functional errors to propagate to the outputs. In addition to bug
detection, assertions improve the efficiency in a unified methodology by improving reuse, enhancing
testbench checking, and capturing coverage information. PSL assertions can allow the user to write
properties that reason about the temporal or time-based behavior in designs. They are thus highly
suited for use in sequential circuits of any form, and can be used to implement self-checking
testbenches, etc. These types of assertions are typically written to check circuit properties at the
design/block/inter block level, and less so at the individual device (transistor) level. They are used for
functional checking/debug, but can also be used for checking assumptions about the valid inputs to a
block, etc. PSL novices are also directed at the following extremely useful tutorial.

Introduction

PSL assertions express functional design intent in terms of time-based behavior. Assertions can
be used to express assumed input behavior, expected output behavior, or forbidden behavior. For
example, if a sample and hold circuit has a sample signal and a hold signal, a designer might
assume that the hold signal should always follow the sample signal after a certain minimum
period. With assertion-based verification (ABV) in a simulation environment, if during a
particular simulation run, there was ever a sampling period when the sample and hold signal
timing violated that simple sample and hold timing constraint, then the assertion would
immediately fire and report a message. This is an example of an interface assertion. Interface
assertions are used to check the protocol of interfaces between blocks. Other types of assertions
include architectural assertions and structural assertions. Application assertions are used to prove
architectural properties. For example, after a request for analog to digital conversion, eventually
the conversion done signal is asserted. Structural assertions are used to verify low-level
internal structures within an implementation, such as arithmetic sign preservation in analog
integrator blocks. For example, if the current input and output voltages of a switched capacitor
integrator are both negative, then the output voltage at the next sample time should also be
negative. This document provides an introduction to the PSL assertion language and to the PSL
- based implementation of ABV (Dynamic ABV) that is supported in the AMS Designer
simulator. PSL assertions (due to their digital pedigree) are time-based assertions used during
transient analysis. The benefits of using assertions are discussed, and a specific example of
interface assertions for a Sigma Delta modulator circuit is presented. The use models of the
AMSD PSL implementation of Assertion-Based Verification are also discussed, including how
you run a simulation with assertions; instruct the simulator when to evaluate them, how to debug
them, and how to turn them on and off.

The primary focus of AMD Designers implementation of PSL-assertion-based verification is to

identify bugs and design issues as close to the source as possible. This reduces the debug time,
especially after hierarchical integration of blocks when bugs take longer to propagate to the
output and are more difficult to isolate. Assertion checking during simulation can identify
internal errors within the design or block level sooner and closer to the source than is possible
without assertions. Without assertions, errors must propagate to the observed outputs before
being detected. Assertions reduce the time it takes to locate difficult errors by identifying where
in a design the error first appears. Assertions also catch errors that do not propagate to the output.
When an assertion fires, it provides an immediate localization of the failure, which simplifies the
insertion of intellectual property (IP) or other forms of block reuse into design environments.

Booleans PSL was originally designed to be used in conjunction with hardware description
languages (HDL) such as Verilog or VHDL. With AMS Designer, it is now used in conjunction
with Verilog-AMS. At the bottom level, the Verilog-AMS language is used to specify the
conditions that define a behavior of interest, referring to signals, variables, and values within a
netlisted description of a design. Those conditions are represented by Verilog-AMS expressions,
involving both analog and digital quantities, that can be interpreted as having Boolean values
(for example: relational expressions). Using the underlying Verilog-AMS for such expressions
ensures that the assertion language can cover the full range of behavior that can be described in
the Verilog-AMS language, and that there is no chance of semantic mismatch between the
simulators most native digital description of a behavior and the Verilog-AMS description of the
same behavior involving analog quantities. This also reduces the learning curve for being able to
 System Verilog Assertions Language

Assertion checking is a simple addition to your simulation-based verification methodology.

All you need to do is add monitors to your design. These monitors are called assertions. During
simulation, these monitors watch to see

If a specific condition occurs, or

If a specific sequence of events occurs

The monitors generate warnings or errors if required conditions or sequences fail, or if forbidden
conditions or sequences occur.

SVA Immediate Assertions

[ label ] assert boolean_expression [ action_block ] ;

Immediate assertions are executed like procedural code during simulation.

An immediate assertion tests an expression when the statement is executed in the

procedural code. If the expression is interpreted as true, the assertion passes. If the expression is
interpreted as false, the assertion fails.

By default, when an assertion fails, the simulator calls the $error severity task, which displays an
error message. No action is taken by default when an assertion passes. However, you can include
an action block ("SVA Action Blocks" ) in an immediate assertion to specify the action to take
on success, and to change the default behavior to take when the assertion fails.

The assert directive causes an immediate assertion to be checked during simulation. You place
this statement in the procedural code wherever you want the assertion to be checked.
The label becomes the name of the assertion.

The following examples define several styles of immediate assertions inside always blocks.
Comments in the code describe each style.
SVA Deferred Assertions
[ label :] directive #0(expression)[ action_block ] ;

A deferred assertion is used to suppress the errors that occur due to glitching activity
on combinational inputs to immediate assertions. A deferred immediate assertion is similar to
simple immediate assertion with the following key differences:

A #0 delay is specified after the assertion directive

Reporting is delayed rather than immediate

Action blocks can contain only a single subroutine call

Assertions can be used outside procedural blocks as a module_common_item

In a deferred assertion, a #0 delay control is specified after the directive to delay reporting. This
is followed by an expression and an action block. For example:

always@(clk)
begin
x=foo();
a1:assert#0(x>0)$display("a1 passed");
else $error("a1 failed as x=%d",x);
end

If the action block contains a pass or a fail statement, then each of the statements can contain
only one subroutine call, which can be a task, a task method, a void function, a void function
method, or a system task. In this case,begin-end statements cannot surround the pass or fail
statements as begin is not a subroutine call.
In an action block, a subroutine argument can be passed either by value or by reference as a ref
and a const ref. If an argument is passed by value, the expressions use the values of the
underlying variables when the deferred assertion expression was evaluated. However, if the
argument is passed by reference, expressions use the current values of the underlying variables in
the Reactive region. Further, it is not allowed to pass automatic or dynamic variables as actual to
a ref or a const ref formal.

Note: As a limitation in a subroutine call in an action block, saved values are not used
when actuals are out of scope or wires.

Reporting in a Deferred Assertion

In a deferred assertion, though the deferred assertion's expression is evaluated when the deferred
assertion statement is processed but the reporting or action blocks are scheduled in the Reactive
region in the current time step.

The action block subroutine call and the current values of its input arguments are placed in
a deferred assertion reporting queue with the currently executing process. When a deferred
assertion flush point is reached, the deferred assertion reporting queue is cleared and any pending
assertion reports are not executed. After a queue reaches the deferred assertion flush point, each
pending report that is in the Observed region of each simulation time step and has not been
flushed either matures or is confirmed for reporting. The associated subroutine call in the
pending report is executed in the Reactive region and finally, the report is cleared from the
specific deferred assertion report queue. Remember that any report that matures cannot be
flushed.

In case a deferred assertion expression is evaluated in the Observed region, the deferred assertion
matures immediately. For example:

wait (S.triggered);//Here, S is a sequence.

A1: assert #0 (expr);

In the given example, S.triggered stands true only in the Observed region. Therefore, the
deferred assertion A1 will hit only the Observed region and will definitely report.

Note: At times, code in the Reactive region may modify a signal and lead to another pass to the
Active region. In this case, the Active region may re-execute some of the deferred assertions
with different reported results and may lead to glitching behavior. Though deferred assertions
prevent glitches due to order of procedural execution but do not prevent glitches caused by
execution loops between regions due to the assignments from the Reactive region.

Deferred Assertion Flush Point

A deferred assertion flush point is reached when:

 A process that was earlier suspended resumes execution on reaching an event control or
wait statement.
A process that was declared by an always_comb or always_latch resumes execution due to
a transition on one of its dependent signals.
The outermost scope of the process is disabled by a disable statement. However, when you
disable a task or a non-outermost scope of a procedure any pending reports are not flushed.

Note: In IES, the flushing of deferred assertions in case the outermost scope of the process is
disabled by a disable statement is not supported and the results are reported.
 VAMS EQUIVALENT TOOL

Introduction

Assertions are formal properties that capture specic functional requirement of a design.
Assertions are a standard low-overhead verication technical in the digital domain. With
increased integration of analog and mixed signal (AMS) components in large scale designs,
Lancelot aims to bring the convenience of digital verication to the AMS domain. There major
changes Lancelot to cater to the AMS domain are:

1. Dense real-time and real-value semantics as opposed to clock ba

assertions in digital domain.

2. Latches to electrical nets directly unlike the sampled values in dig

assertions.

All statements in Lancelot are single line statements. The statements in Lancelot are of two
categories namely:

Aliases

Properties

. Alias statements

Alias statements are the means to access design signals in assertions. They are similar to bind
statements in SVA. The syntax for alias signals is given below.

@ a l i a s ? < a l i a s name> ~ <designs i g n a l >

Aliasing signals is the only way to use them in assertions. The aliases can be over-written in the
same property le(This will generate a warning message of severity:1) but to be used with
caution. The property will use an alias last found before its denition. Aliases currently cannot
used as macros or parameters to dene constants, they must refer to a design signals only.
However data-buses whether analog or digital can be addressed with aliases as follows.
@ a l i a s ? data_out ~ top . adc_out [ 0 : 1 2 ]

@ a l i a s ? d a t a _ o u t _ l s b ~ top . adc_out [ 0 ]

In the above example data_out refers to the entire bus and data_out_lsb refers to the LSB of
adc_out bus. At this stage Lancelot does not see a valid property yet. The signal can also have
the macro scope included in its declaration and it will lled out during the pre-processor stage
by the tool. Note that Lancelot does not yet know whether the signal belongs to analog or the
digital domain. This would be indicated by the boolean layer from the properties.

@ a l i a s ? < a l i a s name> ~ < s i g n a l >

@alias ? enable~ scope . ADC_inst . e n a b l e.

What if an alias is not declared but used in an assertion? Lancelot assumes that the designer is
referring to an internal signal in Lancelot module, issues a warning and allows read-access to it.
This is a very useful feature as this allows us to write many complicated assertions that are
otherwise not possible. The aliases that the user can make use of are the following:

1. Pass/fail triggers of propert

2. Local variables from other properties

3. Specic internal nets of lancelot depending on the properties. (Sub-

Parts of the properties are stored as signals for debug usage

prop_1 ? @+( a ) => ( b )

prop_2 ? @+( p r o p _ 1 _ f a i l ) , x : = b => ( c ) , $ p r i n t ( x )

In the above example prop_1 checks for signal b to be high when there is a pos-edge of a occurs.
The second property prop_2 checks for c to be high whenever prop_1 fails( a occurs but b is not
high). The addition of "_pass/fail" to the property name dictates the trigger to latch on to. Care
should be taken while naming a property with "_pass/fail" at the end as that might lead to wrong
trigger latching. If no property trigger with the name is found Lancelot assumes that the user is
referring to an internal net. This might lead to elaboration stage errors in the simulators, hence all
these features carry a severity:1 warning whenever they are used.

. Properties
This section explains the various keywords of AMS-LTL language followed by construction of
assertions. Every AMS-LTL assertion is a single line assertion. All Lancelot assertions start with
an assertion name and the denition is separated by a ?. Consequently SVA assertion links are
made with the names assert_<Assertion-Name>. The e-manager links can be attached to these
SVA assertions.
 BACKGROUND (GOAL OUTLOOK)

TOPIC: To write assertions according to the provided test case scenario in a typical
assertion tool and write auxiliary scripts to present data in a neat and clean fashion.

TEAM NAME: ANALOG MIXED SIGNAL VERIFICATION TEAM

TEAM PROFILE

Basic profile of the team includes checking the integration between the analog I.P and D.A.I.P
has been done at the Mosfet level or not.

This could be explained in the form of an example, which is lets say two IPs of a chip are
interacting then say A gives an output 1b1 whereas B receives that output and perform a related
action. Now from the behavioral aspect this may seem correct but as we go down there are
certain aspects we must carefully look upon. Say, in this particular case, if IP A and chip B have
different voltage specification chip A being from 0 to 3v whereas IP B varies from 0 to 5v .
Now what happens is that although the IP A is sending 1b1 but the voltage being produced is
maximum 3v whereas IP B is expecting 4.9V which is not the case. So this a bug because
behaviorally IPB must perform the required action but it wont simply because both the IP were
not of the same.

Finding bugs like these and may others in the integration parts is the Analog Signal Design work
profile.

JOB ROLE:

This can be explained with the help of logical statement, more the test case scenarios more the
probability of finding bugs in the design. If most of the bugs in the design are found, then we can
probably be finding a fix for it but there is a price to pay which is that if the number of test case
scenarios increase then proportionally the amount of checks being done manually will also
increase. This is troublesome, because it is quite possible that some of the bugs might go
unnoticed as a result.

So the question came better handover the task to a certain tool /software but how would it know
what to check, this is my job basically to supply the tool which the checks needed to performed.

PROJECT LAYOUT

1. Understand the work profile of the team

Goal : This would help me to understand what my does and how their work affects the
organization

2. Understand my role, why it is so important

Goal: To induce a greater sense of responsibility and seriousness towards my work.

3. Understand the basics of Linux, GVIM editor.

Goal: To be able to work efficiently with the environment.

4. Understand the basics of MOS transfer characteristics, MOS capacitance to be able to and
understand the basic IP fundamentals and test scenarios written.
Goal: Good understanding of MOS transistor characteristics is required because in this
way we would be able to understand what is happening in the test case scenario.

5. Understand how the Lancelot is integrated with the tool.

Goal: Before being able to write and implement assertions on a SOC level , we must be
able to integrate Lancelot with the tool.

6. Develop understanding syntax of Lancelot, P.S.L.

Goal: To gain proficiency in writing assertions.

7. Develop understanding syntax of bash shell scripting.

Goal: It is needed to be able develop scripts which allow the user to present data in an
orderly fashion.

8. Develop Assertions for K.F.A I.P PMC(Power Management Control)

9. Develop Assertions for KFA- PLL REG , VCO , XOSC.

10. Develop Assertions for KFA ADC

11. Develop Assertions for CALYPSO low power entry/exit mode.

 BASIC CONCEPTS LEARNT

LINUX

Basic Linux commands:

Introduction The purpose of this document is to provide the reader with a fast and simple
introduction to using the Linux command shell and some of its basic utilities. It is assumed that
the reader has zero or very limited exposure to the Linux command prompt. This document is
designed to accompany an instructor-led tutorial on this subject, and therefore some details have
been left out. Explanations, practical examples, and references to DOS commands are made,
where appropriate.

What is a command shell?

A program that interprets commands Allows a user to execute commands by typing them
manually at a terminal, or automatically in programs called shell scripts. A shell is not an
operating system. It is a way to interface with the operating system and run commands.

What is BASH?

BASH = Bourne Again SHell Bash is a shell written as a free replacement to the standard
Bourne Shell (/bin/sh) originally written by Steve Bourne for UNIX systems. It has all of the
features of the original Bourne Shell, plus additions that make it easier to program with and use
from the command line. Since it is Free Software, it has been adopted as the default shell on
most Linux systems.
BASIC SHELL COMMANDS

acroread - Read or print a PDF file.

cat - Send a file to the screen in one go. Useful for piping to other programs
cat file1 # list file1 to screen
cat file1 file2 file3 > outfile # add files together into outfile
cat *.txt > outfile # add all .txt files together
cat file1 file2 | grep fred # pipe files

cc - Compile a C program
cc test1.c # compile test1.c to a.out
cc -O2 -o test2.prog test2.c # compile test2.c to test2.prog

cd - Change current directory

cd # go to home directory
cd ~/papers # go to /home/user/papers
cd ~fred # go to /home/fred
cd dir # go to directory (relative)
cd /dir1/dir2/dir3... # go to directory (absolute)
cd - # go to last directory you were in

cp - Copy file(s)
cp file1 file2 # copy file1 to file2
cp file1 directory # copy file1 into directory
cp file1 file2 file3 ... directory # copy files into directory
cp -R dir1 dir2/ # copy dir1 into dir2 including subdirectries
cp -pR dir1 dir2/ # copy directory, preserving permissions

grep- Look for text in files. List out lines containing text (with filename if
more than one file examined).
grep "hi there" file1 file2 ... # look for 'hi there' in files
grep -i "hi there" filename # ignore capitals in search
cat filename | grep "hi there" # use pipe
grep -v "foo" filename # list lines that do not include f
 MOS Transistor Characteristics

Figure 61 shows the basic structure of a MOSFET. The two PN junctions are the source
and the drain that supplies the electrons or holes to the transistor and drains them away
respectively. The name field-effect transistor or FET refers to the fact that the gate turns
the transistor (inversion layer) on and off with an electric field through the oxide. A
transistor is a device that presents a high input resistance to the signal source, drawing
little input power, and a low resistance to the output circuit, capable of supplying a large
current to drive the circuit load. The hatched regions in Fig. 61a are the shallow-trench-
isolation oxide region. The silicon surfaces under the thick isolation oxide have very high
threshold voltages and prevent current flows between the N+ (and P+) diffusion regions
along inadvertent surface inversion paths in an IC chip. Figure 61 also shows the
MOSFET IV characteristics. Depending on the gate voltage, the MOSFET can be off
(conducting only a very small off-state leakage current, Ioff) or on (conducting a large
on-state current, Ion).

Saturation Region:
ID= un * Cox * W/L * ( Vgs-Vt) ^2 /2;

Linear Region:
ID=un* Cox * W/L * ( (Vgs-Vt)* Vds Vds^2 /2);

The general shape of the VTC in Fig. 5.4 is qualitatively similar to that of the ideal
inverter transfer characteristic shown in Fig. 5.2. There are, however, several significant
differences that deserve special attention. For very low input voltage levels, the output
voltage V is equal to the high value of VOH (output high voltage). In this case, the driver
nMOS transistor is in cut-off, and hence, does not conduct any current. Consequently, the
voltage drop across the load device is very small in magnitude, and the output voltage
level is high. As the input voltage V increases, the driver transistor starts conducting a
certain drain current, and the output voltage eventually starts to decrease. Notice that this
drop in the output voltage level does not occur abruptly, such as the vertical drop
assumed for the ideal inverter VTC, but rather gradually and with a finite slope. We
identify two critical voltage points on this curve, where the slope of the Vt(Vin)
characteristic becomes equal to -1, i.e., dV =- (5.2) dMi, The smaller input voltage value
satisfying this condition is called the input low voltage VILE and the larger input voltage
satisfying this condition is called the input high voltage VIH. Both of these voltages play
significant roles in determining the noise margins of the inverter circuit, as we will
discuss in the following sections. The physical justification for selecting these voltage
points will also be examined in the context of noise immunity. As the input voltage is
further increased, the output voltage continues to drop and reaches a value of VOL
(output low voltage) when the input voltage is equal to VOH.

Inverter threshold voltage Vt., which is considered as the transition voltage, is defined as
145 the point where V. = VO., on the VTC. Thus, a total of five critical voltages, VOL,
VOH' VIL' VIH, and Vth, characterize the DC input-output voltage behavior of the
inverter circuit. The MOS Inverters: functional definitions for the first four of these
critical voltages are given below. Static Characteristics VOH: Maximum output voltage
when the output level is logic " 1" VOL Minimum output voltage when the output level is
logic "0" VIL: Maximum input voltage which can be interpreted as logic "0" VIH:
Minimum input voltage which can be interpreted as logic " 1" These definitions
obviously imply that logic levels in digital circuits are not represented by quantized
voltage values, but rather by voltage ranges corresponding to these logic levels.
According to the definitions above, any input voltage level between the lowest available
voltage in the system (usually the ground potential) and V1L is interpreted as a logic "0"
input, while any input voltage level between the highest available voltage in the system
(usually the power supply voltage) and VIH is interpreted as a logic " 1 " input. Any
output voltage level between the lowest available voltage in the system and VOL is
interpreted as a logic "0" output, while any output voltage level between the highest
available voltage in the system and VOH is interpreted as a logic " 1 " output. These
voltage ranges are also shown on the inverter voltage transfer characteristic shown in Fig.
5.4. The ability of an inverter to interpret an input signal within a voltage range as either
a logic "0" or as a logic " 1 " allows digital circuits to operate with a certain tolerance to
external signal perturbations. This tolerance to variations in the signal level is especially
valuable in environments in which circuit noise can significantly corrupt the signals. Here
the circuit noise corresponds to unwanted signals that are coupled to some part of the
circuit from neighboring lines (usually interconnection lines) by capacitive or inductive
coupling, or from outside of the system. The result of this interference is that the signal
level at one end of an interconnection line may be significantly different from the signal
level at the other end.

To illustrate the effect of noise on the circuit reliability, we will consider the circuit
consisting of three cascaded inverters, as shown in Fig. 5.5. Assume that all inverters are
identical, and that the input voltage of the first inverter is equal to VOH, i.e., a logic " 1."
By definition, the output voltage of the first inverter will be equal to VOL' corresponding
to a logic "0" level. Now, this output signal is being transmitted to the next inverter input
via an interconnect, which could be a metal or polysilicon line connecting the two gates.
Since on-chip interconnects are generally prone to signal noise, the output signal of the
first inverter will be perturbed during transmission. Consequently, the voltage level at the
input of the second inverter will be either larger or smaller than VOL. If the input voltage
of the second inverter is smaller than VOL' this signal will be interpreted correctly as a
logic "0" input by the second inverter. On the other hand, if the input voltage becomes
larger than VIL as a result of noise, then it may not be interpreted correctly by the
inverter. Thus, we conclude that VIL is the maximum allowable voltage at the input of
the second inverter, which is low enough to ensure a logic "1" output. Now consider the
signal transmission from the output of the second inverter to the input of the third
inverter, assuming that the second inverter produces an output voltage level of VOH. As
in the previous case, this output signal will be perturbed because of noise interference,
and the voltage level at the input of the third inverter will be different from VOH. If the
input voltage of the third inverter is larger than VOW, this signal will be interpreted
correctly as a logic " 1 " input by the third inverter. If the voltage level drops below VIH
due to noise, however, the input cannot be interpreted as a logic "1." Consequently, VIH
is the minimum allowable voltage at the input of the third inverter which is high enough
to ensure a logic "0" output. These observations lead us to the definition of noise
tolerances for digital circuits, called noise margins and denoted by NM. The noise
immunity of the circuit increases with NM. Two noise margins will be defined: the noise
margin for low signal levels (NML) and the noise margin for high signal levels (NMH).
NML = VIL - VOL NMH = VOH -VIH (5.3) (5.4) Figure 5.6 shows a graphical
illustration of the noise margins. Here, the shaded areas indicate the valid regions of the
input and output voltages, and the noise margins are shown as the amount of variation in
the signal levels that can be allowed while the signal is transmitted from the output of one
gate to the input of the next gate. The selection of the two critical voltage points, VIL and
VIH, using the slope condition (5.2) can now be justified based on noise considerations.
We know that the output voltage V, of an inverter under noise-free, steady-state
conditions is a nonlinear function of the input voltage, Vi,. The shap
 VERILOG A.M.S

Verilog-AMS introduction 1.1 Overview This Verilog-AMS Hardware Description Language

(HDL) language reference manual defines a behavioral language for analog and mixed-signal
systems. Verilog-AMS HDL is derived from IEEE std 1364-2005 Verilog HDL. This document
is intended to cover the definition and semantics of Verilog-AMS HDL as proposed by
Accellera. Verilog-AMS HDL consists of the complete IEEE std 1364-2005 Verilog HDL
specification, an analog equivalent for describing analog systems (also referred to as Verilog-A
as described in Annex C), and extensions to both for specifying the full Verilog-AMS HDL.
Verilog-AMS HDL lets designers of analog and mixed-signal systems and integrated circuits
create and use modules which encapsulate high-level behavioral descriptions as well as structural
descriptions of systems and components. The behavior of each module can be described
mathematically in terms of its ports and external parameters applied to the module. The structure
of each component can be described in terms of interconnected sub-components. These
descriptions can be used in many disciplines such as electrical, mechanical, fluid dynamics, and
thermodynamics. For continuous systems, Verilog-AMS HDL is defined to be applicable to both
electrical and non-electrical systems description. It supports conservative and signal-flow
descriptions by using the concepts of nets, nodes, branches, and ports as terminology for these
descriptions. The solution of analog behaviors which obey the laws of conservation fall within
the generalized form of Kirchhoffs Potential and Flow Laws (KPL and KFL). Both of these are
defined in terms of the quantities (e.g., voltage and current) associated with the analog behaviors.
Verilog-AMS HDL can also be used to describe discrete (digital) systems (per IEEE std 1364-
2005 Verilog HDL) and mixed-signal systems using both discrete and continuous descriptions as
defined in this LRM. 1.2 Mixed-signal language features Verilog-AMS HDL extends the
features of the digital modeling language (IEEE std 1364-2005 Verilog HDL) to provide a single
unified language with both analog and digital semantics with backward compatibility. Below is a
list of salient features of the resulting language: signals of both analog and digital types can
be declared in the same module initial, always, and analog procedural blocks can appear in
the same module both analog and digital signal values can be accessed (read operations) from
any context (analog or digital) in the same module digital signal values can be set (write
operations) from any context outside of an analog procedural block analog potentials and
flows can only receive contributions (write operations) from inside an analog procedural block
the semantics of the initial and always blocks remain the same as in IEEE std 1364-2005
Verilog HDL; the semantics for the analog block are described in this manual the discipline
declaration is extended to digital signals a new construct, connect statement, is added to
facilitate auto-insertion of user-defined connection modules between the analog and digital
domains.
Systems A system is considered to be a collection of interconnected components which are acted
upon by a stimulus and produce a response. The components themselves can also be systems, in
which case a hierarchical system is defined. If a component does not have any subcomponents, it
is considered to be a primitive component. Each primitive component connects to zero or more
nets. Each net connects to a signal which can traverse multiple levels of the hierarchy. The
behavior of each component is defined in terms of values at each net. A signal is a hierarchical
collection of nets which, because of port connections, are contiguous. If all the nets which make
up a signal are in the discrete domain, the signal is a digital signal. If, on the other hand, all the
nets which make up a signal are in the continuous domain, the signal is an analog signal. A
signal which consists of nets from both domains is called a mixed signal. Similarly, a port whose
connections are both analog is an analog port, a port whose connections are both digital is a
digital port, and a port whose connections are both analog and digital is a mixed port. The
components connect to nodes through ports and nets to build a hierarchy, as shown in Figure 1-1.
Figure 1-1: Components connect to nodes through ports If a signal is analog or mixed, it is
associated with a node (see 3.6), while a purely digital signal is not associated with a node.
Regardless of the number of analog nets in an analog or mixed signal or how the analog nets in a
mixed signal are interspersed with digital nets, the analog portion of an analog or mixed signal is
represented by only a single node. This guarantees a mixed or analog signal has only one value
which represents its potential with respect to the global reference voltage (ground). In order to
simulate systems, it is necessary to have a complete description of the system and all of its
components. Descriptions of systems are usually given structurally. That is, the description of a
system contains instances of components and how they are interconnected. Descriptions of
components are given using behavior and or structure. A behavior is a mathematical description
which relates the signals at the ports of the components.

Conservative systems An important characteristic of conservative systems is that there are two
values associated with every node, the potential (also known as the across value or voltage in
electrical systems) and the flow (the through value or current in electrical systems). The potential
of the node is shared with all continuous ports and nets Module Module Module Node Ports
Accellera Analog and Mixed-signal Extensions to Verilog HDL Version 2.3.1, June 1, 2009 3
Copyright 2009 Accellera Organization, Inc. All rights reserved. connected to the node so all
continuous ports and nets see the same potential. The flow is shared so flow from all continuous
ports and nets at a node shall sum to zero (0). In this way, the node acts as an infinitesimal point
of interconnection in which the potential is the same everywhere on the node and on which no
flow can accumulate. Thus, the node embodies Kirchhoff's Potential and Flow Laws (KPL and
KFL). When a component connects to a node through a conservative port or net, it can either
affect, or be affected by, either the potential at the node, and/or the flow onto the node through
the port or net. With conservative systems it is also useful to define the concept of a branch. A
branch is a path of flow between two nodes through a component. Every branch has an
associated potential (the potential difference between the two nodes) and flow. A behavioral
description of a conservative component is constructed as a collection of interconnected
branches. The constitutive equations of the component are formulated as to relate the branch
potentials and flows. In the probe/source approach (see 5.4.2), the branch potential or flow is
specified as a function of branch potentials and flows. If the branch potential and flow are left
unspecified, not on the left-hand side of a contribution statement, then the branch acts as a probe.
In this case, if the branch flow is used in an expression, the branch potential is forced to zero (0).
Otherwise the branch flow is assumed to be zero (0) and the branch potential is available for use
in an expression. Using both the potential and flow of a 'probe' branch in an expression is not
allowed. Nor is specifying both the branch potential and flow at the same time. (While these last
two conditions are not really necessary, they do eliminate conditions which are useless and
confusing.)
 SIMVISION

SimVision is a modeling, project design, and simulation tool that integrates organizational and process
views of strategic, time-critical projects. You can use SimVision to build, view, analyze, and refine a case
(or instance) of a project, no matter how large and complex, and no matter how aggressive the
schedules and performance targets. The vision behind SimVision is to provide a tool and methods to
design an organization the way an engineer designs a bridge, that is, by first creating and analyzing a
virtual computer model, and then implementing the organization that has predictable capabilities and
known limits. Using SimVision, you develop a case of your project or projects and run simulations to see
project time lines. Simulations also identify risks to development quality, schedule, and cost. Software
simulation helps you set up, monitor, and troubleshoot a large project or a program of projects
successfully. By altering the SimVision planning components, you can experiment with different
solutions to determine which one meets your program quality, cost, and scheduling objectives.
SimVision links a project plan, the responsible organization, and a simulator program that uses discrete
event simulation to run the project. The simulator results include information such as the predicted time
to complete a project, the total effort to do the project, and several measures of process quality. Using
the SimVision charts and reports, you can identify any plan, organization, and performance risks. More
detailed case behaviors include the time-varying backlog of individual organizations and the exceptions
associated with tasks. SimVision results are detailed and specific, so they can guide specific managerial
changes in a project team and can support studies of the relative effects of different organizational
changes. Using SimVision to Meet Your Objectives Using SimVision allows you to meet the following
universal project management objectives: Conceptualize your work process and organization in a
clear, graphical manner. When several members of a product development team collaborate in building
a baseline model, the process helps the team develop a shared mental map of the process. Define
project and organization interdependencies within a program. Clarify task and role interdependencies
among participants in the different projects. What is SimVision? 3 Getting Started Predict
project and program risks to high-level projects and organizations and to lower-level tasks, groups and
individual participants. SimVision predicts risks that project participants will become backlogged by a
combination of direct work, coordination, rework, and decision wait time. SimVision predicts risks of
task, project, and program schedule delay by dynamically simulating participant workloads. It also
predicts risks to project and program communication and work process quality. Model and analyze
management interventions to shorten the duration of a program and its individual projects while
maintaining the desired product quality and cost. You can investigate the predicted effects on program
performance of redesigning work flow, adding or reallocating resources, or adjusting product
performance targets to fit time and resource constraints. Benefits of Using SimVision Using SimVision
has the following benefits: Pre-project strategic planningYou can plan projects, considering the tasks
and the organization concurrently. Goal alignment and consensus buildingBuild consensus among
project stakeholders about project objectives, risks, managerial contingencies, and significant
milestones. Stakeholders can include both groups with direct project responsibilities and other
interested parties such as customers and senior executive staff. Effective organization design and
staffingBy including position analysis and skill levels, you can put together the team that will meet the
product schedule and quality objectives. Periodic program and project checkupPrograms and projects
follow a natural growth and completion cycle. In addition, requirements, constraints and opportunities
often change. SimVision cases can help you review and manage programs and projects whenever
conditions change. Process refinementGiven a baseline project definition, consider the predicted
benefits of a number of possible interventions in the management of tasks, positions and the project
management style. It may be necessary to scale down technical requirements of the product or to
stretch out the desired delivery date to achieve a feasible solution. Outsource evaluationOutsourcing
can often help improve your schedule, quality, and cost performance, but it requires coordination to
support the supplier or contractor. Multiple projects are organized into a program and the program 4
2005, ePM, LLC SimVision User Guide must be coordinated to produce a successful product.
SimVision cases can help you plan and manage the way work is distributed among product-development
groups. Risk analysisSimVision produces data showing the project risks based on your project data.
Portfolio managementManage a portfolio of projects that have related objectives and compete for
limited resources. Process knowledge communicationSimVision cases can be distributed worldwide
using the Internet. Practices that work well once can be reviewed, modified, and reused at different
times and locations. Important Terms Before you start using SimVision, you should understand the
following concepts: ModelA visual representation of a program and its projects. ProgramA set of
related projects that together produce the product or products. A program also includes the associated
responsible organizations, milestones, and relationships between projects. ProjectA set of related
product development tasks including positions (groups of one or more individuals) that perform tasks
and the dependencies between tasks and positions. CaseA specific instance of a program. PortfolioA
program of multiple projects. PaneAn area of the workspace. SimVision has five panes: the Model,
Tree, and Properties panes, Table View, and the Fix Simulator Errors and Warnings pane. Workspace
The area of the application where you work, which contains the Model pane, other optional panes, and
the toolbars. SimulatorSoftware that simulates the work done by positions as they perform individual
project tasks, including both planned direct work and coordination and rework. Simulation charts
Charts that summarize and provide details of the simulated performance of the program and the
individual modeled projects. System Requirements 5 Getting Started ShapesA set of color-
coded objects that represent projects, milestones, tasks, positions, organizations, departments,
meetings, ghost milestones, and ghost tasks. LinksA set of color-coded arrows that represent the
relationships between shapes. ObjectsAn umbrella term for shapes and links. System Requirements
To run SimVision, you need the following: Operating system: Windows 2000 Professional or later, or
Windows NT 4.0 recommended. Processor: 300 MHz required. 500+ MHz recommended. Memory:
64MB minimum. 96MB RAM with 50 MB disk space recommended. Monitor: XVGA or better.
Browser: able to view HTML 2.0 or better (Internet Explorer 5.0 or higher.
 BASIC I.P. FUNDMENTALS

BAND GAP REFERENCE : -

A bandgap voltage reference is a temperature independent voltage reference circuit widely used
in integrated circuits. It produces a fixed (constant) voltage irrespective of power supply
variations, temperature changes and the loading on the device. It produces a voltage that is
temperature independent by adding a voltage that increases with temperature, i.e., has
proportional-to-absolute-temperature or PTAT dependence, to a voltage that decreases linearly
with temperature, i.e., has complementary-to-absolute-temperature or CTAT dependence. The
generation of CTAT voltage VCTAT is simply obtained by tapping the forward-biased base-
emitter junction of a bipolar transistor. PTAT voltage VPTAT is generated by using the
difference in the base-emitter voltages of two bipolar transistors, one of which is larger than the
other but both carrying the same total current.

LOW VOLTAGE DETECTOR : -

Low Voltage Detector (LVD) monitors the supply voltage and genetrates an internal Reset
when voltage drops below minimum operatable level. In some cases after voltage drops below a
predetermined value,the voltage is monitored for a few clock cycles to ensure voltage drop is not
due to noise/glitches.

The low-voltage detect (LVD) module sets a flag bit, triggers an interrupt, or generates a reset
when VDD falls below trip falling level. The reset signal is deactivated when VDD rises above
the trip rising level (falling threshold level + hysteresis)..

Figure 6 illustrates reset generation for both POR and LVD situations. VDD is not plotted on a
linear scale. The difference between POR and LVD voltages are exaggerated for illustrative
purpose. VPOR is power on reset voltage, VTF is LVD trip falling voltage, and VTR is LVD trip
rising voltage.
POR (POWER ON RESET) :-

Power-on reset (POR) system ensures that the microprocessor or microcontroller will start in the
same condition every time that it is up. It restores devices, registers, and memory to a
predetermined state when power is applied It ensures that the MCU start at a known address
with registers in defined state when power is first applied.

POR circuit is required to assert the reset signal only when supply voltage has stabilized and
reached a minimum required voltage.

Clock oscillators should also be stabilized before asserting RESET signal

To accomplish the task, the POR logic output holds the processor in its reset state when the
processor's power supply is first turned on. Then it keeps the processor from starting its
operation until the system power supply has stabilized at the appropriate level. Once the supply
has reached its appropriate level POR is deasserted. If ever the chip supply falls below the POR
level , it would cause the chip to enter the reset state.

L.D.O (Linear Drop Out) Regulator:

A low-dropout or LDO regulator is a DC linear voltage regulator which can regulate the output
voltage even when the supply voltage is very close to the output voltage. The advantages of a
low dropout voltage regulator over other DC to DC regulators include the absence of switching
noise (as no switching takes place), smaller device size (as neither large inductors nor
transformers are needed), and greater design simplicity (usually consists of a reference, an
amplifier, and a pass element). A significant disadvantage is that, unlike switching regulators,
linear DC regulators must dissipate power across the regulation device in order to regulate the
output voltage.

The main components are a power FET and a differential amplifier (error amplifier). One input
of the differential amplifier monitors the fraction of the output determined by the resistor ratio of

R1 and R2. The second input to the differential amplifier is from a stable voltage reference.

H.V.D(HIGH VOLTAGE DETECTOR)

The High-voltage detect (HVD) module sets a flag bit, triggers an interrupt, or generates a reset
when VDD rise above maximum upper limit. This is done to protect the chip from high supply
levels form reliability considerations.

P.M.C OPERATION

PMC makes sure that during the start-up of the chip the chip boots properly and doesnt remain
stuck in the reset state and is loaded with proper initial states and conditions .It makes use of
POR and LVDs to insure this .After the chip comes out of the RESET ,PMC monitors the
supply inputs to the chip to insure that it is within the specified safety limits ,if at any time any
supply fall below or above its specified limits it checks whether it is because of noise/glitch or
actual variation in supply and if it is the latter PMC generates a RESET signal and put the whole
chip in reset stated to protect the chip from going into undetermined or metastable states which
may lead to corruption of chips operation .

Assume that the SOC is in the Run mode (fully functional mode). Firstly, a Low
Power entry request is received. The next step is to reduce the operational frequency,
e.g. going from PLL-engaged mode to the lowest frequency mode, so as to reduce
dynamic power dissipation. This is followed by clock gating certain IPs so as to
further reduce dynamic power dissipation. Some other IPs are further power gated, so
as to additionally reduce even static power dissipation due to leakage. All these
actions result in minimizing the load on the power regulator, and thus even a weak
regulator can take up the load, once the Run mode regulator has been switched off.
 Irun(Incisive)

Irun is a wrapper which manages both the analog solver and the digital solver. The irun
utility lets you run the simulator by specifying all input files and command-line options on a
single command line. The utility simplifies the invocation process by letting you use one tool to
invoke the simulator instead of invoking multiple tools separately to piece together a snapshot
that can be simulated. irun takes files from different simulation languages, such as Verilog,
SystemVerilog, VHDL, Verilog AMS, VHDL AMS, Specman e, and files written in general
programming languages like C and C++, and compiles them using the appropriate compilers.
After the input files have been compiled, irun automatically invokes ncelab to elaborate the
design and then invokes the ncsim simulator. The most basic way to use irun is to list the files
that are to comprise the simulation on the command line, along with all command-line options
that irun will pass to the appropriate compiler, the elaborator, and the simulator. For example:

% irun -ieee1364 -v93 -access +r -gui verify.e top.v middle.vhd sub.v

In this example:

The files top.v and sub.v are recognized as Verilog files and are compiled by the Verilog
parser ncvlog. The -ieee1364 option is passed to the ncvlog compiler.

The file middle.vhd is recognized as a VHDL file and is compiled by the VHDL parser
ncvhdl. The -v93 option is passed to the ncvhdl compiler.

The file verify.e is recognized as a Specman e file and is compiled using sn_compile.sh.

After compiling the files, irun then calls ncelab to elaborate the design. The -access

option is passed to the elaborator to provide read access to simulation objects.

After the elaborator has generated a simulation snapshot, ncsim is invoked with both the

SimVision and Specview graphical user interfaces.

Use the irun help system to get information on tool-specific command-line options. The
helpoptions are described in Chapter 2, Getting Help on irun.
 Property Specification Language (P.S.L)

Overview

Assertions play an important role in a unified verification methodology. Assertions allow the
architect or designer to capture his or her design intent and assumptions in a manner that can be
verified in the implementation. Assertions are captured during the development process and are
continually verified throughout the process. Assertions, working in a unified verification
methodology, reduce the verification time by detecting bugs earlier, isolating where a bug is
located, and even detecting internal protocol violations that may not cause functional errors to
propagate to the outputs. In addition to bug detection, assertions improve the efficiency in a
unified methodology by improving reuse, enhancing testbench checking, and capturing coverage
information. PSL assertions can allow the user to write properties that reason about the temporal
or time-based behavior in designs. They are thus highly suited for use in sequential circuits of
any form, and can be used to implement self-checking testbenches, etc. These types of assertions
are typically written to check circuit properties at the design/block/inter block level, and less so
at the individual device (transistor) level. They are used for functional checking/debug, but can
also be used for checking assumptions about the valid inputs to a block, etc. PSL novices are also
directed at the following extremely useful tutorial.

Introduction

PSL assertions express functional design intent in terms of time-based behavior. Assertions can
be used to express assumed input behavior, expected output behavior, or forbidden behavior. For
example, if a sample and hold circuit has a sample signal and a hold signal, a designer might
assume that the hold signal should always follow the sample signal after a certain minimum
period. With assertion-based verification (ABV) in a simulation environment, if during a
particular simulation run, there was ever a sampling period when the sample and hold signal
timing violated that simple sample and hold timing constraint, then the assertion would
immediately fire and report a message. This is an example of an interface assertion. Interface
assertions are used to check the protocol of interfaces between blocks. Other types of assertions
include architectural assertions and structural assertions. Application assertions are used to prove
architectural properties. For example, after a request for analog to digital conversion, eventually
the conversion done signal is asserted. Structural assertions are used to verify low-level
internal structures within an implementation, such as arithmetic sign preservation in analog
integrator blocks. For example, if the current input and output voltages of a switched capacitor
integrator are both negative, then the output voltage at the next sample time should also be
negative. This document provides an introduction to the PSL assertion language and to the PSL
- based implementation of ABV (Dynamic ABV) that is supported in the AMS Designer
simulator. PSL assertions (due to their digital pedigree) are time-based assertions used during
transient analysis. The benefits of using assertions are discussed, and a specific example of
interface assertions for a Sigma Delta modulator circuit is presented. The use models of the
AMSD PSL implementation of Assertion-Based Verification are also discussed, including how
you run a simulation with assertions; instruct the simulator when to evaluate them, how to debug
them, and how to turn them on and off.

The primary focus of AMD Designers implementation of PSL-assertion-based verification is to

identify bugs and design issues as close to the source as possible. This reduces the debug time,
especially after hierarchical integration of blocks when bugs take longer to propagate to the
output and are more difficult to isolate. Assertion checking during simulation can identify
internal errors within the design or block level sooner and closer to the source than is possible
without assertions. Without assertions, errors must propagate to the observed outputs before
being detected. Assertions reduce the time it takes to locate difficult errors by identifying where
in a design the error first appears. Assertions also catch errors that do not propagate to the output.
When an assertion fires, it provides an immediate localization of the failure, which simplifies the
insertion of intellectual property (IP) or other forms of block reuse into design environments.

Booleans PSL was originally designed to be used in conjunction with hardware description
languages (HDL) such as Verilog or VHDL. With AMS Designer, it is now used in conjunction
with Verilog-AMS. At the bottom level, the Verilog-AMS language is used to specify the
conditions that define a behavior of interest, referring to signals, variables, and values within a
netlisted description of a design. Those conditions are represented by Verilog-AMS expressions,
involving both analog and digital quantities, that can be interpreted as having Boolean values
(for example: relational expressions). Using the underlying Verilog-AMS for such expressions
ensures that the assertion language can cover the full range of behavior that can be described in
the Verilog-AMS language, and that there is no chance of semantic mismatch between the
simulators most native digital description of a behavior and the Verilog-AMS description of the
same behavior involving analog quantities. This also reduces the learning curve for being able to
express a behavior. Clocking And Evaluations PSL assertions are declarative in nature. This
means that every assertion is evaluated on every simulation timestep (if un-clocked) or every
sample point (if clocked), and all assertions are evaluated concurrently. PSL generally allows for
asynchronous or synchronous behavior to be expressed. To create asynchronous pure-digital PSL
assertions, simply omit the clocking expression. However, unclocked (asynchronous) mixed
signal expressions are not currently supported by AMS Designer. Unclocked PSL expressions
containing references to analog objects will currently result in an error (this may be fixed in a
future release) as follows:
 //psl same_time_bad: assert never (V(out1)> 0.5) && (V(V1) > 0.5); | ncvlog: *E,CLKANA
(VAMS/top.vams,18|32)

: All elements of a property containing analog objects must be clocked by a single clock. The
real power of PSL comes in however for sequential circuits or sampled data systems which have
the checks performed synchronously i.e. at well defined points (e.g. sample points, co-incident
with circuit clocks, etc) during the simulation.

The following shows an example where the assertion property is checked whenever the Mixed-
Signal PSL Assertions in AMS Designer April 8, 2013 9 Product Version IUS9.2 analog clock
voltage crosses above 0.5 volts in a rising direction, with the clocking event shown underlined:
//psl integ1_bounded: assert never (abs(V(I1)) > 1.5*V(Vref)) @( cross(V(clk)-0.5, +1));

For synchronous checking in AMS Designer, the clock or sampling event can be defined as any
standard mixed signal simulation event such as cross(), posedge(clk), negedge(clk), etc.

Accessing values within SPICE subcircuit contexts It is also possible for PSL expressions to
include references to analog circuit quantities represented below the SPICE subcircuit level
e.g. for an analog node foo within an instance top.sub.end of a SPICE
subcircuit:$cds_get_analog_value("top.sub.end.foo", "potential");

The user provides the hierarchical string to the object to be accessed and defines a quantity
specifier (in this case potential to the voltage), and the return value is a real number that
represents the analog voltage at the moment where the function is triggered. The syntax of the
cds_get_analog_value function is the following: real $cds_get_analog_value(hierarchical_name
[, optional index[, optional quantity qualifier]])where: The index can be variable, reg, or
parameters so long as their value evaluates to an integer constant The quantity qualifier can be
potential, flow, pwr, or param. If none is specified, potential is assumed The object referred to by
hierarchical_name must exist and must be owned by the analog solver. It must be a scalar or a
vector, and if the latter, the index must be specified such that the result resolves to a scalar. The
hierarchical_name can be a relative or absolute path.

The following shows an example: //psl foo_bounded: assert never

(abs($cds_get_analog_value("top.sub.end.foo", "potential")) > 1.5*V(Vref)) @( cross(V(clk)-
0.5, +1));

Sequences The real power of PSL comes from its support for time-based sequences. Sequences
can express a simple Boolean expression or a multi-cycle (aka multi-sample-point) behavior of
Boolean expressions, where each cycle of a sequence is separated by a ;.

Mixed-Signal PSL Assertions in AMS Designer April 8, 2013 10 Product Version IUS9.2
For example, if V(a) > 0.5 V(b) < 1.0 V(c) != V(d) reset || pwr_down are Boolean expressions
(the first 3 being analog, the fourth being digital)

, then the following define legal sequences: Sequence Comment { V(a) > 0.5}; simple sequence
{ V(b) < 1.0 ; V(c) != V(d)}; simple sequence, two events occurring in successive sample
times/clock events {{V(a) > 0.5 }; !(reset||pwr_down); {V(b) < 1.0 ; V(c) != V(d)}}; complex
sequence which contains nested sequences, including analog and digital values The complex
sequence in the third example evaluates to true when Verilog-AMS analog expression V(a) > 0.5
is true followed by digital expression !( reset || pwr_down) is true followed by analog expression
V(b) < 1.0 is true followed by analog expression V(c) != V(d) is true.

Note the following:

1. Sequences are enclosed in braces when referenced, indicating it is a sequence expression.

2. Successive cycles of a sequence are separated by a semicolon (;).

3. A Boolean expression (such as V(b) < 1.0) may be viewed as having a sequence length of
one.

4. The keyword true can be used to specify a dont care condition during any cycle.

5. You cannot apply the! (not) operator on a sequence expressions. (For example, !{{ V(a)>
0.5}; {V(b) > 0.5; V(c) > 0.5}}; is not valid).

6. Repetition specifiers can be used for any expression of a cycle. The keyword inf can be used
to express infinity. The more commonly used operators are shown below: [*] Indicates that the
expression may occur zero or more consecutive times. [+] Indicates that the expression may
occur one or more consecutive times. [*n] Indicates that the expression should occur exactly n
consecutive times. [*n:inf] Indicates that the expression should occur a minimum of n
consecutive times. [*0:m] Indicates that the expression may occur a maximum of m consecutive
times. [*n:m] Indicates that the expression may occur n or m consecutive times. Mixed-Signal
PSL Assertions in AMS Designer April 8, 2013 11 Product Version IUS9.2 Properties A
property defines a time-based behavior to be checked. A property can be thought of as containing
an optional enabling condition, a fulfilling condition, which is the behavior to be checked, an
optional discharging condition, and an optional clocking condition. The most general form of a
PSL property and the definition of terms is shown below: [operator] [enabling_condition(s)]
[implication_operator(s)] (fulfilling_condition) [until | until_ | abort discharging_condition]
[@(clock_expression)]; The following describes the key terms of a property expression:

1. The operator is one of always or never and indicates whether the behavior should always
occur or should never occur.
2. The enabling condition can be any Verilog-AMS Boolean expression or sequence expression.
Multiple enabling conditions and implication operators can be strung together to form a complex
enable. The assertion is considered to begin when the first sequence of the enabling condition
evaluates to true.

3. The implication operator specifies the logical relationship between two expressions. The
operator of the form LHS symbol RHS where symbol is one of the following symbols: ->
Evaluation of the right hand side (RHS) is started when the left hand side (LHS) is true. The
behavior can be read as if (enabling condition) is true, then the (fulfilling condition) must also
be true. The LHS must be Verilog-AMS Boolean. -> next Evaluation of the RHS is evaluated in
the next cycle after the LHS becomes true. The behavior can be read as if (enabling condition)
is true, then the (fulfilling condition) must be true in the next verification cycle/sample point.
The LHS must be Verilog-AMS Boolean |-> Evaluation of the RHS is started in the last cycle of
the LHS. The LHS must be a sequence when this is used. |=> Evaluation of the RHS is started
following the cycle when the LHS condition becomes true. The LHS must be a sequence when
this is used. eventually! The RHS is true in some future cycle, and must be true before the end of
simulation. The RHS must be a Verilog-AMS Boolean expression or a sequence.

4. The fulfilling condition is the behavior to be tested. It is checked on every verification cycle
by default. The fulfilling condition can be any Verilog-AMS Boolean expression or sequence.
The fulfilling condition is the last expression prior to any discharging condition.

5. The discharging condition is a condition that indicates to the simulator to stop the checking of
the behavior. Discharging conditions include the following: until (Verilog-AMS Boolean
expression) When all of the enabling conditions have evaluated to true, the fulfilling condition
must be true until the Boolean expression becomes true. It then finishes immediately. until has
no affect until the fulfilling condition is being checked. Mixed-Signal PSL Assertions in AMS
Designer April 8, 2013 12 Product Version IUS9.2 until_ (Verilog-AMS Boolean expression)
When all of the enabling conditions have evaluated to true, the fulfilling condition must remain
true up to and including the cycle where the Boolean expression is true. It then finishes
immediately. until_ has no affect until the fulfilling condition is being checked abort (Verilog-
AMS Boolean expression) abort cancels the checking of an assertion. An abort that occurs
during the checking of the enabling condition or the fulfilling condition will cancel the checking.
This is different than until or until_ that requires that the fulfilling condition is being checked.

6. The clock expression, when specified, is the condition that is used to sample the assertion (the
default condition is to sample the assertion at every simulation timepoint). The clock expression
often corresponds to a clock edge in a clocked circuit, and can be defined using any of the
Verilog-AMS standard event functions: cross( expression, direction) posedge(clk)
negedge(reset) etc Note that the Verilog-AMS cross function is supported in order to allow for
analog clocking events to be specified. Property Examples Some examples are as follows:
Assuming sample and hold are interface signals (electrical nodes), the following is an example of
an interface assertion: //psl assert_7: assert never ((V(sample)> 0.5) && (V(hold) > 0.5))
@(cross(V(clk)-0.5, +1); An architectural level example might be a stability check: that the
output of integrator I1 within a 2-stage Sigma Delta modulator is always bounded within 1.5
times the limits of the modulators reference Voltage Vref, a property that is periodically
checked every modulator clock period: //psl integ1_bounded: assert never (abs(V(I1)) >
1.5*V(Vref)) @( posedge(clk) ); A pair of structural assertion examples might be to ensure that
an analog comparator does a sufficiently good job of comparing a signal versus a reference level
(such as zero) within a sufficiently small margin, and doing so for both positive and negative
input (and expected output) values

//psl comparator_pos: assert always (((V(comp_in) > 0.001) -> (V(comp_out) >= V(Vref)))) @(
posedge(clk) ); //psl comparator_neg: assert always (((V(comp_in) < 0.001) -> (V(comp_out) <=
V(Vref)))) @( posedge(clk) ); Mixed-Signal PSL Assertions in AMS Designer April 8, 2013 13
Product Version IUS9.2 Directives A sequence or a property by itself just describes a circuit
behavior; there is no inherent obligation for the behavior to occur. Directives specify whether a
given property is expected to hold (assert) or assumed to hold (assume). Properties are always
asserted or assumed. For assertions used in mixed signal simulation, assert and assume have the
same meaning. Sequences can be used in properties. The format is as follows assume | assert ; In
AMS Designers implementation of simulation-based assertion verification, all mixed signal
properties are treated as if they are asserted. That is to say, the assert or assume directives are
interchangeable Defining PSL Assertions in AMS Designer AMS Designers implementation of
PSL for Verilog-AMS supports defining assertions embedded inline as a //psl prefixed
comment(aka assertion pragmas) in Verilog modules or within a separate vunit file.

The PSL assertions are described in the same way as legacy digital cases, and can be placed
wherever AMS Designer/irun supports digital assert statements. As usual, the AMS Designer
assert is prefixed with an alphanumeric identifier (such as assert_1 or comparator_pos, etc) e.g:
//psl comparator_neg: assert always (((V(comp_in) < 0.001) -> (V(comp_out) <= V(Vref)))) @(
posedge(clk) ); Where to Place PSL Assertions Structural Assertions Structural assertions that
are used to verify low level internal structures within an implementation will likely be placed as
pragmas within a (medium-to-low level) module, or better yet in a separate vunit that is
dynamically bound to that module. This is the recommended approach when the assertion is
specific to a design block, because the assertion is guaranteed to travel with the design. module
sample_and_hold(in, sample, hold, out); inout in, sample, hold, out; electrical in, sample, hold,
out; // ensure there is some aperture between sample and hold events //psl: assert_7 assert
never ((V(sample)> 0.5) && (V(hold) > 0.5)) @(posedge(clk)); endmodule Mixed-Signal
PSL Assertions in AMS Designer April 8, 2013 14 Product Version IUS9.2

Architectural/Application Assertions Application assertions that are used to prove architectural

properties are best embedded in the top level design modules (recommended approach so that
they are always evaluated anywhere that module is later instantiated), but may also be placed in
the testbench level (though this approach does not promote assertion re-use): Better yet, place in
a separate vunit that is dynamically bound to that top level module. The following example
shows the inline pragma based approach: module mytestb; // instantiate the modulator x1 (In, E1,
I1, E2, I2, Y) modulator // testbench components vin vsource (In, gnd) type=sine //
architectural assertions at the testbench level //psl integ1_bounded: assert never (abs(V(I1)) >
1.5*V(Vref)) @( posedge(clk) ); endmodule While the above example shows these embedded as
pragmas within a module, a vunitbased approach is superior in order to separate verification IP
from design IP, while still allowing them to be dynamically bound together at runtime. Interface
Assertions Interface assertions that check the protocol of interfaces between blocks, are likely to
be placed either within the module that instantiates those blocks, or within a vunit that binds to
that module: module medium_level(in, dout_0, dout_1); inout in, dout_0, dout_1; electrical in,
dout_0, dout_1; // instantiate sample & hold circuit sample_and_hold S1 ( in, sample, hold,
sampled); // instantiate ADC, driven by Sample hold circuit ADC adc (sampled, dout_0, dout1);
// instantiate a lower level module to generate the sample/hold signals sh_signal_gen sh_gen
(sample, hold); // ensure there is some aperture between sample and hold events //psl aperature:
assert never ((V(sample)> 0.5) && (V(hold) > 0.5)) @(posege(clk)); endmodule.
 System Verilog Assertions Language

Assertion checking is a simple addition to your simulation-based verification methodology.

All you need to do is add monitors to your design. These monitors are called assertions. During
simulation, these monitors watch to see

If a specific condition occurs, or

If a specific sequence of events occurs

The monitors generate warnings or errors if required conditions or sequences fail, or if forbidden
conditions or sequences occur.

SVA Immediate Assertions

[ label ] assert boolean_expression [ action_block ] ;

Immediate assertions are executed like procedural code during simulation.

An immediate assertion tests an expression when the statement is executed in the

procedural code. If the expression is interpreted as true, the assertion passes. If the expression is
interpreted as false, the assertion fails.

By default, when an assertion fails, the simulator calls the $error severity task, which displays an
error message. No action is taken by default when an assertion passes. However, you can include
an action block ("SVA Action Blocks" ) in an immediate assertion to specify the action to take
on success, and to change the default behavior to take when the assertion fails.

The assert directive causes an immediate assertion to be checked during simulation. You place
this statement in the procedural code wherever you want the assertion to be checked.
The label becomes the name of the assertion.

The following examples define several styles of immediate assertions inside always blocks.
Comments in the code describe each style.
SVA Deferred Assertions

[ label :] directive #0(expression)[ action_block ] ;

A deferred assertion is used to suppress the errors that occur due to glitching activity
on combinational inputs to immediate assertions. A deferred immediate assertion is similar to
simple immediate assertion with the following key differences:

A #0 delay is specified after the assertion directive

Reporting is delayed rather than immediate

Action blocks can contain only a single subroutine call

Assertions can be used outside procedural blocks as a module_common_item

In a deferred assertion, a #0 delay control is specified after the directive to delay reporting. This
is followed by an expression and an action block. For example:

always@(clk)
begin
x=foo();
a1:assert#0(x>0)$display("a1 passed");
else $error("a1 failed as x=%d",x);
end

If the action block contains a pass or a fail statement, then each of the statements can contain
only one subroutine call, which can be a task, a task method, a void function, a void function
method, or a system task. In this case,begin-end statements cannot surround the pass or fail
statements as begin is not a subroutine call.

In an action block, a subroutine argument can be passed either by value or by reference as a ref
and a const ref. If an argument is passed by value, the expressions use the values of the
underlying variables when the deferred assertion expression was evaluated. However, if the
argument is passed by reference, expressions use the current values of the underlying variables in
the Reactive region. Further, it is not allowed to pass automatic or dynamic variables as actual to
a ref or a const ref formal.

Note: As a limitation in a subroutine call in an action block, saved values are not used
when actuals are out of scope or wires.
Reporting in a Deferred Assertion

In a deferred assertion, though the deferred assertion's expression is evaluated when the deferred
assertion statement is processed but the reporting or action blocks are scheduled in the Reactive
region in the current time step.

The action block subroutine call and the current values of its input arguments are placed in
a deferred assertion reporting queue with the currently executing process. When a deferred
assertion flush point is reached, the deferred assertion reporting queue is cleared and any pending
assertion reports are not executed. After a queue reaches the deferred assertion flush point, each
pending report that is in the Observed region of each simulation time step and has not been
flushed either matures or is confirmed for reporting. The associated subroutine call in the
pending report is executed in the Reactive region and finally, the report is cleared from the
specific deferred assertion report queue. Remember that any report that matures cannot be
flushed.

In case a deferred assertion expression is evaluated in the Observed region, the deferred assertion
matures immediately. For example:

wait (S.triggered);//Here, S is a sequence.

A1: assert #0 (expr);

In the given example, S.triggered stands true only in the Observed region. Therefore, the
deferred assertion A1 will hit only the Observed region and will definitely report.

Note: At times, code in the Reactive region may modify a signal and lead to another pass to the
Active region. In this case, the Active region may re-execute some of the deferred assertions
with different reported results and may lead to glitching behavior. Though deferred assertions
prevent glitches due to order of procedural execution but do not prevent glitches caused by
execution loops between regions due to the assignments from the Reactive region.

Deferred Assertion Flush Point

A deferred assertion flush point is reached when:

A process that was earlier suspended resumes execution on reaching an event control or
wait statement.
A process that was declared by an always_comb or always_latch resumes execution due to
a transition on one of its dependent signals.
 The outermost scope of the process is disabled by a disable statement. However, when you
disable a task or a non-outermost scope of a procedure any pending reports are not flushed.

Note: In IES, the flushing of deferred assertions in case the outermost scope of the process is
disabled by a disable statement is not supported and the results are reported.

Usage of a Deferred Assertion

You can specify a deferred assertion either inside or outside a procedural code. The
following example illustrates specifying a deferred assertion inside a procedural code:

always@(clk)
begin
x=foo();
a1:assert#0(x>0)$display("a1passed");
else
$error("a1failedasx=%d",x);
end

When you specify the deferred assertion outside the procedural code as a module_common_item,
it is treated as if it is in an always_comb procedure. For example:

Module m
(input a, b);
a1: assert #0 (a == b);
endmodule

is equivalent to:

module m (input a, b);

always_comb begin
a1: assert #0 (a == b);
end
endmodule
SVA Concurrent Assertions

Concurrent assertions can describe Boolean behaviors or patterns of behavior that span clock
cycles. They can also specify assumptions about the environment, or monitor behavior for
functional coverage. Concurrent assertions are distinguished by
the property and sequence keywords; for example, assert property.

Concurrent assertions are triggered by a clock, which must be explicit.

You can place a concurrent assertion outside of procedural code in a module, interface, clocking
block, or program. You can also place a concurrent assertion in simple initial and always blocks.
Assertions in initialblocks are evaluated only once ("Embedding Concurrent Assertions in
Procedural Code" ).

The following example defines a property, P1, which checks that if a is true, and b is true two
clock cycles later, then c must be true one clock cycle after that. The concurrent assertion, A1,
causes this property to be checked during simulation or formal analysis.

property P1;
@(negedge clk) (a ##2 b) |=> (c);
endproperty
A1: assert property (P1);

Labels in SVA

A Boolean expression describes a behavior that might be true during a single clock cycle. It can
be any SystemVerilog expression that evaluates to 0, 1, X, or Z. The value 1 is interpreted as
true; the values 0, X, and Zare interpreted as false.

A Boolean expression is satisfied in the clock cycle in which it evaluates to true.

The operands can be any data type except shortreal, real, realtime, string, event, chandle,class,
associative arrays, and dynamic arrays. An operand can include function calls, including calls to
system functions, such as $onehot or $countones. System functions are described in SVA System
Functions .

For example, the following expression evaluates to true if a is 1 or b is 0:

(a || !b)
 VAMS EQUIVALENT TOOL

Introduction

Assertions are formal properties that capture specic functional requirement of a design.
Assertions are a standard low-overhead verication technical in the digital domain. With
increased integration of analog and mixed signal (AMS) components in large scale designs,
Lancelot aims to bring the convenience of digital verication to the AMS domain. There major
changes Lancelot to cater to the AMS domain are:

1. Dense real-time and real-value semantics as opposed to clock ba

assertions in digital domain.

2. Latches to electrical nets directly unlike the sampled values in dig

assertions.

All statements in Lancelot are single line statements. The statements in Lancelot are of two
categories namely:

Aliases

Properties

. Alias statements

Alias statements are the means to access design signals in assertions. They are similar to bind
statements in SVA. The syntax for alias signals is given below.

@ a l i a s ? < a l i a s name> ~ <designs i g n a l >

Aliasing signals is the only way to use them in assertions. The aliases can be over-written in the
same property le(This will generate a warning message of severity:1) but to be used with
caution. The property will use an alias last found before its denition. Aliases currently cannot
used as macros or parameters to dene constants, they must refer to a design signals only.
However data-buses whether analog or digital can be addressed with aliases as follows.

@ a l i a s ? data_out ~ top . adc_out [ 0 : 1 2 ]

@ a l i a s ? d a t a _ o u t _ l s b ~ top . adc_out [ 0 ]

In the above example data_out refers to the entire bus and data_out_lsb refers to the LSB of
adc_out bus. At this stage Lancelot does not see a valid property yet. The signal can also have
the macro scope included in its declaration and it will lled out during the pre-processor stage
by the tool. Note that Lancelot does not yet know whether the signal belongs to analog or the
digital domain. This would be indicated by the boolean layer from the properties.

@ a l i a s ? < a l i a s name> ~ < s i g n a l >

@alias ? enable~ scope . ADC_inst . e n a b l e.

What if an alias is not declared but used in an assertion? Lancelot assumes that the designer is
referring to an internal signal in Lancelot module, issues a warning and allows read-access to it.
This is a very useful feature as this allows us to write many complicated assertions that are
otherwise not possible. The aliases that the user can make use of are the following:

1. Pass/fail triggers of propert

2. Local variables from other properties

3. Specic internal nets of lancelot depending on the properties. (Sub-

Parts of the properties are stored as signals for debug usage

prop_1 ? @+( a ) => ( b )

prop_2 ? @+( p r o p _ 1 _ f a i l ) , x : = b => ( c ) , $ p r i n t ( x )

In the above example prop_1 checks for signal b to be high when there is a pos-edge of a occurs.
The second property prop_2 checks for c to be high whenever prop_1 fails( a occurs but b is not
high). The addition of "_pass/fail" to the property name dictates the trigger to latch on to. Care
should be taken while naming a property with "_pass/fail" at the end as that might lead to wrong
trigger latching. If no property trigger with the name is found Lancelot assumes that the user is
referring to an internal net. This might lead to elaboration stage errors in the simulators, hence all
these features carry a severity:1 warning whenever they are used.

Properties

This section explains the various keywords of AMS-LTL language followed by construction of
assertions. Every AMS-LTL assertion is a single line assertion. All Lancelot assertions start with
an assertion name and the denition is separated by a ?. Consequently SVA assertion links are
made with the names assert_<Assertion-Name>. The e-manager links can be attached to these
SVA assertions.

< A s s e r t i o n Name> ? < A s s e r t i o n d e f i n i t i o n >

The different layers in a Lancelot assertion are:

1. Boolean Layer

2. Local Variable Layer

3. Property Layer

Boolean Layer

..

Boolean layer or the atomic predicate layer is a time independent layer. It is delimited by ( and
) for indication. Whenever an alias is enclosed in parenthesis, Lancelot assumes it is a boolean
unit unless the term inside has arithmetic operators. Hence whenever a predicate of the form a ==
b is to be written, do not enclose any one of a or b in parenthesis as this causes a syntax error.
There are two types of predicates in Boolean layer.

Analog Predicates Predicates of the form (V(in) > 3.0), (wreal_vout 0.8 < 3.0) and
($bits2real(ADC_out) >= V(in)) are considered Analog Predicates. This is the layer where the
tool reasons out the discipline of the signal. Mathematical manipulations are allowed in the
analog predicate.

Digital Predicates Predicates of the form (enable) ,(reg_bus == 8 h00) ($test_vin(in)).

Notice the use of (). These are essential to indicate the change to predicate layer. (True) and
(False) are special booleans that are always true and false respectively. A use case of these
predicates is to generate delay as below.

#The a s s e r t i o n d e l a y s t h e posedge event of

# e n a b l e changing by 50 ns .

delay_50ns ? @+( e n a b l e ) => f u t u r e [ 5 0 e 9 , $ ] ( True )

Local Variable Layer

Similar to SVA the local variables can be assigned and used in the assertion on success of
predicates. Following are the example use cases of local variables. The local variable assignment
can be after an antecedent(ex) and/or after a consequent(ex2). The assignment operator is ":="
and the RHS of the expression can be a mathematical expression or a function call. The scope of
the variable is only until the end of the property.

ex ? (@( e n a b l e ) , x : =V( out )V( i n ) ) => ( x> 1 . 5 )

ex2 ? (@( e n a b l e ) => ( Future [ 0 , 3 e 6]

( $slewrate ( in ) > 2 . 0 ) ) ) , y:= $slewrate ( in ) , $print ( y )

Assertion Layer The nal layer in the hierarchy. It can either be a simple predicate or a
complex assertion using temporal operators like "future","global" or "until".Each assertion layer
has a pass/fail trigger tied to it, which can be used in other assertions to chain properties together.
The triggers are available only in the scope of properties present in that le where assertion is
declared. The triggers are accessed with the names of the property follwed by "_pass" or "_fail"
for pass/fail respectively.

ex3 ? (@( e n a b l e ) , x : =V( out )V( i n ) ) => ( x> 1 . 5 )

ex4 ? (@( ex3_pass ) => ( Global [ 0 , 3 e 6] (V( i n ) > 2 . 0 ) ) )

. Operators

There are various operators used in various levels in Lancelot . This is a comprehensive
summary of them:
 1. Relational Operators: >,<,>=,<= Operators to be used in PORV construction.

2. Arithmetic Operators: +,-,*,/ operators can be used to combine terms in PORV. Only
similar terms can be added; addition of Voltages or currents with rational numbers is not
permitted by syntax.

Similarly Voltage terms can be combined with only other Voltages or wreals. Multiplication is
permitted between rationals and Electrical nets or WREALs.

OBSERVATION

(PROPERTY SPECIFICATION LANGUAGE)

1. Major limitations were found in P.S.L while writing analog assertions
a) First assertion have to be written power by the clock. The problem this is that
since every assertion in the file has to be run at every positive edge of a clock and
because of our need to use a frequency clock in order to prevent loss of a certain
event. The amount of computation needed to be done frequently after small
intervals is very high.The result the simulation time required is much higher.

b) Failures being generated repeatedly after every clock cycle. The problem is that
even in the actual design, the failures might persist for around 100 ns and since
our frequency is much higher. The amount of failures being printed is much
higher again.

c) Most of the functions presented by the language does not go well with the voltage
access function. Most common error was the reserved keyword could not be used
in the assertion body.

d) The P.S.L did not produce any pass messages so if we want to write an assertion
which basically detect an event, then it has to be deliberately failed so that the tool
must display the message in the log file.

e) Very less flexibility in introducing delays the delays had to be introduced in

multiples of clock cycles only.

f) The Until_ operator does not work, communicated P.S.L with cadence.
 (VAMS EQUIVALENT TOOL)

Few areas of improvement were found with VAMS equivalent tool as well, they were
communicated with concerned owners through tickets filled at my end.

This is a list of filled tickets at freescale , basically consisiting of the various issues found with
VAMS equivalent tool.

TKT296871 : proper edge not detected(all failures getting reported at 0)

TKT290431 : variables in an assertion couldnt be used in operations
TKT297383 : using wreal was not possible
TKT290434 : frequency calculator was asked to be included
TKT290437 : local variable value getting corrupted
TKT296718 : slope function was asked to be included
TKT296726 : Hexadecimal support
TKT290439 : sequence of checking and end condition interchanged
TKT287065 : separate log file for assertions
TKT288018 : global operator not working
TKT283720 : internal exception issue (corrupting our environment)
TKT283721 : support for functions such as Avg, RMS, t_rise, t_fall etc.
TKT283722 : support to print values (time and voltage)
 REGRESSION

Most importantly we were able to verify and validate Lancelot compatibility with regression.

What is regression ?
Regression is a technique which enables a user to run a multiple simulation or test case scenarios
in a broader sense.

Thus few issues we found which were overwriting of log file repeatedly, which we overcame by
writing an auxiliary script which renames log file and stores in different directories.
 SYSTEM VERILOG ASSERTIONS

System Verilog Assertions were individually tested on my system and it seemed to better than
P.S.L by the following reasons:-

1.) S.V.A gives the user the power to control number of messages being printed at a trigger
lock.

But still the number of problems similar to P.S.L are being faced because of which we dropped
S.V.A.

Moreover the learning curve was pretty steep so it would not be convenient for other team
members to understand a new language and then write its assertions
 FUTURE WORK

1. Planning to work on more scenarios so as to gain more knowledge in writing

assertions.
2. Introduce certain changes such as increase the scope of the variables defined in the
file so that the variables have to changed parallel with the simulation.
3. To work on my own project, verify a certain part of an I.P with assertions.
4. Work with the virtuoso platform.
5. Work with T.S.O department and develop a GUI based system to ease assertion
making.
6. Looking forward towards S.V.A

REFERENCES
1. Freescale open source material
2. Cadence.Support.com
3. Wikipedia
4. Nxp.com
5.