“OK people, let’s do this. I called this meeting because we have a problem. I know, you might think that tales of what goes on here might not make it out to the golf course and into my ear, but I hear things, OK? And sometimes I don’t like what I hear.

“Lately I hear that your designs have been delayed because you keep finding things to change at the last minute. That tells me you’re being sloppy. If you did your verification right up front, you shouldn’t need last-minute changes, right? Am I right?

“I’ve also heard that some of you blame marketing for tossing in last-minute feature requests after you’ve completed place and route. I don’t know about that and, frankly, I don’t care. Because, you see, I didn’t get to be your boss by dealing with problems and their causes: I got here by dealing in solutions. I’m results-oriented, which means I don’t have to know or even care about what the problems are. I simply demand results, and if you don’t deliver them (and I don’t care how you deliver them), then I’ve done my part and you have failed.

“So I shouldn’t have to be up here talking about this, but I am, and I have some information for you that Smithers [huh? What? Oh… Sorry …] Smith here has put together on how you can manage those change things more effectively. So you see, I’m giving you solutions. I’m not up here whining about problems. Now… listen up to what he has to say. I’m looking forward to being able to finish a full 18 holes without someone having to bring something to my attention.”

And so we enter the realm of the “engineering change order,” or ECO. Now… any change to a design will likely have been requested by (and made by) an engineer, so you might think that ECOs would apply at any time during the design project. But nope: there’s a hidden semantic buried in those three little letters. Some perhaps more accurate names might be:

• ECOAIRTL: Engineering change order, after it’s really too late
• LMECO: Last-minute engineering change order (and its subset the “Marketing-induced LECO” or MILMECO)
• #(#*&(@#$&ECO: “We’re just taping out; are you freaking kidding me?” engineering change order

In other words, you’ve worked your way completely through the verification gauntlet. You design is clean from its earliest specification all the way through physical design; each stage is equivalent to its predecessor and successor. It’s simply a thing of consistent beauty.

And then someone tosses in an “oops!” or a “Hey, while you’re up, how about if you add…”

If you want to keep your pristine, self-consistent design purity, you now need to go back to the earliest form of the design that captures whatever needs to be changed. That would typically be RTL for digital. Or even earlier.  Matlab?

So now you need to resynthesize. Maybe you have a tool that can do incremental synthesis, but then you need to redo place and route. And all that timing work you did to tune it in? You may need to go back and redo large swatches of it. And all for a last-minute change when things are already running late. Ready for that?

Nope. That’s not what’s going to happen. You’re going to say, “The hell with the self-consistent thing!” You break into the design at the last feasible format – Netlist? Layout? – and manually change whatever needs changing and get on with life.

Now, from a purity standpoint, you no longer have equivalence, since you made a change in a downstream file that wasn’t reflected in the earlier version. You’ve broken the automation chain. Perhaps you manually edited the layout with a new function: the RTL no longer agrees. It’s reasonable to suggest that this could be a problem in the future, but weighed against excessive delays, well, purity often loses.

Some companies make a distinction as to the type of ECO. For some folks, an ECO implies a change at the physical level. They use the phrase “DCO,” or “design change order,” for last-minute RTL changes.

All of which is a very roundabout way of stating that ECOs are messy. Yes, you might think that they shouldn’t exist because they reflect late bug discoveries or, in the engineering mind, a marketing group that doesn’t know what it wants (which the marketing group may refer to, perhaps justifiably, as being nimble in a changing market). Yes, in a perfect world, there would be no ECOs. And in that perfect world, people wouldn’t get hit by busses either.

So here in the real world, we have to deal with ECOs (and DCOs, if you make that distinction). Four recent announcements involved ECOs at one level or another in an attempt to make them more manageable or take advantage of ECO functionality for other things.

First off, Synopsys came at it a couple of different ways. The first involved IC Compiler, their physical design tool for digital logic. And it deals with the fundamental fact that, once you’re this far into the design, you want to touch as little as possible. Even if you’re touching only one net by, say, adding a buffer for timing, you could end up rerouting that entire net when, in fact, most of the route could have been left alone.

So the idea is that, when an ECO is implemented, the result should preserve as much as possible about the original pre-ECO layout. That means fewer newly-introduced timing changes or other surprises.

Then, separately, they announced a new ECO capability for their Formality tool. (Which does formal analysis, in case that wasn’t obvious). This is for making changes at the RTL level. While the intent in IC Compiler is to minimize the impact of a net change, the focus at the RTL level is to change as few nets as possible. But it’s not always easy to visualize what nets will change during logic synthesis.

Synthesis can do all kinds of strange things. It can introduce new nets with opaque names; it can monkey with state machines and pipelines. It can effectively generate a gap between RTL and netlist that’s hard to cross. So Formality can now be used to analyze the design, exploring the “cones of influence” relating to the changes you’re making. From that, it figures out specifically what the net changes would be corresponding to the RTL change.

Assuming you’re good with those changes, it can then generate an ECO script for IC Compiler. That way you don’t run the risk of a completely new synthesis run making completely different decisions based on your design tweak; you implement the minimal amount of change needed to effect the ECO.

There was also a mention in conjunction with Cadence’s Tempus announcement. This actually has less to do with managing last-minute changes and more to do with taking advantage of a tool’s ECO capabilities to speed up timing closure.

When timing violations are found by a timing analysis engine like Tempus, those violations imply a tweak (routing, buffering, whatever). So Tempus can write an ECO script consisting of the changes needed to fix violations. The analysis can then be automatically repeated – perhaps with a few more violations, generating a new ECO script. In general, this will converge and will do so much more quickly than if an engineer had to manage this all by hand.

This automatic looping isn’t unique to Tempus, but it does illustrate how the unfortunate necessity of managing ECOs can provide a capability that can be leveraged for the forces of good.

Finally, while most of this relates to digital design, there was an analog mention. Analog is different because layout is typically done by hand, so you don’t have this automated tool chain that you’re breaking. Still, when changes are needed, one designer may implement them, but then it has to get rolled into the complete design and be documented and such. Cliosoft’s design management tools have a new “visual diff” feature that can be very helpful for managing such ECOs.

We’re used to text “diff” capabilities; that’s old news. Doing a graphic diff, on the other hand, isn’t quite so easy. Even figuring out how to represent a difference graphically can take some thought. Which is why something as basic-sounding as a diff for analog hasn’t been around forever.

It has struck me over the last couple of months how many times the term “ECO” was coming up. I infer from that two things. First, the sheer size of designs creates more ECOs than can be managed easily by hand. Second, each new process node becomes more finicky than the last, so each little change has the potential to ripple further out.

So the goal of all of these features and tools is to minimize how far out those ripples go. Hopefully they don’t make it all the way out to the 17^th hole.

More info:

Cadence Tempus

Cliosoft Visual Diff

Synopsys’ latest IC Compiler announcement

Synopsys’s latest Formality announcement