Jasper RTL Design Bringup

Rapid Adoption Kit (RAK)

February 2023
Copyright Statement

© 2024 Cadence Design Systems, Inc. Cadence and the Cadence logo are
registered trademarks of Cadence Design Systems, Inc. All others are the property
of their respective holders.

This content is Cadence Confidential and for Cadence customers only.

DO NOT DISTRIBUTE.

2 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Objectives of this RAK

• Learn how Jasper Design Bringup can accelerate your design process.
• Learn to use Jasper FPV as an “instant testbench” for design exercise
much more efficiently than creating a simulation testbench.
• Learn key features of Jasper Visualize™ to explore the design
behavior.
• Gain confidence in early RTL, before handing off to validation.

➔“Shift left” your bug finding and improve design efficiency!

3 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Agenda

• A Motivating Demo
• Formal as Compared to Simulation
• Design Bringup: Challenges and Solutions
• Design Bringup: Lab

4 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Agenda

• A Motivating Demo
• Formal as Compared Simulation
• Design Bringup: Challenges and Solutions
• Design Bringup: Lab

5 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

A Common Problem

▪ RTL model but no testbench

▪ Desire: Test behaviors and waveforms Right-click on the
state variable in the
− Can parser reach the CHECKSUM state? source code to
visualize*.

* Equivalent to creating SVA cover

6 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.
Jasper solves backwards from state request
▪ Auto-generates trace (artificial simulation)
− From the space of mathematically possible traces
▪ Drives legal traffic from inputs
− No testbench / input pattern provided!

7 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Asking follow-up questions

▪ Are multi-cycle headers supported by this design?

− Request example of 5-cycle header Select the point in the
waveform and click the
option to modify

8 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

New waveform incorporating new constraint
▪ Input pattern changes radically
− Satisfies the original request (CHECKSUM)
…with the new constraint (5-cycle header)

9 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Does data need to change every cycle?
▪ Current waveform met requirements, but is hard to debug
− Is a simpler example possible?

10 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Asking Jasper for a “Quiet Trace”

11 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Agenda

• A Motivating Demo
• Formal as Compared to Simulation
• Design Bringup: Challenges and Solutions
• Design Bringup: Lab

12 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Simulation as Compared to Formal In Practice (1)
Concept Simulation Formal
Values checked Specific test values Universe of possible values
• How to target • Describe the journey • Describe the destination
• Constraining models • Limit the driven values • Behavioral assumptions

13 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Simulation as Compared Formal In Practice (2)
Concept Simulation Formal
Values checked Specific test values Universe of possible values
• How to target • Describe the journey • Describe the destination
• Constraining models • Limit the driven values • Behavioral assumptions
Debugging Fixed waveform Modifiable waveform
• “What-if” questions • Modify/rerun test • Add live constraint and replot
• Waveform length • Long: Arbitrary activity on path • Short: Tools aim for minimal
• Noise in waveforms • Hard to isolate the relevant • Tool can ‘Quiet Trace’
behavior

14 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Simulation as Compared to Formal In Practice (3)
Concept Simulation Formal
Values checked Specific test values Universe of possible values
• How to target • Describe the journey • Describe the destination
• Constraining models • Limit the driven values • Behavioral assumptions
Debugging Fixed waveform Modifiable waveform
• “What-if” questions • Modify/rerun test • Add live constraint and replot
• Waveform length • Long: Arbitrary activity on path • Short: Tools aim for minimal
• Noise in waveforms • Hard to isolate the relevant • Tool can ‘Quiet Trace’
behavior
Validation Efficiency Good Best
• General ROI • If you write and run many tests • Each run covers full space
• Corner case bugs • Rare: Depends on specific tests • Common: Covers all legal
behaviors under constraints

15 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Simulation as Compared to Formal In Practice (4)
Concept Simulation Formal
Values checked Specific test values Universe of possible values
• How to target • Describe the journey • Describe the destination
• Constraining models • Limit the driven values • Behavioral assumptions
Debugging Fixed waveform Modifiable waveform
• “What-if” questions • Modify/rerun test • Add live constraint and replot
• Waveform length • Long: Arbitrary activity on path • Short: Tools aim for minimal
• Noise in waveforms • Hard to isolate the relevant • Tool can ‘Quiet Trace’
behavior
Validation Efficiency Good Best
• General ROI • If you write and run lots of tests • Each run covers full space
• Corner case bugs • Rare: Depends on specific tests • Common: Covers all legal
behaviors under constraints
Capacity High: Run at cluster or full chip Lower: Aim at a unit or targeted logic
• Linear cost in model size • Worst-case exponential
Design/RTL Styles General SystemVerilog Synthesizable logic
Avoid complex data transformations
16 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.
Formal Challenges (I)

• Formal is a change in mindset

− Simulation: Target tests and drive actively
− Formal: Target behaviors and constrain passively

• FUD Factor
− Complexity: Will I get stuck?
− Coverage: How do I understand?
− Be careful: Due to assumptions, you cannot expect 100% coverage
− Integration with simulation coverage?
− Training: Can I learn this new thing?
− Setup Time: New types of collaterals, not old UVM tests

17 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Formal Challenges (II)
With training and
practice, FPV
• Formal is a change in mindset method is easier
− Simulation: Target tests and drive actively
− Formal: Target behaviors and constrain passively
Complexity is often
not an issue at the
• FUD Factor unit level, and good At design Bringup,
toolkits enable user full coverage is not
− Complexity: Will I get stuck? needed, but the
solutions
− Coverage: How do I understand? Jasper COV tool can
measure
− Be careful: Due to assumptions, you cannot expect 100% coverage.
− Integration with simulation coverage? Many training
− Training: Can I learn this new thing? available!
− Setup Time: New types of collaterals, not old UVM tests
FV setup easier from scratch – “easy”
sim setup is due to old UVM reuse
18 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.
Agenda

• A Motivating Demo
• Formal as Compared to Simulation
• Design Bringup: Challenges and Solutions
• Design Bringup: Lab

19 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Bringup Challenge 1: Missing Pieces
Default
bbox All Behavior

Assume {behavior}
bbox Constrain

Assert {behavior}
Done Check

• Traditional Bringup • Formal Bringup

o Not all RTLs are complete/compilable o Missing modules can be black boxed
o Modeling missing parts takes a lot of time – Tests all possible behaviors by default
– Optional assumptions can be added to constrain the behavior
o Throwaway work on low-level modeling
o When the instance becomes available, change
assumptions to assertions

20 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Bring-Up Challenge 2: Stimulus

• Traditional Bringup • Formal Bringup

o Local testbench creation is time-consuming o Specify the destination, not the journey
– Jasper solves backwards from desired state/output
o It is hard to get the protocol-compliant
stimulus o Leverage Formal VIP for interface protocols
o Block-level testing is useless at the system o SVAs you create are reusable at higher levels
level – For both simulation and formal

21 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Bring-Up Challenge 3: Checkers

• Traditional Bringup • Formal Bringup

o Takes a lot of time developing checkers o Superlint provides automatic formal for common issues
o Each check relies on a specific stimulus such as overflow and deadlocks
o Checkers usually provide little value to o Focus on the end behavior and formal finds the stimulus
other RTL developers or verification team o Use Visualize to capture interesting behaviors
o Most checks usable by the verification team (simulation
or formal) and by other designers

22 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Bringup Challenge 4: Dead Code and Unreachable Behaviors

• Traditional Bringup • Formal Bringup

o Time is wasted in trying to test behaviors that o Jasper can prove a state or behavior is
are unreachable impossible
o There is no way to confirm unreachability in o It can formally prove RTL to be unreachable
simulation with Superlint dead-code checks
o Unreachability can indicate an RTL bug

23 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Bringup Challenge 5: Poor Visibility at System Level

“Yes! Simulation is exercising

them at the system level!”
“Here are things that
should be exercised in
system-level simulation”

• Traditional Bringup • Formal Bringup

o Once you send your RTL “over the wall”, is o Behaviors that you visualize during the design
the verification team exercising things you Bringup can be preserved as SVA properties
are concerned about? o SVAs can be handed off to the verification
o Bug escapes often occur where the team, usable in simulation and emulation
system-level tests are not testing what you
need them to

24 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Bringup Challenge 6: Pinpointing the Root Cause
“Why”
Analysis

Quiet
Trace

The problem is here!

(no more wasted time debugging
backwards from the system outputs)

• Traditional Bringup • Formal Bring-up

o Simulation traces are long, non-minimal o Jasper usually finds the shortest waveform
o Thus, root-cause analysis can be hard o Powerful root-cause tracing in Jasper Visualize
– Which is the block that failed?
– Where is the failure in the block? o Exported SVA properties can check for similar
failures in system simulations

25 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Design Exploration + Bringup
Clean Write Let Jasper
Compile design generate More
Clean linting Superlint properties for
and do structural stimulus for behaviors to
with waivers dead code interesting interesting
inspection explore?
with waivers behaviors behaviors

Debug Debug
Debug Export
generic design- Save
interface
failures
behaviors
w/ Superlint
specific
behaviors
waivers
properties for
simulation Handoff!
26 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.
When is your design ready to handoff to verification?

▪ Superlint passes a predetermined baseline

▪ Initialization looks correct

▪ Interfaces are clean…no protocol violations

▪ Critical good behaviors can be covered

▪ No failing basic functional behaviors

▪ Waivers have been saved

▪ Important Bringup properties added as embedded SVAs in RTL

27 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Agenda

• A Motivating Demo
• Formal as Compared to Simulation
• Design Bringup: Challenges and Solutions
• Design Bringup: Lab

28 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Jasper Design Bringup: Lab

▪ Demonstrating design Bringup on a small RTL

− “Elevator Controller” model

▪ Note: Not including Superlint steps

− Recommended: Superlint on RTL before FPV exercise
− Superlint handled in separate RAKs
− Basic lint:
https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O3w000009FNdfEAG&pa
geName=ArticleContent
− Auto Formal:
https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O3w000009l3bQEAQ&pageName=
ArticleContent

29 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Set up and confirm tool installation

• Confirming your license and Jasper version

– Type the following in your shell:
– % jg –version
– % jg -fpv -batch

• These should display the Jasper version. You should be running with 2021.06FCS
or newer.

• Unpack the RAK distribution package in your work area. This document and all
files needed to run the example are included in the package.

30 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Cycle N Cycle N+1
Design Overview for Lab floor_to_stop_at floor_to_stop_at

0 Bit 0 0 Bit 0
• The elevator controller is responsible for determining when 0 Bit 1 0 Bit 1
the elevator should move up or down or stop. 1 Bit 2 1 Bit 2
Request 0 Bit 3 1 Bit 3
Button[3]
• There is a single request input (request_button) for
each floor. Once request_button for any floor is high, it
is set in the floor_to_stop_at array. Request
0 Bit 14 1 Bit 14
Button[14]
1 Bit 15 0 Bit 15
• The FSM decides if the elevator goes up or down or waits.
Floor_done=‘d15
• When floor_to_stop_at is reached, floor_done
indicates which bit to clear. The elevator then waits until
ready_to_move goes high again.
elevator_top.v
Door
Door_motor_control
• The going_up flag toggles from high to low if the Open/Close
door_controller
floor_done vector equals cfg_reg_top_floor. It Sense ready_to_move
toggles from low to high when it equals 1. Current
Floor[3:0]
0
0
• The door_controller instance (black boxed) provides Request 1
0 floor_done FSM Elevator
the ready_to_move signal that tells FSM when the doors Button[15:0]
0
cfg_reg_top_floor
Control
have closed, and the elevator can move again. 1
(Up/Down/
floor_to_stop_at Stop)
going_up? cfg

31 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Design Overview for Lab (Contd.)
• Finite State Machine (FSM) for the elevator_top module is shown below,
with the conditions simplified to help you get familiar with the design.

~floor_to_stop_at[next floor] &&

current_floor != cfg_reg_top_floor ~ready_to_move ~floor_to_stop_at[next_floor] &&
current_floor != 1

floor_to_stop_at[next floor]
ready_to_move &&
||
going_up current_floor==1

floor_to_stop_at[next floor] ready_to_move &&

|| ~going_up
current_floor==cfg_reg_top_floor

32 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 How black boxing
Black boxing can help you

• As mentioned in the previous slide, door_controller is black

boxed.

• Objective is to verify the elevator_top module, even though you

do not have the RTL available for the door_controller module. elevator_top.v
Door Door_motor_control
Open/Close
• In Jasper, you can compile elevator_top and indicate that you Sense door_controller ready_to_move
want to black box door_controller.

• This means that Jasper can wiggle each blackbox output any way
that it wants in ANY cycle! FSM

• How you can constrain this behavior will be shown later in the RAK.

• You might want to consider black boxing large or complex elements

in your design. Jasper will automatically black box large memory
arrays and multipliers by default.

• For more details on blackboxing commands, see Tcl Help for the
elaborate command or the following video: Because door_controller is
– Article (20467784) An Introduction To Elaborating Designs in black boxed, ready_to_move and
Jasper (Video)
https://support.cadence.com/apex/ArticleAttachmentPortal?id=a door_motor_control can take
1O0V000007MnuKUAS
ANY value in ANY cycle!

33 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Compiling the RTL

• You need to compile your design in

Jasper. Code should be fully
synthesizable Verilog, SystemVerilog,
or VHDL.

• There are some non-synthesizable

constructs, such as “initial” blocks,
which will compile but will be ignored
by Jasper.

• This design is all Verilog and located

in a single file named
elevator_top.v.

• Notice that there is one clock named

clk and one active-high reset named
rst.
34 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.
 Compiling the RTL
• With your preferred text editor, create a new file named
run_elevator_top.tcl.
Setting up Tcl to load your design into Jasper
• This file will be used to compile the design and tell Jasper what your
clock and reset look like.
run_elevator_top.tcl
• The elaborate command contains the -bbox_m door_controller
switch to tell Jasper you we are black boxing this module. # Clear environment
clear -all
• See the Tcl Help for additional capabilities of the analyze and
elaborate commands.

• Copy the text at the right (or from # Compile HDL files
<RAK_install>/solution/compile_rtl.tcl) to create your Tcl
file. analyze -sv elevator_top.v
elaborate -top elevator_top -bbox_m
• For more information about analyze and elaborate, see the door_controller
following videos:
Article (20467785) Introduction to the Analyze Command for Jasper (Video)
https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O0V00000
7MnuoUAC
Article (20467784) An Introduction To Elaborating Designs in Jasper (Video)
https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O0V00000
7MnuKUAS

35 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Launching Jasper
Launching Jasper

• You can first launch Jasper from your terminal:

% jg run_elevator_top.tcl
Jasper Apps 2023.06 FCS 64 bits 2023.04.01 18:13:48 PDT

• You will see the Jasper GUI with the design loaded

36 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Linting checks
Basic Compile Issues: Analyze/Elaborate
• After launching Jasper, you will see
compilation warnings in the message log.

• Let us debug the first VERI-1214 warning.

• This warning says you are assigning a value

to an input named cfg_rd_data.

• You can click on the link to RTL line 33 (blue)

to bring up the Source Browser, which
highlights the line of RTL where you have the
problem.

• This is a problem because cfg_rd_data is

incorrectly declared as an input.

• TIP: You can right-click in the source code

pane and choose Edit to bring up an editor.
To configure which editor you prefer, you can
go to the Jasper menu bar and choose Edit >
Preferences > External Tools. Here, you
can enter the command used to launch your
favorite editor.

37 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Basic Compile Issues: Analyze/Elaborate (Contd.)
• Edit elevator_top.v to change
cfg_rd_data from an input to an
output.

• Then, reload the Tcl file by going to

the toolbar, pressing the small down
arrow, and choosing the
run_elevator_top.tcl script.

38 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Design Hierarchy
• After relaunching Jasper, right-click
on elevator_top in the hierarchy
and choose Open in Source
Browser Window.

• In the search bar, type cfg and

choose Source Code Pane from
the drop-down menu.

• Notice that you can also search

the Design Hierarchy, Full
Instance Paths, and so on. In
large designs, this can be very
useful.

39 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Design Hierarchy (Contd.)

• In the Source Browser, you can

see that door_controller is a
blackbox. Click on it to select it.

• To see the instantiation of

door_controller_inst, click
on the Show Instantiation button.
This shows you the instantiation in
the Source Browser.

• Close the Source Browser.

40 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Defining clock and reset
Clock and Reset

• Before you run Jasper on your design, you need to define the clock and
reset.

• For simple designs, use the following Tcl commands in the Jasper Console:
clock <your_clock>
reset <your_reset>

• In the next section, you will see how to use the clock viewer and reset
analysis to help you declare clock and reset.

41 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Clock Viewer Clock schematic

• Now, use Clock Viewer to help identify and

declare a clock. In the toolbar, click on the Clock
Viewer button.

• The table shows that there is only one clock.

Click on the button shown on the right to bring up
a schematic of the clock cone-of-influence.

• The schematic can be useful to help you

understand which clocks you need to declare.

• In this design, the clock is simple. In more

complex designs, it can help identify undriven
clocks and registers driven on different clock
edges, gated clocks, clock dividers, and more.

• Close the schematic.

• Right-click on the clk signal in the table and

choose Declare Clock.

• You do not have any special clock requirements,

so just press OK in the dialog that appears.

• You can now close the Clock Viewer window.

42 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Reset Analysis
• Click on the Reset button in the toolbar.

• Choose Pin constraint, which will let Jasper drive

the reset pin and reset all your flops.

• Next, choose Infer to find out which pin controls

your reset. Press Yes to proceed.

• You will see that one reset pin named rst was
found.

• Press OK to finish.

• In more advanced designs, reset analysis can

identify sync/async reset conditions, multiple top-
level reset pins feeding flops, the number of flops
and properties using the reset, and more.

• For more information on reset analysis, refer to the

following:
– Article (20417121) Reset Analysis and Verification
with Jasper Apps
https://support.cadence.com/apex/ArticleAttachmentP
ortal?id=a1Od000000050ZgEAI

43 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Tcl history
Editing your Tcl file
• Now that you have identified the clock
and reset, you need to add the clock
and reset commands to your Tcl file.

• You can source this Tcl file again at

any time to instantly set up your
formal environment.

• In the File menu, choose View Tcl

Command History.

• This gives you a list of all commands

you have run so far and gives an easy
way to copy the commands.

• Copy the clock and reset commands

and paste them at the bottom of your
run_elevator_top.tcl file in your
text editor.

• Close the Tcl History window and

save the file in your editor.

44 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Querying the design
Querying the design
• Jasper offers some powerful ways to help you
query the design.

• In the Console, you can use get_design_info

to get a summary of the design. The numbers
in parentheses are “bit-blasted” counts.

• Some other switches that you can pass are

shown on the right.

• The command returns a Tcl list, which can be

used to pass on to other Tcl commands.

• For more information and examples, you can

type help get_design_info -gui in the
Console.

45 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

Checking Basic Behavior
• Select some state or output signal of your choice in RTL & right-click, choose “Modify Value”
• Modify the Expression field as needed and click OK
• Examine the resulting waveform for a quick look at one behavior
• Right-click on the final cycle of the wave and select Add Relevant Input/Undriven Signals
• Note: This is an experiment to check the basic behavior; the real work is on the next slide…
• But this type of experimentation is very useful for a quick initial check
Right-click on the
state variable in
source code to
visualize*.

46 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 RTL design Bringup
Defining interesting behaviors flow

• Now, you need to plan the good behaviors to exercise more systematically
• As you exercise the design, you will capture additional behaviors as properties that can
be handed off to other simulation and formal teams
• You iterate between exercising and capturing properties until you are satisfied

Fix RTL and add Properties

Create exercise plan • Capture additional good
•Create a list of good behaviors as “Cover” properties
behaviors you want • Add assumes (as needed)
to exercise • Add assertions (optional)

Iterate

Exercise Design
• Exercise the good behaviors in your plan
• Interactively visualize these good
behaviors
• Inspect these waveforms for bad
behaviors

47 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Developing a design
Creating exercise plan exercise plan

• Now, start with planning out the good behaviors you want to exercise

• You want to check some parts of the design for simple reachability. For example, you can check that all FSM states can be reached.

• You also have functional sequences you can exercise. In this case, you want to observe that the elevator can go all the way up and down and that
the top floor can be reprogrammed

• Rather than telling Jasper what you want to do with the inputs, you tell it what you want to observe. Jasper will generate the input stimulus required to
show the behavior

• The plan has been color-coded against the block diagram to show which tests are exercising each part of the design

• Reachability
– All FSM states and transitions are reachable elevator_top.v
Door Door_motor_control
– All valid output states are reachable Open/Close
door_controller
Sense ready_to_move
– Configuration bits can be programmed
• Functional Sequences Current
Floor [15:0]
– Elevator goes all the way up and down twice (UP > 0
0
1
FSM
Request floor_done
Down > Up > Down) Button[15:0]
0 Elevator
Control
– Elevator goes up, then stops, then continues going
0
1 cfg_reg_top_floor
(Up/Down/Stop)
up, then goes down (UP > Wait> Up > Down) floor_to_stop_at
going_up? cfg
– While going up, you reprogram the top floor (UP >
CFG > UP > CFG > Down)

48 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Adding covers for
Creating exercise plan (Contd.) // ***************************************************************************
// Coverage (Reachability)
// ***************************************************************************
good behaviors
cov_elevator_top_fsm_WAIT: cover property (@(posedge clk) state==WAIT);
Edit elevator_top.v and copy the SVA cover properties at the bottom cov_elevator_top_fsm_ELEVATOR_UP: cover property (@(posedge clk) state==ELEVATOR_UP);
cov_elevator_top_fsm_ELEVATOR_DOWN: cover property (@(posedge clk) state==ELEVATOR_DOWN);
of the RTL, just above endmodule. You can copy from cov_elevator_top_fsm_WAIT_to_WAIT: cover property (@(posedge clk) state==WAIT ##1 state==WAIT);
<RAK_install>/solution/sva_cover_properties.txt. cov_elevator_top_fsm_WAIT_to_UP: cover property (@(posedge clk) state==WAIT ##1 state==ELEVATOR_UP);
cov_elevator_top_fsm_WAIT_to_DOWN: cover property (@(posedge clk) state==WAIT ##1
state==ELEVATOR_DOWN);
You can theoretically define all these by cov_elevator_top_fsm_UP_to_WAIT: cover property (@(posedge clk) state==ELEVATOR_UP ##1 state==WAIT);
cov_elevator_top_fsm_UP_to_UP: cover property (@(posedge clk) state==ELEVATOR_UP ##1
clicking in the GUI, but it is much easier to state==ELEVATOR_UP);
write and maintain SVAs when you have cov_elevator_top_fsm_DOWN_to_WAIT: cover property (@(posedge clk) state==ELEVATOR_DOWN ##1
state==WAIT);
many in your plan cov_elevator_top_fsm_DOWN_to_DOWN: cover property (@(posedge clk) state==ELEVATOR_DOWN ##1
state==ELEVATOR_DOWN);

Exercise Plan cov_elevator_top_out_stop: cover property (@(posedge clk) elevator_control==ELEV_MOTOR_STOP);

cov_elevator_top_out_up: cover property (@(posedge clk) elevator_control==ELEV_MOTOR_UP);
cov_elevator_top_out_down: cover property (@(posedge clk) elevator_control==ELEV_MOTOR_DOWN);
• Reachability
– All FSM states and transitions are reachable cov_elevator_top_cfg_all_zero:
cov_elevator_top_cfg_all_ones:
cover property (@(posedge clk) cfg_rd_data==4'b0000);
cover property (@(posedge clk) cfg_rd_data==4'b1111);
– All valid output states are reachable
– Configuration bits can be programmed // ***************************************************************************
// Coverage (Functional Sequences)

• Functional Sequences // ***************************************************************************

cov_elevator_top_up_down_up_down: cover property (@(posedge clk) state==ELEVATOR_UP ##[1:$]

– Elevator goes all the way up and down twice (UP >
state==ELEVATOR_DOWN ##[1:$]
state==ELEVATOR_UP ##[1:$]
state==ELEVATOR_DOWN);
Down > Up > Down)
– Elevator goes up, then stops, then continues going // This cover shows requests coming in while we are going up. So we have to stop along the way to the highest floor
up, then goes down (UP > Wait > Up > Down) cov_elevator_top_up_wait_up_wait_down:cover property (@(posedge clk) state==ELEVATOR_UP ##5
state==WAIT ##6
– While going up, you reprogram the top floor (UP > state==ELEVATOR_UP ##3
state==WAIT ##[1:$]
CFG > UP > CFG > Down) state==ELEVATOR_DOWN);

// This cover shows the upper floor being re-programmed as we are going up
cov_elevator_top_up_cfg_up_cfg_down: cover property (@(posedge clk) state==ELEVATOR_UP ##[10:$]
~$stable(cfg_reg_top_floor) ##[1:$]
state==ELEVATOR_UP ##[1:$]
~$stable(cfg_reg_top_floor) ##[1:$]
state==ELEVATOR_DOWN);
49 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.
 Exercising the design
• Now that you have your “good behavior” cover properties, reload the run_elevator_top.tcl
script, which will recompile your design to include these properties

• Type the following into the Jasper Console:

• You will now see that there are 18 cover properties in the design:

• Click on Prove All in the toolbar:

18 Cover Properties!

50 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Exercising the design (Contd.)
• You will see that green checkmarks show up next to each property, indicating that Jasper managed cover that
property

• If you type fsm in the property filter box, you can see that all your FSM states and transitions have been reached:

• Reachability
– All FSM states and transitions are reachable
– All valid output states are reachable
– Configuration bits can be programmed
• Functional Sequences
– Elevator goes all the way up and down twice (UP >
Down > Up > Down)
– Elevator goes up, then stops, then continues going up,
then goes down (UP > Wait > Up > Down)
Note: You may see different information here,
– While going up, you reprogram the top floor (UP →
depending on the tool version and settings. This
CFG > UP > CFG > Down)
RAK will not cover formal engines.

• By browsing/filtering Property Table, you can quickly see that all your reachability requirements have been met!
• Because you used a good naming convention for your properties, searching for properties is easier

51 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Viewing a trace
Exercising the design (Contd.)
• Now, look at the waveform for one of the functional sequences

• You want to inspect the waveform to confirm that the behavior is reached in a ”reasonable” way. This might
not be the only way it can be reached, but it is often the shortest.

• Right-click on elevator_top.cov_elevator_top_up_down_up_down and choose View Cover Trace.

• Reachability
– All FSM states and transitions are reachable
– All valid output states are reachable
– Configuration bits can be programmed
• Functional Sequences
– Elevator goes all the way up and down twice (UP >
Down > Up > Down)
– Elevator goes up, then stops, then continues going up,
then goes down (UP > Wait > Up > Down)
– While going up, you reprogram the top floor (UP >
CFG > UP > CFG > Down)

52 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 “Why” analysis
Exercising the design (Contd.)
Add Relevant Input/undriven signals

• The Visualize window displays, showing the trace where the cover property is reached

• Something does not look right. You see that FSM is transitioning too quickly. It is toggling between
down and up several times within only 12 cycles!

• Let us see why it is immediately going back down in cycle 8

• Right-click on the value of state in cycle 8 and choose Add Relevant Input/Undriven Signals

53 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Zooming the waveform
Exercise the design (Contd.)
• You can see that Visualize has provided the values at the primary inputs automatically!

• You notice that the current_floor input is not behaving legally. It is jumping randomly from floor to floor!

• Use the zoom buttons on the toolbar to zoom in to see what is going on.

Not legal!

54 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 “Assume-Guarantee”
Adding properties Converting assert to assume
• You check with the design architect who says that the current floor input comes from the output of a ‘sensor decoding’ block. This block should never skip
floors from cycle to cycle. In addition, it should only change if the elevator control is indicating that the motors are moving the elevator up or down!
• This seems like something you want to guarantee. If any upstream module (or simulation) violates this behavior, you need to know about it.
• Because this behavior should be guaranteed, you should first write it as an SVA assertion that compiles with your RTL. Then, if you are ever testing this
module as the top level (like here), you can convert it to an assumption by using a special command in Jasper. This methodology is sometimes named
“Assume-Guarantee.” You are assuming the behavior at the inputs to your block, and this behavior can be verified in other formal testbenches, and even in
simulation.
• Another way to do this is to have each of these properties be an assert property <expression> by default and have an `ifdef ASSUME_INPUTS
macro choose an assume property <expression> version of the same property. You want to make it an assert by default, because if this module is ever
instantiated somewhere else, you do not want assumptions on signals that are not the top level.

Copy from <RAK_install>/solution/sva_input_properties.txt to the Copy from <RAK_install/solution/assert_to_assume.tcl to the bottom of

bottom of elevator_top.v, above “endmodule” run_elevator_top.tcl
// *************************************************************************** assume -from_assert <embedded>::elevator_top.ast_elevator_top_input_next_floor_up
// Assume or Assert behavior at the input to the elevator controller assume -from_assert <embedded>::elevator_top.ast_elevator_top_input_next_floor_down
// Note: We will convert these to assumptions in the TCL script, if necessary assume -from_assert <embedded>::elevator_top.ast_elevator_top_input_current_floor_behavior
// ***************************************************************************
ast_elevator_top_input_next_floor_up: assert property (@(posedge clk)
elevator_control==ELEV_MOTOR_UP |=> current_floor==($past(current_floor) + 1'b1))
else $display ("ERROR: motor up and current floor not incrementing");

ast_elevator_top_input_next_floor_down: assert property (@(posedge clk)

elevator_control==ELEV_MOTOR_DOWN |=> current_floor==($past(current_floor) - 1'b1))
else $display ("ERROR: motor down and current floor not decrementing");

ast_elevator_top_input_current_floor_behavior: assert property (@(posedge clk)

elevator_control== ELEV_MOTOR_STOP |=> $stable(current_floor)) else $display
("ERROR: current floor changed when motor was stopped");

55 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Re-exercising design with added properties
• You can now exercise the design again with your new assumptions

• Type the following into the Jasper Console:

• If you scroll through Property Table, you will now see your three
new assumptions:

56 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Re-exercising the design with added properties (Contd.)
• Use the Prove All button again to prove all properties.

• In the Property Table filter bar, type up_down_up_down to search for the property
you previously looked at:

• Double-click on the property to open the trace, which will now have all your
assumptions applied.

57 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Adding signal
Re-exercising the design with added properties (Contd.)

• Now, click on the Add Signal

button and add current_floor
to confirm that your assumption
fixes the floor behavior.

• As you can see, current_floor

looks good. It is incrementing
and decrementing by 1.

• But why is state going down

in cycle 3 and back up in cycle
6 and down again in cycle 8?

58 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Re-exercising the design with added properties (Contd.) Adding Why signals

• Right-click on state in cycle

6 and choose Add Why
Signals.

• The signals that contribute to

the state changing in cycle
6 are added automatically.

• You know from the design

description that the going_up
flag toggles when it equals
cfg_reg_top_floor.

• Now, see if this is what is

happening. Right-click on
going_up in cycle 7 and
choose Why.

59 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Re-exercising the design with added properties (Contd.)
• After choosing Why on a signal in a
cycle, the source code pane appears

• The source code is annotated with the

signal values contributing to why
going_up went low in cycle 7

• You can see that it is pointing to line

66, and that cfg_reg_top_floor is
equal to 4’b0001

• This is why going_up toggles low!

• Now, plot the value of

cfg_reg_top_floor

• In the source code pane, right-click on

cfg_reg_top_floor and choose
Plot Selected Signals

• Optionally, you can just drag any

signal from the Source Browser to the
waveform

60 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Re-exercising the design with added properties (Contd.) Adding Visualize constraint
• Jasper is driving the configuration logic
so that cfg_reg_top_floor changes
periodically

• This might be realistic, but suppose you

wanted to see what happens if you force
the value of cfg_reg_top_floor to be
4’b1111

• You do not want to add an SVA constraint

because that is a dangerous over-
constraint!

• Because this is just a quick experiment,

you can add the constraint so that it only
exists inside this Visualize window

• Click on the value of cfg_reg_top_floor

in any cycle
Why did we choose 2
• Now, click on the Add Constraint button instead of 1 as the starting
in the toolbar cycle?

• In the Add Constraint dialog, choose Because “cfg_reg_top_floor”

Force, set the value to 4’b1111, and is a flop that MUST take on
specify On Cycles with 2 to $. Then, its reset value of 4’b0000 in
press OK.
cycle 1
61 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.
 Re-exercising the design with added properties (Contd.)
• Press the Replot
button to replot with
your new constraint

• You can see that

cfg_reg_top_floor
is programmed to be
4’b1111 from 1 to $

• Now, your trace is

much longer, which
makes sense because
the elevator needs to
go all the way up to
floor 15 and back down
to 1!
62 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.
 Re-exercising the design with added properties (Contd.)
• Closer inspection of the waveform reveals
that something is wrong

• From the design specification, you know

that when floor_to_stop_at[current_floor]
is true, you should stay at that floor
(state==WAIT)

• You can see that floor_to_stop_at[3]

is set.

• But instead of stopping at floor 3,

current_floor goes all the way back
to floor 1 before you go to the WAIT state!

• This is a bug!

• If you add the entire floor_to_stop_at

vector to the waveform, you can clearly
see that you should stop at at both floor 3
and floor 1.

63 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Re-exercising the design with added properties (Contd.)

• This is a good opportunity

to add an assertion
property to check that this
behavior never happens

• Now, use the bad behavior

in the waveform as a guide English
“IF state is equal to ELEVATOR_DOWN …THEN state should be
AND floor_to_stop_at[current_floor-1] WAIT on the next cycle.”
is true…
• In cycle 34, you know that
you need to stop at floor 3
on cycle 35. So, state SVA
should equal WAIT in cycle Assert (state==ELEVATOR_DOWN && floor_to_stop_at[current_floor-1] |=> state==WAIT)

35

64 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Re-exercising the design with added properties (Contd.)

• You will see that there are two SVA checkers, one for ELEVATOR_UP and another for
ELEVATOR_DOWN

• Edit elevator_top.v and copy the SVA checker properties as shown below. Paste
them at the bottom of the RTL, just above endmodule. You can also copy these directly
from <RAK_install>/solution/sva_checker_properties.txt.

// ***************************************************************************
// Assert correct behavior of the elevator controller
// ***************************************************************************
ast_elevator_top_stop_at_next_floor_down: assert property (@(posedge clk) state==ELEVATOR_DOWN &&
floor_to_stop_at[current_floor-1] |=> state==WAIT) else $display ("ERROR: did not stop at floor correctly when going down");

ast_elevator_top_stop_at_next_floor_up: assert property (@(posedge clk) state==ELEVATOR_UP &&

floor_to_stop_at[current_floor+1] |=> state==WAIT) else $display ("ERROR: did not stop at floor correctly when going up");

65 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Re-exercising the design with added properties (Contd.)
• As you inspect this waveform, you also see that
ready_to_move wiggles too fast

• This signal comes from door_controller,

which is black boxed

• You check the architectural specification and

find that when state==WAIT, the
ready_to_move signal from door_controller
should go high between 1 and 20 cycles later.

• Because you are not responsible for the

door_controller logic, you should add an
assertion at the output of door_controller
that verifies this behavior.
•
Then, because you are black boxing
door_controller, you need to convert this
assertion to an assumption by using a Tcl elevator_top.v
command. Door Door_motor_control
Open/Close
Sense door_controller ready_to_move
• This assumption will let Jasper wiggle the
ready_to_move signal according to the
specification while you test your logic.
FSM
• In the next slide, you will fix your RTL and add
this property on the ready_to_move signal.

66 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Fixing RTL and adding properties
• When you inspect the RTL for the
floor_to_stop_at bug on the previous
page, you find that you have a typo in the
ELEVATOR_DOWN state. Fix the following
line of RTL:

• Next, you add a property to the ready_to_move signal as follows, so that if you black box
door_controller, the property is an assumption. If door_controller is not black boxed, it is
an assertion.
Copy from <RAK_install>/solution/sva_door_controller_properties.txt Add the following (in red) to run_elevator_top.tcl
to bottom of elevator_top.v, above “endmodule” # Clear environment
// clear -all
**********************************************************************
// Assume or Assert behavior at the output of the door controller
// Note: Here we are showing one way to convert assumptions to # Compile HDL files
assertions using a `define analyze -sv elevator_top.v +define+DOOR_CONTROLLER_IS_BBOXED
// elaborate -top elevator_top -bbox_m door_controller
**********************************************************************
`ifdef DOOR_CONTROLLER_IS_BBOXED clock clk
asm_door_controller_output_ready_to_move: assume property reset rst
(@(posedge clk) state==WAIT |-> ##[1:20] ready_to_move) else $display
("ERROR: ready_to_move failed to occur in the required time"); assume -from_assert
`else <embedded>::elevator_top.ast_elevator_top_input_next_floor_up
ast_door_controller_output_ready_to_move: assert property assume -from_assert
(@(posedge clk) state==WAIT |-> ##[1:20] ready_to_move) else $display <embedded>::elevator_top.ast_elevator_top_input_next_floor_down
("ERROR: ready_to_move failed to occur in the required time"); assume -from_assert
`endif <embedded>::elevator_top.ast_elevator_top_input_current_floor_behavior

67 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 Re-exercising the design after adding properties to RTL
• Once again, you can exercise the design

• Type the following into the Jasper Console:

• If you search for ready_to_move with the Property Table filter, you will now see your new assumption on the
ready_to_move signal. In addition, Jasper has created an automatic cover property that checks to ensure that
the precondition of your assumption can be covered!

68 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

 ❑Reachability
Conclusion and Next Steps ❑ All FSM states and transitions are reachable
❑ All valid output states are reachable
• You tried initial FPV-based design Bringup ❑ Configuration bits can be programmed
• You identified bugs quickly on new RTL ❑Functional Sequences
• You did a “shift left” of basic validation ❑ Elevator goes all the way up and down twice (UP →
Down → Up → Down)
• We have gained confidence in the design ❑ Elevator goes up, then stops, then continues going
up, then goes down (UP → Wait → Up → Down)
• There is plenty more to do in Bringup; you do not ❑ While going up, you reprogram the top floor (UP →
verify the full spec CFG → UP → CFG → Down)
– Goal is to get basic confidence and reduce work for the
validation team
– That will be part of the formal signoff methodology, a
more advanced FPV topic
• This concludes the RAK!
• For more information on more powerful Jasper Visualize features and initial Superlint steps, refer to the following:
Visualize; Freeze and Add Constraint (Video) https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1Od0000000511NEAQ&pageName=ArticleContent
Visualize RTL Signal and Highlight Relevant Logic (Video) https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1Od000000050u4EAA&pageName=ArticleContent
Visualize Features: Clone, QuietTrace and Highlight Difference (Video)
https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1Od000000050taEAA&pageName=ArticleContent
Custom Markers and Vertical Annotation in the Visualize Window (Video)
https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O0V0000091BqGUAU&pageName=ArticleContent
Jasper Visualize GUI Features https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O0V000007Mh9EUAS&pageName=ArticleContent
Introduction to Jasper® Superlint App (RAK) – Jasper front-end https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O0V000006Aia8UAC
Overview of Jasper X-Propagation Verification App (Video) https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O0V0000067A1SUAU&pageName=ArticleContent
Superlint- Basic Linting: https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O3w000009FNdfEAG&pageName=ArticleContent
Superlint- Auto Formal: https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O3w000009l3bQEAQ&pageName=ArticleContent
69 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.
Support and Feedback

• Support
Cadence Learning and Support Portal provides access to support resources, including
an extensive knowledge base, access to software updates for Cadence products, and
the ability to interact with Cadence Customer Support. Visit
https://support.cadence.com.

• Feedback
Email comments, questions, and suggestions to [email protected].

70 © 2024 Cadence Design Systems, Inc. DO NOT DISTRIBUTE.

© 2024 Cadence Design Systems, Inc. Cadence, the Cadence logo, and the other Cadence marks found at www.cadence.com/go/trademarks are trademarks or registered trademarks of Cadence Design Systems, Inc. Accellera and
SystemC are trademarks of Accellera Systems Initiative Inc. All Arm products are registered trademarks or trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere. All MIPI specifications are registered trademarks or
service marks owned by MIPI Alliance. All PCI-SIG specifications are registered trademarks or trademarks of PCI-SIG. All other trademarks are the property of their respective holders.
This content is Cadence Confidential and for Cadence customers only. DO NOT DISTRIBUTE.