Open Source Hardware 2009 (Make) [LWN.net]

Real world problems

Posted Dec 12, 2009 23:42 UTC (Sat) by ahvezda (guest, #19657) [Link]

Also, I am sad to see "open source hardware" designs that are done using proprietary (non-open source) ECAD software, such as Eagle. I am always excited to see a free/open source hardware project that is using free/open source software to publish their schematics and/or printed circuit board layouts.

-Ales

PS. Some bias here given that I'm a developer of gEDA. ;->

Real world problems

Posted Dec 13, 2009 7:53 UTC (Sun) by tajyrink (subscriber, #2750) [Link]

How does gEDA compare with KiCad by the way? I also like the fact that eg. gta02-core (http://wiki.openmoko.org/wiki/Gta02-core) extends KiCad while they are doing schematics, and asking around from manufacturers which of them can use KiCad files.

Real world problems

Posted Dec 14, 2009 2:29 UTC (Mon) by jeff@uclinux.org (guest, #8024) [Link]

Back in 1998, I designed the first uCsimm board with a hand edited netlist and PCB. I had to
hack PCB at the same time to make it possible. I couldn't be productive that way, unfortunately,
and the only reason it was possible at all was because uCsimm type modules are simple... just
fairly high density and relatively small geometry.

KiCad is closer, but just isn't enough. The reason, IMHO, is the file formats. To have really
effective electronics CAD, the data model is most important. It doesn't need to get as complex
as a database engine (actually, I think a database misses the point) but it does have to have good
structure. For the sorts of things I do (consumer stuff lately: sub 600 components, sub 20 ICs,
BGA, double sided surface mount, high density but usually only 4 layers, no blind vias and hand
routed) the data model Eagle uses is adequate (documented in the manual).

I'm convinced that the right approach to this is a simple one: LEX/YACC parser that reads a text
file with a structured design, perhaps similar to Eagle's. Or even just map a data structure like
that to something like JSON and reuse some other parser (ok, you could make an XML schema if
you really must ;). From there, write code to manipulate the structure and _then_ another
project(s) can write some front end code, CAM processing for Gerber generation, etc... whatever
itch needs scratching.

I figure the whole library that can programatically perform any necessary action on the data
model should be 20k lines. Demonstrating the data model is sufficient first would seem to be
the right approach, and easy too... just convert some real world designs to it without loss.

Real world problems

Posted Dec 14, 2009 14:22 UTC (Mon) by bcopeland (subscriber, #51750) [Link]

Demonstrating the data model is sufficient first would seem to be the right approach, and easy too... just convert some real world designs to it without loss.

I used to do this for a job -- that is, write translators from various PCB cad systems (our competitors) into our own software. Mostly people just wanted to route through our software to get to somewhere else, like Allegro -> us -> Mentor. Although each system had its own quirks, you can go a really long way with a very simple flat model: list of nets, list of pins, list of pads, list of vias, list of traces, list of layers, list of random artwork. And then maybe a map or two or some pointers thrown in to have hierarchy. ISTR Orcad being especially amenable to lexx/yacc treatment.

It's definitely not hard. I found it extremely boring work :)

Real world problems

Posted Dec 14, 2009 16:11 UTC (Mon) by endecotp (guest, #36428) [Link]

> I'm convinced that the right approach to this is a simple one:
> LEX/YACC parser that reads a text file with a structured design

The case for using something more complex - e.g. more database-like - is that you can avoid the need for expensive parsing and indexing each time the file is opened. There is also the question of how to implement auto-saves that are not >= O(N). Whether this matters depends on the type of tool and how it is used.

Maybe yours could be considered an "interchange" format?

Real world problems

Posted Dec 14, 2009 4:33 UTC (Mon) by ahvezda (guest, #19657) [Link]

gEDA and KiCad are different. KiCad is a more tightly coupled ECAD environment. The programs in the gEDA suite are not tightly coupled and try hard to follow the Unix philosophy of program design. gEDA is more of a toolkit/collection of GUI and command line programs that cooperate using open and well documented file formats (all ASCII based). One of the major strengths (and to some people a weakness) of gEDA is that the hardware designer has a tremendous amount of control over the design work flow and can easily inject a new component without having to change any of the core tools. This control comes at a price, of course-- a steep learning curve (but there is documentation and several tutorials).

If you just want to create schematics/PCBs without having to scale a steep learning curve, then KiCad will probably meet your needs nicely. If you like Makefiles, command line tools, scripts, many netlist targets, and extreme control over the design flow, then gEDA might be more to your liking. It really depends on what you are used to and how much time you are willing to invest.

The wikipedia pages on gEDA and KiCad are current and check out the the respective homepages for more info.

Yeah, I'm glad that the openmoko folks are using KiCad instead of something closed.

Real world problems

Posted Dec 13, 2009 18:14 UTC (Sun) by BrucePerens (subscriber, #2510) [Link]

Hm. Does "real" Open Source hardware then have to be made of 100% components that are themselves Open Source hardware? We can't use CPUs that have public documentation but not public internals? It seems a bit self-defeating to set the bar quite that high.

If you want to use them, there are lots of public CPUs at OpenCores. We don't yet have a good public gate-array to program them into.

Real world problems

Posted Dec 14, 2009 5:23 UTC (Mon) by flewellyn (subscriber, #5047) [Link]

Intriguing question. As more and more of the hardware we use becomes programmable, where does the line fall?

Real world problems

Posted Dec 14, 2009 5:40 UTC (Mon) by BrucePerens (subscriber, #2510) [Link]

For Open Source software, the line falls at the bus. You need to know how to program everything at the peripheral bus level. Device functions for normal operation and system management that can be accessed at the bus level must be documented. This may also include a subset of diagnostics used to detect configuration of the device and sanity-check the device.

For hardware, you need that too, but instead of an I/O bus it's the pins of the device.

Nobody out there is seriously considering making their own RAM at this point. We need to be able to take advantage of economies of scale.

Open Source Hardware 2009 (Make)

Posted Dec 13, 2009 2:38 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]

If you want to be pedantic you could claim that open software is exceptionally rare because there is some less that totally free element (a firmware or microcode, for example) in the execution path of almost everything.

There is a spectrum of freeness and in order to move towards the freeer end of the spectrum it can be useful to draw artificial lines to denote "free enough", but all that is is an artificial line. Until you can click-to-download the brain of the person who created something there is always going to be room to make any complex system more open and liberated.

Recondition of this spectrum is why things like the FSF's definitions have changed over time in 1990 they didn't complain about firmware blobs, but today they do.

In the realm of hardware not only is nothing absolutely free but there is a wide diversity in the freeness provided. OpenMoko was widely described as open hardware, but it really was regular hardware with open documentation.

The Elphel cameras are much more open, with gerber files for the boards and GPLed synthesizeable verilog but it still depends on some less-open digital parts (like a mips SOC).

Another example The USRP2 even implements its control CPU on its FPGA all with open code, but you can't target the particular FPGA it is using with the gratistools, much less free software tools.

We lack the language to even talk clearly about the degree of openness provided by non-trivial hardware without digging deep into every fine detail.