PSS (Portable Stimulus) is a modeling approach that uses graphs to comprehensively model complex functionality in an understandable way. It enables portable test scenarios for UVM sequence generation and C-based SoC tests across different environments. PSS models are modular, allowing smaller tests to be easily shared and reused. The document compares Cadence Perspec and Breker TrekSoC PSS tools on various parameters like modeling, constraint solving, test intent, libraries, debugging, coverage, and support for the Accellera PSS language standard. In general, Cadence Perspec provides more comprehensive functionality for modeling, constraint solving, test intent specification, debugging and coverage compared to Breker TrekSoC.

1. PORTABLE STIMULUS (PSS)
VERIFICATION REDIFINED
-Archit halder

2. What is PSS?
Highly descriptive and
easy to understand
modeling approach that
makes use of GRAPHS, a
well-known method to
detail complex
functionality in a
comprehendible fashion.
When used with the test
synthesis, enables
PORTABLE scenarios for
UVM sequence generation
and C-based SoC tests
across simulation,
hardware verification and
actual silicon.
Modular in fashion
allowing smaller, UVM
block tests to be easily
SHARED with SoC teams
for incorporation into
larger tests, enabling
seamless reuse and
eliminating authoring
redundancy.

4. An Analogy
It is analogous to today’s Google maps, if we
•
want to go from City A to City B, it has
knowledge database of all the possible path,
information from users and other data, about
experiences from which roads get clogged at
what time.
Depending upon all the factors, it gives us the
•
most optimal solution.
That’s what PSS does for the users in creating
•
stimulus that covers the coverage space.

5. Who are in the Horserace for PSS?
CADENCE Perspec (1st
)
•
Breker TrekSoC (2nd
)
•
MENTOR InFact (4th
)
•
SYNOPSYS Mystery PSS Tool (3rd
)
•
Now we will talk about the differences between
CADENCE Perspec and Breker TrekSoC only.

6. Parameterized differences in Cadence
and Breker tools.
The basis of differentiation would be in the basis
•
of following parameters:
PSS Modeling
1.
PSS Constraint Solving
2.
PSS Test Intent
3.
PSS Libraries & Apps
4.
PSS Debug
5.
PSS Coverage
6.
Accellera PSS Language Support Plans
7.

7. PSS Modelling
To use PSS, you must break down your entire system into
subsystems.
Cadence Perspec Breker TrekSoC
With cadence it is easy to divide your
entire chip design into small subsystems,
also it uses pre-built libraries. Users have
the ability to customize a set of actions,
then Perspec figures out the possible i/p
and o/ps, and then build the test for you.
Whereas, Breker does the modelling as a
graph, for a system with lots of intertwined
dependencies, such as SoC with 50
subsystems, it’s very hard to use graph.
Also Breker uses libraries and call them
‘apps’. I/p and o/p are not clearly defined
Perspec supports Memory Management. It
supports coherency where multiple
processors must choose a small portion of
address range and share the same area.
Breker also supports memory
management. However, unlikePerspec,
their graph language itself does not assign
meaning to your steps and choices.

8. PSS Constraint Solving
PSS Model can be viewed as a set of constraints about the data flow in the
design. As a result, PSS tools have constraint solvers to generate all the
possible paths/tests.
Cadence Perspec Breker TrekSoC
With Perspec. You have to define the i/p
and o/p for all the different actions. The
tool then automatically solves all the
actions that produce an output that can
be consumed by that action.
Here we have to specify all the possiblle
connections in the graph ourselves.

9. PSS Test Intent
The way PSS works is it uses detailed models to describe all the scenarios you
want to test in a generalized form of a set of actions. When you are defining your
tests, you have the scenarios you want to create your test for. ‘Test Intent’
narrows the test space to only to tests you want to generate. This is done by a
way of text file or GUI.
Cadence Perspec Breker TrekSoC
It’s easier to capture and describe high-level
hierarchical actions in Perspec. With Perspec
you can create a library of higher level
sequences which use lower level actions. You
can then describe multiple sequences in full
detail. Perspec looks at your model to find all
possible sequences the test will execute,
then lets you choose exactly which test you
ant to generate.
Establishing test intent is harder with Breker,
because it must be shown in terms of graph
when you do your modelling, even if you
want to verify one element.
It’s easier to describe your partial intentions,
so that you only test what you care about.
Breker makes it hard to describe partial
intentions.

10. PSS Libraries & Apps
Both Cadence and Breker provide a set of ready-made models of actions for
a boat-load of different components, which are kept in repository. Pre built
libraries save many engineering man-months over the duration of a project
involving complex actions.
Cadence Perspec Breker TrekSoC
Perspec has an ARM library with an
extensive collection of low-level and high-
level actions. They also have a feature of
SML (system Modelling Library ) where it
lets people to build their own models.
These libraries also help a lot with the
entire coherency, ARM power, and ARM
process verification.
It is believed that Breker’s apps help the
users with ARM v8 and power
management.
Also, their coherency app is the most
popular app, with predefined models.

11. PSS Debug
You can use PSS tools to look at different parts of the design and the tests at
the same time to identify the source of the problem. Thus it help you save
time during debug
Cadence Perspec Breker TrekSoC
Perspec checks the test progress from
both a control-flow and data-flow
perspective. Perspec generally uses
graphical method for runtime debug.
Indago can be used independently with
other non-Cadence simulators. Its gives us
to see the progress in waveform.
Breker’s debugger works from a
microprocessor’s point of view. It doesn’t
show the data flow very well. The
debugging is mainly at low-level rather
than high-level

12. PSS Coverage
There are 2 types of coverage:
Pre runtime coverage – This is calculating your coverage before exercise of the test. The
•
idea is you get to know full spectrum of your coverage before you run your single test
case.
This is collecting your coverage after you’ve run all the tests. All the information needed
•
for runtime coverage calculation is dumped in your simulation log files.
Cadence Perspec Breker TrekSoC
Perspec has broader coverage functionality
than Breker. It calculates your pre-runtime
coverage for a scenario when the tests are first
generated, and then it calculates your
coverage after your tests are run. It shows:-
When certain transactions have started
•
When certain transaction have completed
•
If other transaction have taken place in
•
between.
You can define coverage across various actions
Breker also has pre-runtime coverage, but it
was a little simplistic in nature. Compared to
Perspec they don’t have the advanced runtime
coverage

13. Accelera PSS Language support plans
Accellera is working on it’s PS standard, which is
•
expected to be finalized in 2018
Once PSS is approved, it will have some built-in
•
constructs for vendors to add new functionality
according to their need.
The PSS being approved will also let us use our
•
generated tests from one tool vendor in another
vendor’s environment.

14. THANK YOU FOR YOUR TIME.
Select this paragraph to edit