Encounter 101: Implementing ECOs with ecoDesign

When people say "ECO" in the context of back-end digital implementation tools, they can mean a number of things:

• TCL commands that trigger netlist changes to the design
• Functionality that takes RTL-based changes and automatically implements them automatically and surgically
• Functionality that takes a new Verilog netlist and implements the changes to an existing database
• Pre-mask or Post-mask (i.e., can the base layers in the design be altered?)
• Selective metal layer (i.e., which metal layers are allowed to be altered?)

I consider these all part of a similar family of functionality.  They're pointed at surgically altering the existing database for whatever reason and implementing just a small change in the design while leaving everything else undisturbed.  This can be hugely beneficial for accomodating late-breaking changes to the design specification or repairing bugs in the RTL.

In Encounter, "ecoDesign" is the super-command targeted at implementing ECOs.  The input is an existing Encounter database along with a new Verilog netlist that describes the desired logical netlist.  Here's a simple example of an ECO that Encounter could be tasked with implementing and how you'd instruct the tool to do so:

Here's how we'd do it:

1. Save the existing database with "saveDesign <designName>.enc.dat" 
2. In a new Encounter session, call ecoDesign pointing to the new netlist along with the old Encounter database:
   Syntax: ecoDesign <sessionDirectory> <designName> <newNetlistFile>
   "ecoDesign testcase.enc.dat testcase eco.v"

This will instruct the tool to load the new netlist while refering to the old physical database.  It will then compare the new netlist to the old and retain as much physical information as possible while preparing the database for incremental routing.  Finally, it will implement surgical changes to the routing to finalize the ECO.  Conceptually, this is why it is advantageous to perform an ECO as opposed to completely respinning.  It's all about minimizing turnaround time and reducing the uncertainty associated with changing the entire design.

Here's what the database would look like after ecoDesign.  Note how the connection is changed, but the old unaffected routing isn't touched:

I'll be writing about other nuances related to ECO in future blog entries so I wanted to share this as a foundation for further discussion.  Developing an ECO strategy is something I've seen successful design teams do while implementing their first chip -- not only because they want to make their designs amendable to future re-spins but because they want to speed their first release to market by spinning late breaking changes effectively.

Further Reading: The ECO Flows Chapter in the Encounter User's Guide is actually pretty good.  It covers a wide variety of ECO types and gives detailed step-by-step insight into the steps ecoDesign performs to implement an ECO.

Have you used Encounter's ECO capabilities?  We'd love to hear about your experiences.

Bob Dwyer