feature article
Subscribe Now

ECO Systems

When You Need to Make That One Last Tweak

“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 17th hole.

More info:

Cadence Tempus

Cliosoft Visual Diff

Synopsys’ latest IC Compiler announcement

Synopsys’s latest Formality announcement

One thought on “ECO Systems”

Leave a Reply

featured blogs
May 25, 2023
Register only once to get access to all Cadence on-demand webinars. Unstructured meshing can be automated for much of the mesh generation process, saving significant engineering time and cost. However, controlling numerical errors resulting from the discrete mesh requires ada...
May 24, 2023
Accelerate vision transformer models and convolutional neural networks for AI vision systems with the ARC NPX6 NPU IP, the best processor for edge AI devices. The post Designing Smarter Edge AI Devices with the Award-Winning Synopsys ARC NPX6 NPU IP appeared first on New Hor...
May 8, 2023
If you are planning on traveling to Turkey in the not-so-distant future, then I have a favor to ask....

featured video

Automate PCB P&R Tasks for Designs in Minutes

Sponsored by Cadence Design Systems

Discover how to get a dramatic reduction in design turnaround time by automating your placement, power plane generation, and critical net routing with Cadence® Allegro® X AI technology. Built on and accessed through the Allegro X Design Platform, Allegro X AI reduces P&R tasks from days to minutes with equivalent or higher quality compared with manually designed boards.

Click here for more information

featured contest

Join the AI Generated Open-Source Silicon Design Challenge

Sponsored by Efabless

Get your AI-generated design manufactured ($9,750 value)! Enter the E-fabless open-source silicon design challenge. Use generative AI to create Verilog from natural language prompts, then implement your design using the Efabless chipIgnite platform - including an SoC template (Caravel) providing rapid chip-level integration, and an open-source RTL-to-GDS digital design flow (OpenLane). The winner gets their design manufactured by eFabless. Hurry, though - deadline is June 2!

Click here to enter!

featured chalk talk

ADI's ISOverse
In order to move forward with innovations on the intelligent edge, we need to take a close look at isolation and how it can help foster the adoption of high voltage charging solutions and reliable and robust high speed communication. In this episode of Chalk Talk, Amelia Dalton is joined by Allison Lemus, Maurizio Granato, and Karthi Gopalan from Analog Devices and they examine benefits that isolation brings to intelligent edge applications including smart building control, the enablement of Industry 4.0, and more. They also examine how Analog Devices iCoupler® digital isolation technology can encourage innovation big and small!  
Mar 14, 2023