Slashdot Mirror

VHDL Cookbook is a good, though dated, intro.

Use ghdl to learn vhdl, without the need to have hardware, as it compiles VHDL to an executable. Icarus is similar, but for Verilog. gEDA has good tools, including the gtkwave waveform viewer. Combined, ghdl, Icarus and gtkwave are a pretty useful simulation suite. You can go a long way with simulation, since the normal design flow is to get the system 100% using simulation, then as a last step program the FPGA with maximal probability of it just working. As Bruce said, the actual partition, place and route tools are proprietary and specific to each FPGA vendor, and a google search will come up with a number of cheap FPGA boards.

Keep an eye on left field though. There is a convergence in progress between desktop CPU's, GPU's, parallel systems and FPGAs (which can be seen as an array of massively parallel simple processors). One day all I wrote may be obsolete and you will be able to program your FPGA in CUDA, or whatever results when mainstream programming figures out how to handle parallel systems properly.

VHDL Cookbook is a good, though dated, intro.

Use ghdl to learn vhdl, without the need to have hardware, as it compiles VHDL to an executable. Icarus is similar, but for Verilog. gEDA has good tools, including the gtkwave waveform viewer. Combined, ghdl, Icarus and gtkwave are a pretty useful simulation suite. You can go a long way with simulation, since the normal design flow is to get the system 100% using simulation, then as a last step program the FPGA with maximal probability of it just working. As Bruce said, the actual partition, place and route tools are proprietary and specific to each FPGA vendor, and a google search will come up with a number of cheap FPGA boards.

Keep an eye on left field though. There is a convergence in progress between desktop CPU's, GPU's, parallel systems and FPGAs (which can be seen as an array of massively parallel simple processors). One day all I wrote may be obsolete and you will be able to program your FPGA in CUDA, or whatever results when mainstream programming figures out how to handle parallel systems properly.

the sooner Autotools dies, the better.

I quite like autotools, actually. If you actually think about what you're doing when writing your configure.ac and M4 macros, it's an elegant, clean and easy to understand solution.

Unfortunately, at the moment it seems fashionable to throw all the configuration macros into a single, poorly commented file, with all the code copied and pasted from other projects with little understanding demonstrated of what it does or why it does it, with the predictable poor performance and low maintainability.

the sooner Autotools dies, the better.

I quite like autotools, actually. If you actually think about what you're doing when writing your configure.ac and M4 macros, it's an elegant, clean and easy to understand solution.

Unfortunately, at the moment it seems fashionable to throw all the configuration macros into a single, poorly commented file, with all the code copied and pasted from other projects with little understanding demonstrated of what it does or why it does it, with the predictable poor performance and low maintainability.

Howdy,

I posted above, but I think things were lost in the noise. I've been using anyInventory ( http://anyinventory.sourceforge.net/ ) for my electronics catalog. The bonus is that it is a web interface, so you can use any web browser to view/search/edit your inventory, which is a big plus over zparts, I think.

I have it setup to track these fields:

    My 'part number' (which I put on schematics so I know what I used)
    Vendor, price, Vendor part (for re-order and quick costing of a project)
    Manufacturer, part, link to datasheet, part photo
    Value, tolerance, power rating, package, etc
    Location (more below)
    Quantity on hand/order
    geda footprint (for geda's PCB http://www.gpleda.org/index.html [gpleda.org])

My internal part numbering system is a 3x4 part number, ie, 100-0001, where the first 3 digits are a category of part (resistor, 74 series, whatever) and the 4 digit is just a number I assign to make it unique. This allows me to specify my part number on a schematic or BOM along with the refdes and value so I know exactly the part and footprint I need.

Secondly, I have a series of drawer cabinets, bins, etc as needed to store the parts, each labeled with drawer, cabinet, shelf (usually with a barcode for some future fun with a barcode reader).

Anyway, I hope that helps.

Here's the solution I use to inventory my electronic components.

First, I have a database setup using anyInventory ( http://anyinventory.sourceforge.net/ ) that catalogs the important bits, ie:

  My 'part number' (which I put on schematics so I know what I used)
  Vendor, price, Vendor part (for re-order and quick costing of a project)
  Manufacturer, part, link to datasheet, part photo
  Value, tolerance, power rating, package, etc
  Location (more below)
  Quantity on hand/order
  geda footprint (for geda's PCB http://www.gpleda.org/index.html)

My internal part numbering system is a 3x4 part number, ie, 100-0001, where the first 3 digits are a category of part (resistor, 74 series, whatever) and the 4 digit is just a number I assign to make it unique. This allows me to specify my part number on a schematic or BOM along with the refdes and value so I know exactly the part and footprint I need.

Secondly, I have a series of drawer cabinets, bins, etc as needed to store the parts, each labeled with drawer, cabinet, shelf (usually with a barcode for some future fun with a barcode reader).

Why go to all the bother? Seriously, I have hundreds and hundreds of parts. I work on circuits for a living, and trust me, not having the organized blows.

I started on another project at one point in time that would automate assigning parts to a 'product' or 'project' so you could wasily generate invoices or costing, but I have not completed it yet. I'll probably get back into that this year, though.

Yes. On my previous job they asked me to create a schematic, and of course I had to wait a week for the IT staff to show-up and install the necessary machine on my machine. While I was waiting I searched for OSS CAD alternatives, gave each one a quick spin, and determined they were all inadequate.

Inadequate for what? gEDA has been successfully used to design several satellite payloads, at least one multi-FPGA number crunchers, software-defined radio equipment, SDSL modems, and very high power converters for wave power applications. The only major downside is that it's not supported on Windows.

(Disclosure: I'm a developer.)

For ASIC design, every IC design shop I've worked at has used Cadence and/or Synopsys running on Serious Hardware in the server room, accessed by engineers using some sort of remote desktop system (either X over SSH or a VNC-alike).

For mechanical CAD, ProE runs just fine on Linux.

The issue isn't that Munich wants to switch to Open Source for everything -- even as a FOSS developer myself, I'd be the first to admit that for some (many?) applications there isn't a FOSS solution on the market -- but that they want to standardise on a single, open platform that includes all of the standard "productivity" applications, and as much other stuff as makes sense.

http://www.acooke.org/andrew/electronics/spice.html- Spice and GEDA tutorial

http://members.dslextreme.com/users/billw/gsch2pcb/tutorial.html-Bill Wilson's tutorial on using gEDA/gaf, gsch2pcb, and PCB

Ugg! These tutorials are completely ancient. I have removed them. Thanks.

The official documentation for the gEDA project can be found here: Official Documentation

Seriously, if you want folks to use gEDA, release a beginner's guide showing how to make something simple, like a fm transmitter or lm317 board, and how to successfully prepare it for sending off to some place like batchPCB.

How about these documents:

• gsch2pcb_tutorial
• gschem_warmup
• transistor_guide
• Getting started with PCB
• ngspice and gschem
• tragesym tutorial
• Circuit Design on Your Linux Box Using gEDA

There is lots of documentation available for using the gEDA suite of tools and the geda-user mailing list is very friendly to all levels of users. I could probably dig up a few more tutorials if the above isn't enough. :)

I've also added a bunch of new free/open source hardware projects to the gEDA links page. There are some really awesome projects listed there that do not use proprietary tools.

Eagle isn't free, though.

kicad is pretty decent, it's GPL and cross platform (there's a win32 branch).

gEDA is ok too, but there's something I don't like about it's schematic editor... Can't think of it right now though.

Libraries break their ABI periodically on Linux because no one really thinks about binary developers. Think about this: a deb package for Ubuntu from a release six months ago will probably not work on the next release.

Just a data point: KDE is planning to have ABI stability for the entire 4.x series -- i.e. a program compiled against KDE 4.0 should work with kdelibs 4.1, 4.2, etc. In fact, that was a stated point of the 4.0 release: to say, "This is the start of the stable KDE 4 ABI.

A project I work on, gEDA, has a shared library called libgeda that is only used by the apps in the gEDA suite. Nevertheless, we are very careful to maintain binary compatibility during a release series -- for instance, all the 1.4.x versions of libgeda are ABI-compatible. This is mostly out of deference to 3rd party app developers (I'm not sure there are any). Yes, we break our ABI -- and API -- regularly, but "regularly" is about once a year and at the start of a new stable branch.

You have to understand, though, that most developers of Linux libraries couldn't care less about closed-source -- because the vast majority of users of their libraries will use Linux distribution packages, and the distributions recompile everything anyway every release cycle, why go to the trouble to avoid some minor inconvenience to people who aren't going to contribute back to the community anyway?