Disrupting Electronic Design Automation

The EDA industry is hostile to innovation.

This is the first line of a blog post title Engineers, assemble! written by Saar Drimer, a friend and fellow EDA innovator. It’s a great blog post, it’s short, it’s too the point, and honestly it touched me. We circled it around the office at Upverter. We grumbled, complained, brainstormed. Exactly what I think Saar hoped for. You see, we share a lot of his frustrations and have encountered many of the same pain points. We too are attempting to disrupt part of the EDA market. We’ve been working on it for 5 years now, and we’re making progress [1]. But we too have found it resistant to innovation.

This started as a different kind of post.

Re-reading Saar’s blog post this week I was inspired to write about my experiences thus far building a disruptive EDA startup. But as I was writing that post, I noticed that it was quickly becoming a laundry list of all the ways traditional EDA makes it hard to disrupt them. All the walls they’ve built that keep startups out, and lock customers in. All the things preventing real innovation. All the little battles and wars we had to fight at Upverter just to get a seat at the table.

And so I decided to write that post instead.

These are the missing links. These are the reasons it’s so hard to innovate in EDA. These are the reasons the big get bigger, the walls get taller, and our jobs as hardware engineers don’t get much better.

These are also things we’ve spent months and years working on at Upverter. Not because they make us unique or different. But simply because they buy us a seat at the table. If someone we’re to solve any of these (or ideally all of them) I believe starting a startup in EDA would become an order of magnitude easier. I believe we would see more disruption, more startups, more innovation for the incumbents, and our lives as hardware engineers would be better, and our jobs easier.

There are four things on my list: a File Format, a Library, an API for Manufacturing, and an Interchange Language.

1. File Format

First, we need a file format that is ASCII, Open, Documented and Complete. It would be ideal if it was also supported. But a powerful open source converter should be a pretty good patch until the big guys are forced to support such a format. [2]

At Upverter we’ve spent millions of dollars interoperating with existing formats simply so that our prospective customers can try Upverter [3]. Hardware designers need to be able to import, and export from anything to anything. It’s ridiculous that we force our engineers to use the same EDA tool as everyone else on the project simply because the file format locks them in. It’s a bit like forcing everyone to use the same chair. But today it’s impossible to reliably work on the same project in different tools. A real ASCII, open documented and complete format would fix this.

It needs to be ASCII, not binary. Users should be able to open up their files, make changes, and expect them to load and work. No more PDFs. No more symbols and footprints and board files and pad frames locked in untouchable binary [4].

It needs to be open, this is tricky — but the work done by the W3 (HTML and CSS namely) would be good examples of something to strive for [5]. It can’t be the same kind of quagmire that all of the other EDA formats have gone through. And it can’t be written by a standards body run by the big 3 — that would defeat the point [6].

It needs to be documented openly. I can’t be required to join the IPC, or EDAC, or IEEE, or any other organization to download the documentation for a format used to store MY ECAD designs. It needs to be open, accessible, up-to-date. I need to be able to write scripts that work with these files, hack them by hand, manipulate them as I see fit. That needs to be ok.

Finally, it needs to be complete. It can’t be like gerber files — a shadow of the thing I designed. I should be able to exchange components using the same file format that my board uses. The layout of my custom analog IC should use the same format as my schematic. It needs to handle system designs, schematics, netlists, layouts, stackups, IP blocks, synthesized silicon, pad frames, packages, bills of material, manufacturing requirements. EVERYTHING [7].

When it becomes possible to switch between tools. When EDA becomes more about editing, and less about lock-in. When it becomes common place for employees sitting next to one another to use different editors. Then better tools and new and disruptive user experiences can be judged for the value they provide, instead of the risk they introduce.

2. Library

We need a proper open-source, collaborative, trustworthy and complete parts library. Furthermore we need this library to begin replacing PDF datasheets. Today there are over ten million commercially available electronic and electro-mechanical parts on the market and that doesn’t include custom parts, internal part numbers, ASICs, etc. These 10,000,000+ parts have all of their data, their symbols, their footprints, their simulation models, everything about these parts is locked-up in non-machine-readable PDF datasheets. And it’s not just on the board side. IP Blocks have exactly the same problems.

What’s worse, each of these PDFs is completely unstructured and creatively different, even when they come from the same vendor. They all take an expert to interpret. And every time an engineer needs to use one of the components these PDFs represent, they first have to decipher the datasheet. Then recreate the part in their cad package, triple check it, and then painfully figure out how to share it with everyone else working on the same project. It’s slow, it’s wasteful, we’re all duplicating each other, and we get little to no support for the vendors. It’s not even the work we’re being paid for, it’s just a prerequisite to doing our jobs. The work around the work [8].

So again, we need a library, filled with the work engineers have already done, available for any other engineer to use, along with a trust-layer so hardware designers know the parts are good. And the parts need to be more than just pictures, and attributes. They need to be useful symbols, footprints, actual cad data, models, etc. The data needs to be available to anyone, via download or API. It needs to get plugged into the existing tools, and be something new tools can be built on top of [9].

This is probably the one we’re closest to actually solving at Upverter. It’s taken us years and years, but we finally have a trust layer. We think we’ve mostly solved the user experience. We finally have sharing that works. We have tools for building and managing parts libraries. Tools for making parts quickly, and verifying they are correct. And we even have some key relationships with vendors to get this data directly, no PDF involved [10].

When we break the bond between EDA tool and component or IP data good things happen. When your library is portable, and when there is a common, public source of data you can use it becomes possible for new and interesting tools to exist. Parts begin to matter less, the risk of manufacturing goes down, and we as engineers get to worry more about the work itself, and less about the work around the work.

3. Manufacturing API

We need an API for manufacturing. I don’t think it’s important whether it’s owned by a manufacturer, or run by a 3rd party company that interfaces between design tools and manufacturers. It just needs to exist.

It needs to be possible to wholly communicate everything about a job over this API. It should require zero phone calls, zero emails, no confirmations or reviews or anything else. It should simply take a job, big or small, bill a credit card, produce the order and drop ship it to the engineer. Ideally all within a few days for small orders (but a week would be fine), and a month for bigger orders.

This API needs to consider that most manufacturing challenges are actually design challenges. It may need to play really nice with design tools. Or they may even need a tool of their piece of software which handles this. Or even better maybe they will publish a set of design rule checks and constraints that I simply import into my tool. But fundamentally, it should feel no different placing an order over this API than consuming every other API on the internet.

As hardware designers we are not supposed to be experts at manufacturing. But we get forced to become experts. We’re forced to learn everything about manufacturing. To travel to or live in China. To learn how to negotiate quotes, optimize bills of materials, design assembly documentation, use excel and the phone relentlessly. We do this because we have to. We need our hardware products to get manufactured, and seemingly this is the only way. But this is wrong, and we need to fix it.

Manufacturers are lazy, and they expose the engineers to orders of magnitude more of their problems, processes, and business concerns than the engineers need to care about. The complete design intent of the engineer should be captured in their tools and their design files in such a way that there is no ambiguity. Manufacturers should then take these files and be capable of producing exactly the design the engineer intended. This may require a new type of manufacturer, a new file format (see #1 above) or even a new type of middleman — but solving it unlocks whole new kinds of design tools, and whole new areas to disrupt and add value [11].

At Upverter we’ve been constantly frustrated that we need to even think about this problem. We make user interfaces for engineers to design electronics. Why isn’t there just an API we can call once the design is finished? Instead we’ve built a whole suite of CAM, BOM management, PLM, inventory, and order management software simply so that our users can manufacturer and produce the designs they create inside Upverter. Most of it isn’t special or unique to Upverter, but it was table stakes, so we were forced to build it [12].

4. Interchange Language

Lastly, we need a way for EEs, SEs and MEs to work together; They need an interchange language. What I mean by this is what software engineers use variables for. I can move code around, put it in a different file, and completely change the underlying algorithms, but as long as the variable names stay the same everything else will just work.

Imagine a similar interchange language between MCAD and ECAD. I make the board bigger, and the MCAD system just knows. I swap pins in my FPGA and my schematic just knows. I swap parts in my BOM and my gerber files get updated. Imagine if it just worked. Component errata, library updates, hole position changes, etc, etc, etc. An enormous part of our jobs as engineers is spent doing clerical work. Wasted on things the computer should be better at than a human. But there is no language, there is no way to communicate these diffs and changes from one tool to another [13].

Again, we’ve spent many man years building systems to keep every design in Upverter consistent, regardless of who made the change or where. And we’ve solved it for components, libraries, schematics and layouts. But we haven’t even made it outside of our own problems yet. There could be an entire company dedicated to interchange. For example we don’t yet have a solution for MCAD, or a solution for syncing FPGA pinouts. Today we can’t keep these consistent. And as we add more and more IC design features to Upverter, we have to solve these same issues for Packages, Pad Frames, IP Blocks, etc.

There needs to be a generalized input-output language for communicating changes in-to, out-of, and within EDA tools. It needs to play nice with mechanical, with software, with FPGAs, and with component updates. ASCII, GIT, Ruby and Makefiles do this is software, we need a hardware equivalent.

Why does any of this matter?

As hardware engineers many of us are tasked with building the future. We build products out of ideas. Products that never existed before. Products that push us all a little further into the future. It is a position of incredible importance. Without us progress would be slower. Less new things would exist.

But markets are inefficient. That shouldn’t be news to you, the best product doesn’t always win. Usually it’s something else that picks the winner — the first to market, the best salesforce, the best marketing, the easiest option, what you’re comfortable with, what you’ve used before, what your boss used before…

And that’s where it all breaks down for me. Where the math stops working. We’re probably not using the best design tools; We’re probably using the tools sold by the best salesforce. And we’re trying to build the future; But we’re probably not getting there as fast as we could. And we can’t really change to a better tool, because we can’t really leave our current tools.

I think this adds up to bad things.

In my opinion, it adds up to the future happening slower. It adds up to me getting to experience less in my lifetime. And the serious problems affecting our world not getting solved, or at least not very quickly.

I want the best product in EDA to win. Not because it relates to my day job. But because I only get to do this life once — and I want the best version of this life I can possibly have. I think it starts with making it easier for EDA to change, easier for startups to start. And I think it ends with a market more willing to embrace of innovation, and better tools winning a little more often.

Notes

[1] — We’re still going strong at Upverter! We’re 5 years old and 17 people. We’ve built some of the most powerful system design, schematic capture, and PCB layout tools in the world. We host the largest electronics parts library in the world, about 30,000 electrical engineers use our software, with more than 40,000 ready to use reference designs. We’ve won the key industry awards, raised millions of dollars, and maybe most importantly we’ve survived and continue to. We are well on our way to being the first truly lasting, meaningful and disruptive EDA startup in the past decade. But I truly wish there were others. I wish our space was teeming with innovation.

[2] — This is more of a problem on the printed circuit board side (schematic capture and PCB layout) than it is in IC design. At least in semiconductor world they occasionally use ASCII, and GDSII is a reasonably well documented format.

[3] — We’ve only made it so far. We currently support Cadence Allegro and Orcad, Altium and Cadsoft Eagle. We have pre-release versions of Mentor Graphics PADs, KiCAD and GEDA, but they are still months away from finished. It’s an impossibly expensive task trying to read and write these existing proprietary formats — but until someone actually solves the fundamental problem, we’re forced to.

[4] — Ideally it would also play nice with version control, but that’s probably too hard to hope for off the start.

[5] — The W3. They have their own controversy but they seem less victim to the browser companies than EDAC or the IEEE seem to be with EDA companies.

[6] — That said, someone just needs to make it and write it. Fuck asking for permission.

[7] — We don’t need to use it for everything from the start — that will happen, just like it has with other open and extensible formats. But it needs to be possible.

[8] — As a result every single EDA tool has had to build a library just to ship their tool. In fact many of the big EDA companies employ hundreds or thousands of people to make IP, component symbols, simulation models because they know how important the library is for lock-in. Engineers can’t work without parts, and tools without libraries fail.

[9] — Octopart is the closest thing to this, but it’s exclusively electrical components — nothing too mechanical, no IP blocks, no concept of custom silicon, no concept of custom mechanical, no CAD data, no symbols, no footprints, no simulation modules — just pricing, PDFs and a few attributes.

[10] — So far Texas Instruments has been to most willing to work with us, and the most forward thinking about making their design and component data available. We have a long way to go, but some day vendors with publish directly to upverter and you’ll be able to get your component data, everything you’d ever get from a datasheet, directly from Upverter.

[11] — CircuitHub, SmallBatchAssembly, eFabless, and xFab are all working on this, and I believe they are making progress. But until interfacing with manufacturing is as simple as an API call, and until design files equal design intent, manufacturing will continue to be an incredibly painful, error prone and yet commoditized part of our jobs.

[12] — Every single other EDA tool has or will have to build these tools, and most of them will be terrible. But until there are better APIs between the design tools and the manufacturers, there is no opportunity for a new company to disrupt the gap.

[13] — Furthermore, these days every single EDA tool is building in mechanical modeling tools. Mostly for 3D view and explore, but some are taking it as far as 3D manipulation like moving connectors around. This is ridiculous. Why can’t we use Autodesk, or Onshape for these functions? Why are EDA companies diluting their competencies trying to solve geometry and 3D modeling issues. I should be able to send my changes into Onshape say, make my connector placement changes, and then load them back into Upverter.

Thanks To Katherine Hague, and Michael Woodworth for reading drafts of this.