Trying to compare two GDS files using dbdiff command

Dear Arun,

I found this October 2013 post today and have a question. Were you ever able to run Calibre dbdiff and the two layout files not be reported as different because non-functional data such as different access times? If so, was there a manually set -flag used to ignore the access time stamp or was dbdiff's default behavior set to ignore the last access time (or even the 'last modified' time) stamp? I cannot imagine dbdiff being effective as an equivalence checker without one of these behaviors.

https://www.edaboard.com/threads/299938/

Anyway, just curious how the problem was solved while using dbdiff. I had heard as well that dbdiff is much faster than a Boolean XOR using flat layout data. Has this been your experience?

Thank you.

Tom

Calibre's dbdiff does not in any way use timestamps -- it isn't even an option you can set. Are you sure you are getting Calibre dbdiff and not, say, Github's or Linux's? For some Unix/Linux variants you can check which one is happening by typing "which dbdiff" on the command line.

To be sure you are getting Calibre's dbdiff, you could try (assuming standard setup) "$CALIBRE_HOME/bin/dbdiff ..." where ... is the rest of the arguments you have been using.

Good luck-

Sam.

Thank you, Sam. I thought this to be the case. Just doing our homework here. Seemed odd. It is quite possible that the PCells were defined in a different order and "-automatch" was not used to resolve the name mismatches.

We are looking for something, 3rd party, for layout comparisons that is faster than a Boolean XOR. When I saw this, I thought that, perhaps, DBdiff might be a problem for us should it be that it cannot normalize simple, non-functional, differences such as a GDSII access time stamp. Have you worked with some of the features that help DBdiff normalize two sets of layout data prior to a layout comparison? Have you found the reported DBdiff results to be as accurate as a Boolean XOR? Have you found DBdiff to be faster? Mentor is claiming 5X faster which will, of course, depend on the number of differences found.

Tom

Hi, Sam.

Our core problem is the following: It is taking too long to run layout comparisons and fix whatever we've found to have changed. Before the comparison, we must flatten the data because, as examples, (1) cell names change when library cells are used within higher-level IP blocks, (2) cells get copied multiple times under different names, (3) different vendors' tool sets reorder and restructure objects within cells, (4) cell names are routinely changed to Pcells, etc. With flattened results, we spend an extraordinary amount of time re-associating the changes with the actual cell hierarchy of the IP library and/or chip-level design. Each time there are changes, we're faced with finding what, where and how those changes have occurred throughout our flow; 3rd party IP, internal IP, blocks of IP containing both, etc. Error-prone too. There are times when changes should not have occurred but have. We'd like to find and address them quickly and quicker than we are today.

With DBdiff, it sounds like we will not need to flatten the data before the comparison. This might allow us to view, reject and/or even fix changes, flow-wide, right where they are in the cell hierarchy; likely a less error-prone time-saver for us. If so, can DBdiff keep track of the results of its runs so that we only need to compare new layout data against the previous DBdiff results? This is a different type of runtime issue that could, conceivably, be a second big time-saver for us. Would we simply need to instruct DBdiff to keep the results of the comparison so that they can be used again?

If not DBdiff, might anyone viewing this know of other application(s) out there that, conceivably, could address our problem?

-Tom

Sorry for the lag -- I wanted to bump your questions off someone who uses dbdiff. He asked me to forward the information rather than post it himself.

* Flattening -- I am told that if you want to, there is selective cell flattening (-flattencell) but as it tracks hierarchy differences you don't need to. You can also set it to report on just the hierarchy differences with -hierarchyonly.

* Tracking results -- you can save to a report or an ASCII results database to compare across runs.

* Speed -- I'd like to give you his exact words: "DBdiff is blazing fast in comparison to traditional XOR." He does warn that speed that fast probably has some other tradeoff, but he hadn't had it bite him. Guessed it was memory but didn't have a feel for the difference.

I hope someone with a bit more hands-on experience pipes up on this.

Best-

Sam.