Eagle Edge Connector

Eagle has a symbol for an old-style 8-bit ISA edge connector.  It's called IBM8BIT, and it's in the con-pc library.  Unfortunately, it has some extra gunk on it (dimension lines, a PC board outline, and the outline of that metal thing where external ports go) that I just didn't need when adding an edge connector to the ALU board.

As my second adventure into Eagle library editing, I copied the symbol from the con-pc library and removed the gunk.  The newly-slimmed-down library can be found here.

Back to Eagle

I switched from Eagle to Kicad awhile back.  Now I'm back to Eagle, by way of DipTrace.

Why did I leave Kicad?  In short, lack of support for non-hierarchical sheets, a mysterious bug in pin connection, possibly related to hierarchical sheets, and continued annoyance at the the little things I pointed out earlier -- spotty documentation, the need to create most of my symbols, and an opaque release process.

My ALU circuit, in contrast to the one for the Front Panel, is complicated enough that it needs to be on multiple sheets.  Kicad wants you to use hierarchical sheets about as much as I don't want to use hierarchical sheets.  As far as I can tell, there's no way to use non-hierarchical sheets, unless you create a fake two-level hierarchy, with one page at the top level, and everything else at the second level.

I wanted to do things The Kicad Way, so I started in on transforming the schematic for my ALU circuit into a hierarchy.  The design is such that this transformation is pretty straightforward, but you end up passing lots of signals in and out of each component.  I was just about done, when I ran into a crashing bug in eeschema (the schematic capture program), and lost all the hierarchy work I'd done.  That was exciting.

Later on, I tried again (saving all the while), and got everything back in shape.  Now to the electrical rules check, and from there to PCB layout.  Except the electrical rules check kept flagging lots of pins as unconnected, even though they clearly were.  Some poking around with a test schematic seemed to suggest that this was related to the use of hierarchical sheets, but (shame on me) I didn't collect enough data to file a bug report.  Maybe the rules check is wrong.  Maybe I can still lay out the board.  So off to board layout, and the connections the rules check was warning about were actually missing.  It seems the rules check was correct -- it was just flagging a problem caused by eeschema.  Googling and poking around didn't reveal any obvious solutions.

This was enough to tip me over the edge.  I was tired of having to run my EDA package under VMWare, remote-displaying to my X11 on my Mac.  I was tired of not having any visibility into the Kicad release process -- what's in a given release, and when new releases are made available.  I yearned for documentation.  For complete symbol libraries.  For actual non-hierarchical sheet support.

It may well be that everything I wanted (non-hierarchical sheets, documentation, release notes) could be found somewhere or worked around somehow, but I came to realize that I just didn't want to deal with it.  Free and Open Source are fun, but sometimes it's just easier to buy a commercial package so you don't have to deal with the rough edges.

DipTrace

Which one to choose?  Altium Designer?  Just $4,995!  Hahaha...no.  I didn't want to go running straight back to Eagle.  If I was going to switch again, I wanted to try out at least one other package first.  I'd heard people talking about DipTrace, so I gave that a shot.  DipTrace has nice pricing for non-profit use.  They do all of their licensing based on pin count, with the unlimited-pin, unlimited-layer non-profit license coming in at $348.  The trial version, at $0, supports 500 pins on two layers (their website says 300, but I swear I got 500).  So that's quite attractive.

To evaluate DipTrace, I used it to capture the schematic for the ALU.  I then asked it to lay out the ALU PCB.

I was only partially successful.  One of the attractive things about DipTrace was the licensing model.  Trading a sheet restriction for a pin restriction seemed like a no-brainer.  It gave me a chance to play with DipTrace's non-hierarchical sheets, and surely my teeny circuit wouldn't run into those seemingly-massive pin limits.

Even better, they have a version for the Mac!  Well, almost.  The version for the Mac is the same as the Windows version (and presumably the Linux version too).  Literally the same -- it's the Windows version running under Wine.  They have lots of libraries, with lots of symbols, support for non-hierarchical sheets, a very detailed tutorial ... but it's the Windows interface.  On my Mac.  I have nothing against the Windows interface on a Windows machine, but it's a jarring change when you try to use it on a Mac.  As one example, hitting Command-Tab to switch to another app (in my case Preview, showing the DipTrace tutorial) sends an Alt keypress to DipTrace.  When you press and release Alt on Windows, the menubar is selected, letting you use the arrow keys to select menu items.  Combine the two together, and Command-Tab, Command-Tab (i.e. switch to Preview, then back to DipTrace) leaves you in DipTrace with the menus selected.  All sorts of hilarity ensues.  Typing something can magically select an unexpected menu item.  Selection of symbols on the schematic doesn't quite work until you leave menu mode.  Very exciting.  Someone's also capturing Command-`, so you can't use it to flip between DipTrace windows.

Back to the pin limit.  The limit is probably no big deal for someone adding, say, some glue logic to an existing microprocessor.  40-50 pins for the microprocessor, another few dozen for some caps, regulator, and a support chip or two, and you're done.  I'd forgotten that my ALU is not like those projects.  When all is said and done, it'll have about 40 ICs.  That's 600 pins for the ICs alone (assuming an average of 15 pins/chip) before we even get to the edge connector.

Something weird also happened with printing.  I used the standard NAND and NOT gates, but the inverting bubble didn't print on either of them, leaving me with an ALU which looked for all the world like it was made with AND gates and buffers.

On to PCB layout.  The tool looked to be very flexible.  It had a single-layer-with-jumper-wires mode for the autorouter, which seemed like fun.  It had more knobs and adjustments than I quite frankly even knew existed.  More Wine-related UI issues here -- the inability to use Command-`, for example, made it painful to switch between PCB layout and schematic capture.

Unfortunately, my circuit's voracious appetite for pins meant that I would've had to plunk down actual money in order to fully capture the ALU, and to lay out the complete board.  I knew the UI issues would plague me until the end of time.  The printing issue was mysterious as well.  I decided to give Eagle another look.

Eagle


When last we left Eagle, it was in version 5.something, and was writing files in its own binary format.  One thing Kicad taught me was the value of having plain-text data files, as you never know when it'll be far easier to fix something with Emacs than with the app itself.  Version 6 writes its data files using XML, which means they can be edited.  Case in point: Eagle doesn't seem to support the reordering of sheets; nor does it support the addition of new sheets in arbitrary locations (or I don't think it does).  Now that the sch file is XML, adding a new sheet is as simple as adding the string "" in the appropriate place.

I looked long and hard at the pricing page, since I knew that was going to make or break the deal.  I already know there are zillions of symbols and packages available for Eagle, and I already know it runs natively on my Mac.  But I didn't want to pay a fortune for a license.  I no longer mind paying some sort of licensing fee, but I'd rather it not be over $250 or so just yet.

Eagle Hobbyist, which I think is new since I last looked at Eagle, is $169.  It supports 99 sheets, 6 layers, and a 160x100mm routing area (6.3"x3.9").  Assuming I break the microprocessor up into individual daughterboards (something which I think is a good idea in its own right), I think it'll be awhile before I run out of room.  Unfortunately, the next step up from Hobbyist is Professional.  Unlimited everything, but it costs $1640.  Sigh.  Maybe they'll have come up with an intermediate price point in the meantime.  I could see myself paying $500 for a Hobbyist+ version with a larger routing area.

I downloaded the free Eagle version (1 sheet, 2 layers, 3.9"x3.1"), and added the Freemium license code.  This gives me 4 sheets and 4 layers (of which I only need the sheets), but keeps the routing area the same.  Enough to re-evaluate schematic capture, but not enough to lay out the board.

As I remembered, the symbol selection is excellent, especially after I added the Sparkfun library.  The Eagle windows play well with others, which makes sense since Eagle at least pretends to be a native app.  The way you perform actions on groups is beyond annoying, but (grumblingly) manageable.  I don't even find package-selection-in-schematic-capture to be as annoying as I found it in the past.  Perhaps that's because I'm now making actual PCBs, and thus it's a useful step.  It's less useful when I'm simply creating a schematic for a breadboarded circuit.

Once I got some hotkeys set up (DipTrace and Kicad ship with a much more useful set, IMO), the schematic went together quickly.  I started poking around the PCB layout tool, but haven't done a whole lot with it -- primarily because my IC footprint alone exceeds the routing area for this version.

All in all, the XML file formats, the extensiveness of the part library (and the size of the part-making community), and the way the UI plays well with the rest of the system have convinced me to give Eagle another try.  Next step, paying for Eagle Hobbyist, and getting the ALU laid out.

A nice chilly ride

Today was a chilly day for riding.  It started at about 29 degrees in the city (lower outside the city), and gradually warmed up from there.  And by "warmed up", I mean to a balmy 31 degrees.  This was officially my first cold weather ride of the season.  I got some minor ice formation in my uninsulated bottle, but not enough to call it a frozen bottle ride.  I like my bottles to be nice and solid before I put that label on.  It usually takes several hours in the low 20s to pull that off.

I like this new route.  It doesn't have a name yet, but that's not nearly as important as the fact that it doesn't repeat.  I dislike repeating with a fiery passion.  I had previously resigned myself to needing to repeat the last three miles to the bridge, along Hudson Terrace.  Basically you take 9W to Piermont (or beyond), and 340/Piermont Rd back to Churchill, over Churchill, up Palisades, and back to 9W/Hudson Terrace.  Now I've found a new way to continue past Churchill (i.e. not over it), into Fort Lee, through downtown, returning to the GWB from the south.

It's not flat as a pancake, but I think it does pretty well given that this part of NY and NJ is littered with ridges.  Certainly there's nothing to compare to Nyack's Old Mountain Rd or Toga Hill.  While we omit Churchill and Palisades, the altitude gained during those climbs must be made up somewhere.  This route splits those big hills into several shorter ones.

Total mileage is about 55-57, and it takes me about four and a half hours.

View Sickletown addition in a larger map

That said, if I'm going to do 55-57, I might as well do 60, so I'm exploring some options for extending it a little bit.  Rather than turning down Sickletown from West Nyack Rd, I'd like to try continuing on West Nyack until it turns south after Rockland Shopping Center.  West Nyack ends at Church St, so then we jog east to Blauvelt Rd, take Blauvelt to Townline (CR 42), and Townline back to Sickletown.  I've done Townline from South Middletown (CR 33) to Sickeltown, and that was pretty reasonable.  We'll have to see how the rest looks.

My success with finding a nice way through Fort Lee (I had previously thought that escaping east via Palisades back to 9W was the only way to go) inspired me to take another look at the beginning of my Philly route.  I'd been going south from Fort Lee, through Palisades Park, Ridgefield, Ridgefield Park, and then Little Ferry.  This involves a truly unfortunate river crossing on US-46, which is so busy that even I ride on the sidewalk.  That bridge is then followed by a very busy roundabout.  All in all, not a good time.  I had accepted that crossing as a necessary evil, but now I'm not so sure.

View Northern start of Philly route in a larger map

What if I could cross that same river at Bogota/Hackensack?  Basically come around from the north side of I-80, rather than staying to the south of it.  Streetview suggests that there are some nice crossings into Hackensack on Cedar Lane and Main Street.  Cedar Lane looks a bit busier, but the bridge is paved.  Main Street is quiet, and goes through a park, but its bridge is metal grate.  I'll need to investigate both to be sure.  Getting to those bridges might be a bit tricky, though.  Fort Lee Road / Degraw Ave is the obvious choice, but it gets very busy in stretches.  Today's route put me further west on Palisade Ave than I had been before -- far enough down that I could see quite a bit more to the west than I had been able to see from my typical crossing at Woodland Street.  Palisades definitely crosses a ridge to the west, but I'm going to give it a shot to see what it's like.  If this works, it should add about 6 miles to the ride, but it'll get rid of some unpleasantness.  Probably worth the tradeoff.

So much riding to do!  So little time.

No, really -- 2 bits this time

It took me far longer than I had anticipated, but I've finally got the two-bit ALU working correctly.  As I said in my previous post, the problems were all in the control bits.  All sorts of unholy things happen when you try to reduce their number.  Had I chosen to use five bits, the control bit space would've been very sparse, but getting the circuit working would've been merely a matter of nailing down which combination of control bits to use for each operation.  But no, I had to try to be clever.  I had to see if I could use three bits.  Turns out yes, I can.  The trickiness arises when you try to find the one magical bit pattern which will allow all five operations to work without stepping on each other.

Hardware Layout

Here's a diagram of a typical bit in the ALU:

The circuit for a typical bit is best described as a modified full adder.  These modifications, which are necessary to support five operations (ADD, SUB, AND, OR, and 1-bit NOT), are as follows:

1. There's now a subtraction mux which determines whether the full adder sees B or not-B.  Not-B is presented only when we're subtracting.
2. I added two result taps (RA and RB), in addition to the traditional output (labeled RC).  RA gives me access to AND and NOT; RB to OR; and RC to ADD and SUB.  A final 4-1 mux, controlled by OP0 (low bit) and OP1 (high bit), selects between the three.
3. Two muxes -- one controlled by OP2 for AND, and one controlled by OP0 for OR and NOT -- intercept input values and replace them with hard-coded values.  The OP0 mux, for example, allows us to turn the two following NAND gates into NOT gates.

I started out thinking I'd need five control bits -- OP0-3 and SUB.  Somehow I realized that only OP0-2 and SUB were required, and started working on eliminating one of those four.  SUB is pretty much off the table, as it can't be derived from any other line, and doesn't influence any other lines.  I tried guessing at values, with marginal success, until I came up with an approach which simplified things significantly.

First, realize that OP0 and OP2 are the important players.  We'll need OP1 to help select among the result bits, but we can reorder the input values to the R mux just about any way we like, so there's less pressure there.  So first we'll figure out the OP0, OP2, and SUB values for each operation, and then we'll come up with values for OP1 which make the R mux work (i.e. which don't result in overlap).  Once we've come up with OP1 values, we'll see if we can derive one of the OP bits from the other two.

If we just happen to pick OP0 and OP2 alignments (i.e. which bit gives the hard-coded 1 and which passes the existing value through) shown in the diagram above, we get the following truth table:

Operation	OP0	OP1	OP2	SUB
ADD	0	1	1	0
SUB	0	1	1	1
NOT	1	0	1	0
AND	0	0	0	0
OR	1	1	1	0

Looking at this table, we can see that OP2 is easily derived as OP0+OP1.  Three extra NAND gates, and we're down to three input control lines (OP0, OP1, and SUB).

An aside: We had some flexibility with the OP0 and OP2 mux pin assignments, because it's trivial to swap the pins, reversing the entire column in the truth table.  Say we started with the OP2 mux having the hard-coded 1 when OP2 is high.  OP2 in the truth table would thus be 0, 0, 0, 1, 0.  This can still be synthesized from OP0 and OP1 as OP0 NOR OP1, but that requires four NAND gates.  Flip the pin assignments on the OP2 mux, and we need only build an OR gate, which requires three NANDs.

Verification

Testing the ALU is a bit of a pain with 2 bits, and would be even more annoying when fully built out. Five operations times 2 bits (eventually 8 bits) -- it just screams for automation. While the Front Panel may seem a bit silly for interactive use (wiring up LEDs and switches isn't that hard, though it is tedious), it really comes into its own for testing. I wrote a program which uses the Front Panel to set the control and input bits to a particular configuration, and to then verify that the output bits have the expected value. That program takes an input file which describes how to perform each verification.

Armed with an input file which contains 36 test cases, I can now validate the entire ALU in about 15 seconds by running a single command. Suddenly all that time spent building the Front Panel seems quite worthwhile.