The Cadence IC Packaging tools are complex, flexible tools that allow a designer freedom to create a package substrate layout in a myriad of ways. As a result, it becomes possible to run a particular feature at a time when the database is ill-configured to handle the request. Or, a given command could have a bug which results in the corruption of a specific database object in a manner that is not illegal to the database structural integrity but will not be processed correctly by other commands.
While programs built on top of Cadence Allegro database technology have a built-in check for the integrity of the database itself, they lack any similar checking capability for validating that the database is configured in the manner expected for a given application.
It is with this in mind that we aim to implement not a database integrity check, but instead a design integrity checking tool. The goal of these checks, then, is to ensure that the database adheres to the implied requirements of the tool modifying it.
A simple example involves interfacing with the Optimal Paksi-E Field solver. The solver may return incorrect results if the database is not properly configured, but it can run for hours, even days, before returning these bad results. If the customer can run checks to reasonably ensure the database is correctly configured, it can save precious time in the competitive world of package substrate design and layout.
In this way, the user can diagnose some of their own problems and can work to self-correct their flows to account for the expectations of the tool. This can save time and aggravation.
The intention here is to allow a proactive, instead of reactive approach to assisting customers working through common problems.
If the customer is having problems getting a specific command to act appropriately, they are advised to run any checks from this command which deal with the problem area. In addition, the customer should run the Tools->Database Doctor command.
This command should be run prior to performing certain milestone events, such as doing a full 3D SI model extraction on your database and before calling Cadence technical support. The tool will make every attempt to help you overcome problems in your design by correcting them on your behalf or advising you how to correct them.
To run the command, launch it from the menu / toolbar icon and select the checks which you want to run. Press apply, once the appropriate checks are selected and the reporting options are configured to your desire.
If any errors are found in the database which cannot be automatically corrected, we advise you to correct those errors and re-run this command prior to continuing with your design flow to ensure that you do not encounter further problems or compound the difficulties later on.
Menu and Command Line Access
This command is available near the existing Database Doctor tool. It will exist under the tools menu as:
Tools > Design Integrity Check…
From the command line, it may be run by typing: package integrity
Graphical User Interface
The user interface for the design integrity checker is shown below. The fields operate as follows.
NOTE: Rules listed in the Check Categories are for illustration purposes ONLY.
- All On: Toggle all defined integrity checks in all categories to on (checked) state.
- All Off: Toggle all defined integrity checks in all categories to off (unchecked) state.
- Check Category Tree: This tree defines all the categories and checks which are currently registered for the active running product. The user may toggle either a full category or individual rules on/off through this interface. Selecting the name of a rule or category instead of the checkbox will display its documentation in the right panel but will not change its active state. All rules default to de-selected. Any rule which can be automatically fixed by the tool will be suffixed with “(F)” to indicate this and, when selected, will display “(Fixable)” in the display window. Rules which cannot be fixed automatically will provide the user as much detail instructionally as to how to best fix the problem and why the resulting database structure is better.
- Log File: Whether or not to write a log file of problems found to disk. This defaults to on.
- Log File Name: Name of the log file to write, defaults to package_design_check.log. This file will be written to the location pointed to by the ADS_SDLOG user preferences variable.
- Fix errors automatically (where possible): If enabled, this will cause rule checks to fix errors where possible in your design. The ability to self-correct the errors will vary for each rule being checked. Defaults to on.
- External DRC markers: If enabled, the tool will generated external DRC markers at the locations where violations appear. These markers will use the name of the defined rule as their description element, therefore making them easier to location. This defaults to off.
- Clear DRCs: Press this button to remove any DRC violations found by this command during this or previous runs of the tool.
- Descriptive Bitmap: Provides an illustration regarding what this check / category is designed to look for. This is optional for user-defined rules.
- Descriptive Text: Provides a (detailed) text description of the check / category, including such information as what the problem is, how it manifests, what problems it will cause and how it can be corrected or avoided in future design flows.
- OK: Close the form and run the selected checks.
- Close: Close the form without running any checks.
- Apply: Perform the selected checks, but leave the command active and form displayed.
- Help: Raise context-sensitive help for this command.
As always, I look forward to your feddback on using this new capability in the SPB16.2 APD release.
Jerry "GenPart" Grzenia