Showing posts with label Eagle. Show all posts
Showing posts with label Eagle. Show all posts

Tuesday, March 19, 2024

ALU and ID boards sent for fabrication

I started laying out the Instruction Decoder board in late November 2012, and started the Arithmetic Logic Unit board ten days later. Now, only 147 months later, I finally finished their layout and sent them off to JLCPCB for fabrication. Woo hoo!

Fabrication time is quoted as 5-6 days, and shipping from China adds another 2-4 days. That puts delivery in the first week of April. That'll give me time to do my taxes without this as a distraction.

Friday, March 15, 2024

Arithmetic Logic Unit board fully routed

 Here's the Arithmetic Logic Unit board:

All nets have been routed, and the design rule checks run without error. 

Tuesday, March 12, 2024

Instruction Decoder board layout complete

 Here it is, the (hopefully) final layout of the Instruction Decoder board:


Like the previous two and several to follow, this board uses stacking connectors to make the connections between it and the other boards that make up the i4004 CPU. Initially I thought all the inter-board connections could be made through the connector on the right, but once I'd split the master schematic into five smaller schematics I realized that this board and the Arithmetic Logic Unit board had so many connections that a second connector was needed. Thus the connector on the left was added to the designs.

I thought I was done with this board a few days ago, but while checking the connector pinouts against my master spreadsheet of interboard connections I realized there were six that didn't have pin assignments. These nets were fully routed within the board, but didn't connect to pins on a connector. This would have been something easily correctable by adding wires to the board later, but of course it's better to have caught it now.

There are a few reasons I'm I haven't sent this board to JLCPCB for fabrication. The primary reason is that I can't test this board without the ALU board; my FPGA interface board just doesn't have enough I/Os to be able to connect to all the ID board outputs. So there's little benefit to sending this one out without the ALU. Secondly, the shipping cost for this board alone is the same as for this board and the ALU board together, and ordering them together will save me about $25.

The only change I might make to this board before ordering is to reduce the layer count from 6 to 4 by merging the interior signal layer into the power distribution layer. The cost difference is only $6, but with resistive pull-ups I don't need a full power plane and it annoys me to have the extra layers.


What about the ALU board? There are still 60 unrouted nets remaining. A portion of the circuitry is incompletely routed, and I'm not happy with the component arrangement in that portion. I'm thinking it'll probably be sometime next week before it's finished.

Saturday, March 9, 2024

JLCPCB design rules for Eagle

A couple of days ago I "finished" routing the Instruction Decoder board. To be sure JLCPCB wouldn't have manufacturing problems, I used the same Eagle design rules file (DRU) I'd used to fabricate the Scratchpad Register board.

The Scratchpad board's DRU file started with the Eagle DRU file JLCPCB posted on GitHub for use with 2-layer boards which I modified for the 4-layer stack-up. Since JLCPCB's published capabilities allow tighter spacing on 4- and 6-layer boards I assumed this would be safe. The Scratchpad board works, but was this a good assumption?

Thursday, March 7, 2024

The Instruction Decoder PCB

When I started my efforts to construct a discrete-component replica of an Intel 4004 CPU in June of 2012, I realized that I was going to have to split the CPU into several parts. This was largely dictated my hobbyist license for the Eagle CAD program, which limited me to placing components within a 160mm x 100mm rectangle (that's 6.3 x 3.9 inches). So I split the CPU into five boards:

  • Instruction Pointers
  • Scratchpad Registers
  • Instruction Decoder
  • Arithmetic/Logic Unit
  • Timing and Input/Output

By October 2012 I'd assembled a working Instruction Pointer (IP) board, and tested it using an FPGA to substitute for the remainder of the CPU.

Thursday, August 31, 2023

Scratchpad board layout progress

I've just about completed the layout of the Scratchpad board for my Intel 4004 CPU recreation. The only big changes in the layout since 2016, other than the signal routing, has been to reorient some of the decoding sub-circuits on the right side of the board.

Saturday, May 6, 2023

Back to the Scratchpad board

i4004 CPU Block Diagram
As I mentioned in the previous post, I've started working on the Scratchpad board again. This is the board that implements the 16 x 4-bit array of internal registers.

Internally, as depicted at the far right side of the i4004 CPU block diagram, this is actually an 8 x 8-bit DRAM array. It's quite similar to the 4 x 12-bit array used in the Instruction Pointer, which I successfully implemented some years ago.

Friday, April 28, 2023

Problems importing Eagle projects into KiCad

This time last year ago I tried importing my Eagle project for the i4004 Scratchpad board into KiCad. My reasoning was that I'm now much more familiar with KiCad's user interface than Eagle's, and the KiCad PCB router has features not available in Eagle v7. (Later versions of Eagle have improved the router, but I'm not paying Autodesk $70/month to rent it.)

It took a few experiments to get KiCad's importer to produce results I liked, but eventually I checked the results into my version control system (I use Git). Then I began fixing the few visual problems I noted (some of these have been fixed in KiCad v7). Then I got busy with other things again and, well, you know how these things go.

A few weeks ago someone posted to the KiCad forum that he was having problems importing an Eagle project. I did some more experiments importing some other Eagle projects and was able to help him through many of his issues, most of which were misunderstandings of the difference between KiCad and Eagle. However, one serious problem remained. KiCad has a tool that lets you cross-probe between symbols and nets in the schematic and footprints and tracks on the board. This is a critical feature, but it only worked with a small number of nets and tracks in an imported Eagle project. Further experiments exposed a serious flaw in the Eagle schematic importer.

Eagle supports schematics with multiple sheets. This is convenient when a schematic is too large to fit comfortably on one sheet. However, Eagle doesn't support hierarchical schematics. All Eagle nets are global to all sheets. This is very different than KiCad, where nets are local to a sheet unless explicitly made global by applying a global label to the net.

When KiCad imports an Eagle schematic, it only creates global labels for the nets that connect on multiple sheets; all other net names are dropped. However, the imported board retains all the net names assigned by Eagle. Since the cross-probing tool depends on matching net names, the result is that only inter-sheet connections and certain supply nets can be cross-probed.

If you're starting with an Eagle schematic and create the board in KiCad this is may not be a problem. However, if you've already created the board in Eagle, or explicitly named nets in your Eagle schematic, this may be a huge issue for you. Because I wanted to maintain the same net names used in the i4004 simulator, all of my nets have explicit net names. Losing these net names is a non-starter for me.

I reported this bug to the KiCad development team (Issue #14620) and proposed several possible solutions. However, I don't expect to see a fix for this any time soon.

Thus I've reluctantly abandoned my plan to use KiCad for further development of the i4004 CPU recreation. Instead, I've started working on the Scratchpad board using Eagle v7 again.

Thursday, December 17, 2020

KiCad import of an Eagle project

Now that I've gotten the FPGA-based emulation of the i4004 CPU running, I thought I'd go back to the discrete component implementation. It would be nice to get that running for the 50th anniversary of the chip, and that's only 11 months away.

That project, though, was started using Eagle as a PCB CAD tool. I haven't used Eagle in about four years, having spent all my hobbyist efforts on KiCad. I could finish them using my perpetually-licensed Eagle 7 installation, but do I really want to? I'd have to relearn the UI, after spending so long with the KiCad UI.

I've long wondered whether it would be worth the effort to move the remaining four PCBs from Eagle to KiCad. Each of these PCBs have complete schematics occupying several Eagle schematic pages. I'd completed basic layouts, and started routing to some extent. I knew KiCad v5 had an Eagle import capability, but how would it handle this situation?

Frankly, I didn't hold out much hope for this working well enough to be practical.

With KiCad v6 on the horizon it seemed smarter to try that rather than play with v5. After updating my KiCad sources with the latest code I rebuilt and installed v6. Then I created a new KiCad project and started experimenting with the Eagle import feature.

It took a few tries to figure out how this is supposed to work. However, quite to my surprise, the results look very good. The schematics imported cleanly, including the custom symbols I'd created for the FDV-301 and BSS-83 MOSFETs. The inter-sheet connections were all properly translated to global labels (Eagle 7 has no concept of hierarchical sheets). The layouts and initial routing I'd done also came across nicely.

This might actually work!

Monday, June 11, 2018

Eagle track length calculation errors

I decided to see if I could simulate the CLK1 and CLK2 signals on my current Instruction Pointer board using LTspice. Why these two? They're the only signals that have rapid rise times, as the others are all limited by the RC rise time curves of the pull-up resistors and the gate and drain capacitances they drive. To do this with any accuracy I needed to simulate the actual track lengths and capacitances at their ends.

Thursday, January 26, 2017

Major changes in Eagle licensing

When I started to do PCB layout back in 2000, I looked at a number of CAD packages. As a hobbyist I tend to favor open-source products. First I looked at the gEDA suite but it looked like a collection of un-related tools that could be forced to work together. Then I looked at KiCad, but at the time it was lacking many essential functions. Eventually I found CadSoft's Eagle.

Like several other commercial PCB CAD packages, Eagle offered a "freeware" version intended for hobbyists. All of these are crippled in some way to prevent them being used for commercial purposes, but while most limited the number of holes or devices, Eagle limited only the size of the board to 100mm x 80mm and the number of layers to two. The project I wanted to do at the time was a very small 2-layer board but had a lot of holes, so this was a good fit. When that project appeared to be destined for commercial production I spent $50 to obtain the smallest commercial license for V4. I continued to use the freeware V4 and V5 for hobby projects for several years.

When I started the 4004 replica I immediately realized that making 2-layer 100mm x 80mm boards wouldn't work. Again I looked around at other products, but discovered that Eagle V6 offered a non-commercial hobbyist license that would give me 6 layers, 100mm x 160mm dimensions, and multiple schematic sheets of a size large enough for the 4004 schematic. That seemed to work well, so I spent the $160 to get it.

A few years back Farnell bought CadSoft. The initial V7.0 release had a wacko licensing scheme that had all the Eagle users upset. Eventually the outcry forced Farnell to return to the previous licensing scheme. I was content with my perpetual V6 hobbyist license, but decided to buy the V7 upgrade to get the bugfixes. All was good until this summer, when AutoDesk bought Eagle from Farnell. AutoDesk promised expanded investment that would bring all sorts of enhancements, and even promised a better pricing structure.

Beware of people who promise to "make things great", because it means they think what exists is bad. AutoDesk's "better pricing structure" changes the perpetual license to a subscription license, meaning that you have to keep paying or the product stops working. It's "better" because if you only need the product for a month you only have to pay for a month. But then if you want to go back to a project after the end of that month, you have to pay for another month. Of course you can pay for longer-term subscriptions and get better pricing, but when the subscription runs out, poof!

As anyone who has followed this blog knows, I'll work on a project for a weekend and then it may be weeks or months before I work on it again. A subscription license is a non-starter for me and folks like me. Further, the hobbyist license I have seems to have disappeared. For me to use Eagle V8 on my 4- or 6-layer boards I'd need to buy the "Professional" package at $65/mo or $500/yr. I have seen discussions where AutoDesk has talked about expanding the "Standard" package to 4 layers, but that wouldn't help with my 6-layer ID and ALU boards, and it'd still be $15/mo or $100/yr. That's not going to happen.

Thus my involvement with Eagle has nearly reached its end. My license for Eagle V7 has no termination date, and AutoDesk can't change that retroactively. I will continue to use Eagle for the 4004 boards, as most of them have already been started and there's no reason to change horses in mid-stream. But I won't be upgrading to V8, which means no bugfixes and no support for new OS releases.

What will I use in the future? KiCad has come a long way in the last 17 years, and it continues to improve. The PCB I'll need to make to fit into the shell of the P170-DH calculator is larger than the 100mm x 160mm limits of my Eagle hobbyist license, so I'd long planned to use KiCad for that. The changes in Eagle licensing simply means that instead of that being a one-off use I won't be going back to Eagle for future projects. Instead I'll focus on learning to use KiCad as well as I have Eagle.

Thursday, March 17, 2016

I/O & Timing board progress

I've made good progress on the I/O and Timing board, so I thought I'd share a screen capture of the layout. There are currently 249 unrouted signal airwires, plus another 201 to GND and 92 to VDD.

Monday, March 14, 2016

Starting the I/O and Timing board

I figured the best way to be sure all the right components got on the I/O and Timing board was to create an Eagle project for it. So I did. And promptly realized that a lot of the Eagle configuration I'd gotten used to has to be done on a per-board basis, like trace width and via drill diameters. This is the first i4004 board I've started since late 2012, and you can forget a lot in three years.

There are three major functional groups on this board:
  1. A self-initializing 8-bit shift register that produces the one-hot CPU phase of execution signals (A12, A22, A32, M12, M22, X12, X22, X32) and the SYNC signal.
  2. The 5-bit Chip Select decoder and external output drivers (CMROM, CMRAM0 to CMRAM3). This is the chunk of logic that I moved off the ALU board.
  3. The 4-bit, tri-state, bi-directional data bus external pin I/O drivers.
I haven't made a screen shot of the layout yet. I'm at about the half-way point, with the first two groups placed and partially routed. The layout is moving so rapidly because there is a lot of repetition within each group. The shift register is essentially 8 copies of the same 1-bit pattern, with a minor variation on the first (A12) and last (X32) bits, plus some logic to generate the SYNC signal. Once I found a layout that worked well for two adjacent bits the rest follow the pattern. The five Chip Select output drivers are all the same and the decode logic has common elements. I haven't started laying out the data bus I/O drivers yet, but it will be four instances of the same layout pattern -- one for each bit -- plus a little decode logic.

I expect the parts I've already placed will shift position (and possibly rotate in the case of the Chip Select logic) to accommodate the data I/O drivers but I don't expect any problems making it all fit. This board has the fewest components of any board in the set and there's quite a bit of free space left.

Wednesday, March 9, 2016

Preliminary Scratchpad placement complete

I was having trouble getting to sleep last night, so I finished placing the remaining components on the Scratchpad board. Here's a screenshot:


With plenty of free space on the board I kept the components making up the various functions grouped and separated. The DRAM array is pretty obvious. The row drivers are to its immediate right, column pre-charge above and column sense and mux below. The control and data busses are below that (on the bottom of the board, shown in blue), and the write data latches below those.

Outlined on the right edge of the array are the row read and write enable drivers, and to their right is the 3-to-8 row address decoder. Continuing to the right is the 3-bit refresh counter, with each bit outlined. Bit 0 is on the bottom and bit 2 is on the top.

The other groupings are logic functions to generate various signals such as read and write enables for the odd and even nibbles, row read and write strobes, etc. When placing these groups I worked from the output drivers back toward the input signals. I started laying them out left-to-right, but after finishing them I decided they'd work better with each group rotated 90 degrees clockwise. Originally the order of the groups was the same as in the schematic, but I've since rearranged them into what seems better from a signal routing perspective.

Speaking of routing, I also routed the refresh counters and the row decoder logic. This seemed to be the easiest way to be sure the layout was workable. There's still a lot of routing to be done: there are 639 signal airwires, plus 424 ground and 84 VDD airwires. I also need to add power decoupling capacitors, and decide whether to add provisions for charge storage capacitors in the DRAM array as I did with the IP board.

Tuesday, March 8, 2016

Scratchpad refresh counter placement

Thinking how to best pin out the rest of the inter-board connections, last night I decided I should also look at the Scratchpad board. To my surprise I discovered I really hadn't gotten much done on this when I shelved this project back in 2013. Looking back at the blog entry I wrote about Scratchpad Array Placement in August 2012 I see I'd done the placement of the rectangular DRAM array components but not much more. Almost none of the signals are routed.

Friday, February 26, 2016

Progress on the ID board

I took a look at the Instruction Decoder board this evening and discovered there were a handful of parts that not only hadn't been routed at all yet, they weren't even in a near-final placement. I really thought I'd gotten farther on this than I had.

It wouldn't show up on a screen shot so I'm not going to bother, but I juggled most of them into a reasonable layout and routed within the groups. I also took a look at what's left unconnected and, like the ALU board, switched from a 4-layer to a 6-layer stackup using the same layer assignments as the ALU.

Ratsnest now reports 16 VDD, 32 GND, and 85 other airwires. That's after I'd already routed a bunch of unconnected GND pads. Again, I'm a bit surprised these numbers, especially the number of GND airwires.

There's still some possibility that as I get close to the final routing I'll decide to go back to a 4-layer board. Since all the components except the connectors are surface-mount, I've routed as much as practical on the top layer to minimize the number of vias (and thus minimize the board area they occupy). Looking at only the bottom and inner layer there really isn't that much there. If it's practical to route the remainder using only these two, and if the power distribution will also fit, I might dispense with the extra two layers. Or maybe not.

Wednesday, February 24, 2016

Progress on the ALU board

With six copper layers to play with, routing the ALU board has gone from challenging (if not nightmarish) to relatively easy. When routing vertical traces I no longer have to consider how I'm going to get VDD to the various pads, and routing nets to the connectors is mostly a matter of keeping routing lanes free of vias to avoid having to weave around them.

Sunday, February 21, 2016

What's a couple layers among friends?

Ever notice that some projects seem most interesting when there's something else you're avoiding doing? Yeah, me too.

November 2016 will mark the 45th anniversary of the release of the Intel 4004. This is enough of a significant anniversary to make me feel a bit of a kick in the ass to complete the remaining four boards of the CPU this year.

Sunday, April 21, 2013

ALU and ID board progress

I don't know what I did to annoy my sinuses, but I haven't been able to breathe through my nose all day. This has really put a damper on my plans for the day, as I really haven't wanted to be far from a box of tissues. Since I'm otherwise clear-headed, I parked myself in front of my computer and worked on the layouts.

The ALU board now has only 161 airwires remaining, of which 21 go to GND and 11 to VDD. That's down significantly from 560/141/79 on Friday. I don't think I want to do much more with it until I pin-out the remaining inter-board connections. In order to do this I need to work on the Instruction Decoder board.

The ID board didn't have a power plane defined, so very few of the VDD connections had been made. I rectified that, then spent some time adding short stubs and vias. It now has 182 airwires remaining, of which 64 go to GND and 28 to VDD. That's down from 622/322/109 two weeks ago.

While the ALU board has a few channels with clusters of vertical signal traces on the VDD plane, the ID board has lots of vertical signal traces spaced across the board. There are also pull-up resistors in many of the gaps, so current will be drawn through these narrower areas. This will require some attention to make sure I don't end up with islands.


There hasn't been much visible change unless you look really closely, so I won't bother posting pictures today.

Saturday, April 20, 2013

ALU board power plane

With 560 airwires still unrouted, I'm clearly not done with the ALU board. But there's enough to see how the long vertical signal traces break up the power plane, yet leave wide top-to-bottom paths to supply VDD.


At least you'll be able to see it if you make the image large enough! The original is 2560 x 1569 pixels (shrunk to 1600 x 980 by BlogSpot) so there should be plenty of detail.

If this was a truly high-speed logic board with fast rise times, the current would have to detour around the the long vertical breaks in the plane rather than being able to follow the same path as the horizontal signal traces (not shown here). To work around this I'd need very low impedance bypass capacitors between VDD and GND to allow the current to jump to the unbroken ground plane. Or so sayeth the book -- I don't have the personal experience to be able to vouch for it.

I'm actually making pretty good progress on this board, though at this rate it'll be at least another month before I have the ALU and ID boards ready to send off to PCB-Pool for fabrication.