Home > Community > Blogs > PCB Design > what s good about apd s die abstract compare you ll need the 16 5 release to see
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the PCB Design blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

What's Good About APD’s Die Abstract Compare? You’ll Need the 16.5 Release to See!

Comments(0)Filed under: PCB design, Allegro, PCB Editor, APD, IC Packaging, SiP, PCB, layout, design, SPB16.5, Allegro 16.5, packaging, die abstract compare, SiP Design, Allegro Package Designer, die abstract, IC/package co-design

In the distributed co-design environment in the SPB16.5 Allegro Package Designer release, a die abstract file is used to convey die information between IC and package layout tools. For ECO purposes, it is imperative to know the changes that are incorporated inside an abstract file before incorporating them in the database. The Component Compare feature in SiP allows you to view differences between die layout information contained in a die abstract file and the database component. It does not report I/0 cell, port or library information. Alternately, SoC Encounter has an optional checking ability in its readDieAbstract command to report layout differences with the IC database. These comparators are tool-specific.

This new feature is for a standalone comparator tool to compare die information from two die abstract files. By being standalone, it can be used by both SiP and SoC Encounter without being tied to a specific database. The tool also makes a full-blown comparison of information inside the abstract files, including I/O cells, ports, arrays etc, and the comparisons are not only limited to die pins, as with the Comp Compare feature.

During IC and Package co-design, changes are being made by both IC and package designers. As part of an ECO-validation process, this tool can be used to see the kind of changes in the abstract file before importing them in a package or IC design.

For example, in SiP, this can be done by comparing the abstract file and the one stored in, and representing, the package database. The File> Export> Die Abstract File command can be used to output the current die abstract file from a SiP Layout database for comparison with a new die abstract.

Alternatively, at the end of the co-design process, it is imperative that both IC and package designers are seeing identical pin data. The package and IC designer can run this tool to verify that the die pin pattern in the IC and package designs match.


Read on for more details …


Use Model

  • Determine the 2 abstract files to compare. If comparison is to be made against a die abstract file embedded inside a co-design die in a SiP database, the die abstract file should be extracted to disk first, through the File> Export> Die Abstract File menu command.
  • Determine the name and location of the output file showing differences.
  • Determine if there are checks to be discarded. By default, the tool will do all supported checks.
  • Run the tool from the command line.


Menu and Command-Line Access


This feature is only available by running it in the DOS or Unix/Linux shell.


The syntax is:
diacompare file1 file2 [output] [-nolibrary] [-noport] [-norow] [-noobstacle] [-nobump] [-noarray] [-noinstance] [-nonet] [-noproperty]”
- diacompare – path and name of executable to run the dia compare tool.
- file1 – path and name of first abstract file. This is considered the file containing the golden data by default (i.e. the report will highlight differences based on this master file).
- file2 – path and name of second abstract file to compare against the master file. This is optional and if not specified, input will be taken from the standard input stream.
- output – path and name of text output file. This is optional, and if not specified, output will be written to standard output stream.

The following flags are for checks to be excluded for comparison:
-nolibrary – cell library information.
-noport – port information.
-norow – row information.
-noobstacle – obstacle information.
-nobump – bump information.
-noarray – array information.
-noinstance – instance information.
-nonet – net information.
-noproperty – property information.
 
Example: “diacompare abstract1.dia abstract2.dia report.txt –noport” would compare all the above checks except for port information, from the abstract files abstract1.dia and abstract2.dia in the current directory and generate the results in file report.txt in the current directory.
 
This tool does not have a graphical user interface at this time but is planned for the 16.6 release.

Log File

This feature will generate an ASCII report highlighting the differences.
This report will be saved in a directory path and file name specified on the command line.
A sample of the output file is shown below.
 
Sample output file:


DIA Compare Report v1.0 created on: Jul 08 14:04:02 2010
--------------------------------------------------------------------------
Original abstract filename: d:\work\latestdia\compare.dia created in cdnsip
ECO abstract filename: d:\work\latestdia\master.dia created in cdnsip
# [Added]    - Found in ECO and missing from original file.
# [Deleted]  - Found in original and missing from ECO file.
# [Modified] - Found in original and ECO, but with listed differences.
# N/A        - Value not found in file.
10 differences were found:
-------------------------------
================================
Header   ( 2 difference(s) found )
================================
[Modified]
Die Box : (0,0) x (4594635,4593525)     vs.    (0,0) x (4594645,4593525)
[end Modified]
[Modified]
Manufacturing Grid : 0.005000    vs.    0.004000
[end Modified]
================================
Port   ( 4 difference(s) found )
================================
[Deleted] AHB_HADDR[31]
[end Deleted]
[Modified] [Port AHB_HADDR[29]]
Port Direction : [Input] vs. []
Port Net Name : AHB_HADDR[29] vs. AHB_HADDR[30]
[end Modified]
[Added] AHB_HADDR[310] [Dir: Input, Net Name: AHB_HADDR[300]]
[end Added]
================================
Row   ( 1 difference(s) found )
================================
[Modified] [Row CORNER_SE]
Row Site Name : CornerSite       vs.    CornerSite1
[end Modified]
================================
Bump   ( 2 difference(s) found )
================================
[Modified] [Bump Bump_316_2_3]
Bump Cell Name : BUMP8     vs.    BUMP81
[end Modified]
[Modified] [Bump Bump_314_0_3]
Bump Lower Left : (1025000,2225000)     vs.   (1025001,2225000)
[end Modified]
================================
Instance   ( 1 difference(s) found )
================================
[Modified] [Instance talon_core/tdmac_1/tri_des_rx/OUTfifo/dpram/ram0]
Master Cell Name : RAM2P_1024x32 vs.   RAM32P_1024x32
[end Modified]


Watch a Video on this feature!

As usual, please share your experience with this new 16.5 feature.

Jerry "GenPart" Grzenia

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.