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