• Home
  • :
  • Community
  • :
  • Blogs
  • :
  • Custom IC Design
  • :
  • Spectre Tech Tips: Big Data with Spectre SQL Database

Custom IC Design Blogs

  • All Blog Categories
  • Breakfast Bytes
  • Cadence Academic Network
  • Cadence Support
  • Computational Fluid Dynamics
  • CFD(数値流体力学)
  • 中文技术专区
  • Custom IC Design
  • カスタムIC/ミックスシグナル
  • 定制IC芯片设计
  • Digital Implementation
  • Functional Verification
  • IC Packaging and SiP Design
  • In-Design Analysis
    • In-Design Analysis
    • Electromagnetic Analysis
    • Thermal Analysis
    • Signal and Power Integrity Analysis
    • RF/Microwave Design and Analysis
  • Life at Cadence
  • Mixed-Signal Design
  • PCB Design
  • PCB設計/ICパッケージ設計
  • PCB、IC封装:设计与仿真分析
  • PCB解析/ICパッケージ解析
  • RF Design
  • RF /マイクロ波設計
  • Signal and Power Integrity (PCB/IC Packaging)
  • Silicon Signoff
  • Solutions
  • Spotlight Taiwan
  • System Design and Verification
  • Tensilica and Design IP
  • The India Circuit
  • Whiteboard Wednesdays
  • Archive
    • Cadence on the Beat
    • Industry Insights
    • Logic Design
    • Low Power
    • The Design Chronicles
Amaninder
Amaninder
1 Oct 2021

Spectre Tech Tips: Big Data with Spectre SQL Database

As a design gets bigger, simulation generates big data. As data gets bigger, so does the demand to post-process and to efficiently save big data on a disk.

Disk Space

Spectre has several features that output data in various formats. In this blog, the focus is on features such as circuit checks and asserts. In a big design, there could be thousands of violations from circuit checks and asserts. Each violation consists of a device name, node name and timing information. This is the leaf-level information (or data). There could be other violations with the same device name or node name, but with different timing. Storing such violation data in ASCII format consumes a lot of disk space because it writes the same device name or node name information multiple times.

SQLite stores this leaf-level information in separate tables. For example, device names are stored in a device table and node names are stored in a node table. SQLite uses the leaf-level tables to create a violation table by using a VIEW technology. VIEW is a pre-defined SQL query that links (also known as JOIN in database theory) several leaf-level tables to form a new higher-level table. This higher-level table has all the information that a user needs.

Spectre writes the SQLite database in the input.sqldb file, which can be found in a raw directory. In input.sqldb, all the tables whose names end with VIEW are higher-level tables. The following is an example of a VIEW from dyn_highz check. The dyn_highz_0View links leaf-level tables such as “dyn_highz_0”, “checker”, “node” and “analysis”.

In conclusion, big data stored in ASCII or SQLite format gives the same information to a user. However, SQLite stores the big data more efficiently on the disk, saving disk cost.

Post-processing

The demand to post-process big data is inevitable. With big data, users want to waive violations, sort violations and convert data to other formats.

  • Not all violations are serious. Users can waive such violations by using user-specific criteria.
  • Some violations are serious. Users can sort such violations by severity.
  • There are many data visualization tools available on the market. https://github.com/d3/d3/wiki/Gallery. Such tools need data in a specific format, such as JSON. Therefore, a user needs to convert the SQLite format to the JSON format.

Post-processing of the SQLite format is more efficient than the ASCII format. It can be done using scripts written in different programming languages, such as Perl, Python, and so on.

Post-processing of an ASCII format through a script is a two-step process:

  1. A text file is parsed into a leaf-level data. This data is stored in the computer memory in a structured way.
  2. Users manipulate the data structure in the computer memory by using user-defined criteria.

Post-processing with SQLite removes the first step. Data is already stored in a structured way in an SQLite file. The script just opens the SQLite file and there is no need to parse as done in the ASCII format. This makes SQLite less sensitive to changes, such as addition of a column, a change in the location of a column or changes to the delimiter. In the ASCII format, such changes will break the script and require script updates. Therefore, post-processing of the SQLite format reduces the maintenance cost of a script.

There are several third-party tools that can read the SQLite format. The Linux operating system also has an SQLite reader called sqlite3. Type which sqlite3 in the Linux shell to see its path. It is usually located at /bin/sqlite3.

Related Resources

  • Rapid Adoption Kit: Querying Spectre SQL database with design checks
  • SQLite Reference: https://www.sqlite.org/index.html

You may also contact your Cadence support AE for guidance.

For more information on Cadence products and services, visit www.cadence.com.

About Spectre Tech Tips

Spectre Tech Tips is a blog series aimed at exploring the capabilities and potential of Spectre®. In addition to providing insight into the useful features and enhancements in Spectre, this series broadcasts the voice of different bloggers and experts, who share their knowledge and experience on all things related to Spectre. Enter your email address in the Subscriptions box and click SUBSCRIBE NOW to receive notifications about

Tags:
  • APS |
  • Dynamic Checks |
  • assert |
  • Spectre |
  • check |
  • static checks |