Physical (DEF) Design Diff and related back-end analysis tools?

[csotiriou]

Hello Semiwiki colleagues,

I would be very interested on the your feedback to two theoretical physical design questions.

The company Cliosoft seems to be very successful with their VDD (Visual Design Diff) tool, which appears to be primarily focused towards custom design (schematic and layout).

Question 1: are you aware of a similar product or tool for semi-custom flows, i.e. able to (visually or not) present differences between two semi-custom layouts, for instance in DEF format (DEF Diff)?

I am posing this question as it is often the case that back-end optimisations, and generally (positively or negatively impacting) circuit changes between subsequent stages of the semi-custom EDA flow, e.g. cell and critical path placement, buffering, CTS, etc. are often not well understood.

It can theoretically be argued that better understanding of the changes the circuit undergoes during the back-end could improve both aspects of the back-end flow, e.g. floorplanning, or design itself, e.g. logic depth, amount of pipelining, etc.

Question 2: is there a need for more back-end analysis tools in general, which aid in the understanding of the back-end complexities, and if yes, what would these be? I could, for example, add to the aforementioned DEF Diff idea, a Critical Path Diff analysis capability, for tracking critical paths.

I look forward to your feedback and ideas!

Thank you,

Christos.

 

[Ginger Grant]

Question 1: are you aware of a similar product or tool for semi-custom flows, i.e. able to (visually or not) present differences between two semi-custom layouts, for instance in DEF format (DEF Diff)? DEF Diff?

DEF is really just connectivity information from the layout. The real dilema is getting that perfect DEF out from custom layouts in the first place. Maintaining perfect connectivity information on a custom layout using Cadence VXL has proven to be quite a challenge. At DAC I spent time looking for tools that could create DEF without all that layout connectivity maintenance. I had no success.

I am posing this question as it is often the case that back-end optimisations, and generally (positively or negatively impacting) circuit changes between subsequent stages of the semi-custom EDA flow, e.g. cell and critical path placement, buffering, CTS, etc. are often not well understood.

It can theoretically be argued that better understanding of the changes the circuit undergoes during the back-end could improve both aspects of the back-end flow, e.g. floorplanning, or design itself, e.g. logic depth, amount of pipelining, etc.

Are you aware that there are design tools for custom layouts which can provide (rather quickly) various floorplans which the design engineer could then take through backend flows and simulate (pre routed)? so, here's the expectation, run LPE on these various floorplan views to figure out in advance which would provide the most optimized solution. That's specifically for semi-custom or full custom designs. I've not seen many design engineers using this flow. Historically designs are passed to layout to floorplan and route and then LPE is run and this isn't always the best method to obtain an optimized solution. It's really an area design engineers should examine more closely. Routing engines for digital designs can optimize buffering and clocking rather well already. As for custom designs there are a few tools that can do this. Look at Laker L3 as an example.

Question 2: is there a need for more back-end analysis tools in general, which aid in the understanding of the back-end complexities, and if yes, what would these be? I could, for example, add to the aforementioned DEF Diff idea, a Critical Path Diff analysis capability, for tracking critical paths.

DEF tools that can produce DEF from any random flat (non VXL compliant) layout would be great! One that can be read into StarRC or Talus possibly?
DIFF of critical paths is also a pretty nice idea? User identifies the paths they want DIFF'd and the tool provides R, C and timing changes between current and previous views. That would be useful. Actually, forget DIFFing, just a tool that one can do a quick RC extraction of a net in any random layout (even if the layout is not LVS clean but the net is correctly routed and connected) could be very useful!

 

[Daniel Payne]

Comparing two layouts is rather easy in Calibre. As Carey points out, this can be done with DRC and XOR operations. Using a results highlighting tool, like Calibre RVE, you can get the results visually. The only slight challenge there is writing the rules, but assuming you are comparing two versions of the same design, this can also be automated to just compare every layer in the sets. In Calibre we enable that through our fastXOR capability, which can generate the decks and also enables much faster comparison. If we’re just talking layout, then it is all geometric, so you should be able to do this from any of the formats, or directly from any of the tools to Calibre.

What is less clear to me from Christos’ question is exactly what he’s trying to get at. I may be misinterpreting, but I think he’s looking for the physical differences, which he would then manually try to associate back to a design component, such as a specific device. In that case, there are a few other possibilities that could help get him closer to his actual goal. For example, if one or both have already been run through LVS, then, using PERC capabilities, we could associate the geometric differences back to their corresponding netlist components. You could then add extra checking to make sure that those changed devices meet some desired physical or circuit connectivity requirement.

Hope this helps.

PS. I’ve added James Paris, as our local expert on fastXOR, to the thread.

Thanks,

John Ferguson, Mentor Graphics

 

[Ginger Grant]

Fast XOR is possible with VDD Diff from Cliosoft and there is no need for export gds, or all the steps usually involved with Calibre and additionally the results provided are shown in color as well as texted formats. It's pretty clean. Calibre XOR though is a proven process which is of sign off quality and yes, it is critical.

Because Christos specifically asked about DEF then it's more than just geometries but geometries with specific net properties associated so I had assumed he wanted a bit more. I'd be interested to hear Christos's response or clarity to his questions.

Betty Pokerwinski
Qualcomm Director of Digital Mask Layout

 

[csotiriou]

Because Christos specifically asked about DEF then it's more than just geometries but geometries with specific net properties associated so I had assumed he wanted a bit more. I'd be interested to hear Christos's response or clarity to his questions.

Indeed, I mentioned DEF Diff because what I had in mind was both physical component and physical net differences/properties, as DEF represents a complete database which includes both component connectivity and complete net information.

Further on, my question was weighing more towards semi-custom, standard cell designs. My thinking was that rather than observing the top-X critical paths and timing/power histograms, a representation of changes during the passage of the circuit through the back-end (not necessarily solely through DEF Diff, but in general), could aid in the analysis of back-end effects, specifically wirelength/wiredelay related effects, and provide more insight as to where/how timing/power is spent.

This analysis could theoretically even lead to modifying RTL parameters depending on the type of design, e.g. degree of pipelining, bit-widths, etc.

 

[James Paris]

In addition to traditional Calibre XOR, Mentor ships a fast cell-by-cell compare tool with Calibre called DBdiff. DBdiff is available to owners of Calibre DRC and can be used as a standalone application or as a the data pre-processor in the Calibre FastXOR application. </SPAN>

Input data for DBdiff, Calibre FastXOR and Calibre XOR can be GDS, Oasis, LEF/DEF or OpenAccess. There is no need to first convert DEF or OpenAccess to GDS. DBdiff can output Calibre ASCII Result Databases which identify the object differences between the two input designs while FastXOR outputs the traditional polygonal XOR differences in GDS, Oasis or ASCII RDB formats.</SPAN>

While it sounds like Christos idea extends beyond the physical, it is also possible to read the net properties out of DEF and OpenAccess and use those properties to drive XOR compare for a specific net or group of nets which enables capabilities beyond traditional XOR checking.</SPAN>

James</SPAN>

 

[mghenrie]

Fast XOR is possible with VDD Diff from Cliosoft and there is no need for export gds, or all the steps usually involved with Calibre and additionally the results provided are shown in color as well as texted formats. It's pretty clean.

Betty, it is good to hear that Visual Diff is working well for you.

We are looking at further enhancements to the tool to provide even more features.

A DEF diff might be a good feature to add. Any feedback on what customers would like to see are always welcome.

Michael Henrie
Cliosoft Inc.

 

[Ginger Grant]

Betty, it is good to hear that Visual Diff is working well for you.

We are looking at further enhancements to the tool to provide even more features.

A DEF diff might be a good feature to add. Any feedback on what customers would like to see are always welcome.

Michael Henrie
Cliosoft Inc.

Thanks Michael and again thank you for the quick bindkey method for running DIFF quickly (Current vs Previous) in our views. I'm not seeing an immediate benefit of a DIFF on DEF quite yet, though my work on our DEF flow is not quite finished yet. I'll keep you posted.