Assertion Based Verification, Checkers and Smart Lint

1
Assertion Based Verification, Checkers and Smart
Lint

• Itai Yarom Viji Patil
• Intel

2
What is the verification challenge?

• Some of the questions a designer might have
• How can I identify real problems from thousands
  of lint violations?
• How many paths with no synchronization are a real
  problem?
• How can I improve my level of guaranty in the
  verification environment?
• How can I verify false-paths and multi-cycle
  paths?
• Outline
• The design verification gap
• Assertion based verification Checkers
• Smart-lint Benefits
• Summary Results

3
Design Verification Gap

• The number of transistors on a chip increases
  approximately 58 per year, according to Moore's
  Law.
• The design productivity, facilitated by EDA tool
  improvements, grows only 21 per year.
• These numbers have held constant for the last two
  decades.
• Roger Allan, Think Small Can You Meet The Design
  Challenges At 90 nm And Below?, Electronic Design
  Journal, Feb 2005.

4
Design Verilog VHDL

• library IEEE
• use IEEE.std_logic_1164.ALL
• entity alu is (clk in std_logic
• rst_n in std_logic
• wr_en in std_logic
• adr in std_logic_vector(13 downto 0)
• data out std_logic_vector(12 downto 0) )
• end alu
• architecture rtl of alu is
• signal mem std_logic_vector()
• begin
• process (clk, rst_n) begin
• if rst_n 0 then
• data(12 downto 0) lt (others gt 0)
• elsif clkevent and clk 1 then
• if wr_en 1 then
• data(12 downto 0) lt mem(adr)
• end if

• module alu (clk, rst_n, wr_en, adr, data)
• input clk, rst_n, wr_en
• input 130 adr
• output 120 data
• wire clk, rst_n, wr_en
• wire 130 adr
• reg 120 data
• wire 120 mem 130
• always _at_(posedge clk or negedge rst_n)
• if (!rst_n)
• data120 lt 12b0
• else if (wr_en)
• data120 lt memadr
• endmodule

5
Design Verilog SystemVerilog

• module alu (clk, rst_n, wr_en, adr, data)
• input clk, rst_n, wr_en
• input 130 adr
• output 120 data
• wire clk, rst_n, wr_en
• wire 130 adr
• reg 120 data
• wire 120 mem 130
• always _at_(posedge clk or negedge rst_n)
• if (!rst_n)
• data120 lt 12b0
• else if (wr_en)
• data120 lt memadr
• endmodule

• module alu (input clk, rst_n, wr_en,
• input 130 adr,
• output reg 120 data)
• wire 120 130 mem
• always_ff _at_(posedge clk, negedge rst_n)
• if (!rst_n)
• data120 lt 12b0
• else if (wr_en)
• data120 lt mem120 adr
• endmodule

6
SystemVerilog

• Verilog and VHDL are limited.
• Used as HDL (Hardware Description language) and
  additional verification language is needed.
• SystemVerilog will replace them both.
• SystemVerilog provides several advantages
• Concise less error, better readability.
• - Statistics 2-3 bugs for 100 lines of code.
• Better reusability.
• Better verification.
• Better ownership support.
• Presentation from last year (click here).
• Relevant papers
• SystemVerilog - Is This The Merging of Verilog
  VHDL?
• The Verilog PLI Is Dead (maybe) Long Live The
  SystemVerilog DPI!

7
Verilog History
SystemVerilog IEEE Standard is expected to become
available by Oct2005
8
SystemVerilog Components
Advanced verification capability for semiformal
and formal methods. The Assertion Language
Standard for Verilog
Transaction-Level Full Testbench Language with
Coverage
Verilog Testbench
Verilog Assertion
IEEE Verilog 2001
Design Abstraction Interface semantics, abstract
data types, abstract operators and expressions
Direct C interface, Assertion API and Coverage
API
9
SystemVerilog
SV3.1 Focus design language cleanup
SV3.0 Focus enhance design language capabilities
10
Verification Tools

• Logic verification is the bottle-neck task of the
  design process.
• Many tools available for the logic verification.
• What is the best flow for using them?
• Can they support each other?

11
Smart RTL Verification

• The Smart RTL verification solution addresses the
  requirements of achieving first pass silicon, by
  using best-in-class technologies.
• The Solution
• Hardware Description Languages (HDL) addresses
  the challenge of improving design productivity.
• Lint analyzes a designs RTL and identifies code
  as well as design related bugs.
• Hardware Verification Languages (HVL), an
  advanced test-bench automation tool, addresses
  the challenge of improving verification
  productivity.
• Assertions provide a way to concisely describe
  intended design behavior and are usable across
  dynamic and formal verification environments.
• Simulation provides the high performance and
  capacity simulation required to verify todays
  multi-million gate designs and uniquely raises
  verification efficiency by supporting the
  design-for-verification (DFV) methodology.
• Formal verification allows engineers to find
  deep, corner-case bugs, quickly, resulting in a
  shortened functional verification cycle and
  higher quality designs.
• Hybrid formal verification combines the benefits
  of simulation and formal verification techniques.
• Verification IP significantly simplifies the
  development of testbenches.

12
Lint

• Synopsys' Leda and Atrentas SpyGlass are
  programmable design and coding guideline checker
• Finds complex bugs, such as those associated with
  multiple clock domains using static analysis
• Verifies consistency of design and SDC
  constraints for DC, PrimeTime and Astro
• Lint tools provides many violations because of
  their static analysis nature
• How can we know on which violations to focus?
• Can we effectively reduce the number of
  violations?
• SDC Synopsys Design Constraints.

13
Assertion Based Verification (ABV)

• Assertion Based Verification enables to verify
  the DESIGN (RTL model) against the SPEC using
  simulation and formal techniques.
• SPEC can be embedded in the DESIGN by design
  engineers using a set of predefined assertions.
  It is used mainly to specify illegal/unwanted
  behavior (illegal behavior fires the assertion)
• SPEC can be expressed outside the DESIGN as a set
  of properties by verification engineers. It is
  used to specify both legal and illegal behaviors

Test Bench Generation
14
Checkers

• Using Checker Library is an easyway to start
  using ABV.
• You can re-use these checkers acrossblock-level
  and chip level verification.
• You can re-use them across multipletools,
  including
• Simulation
• Formal
• Debug
• There are more than 50 checkersavailable in the
  library
• 33 of them are based on OVL (Open Verification
  Library)
• For example
• The bus state_reg will be monitored onevery
  rising edge of the clock to ensure that only one
  bit is asserted.
• The failing assertion will be printed to standard
  output, whenever this simple rule is violated.
• How to Get Started with SystemVerilog Assertions,
  Synopsys white paper.

15
Smart lint

• Lint tools go over the designand find issues
  that related to the structure of the design.
• Additional logical informationis needed in order
  to understand if this is a violation.
• Does the synchronizer detectedby the lint tool
  prevent data loss?
• Is the unconnected signal being used?
• Is the false-path declared in the SDC file
  correct?
• The lint tool cannot answer those questions, but
  the simulation and formal tools can.
• How can we pass those questions to them?

16
Checker promotions

• The lint tool can identify structures in the
  design that need to be further checked.
• It can generate checkers that will perform the
  check.
• Those checkers are similar to the checkers
  written by the designer, but they are generated
  automatically.
• The checkers can be added to the assertion
  database, and be verified as part of the
  verification flow.

17
Example synchronization data lost
assert_missing_sync

• The Lint tool identifies clock domain crossing
  (CDC) paths.
• The Lint tool checks the presence of
  synchronizers in those paths.

synchronizer
assert_data_stable

• The Lint tool generates assertions (checkers)
  that will validate the correct usage of the
  synchronizer
• assert_missing_sync sig1_check (.clk(clk1),
  .rst(!rst_l), .in(sig1), .out(sig1_new))
• This checker checks whether signal sig1 is static
  and therefore doesnt need synchronizer.
• assert_data_stable (0,clk1_clk2_min) sync1
  (.clk(clk1), .rst(!rst_l), .data(sig1))
• The checker makes sure that the input of the
  synchronizer is stable for clk1_clk2_min clock
  cycles.

18
Example Gray code validation

• The lint tool can identify the gray code logic
• But it cannot verify its correct behavior
• Correct behavior can be verified using formal or
  simulation tools
• assert_one_hot (0,SIZE) aoh1 (clk, !rst_l,
  decoded_bus prev_decoded_bus)always
  _at_(posedge clk) prev_decoded_bus lt decoded_bus

19
Example FIFO checking

• Structural coverage examples
• Has FIFO been empty?
• Has FIFO reached high-water mark?
• Has FIFO been full?
• Number of enqueues
• Number of dequeues
• Maximum FIFO entries

• module assert_fifo_monitor (clk, rst_l, push,
  pop)
• parameter SIZE 0
• assert_fifo_index (0,SIZE) no_over_underflow
  (clk, !rst_l, push, pop)
• assert_always (0,0,"FIFO IS FULL")
  fifo_over_3(clk, !rst_l, no_over_underflow.cnt lt
  SIZE)
• endmodule

20
Timing Constraint Verification

• Types of paths
• False Paths between asynchronous clocks (A-FP)
• Most of the cases in communication designs.
• To verify the correctness of the synchronization
  scheme.
• False paths between synchronous clocks (S-FP).
• Multi-Cycle Paths (MCP).

21
Conclusions

• Finding all the bugs in a design is almost an
  impossible task.
• Improve the data exchange between the
  verification tools
• To provide efficient verification process.
• Key benefits
• Reduce TTM by automatically identifying the major
  violations.
• The designer can focus on the real problems.
• Increase the level of assurance in the
  correctness of the design.
• By validating the design both structurally and
  functionally.
• Good experience in Intel (more details in the
  full paper).

22
Thank You !
Assertion Based Verification, Checkers and Smart
Lint
23
Backup