Chip design, open source, and DIY: Part 2, open source issues

Above: Concept for an "abstract layout" workflow that could reconcile open source circuit designs with "closed" process design rules and libraries. First the designer would generate an abstract layout by instancing cells for various components. The above example shows a 2-input AND gate, with one input pulled to ground with a 10k resistor, and a tri-state buffer as an output. The designer would instance these cells, and then route connections between them. The designer would also place cells corresponding to "pads" at the periphery of the chip. The designer would not need to know the exact layout of the cell interiors- this may be kept "closed" even while the abstract layer itself is "open". This abstract layout may then be converted to a full detailed layout that may be used by a foundry to fabricate the chip.

Introduction

This is the second part of a three-part blog posting on chip design and how to reconcile it with the open source and DIY movements. Previously in Part 1, I gave a top level summary of “indie chip design” as I experience it. In this part I will discuss the real issues I would face if trying to “open” up a chip design. There are three areas to consider: the CAD design tools themselves, the design rules for a particular chip fab process, and design libraries.

First a few definitions: The term “foundry” refers to a company that performs the actual chip fabrication. The term “process” refers to a particular fabrication line of a foundry. A foundry may have several processes including ones optimized for digital circuity and others designed for analog. Typically a foundry will have several grades of processes, with more expensive ones having more capabilities or a smaller feature size. The term “design tools” refers to the CAD tools that one may use to design a chip (analogous to Eagle for PCBs). The term “design rules” refers to specifications such as minimum width, spacing, and other requirements for the different layers.

Chip Design Tools: Open source versions do exist!

First I present some good news- Open source chip design tools do exist. One of the most prominent versions is Magic, which was created in the mid 1980’s and has gone through multiple revisions as late as 2008. I personally used versions 6.4 and 6.5 for all of Centeye’s chip designs from 2001 through 2004, including designs with up to 400,000 transistors. Magic is somewhat derided by many chip designers because it automates the generation of some layers and restricts you to purely Manhattan geometries e.g. no diagonal features. However in practice these restrictions affect only a minority of overall chip designs and do not cost much in terms of layout space. Magic has a real-time design rule verifier- you will know pretty much right away if your layout has violated a design rule. I found this useful when first learning chip design. Magic is also able to create CIF and GDSII files, the chip design equivalent of Gerbers used for PCBs.

Magic was originally designed to run on Unix and Linux operating systems, but it has more recently been ported to Windows (using Cygwin) and is maintained here at Open Circuit Design. Unfortunately it appears that recent development efforts have slowed, so I am not sure if Magic is as actively used as in the past.

Other open source layout tools exist as well, for example Electric. There is also a free, but not open source, tool called Lasi (pronounced “lazy”).

For circuit verification there are also free circuit simulators, most notably the venerable SPICE.

Commercial chip design tools exist as well (if you have the money...)

There are a number of commercial design tools available as well. I now use Tanner Tools, while others (with more resources) may use Cadence or Synopsys. The cost of Tanner Tools is within reach for a small company (on the order of the price of a new car- depreciation is my friend!) but is out of reach for most hobbyists. The other latter tools can cost, as far as I know, a upwards to a million dollars per seat, but allow wide-scale cooperation between large teams of designers.

As for why I switched from Magic to Tanner- Around 2005 we were migrating to a new foundry and process and were anticipating designing more complicated chips, so I felt the need for something “professional”. Tanner Tools has worked very well for us. However- and this would be a good story for another post- we succumbed to “complexity creep”, thus producing complicated (and headache inducing) designs, but later reversed course, so that now are designs are more minimalist again. I could go back to Magic, however since I now have the Tanner and have built up my own libraries within it, it is easier stay with Tanner. There are also other issues, which will be discussed next.

The bad news: Design rules, setup files, and design kits are generally not open.

As I see it, the biggest issue preventing bringing open source to the chip design rule is not the design tools themselves, but the design rules! The design rules on a PCB are relatively easy to set up and for programs like Eagle are freely available. They are also easy to understand. For chips, however, the design rules are generally treated as proprietary by the foundry. This is because the design rules contain information that describes the capabilities of a process, and the foundries don’t want that information freely disclosed without restrictions. Yes- I had to sign NDAs to get the design rules for all of the processes we use now! Similarly, the “setup files” that design tools use to configure a design program for designing chips for a particular process are also generally treated as proprietary by the company that sells the tools.

The same applies to the “design kits” themselves- these are basically library files that contain cells for different subcircuits you may want to use in a chip design. This includes cells such as gates, flip flops, or basic analog components. This also includes essential cells such as the “pads” that allow a chip to be interfaced with the outside world.

And this, folks, is why we cannot open source our chip designs- I would be violating all the NDAs I had signed with these companies! The most I could do (which I have already done in one case) is to release a schematic of the chip, in PDF form, that contains details on the circuits I had designed, and then “black boxes” for anything that came from a design kit.

Overall the trend seems to be for new advances to be made in the “closed” world, with open design tools and design kits being increasingly obscure and obsolete.

Is there a workaround?

I can see two possible workarounds. One method is, in fact, a workaround that has been used in the past and (I believe) is still available to an extent. The other is one that comes to my mind. Both would require some level of cooperation from the chip foundry.

Workaround #1: Use simplified, genericized design rules

During 2000 through 2004 when I was using Magic, I also used the MOSIS service for chip fabrications. MOSIS is effectively a brokerage service that places different designs from different people onto the same wafer, thus allowing everyone to share the tooling costs. (I’ll talk more about that in Part 3 of these posts.) When using MOSIS, you had the option of using either the design rules from the foundry (requiring an NDA), or you could use more generic design rules that MOSIS set up and made freely available.

The MOSIS rules had the advantage of being a bit more transparent and easy to understand. Also a design made for one process could be fabricated on any process that supports the same design rules. However they had several weaknesses- First, designs made using these rules are not a compact as they would be using the native foundry rules. In practice this penalty would be small, on the order of a few percent at most. Second, the MOSIS rules may not allow you to use all the features that a particular foundry or process supports. Third, the MOSIS rules are compatible with only a few processes- A look at the MOSIS website reveals that these rules are usable with two foundries. If you are willing to be constrained to just these two foundries (and both are good!), and if you don’t need some exotic unsupported feature, for most designs this approach will work.

The same concept used to make these MOSIS design rules can be applied to other foundries. The only barrier is obtaining the cooperation of the foundry, who may not want details of their process revealed openly or simply may not want to spend resources supporting an additional set of design rules.

Workaround #2: Use an intermediate abstract layout

The second workaround would be to set up an abstract design layer that is more detailed than “schematic” but less than that of “layout”. I envision something like what is depicted on the top of this post- A designer would create an abstract “layout” that instances cells such as gates, pads, or individual discrete components. Each of these cells would have a number of known “ports”, including power/ground lines, inputs, and outputs. For example an “AND2” gate may have two power ports (ground and power), two digital inputs, and one digital output, while a capacitor or resistor may have just two ports. Some cells, of course, would be the pads that allow the chip to be connected to the rest of the world.

The designer would not need to know the specific layout of these cells or even their exact circuit diagram, but would need to know enough to use them in a design. The designer would instead have several page (or more) datasheet describing everything needed to use that cell. For example, it might be known that the AND2 gate requires 5ns to settle and can source up to 10uA of current, or that a specific capacitor cell holds 1pF but has 0.1pF of parasitic capacitance at one node. The designer could then create an abstract layout by dropping these cells at various locations on the chip, much like a PCB designer places “parts” on a circuit board layout. The designer could then draw the wires to connect the components together. Such a design tool could have autorouting features. The design tool would then perform basic design rule checks.

Once the design is complete, this abstract level design file would be exported and sent to either the foundry or a “middle man”. The foundry or middle man would then be responsible for generating the final layout files from the abstract layout. Finally, the foundry could fabricate the chip.

The disadvantage of this approach is that the design is still only “partially open”. However at least the abstract layout could be made “open” and freely shared or released with appropriate open source licenses as desired.

There would be another benefit to this approach- The workflow would be more similar to that of making a PCB, in both the steps taken and the complexity. This approach would make chip design more accessible to a “casual” chip designer.

In my next post, I will discuss economic issues associated with chip fabrication.

Views: 6229

Tags: chip, design, open, source, vlsi


3D Robotics
Comment by Chris Anderson on September 7, 2011 at 3:54pm

Another great post, Geoffrey. Your point about the difficult in open sourcing hardware with closed source tools dependencies is echoed in a post today by the Microchip folks about why all the PIC tools aren't open. 

Comment by frederic reblewski on September 7, 2011 at 4:40pm

the open source model would have to be different anyway. if you use open source info for a software or board design, most of the time it is to build a single instance of the design. in the chip case there is nothing like building a single chip, so you would have to manufacture a wafer lot so interact with the foundry and sign their NDA. if the idea is to reuse part or all of the design in a derived product you are in the same situation as the derived product will be using the same target process ( so again involvment with foundry and NDA ). in fact the situation would not be very different from offering a hard IP block for free. of course if your design is not full custom and involves a third party library you have that additinal difficulty. but some open libraries are available.

 

on a different note in addition to MOSIS you have CMP http://cmp.imag.fr where you can in a multi project environment create MEMS chip. 

Comment by Richard on September 8, 2011 at 5:52am

Great write up again Geoffrey... I can't wait for the third part...

 

Comment by Ho-Chung Chang on September 8, 2011 at 8:48am

The XMOS maybe is a option.

 

Comment by bGatti on September 9, 2011 at 9:24am

Geoffry,

What is the minimal cost to get back a single test chip?

 

 

Comment by Ritchie on September 9, 2011 at 10:11am

bGatti raises an interesting point. Would chip manufacturers be willing to setup a BatchPCB like chip enterprise that brings many designs onto a single die for production? I'm not sure they would be able to let alone would but is very interesting to think of it. Create our own CMOS chips or capacitive touchscreen systems.

Comment by bGatti on September 9, 2011 at 10:43am

Richie - they already have; It exists - I'm just not sure of the price range

Comment by Geoffrey L. Barrows on September 9, 2011 at 11:42am

Thank You everyone for your replies!

@Chris: I looked at that post by the Microchip folks- yes that makes sense. I would be willing to bet that most employees of these companies understand the benefits of bringing at least a partial open source component to their product offerings. But in addition to overcoming bureaucratic gridlock and getting upper management to change their minds, there is the legal gridlock from multiple layers of IP. I wonder if the companies that make the USB and TCP/IP themselves have arrangements with yet other companies that would prevent opening things up, and those companies with others, and so on.

When everyone was drafting the OSHW 1.0 definition last year, I added what eventually became criterion #2, listed below, to handle this type of situation. I'm glad everyone decided to leave it in!

2. Scope

The documentation for the hardware must clearly specify what portion of the design, if not all, is being released under the license.

@Frederic: Points taken- You come from the EDA (electronic design automation) industry so you probably have more experience with this than me. For 99+% of chip designs your comments are absolutely correct. But one wonders what new value may be created by carving out a space for open source, or at least semi-open source, approaches. As for open libraries- It is true they do exist, but it seems more for digital than analog. Also I'm not sure how many processes they can be applied to. 

@bGatti and @Ritchie: Yes, this already exists. Short answer- Currently I've seen as little as maybe $2k for university customers and about $7k for anyone else for 40 copies of one design. The price breaks as volume goes up is pretty amazing- $20k will get you a set of wafers, which can translate to tens of thousands of chips. (Can anyone say "Kickstarter"?) I will talk about that more in Part 3.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2014   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service