Superneat project. Now someone needs to synthesize a CPU and build a big enough discrete fpga to run it (very slowly) on.
A few comments for those playing at home: 1) Use less solder. When you get boards done at the pcb house, they usually put a solder mask. There is enough solder on the pads that you can solder SMD parts without adding more.
Just flux it with a fluxpen, lay the part on top, and remelt it. Much neater and much faster. You just have to check that there is actually enough solder on the pad to make a solid joint (a light and a magnifier help to verify).
2) Always clean the flux off, even if it's no-clean.
3) Autorouters produce less than ideal results. If you start with an autorouter pass, you can then go back and tear up lines and reposition parts to use fewer vias and straighter lines.
When I first started doing pcbs I wanted to use autorouters, but the results were always ugly. I met a guy who had done a 6-layer ARM board in some old DOS program manually which convinced me it probably wasn't that big of a deal to route by hand. It's calming if nothing else.
The CPU is already done. The OpenRISC has been around for a while and is silicon proven [1].
Not quite an FPGA, but around 2001 Reinoud designed a "Meta FPGA" (the MPGA). This was essentially an FPGA implemented on an FPGA. Whilst not really practical, it was a demonstration of how one might get away from a proprietary tool chain, the idea being that the MPGA would be placed and routed once, then open source tools could place and route the user's design on the MPGA.
An FPGA would be an excellent candidate for a first "open source" chip. A keen university student could fabricate it via MOSIS [2], a service that provides cheap/free fabrication to Universities. The main stumbling block, from an open source point of view, is that many of the process specific libraries are locked up under layers of IP. One day desktop manufacturing might be feasible, especially if carbon (nanotube) based chips can be made to work and can be fabricated at low temperatures using self-assembly techniques.
I probably overdid the solder a bit, but there's no way most of the pads had enough solder on them for SOICs without my adding any. I've soldered SOICs before, but this is by far the largest volume I've done in a sitting.
As I mentioned briefly in the post, the autorouter was something I used largely as a result of time constraints - with 200-odd wires to route and very little time to do them in if I wanted the PCBs back in time, I decided to give it a go. That said, I was surprised with the quality of the results - I'd be surprised if I can find any easy-to-remove vias left in its solution. The tool is also very good for assisted hand routing, since it lets you nudge traces around without ripping them up every time.
I got them done at Hackvana (hackvana.com, or #hackvana on irc.freenode.net); similar prices to Seeed, and excellent customer service.
I'm not sure about the maximum speed. The flipflop, for instance, has a delay of 14ns; if we take that as average, each slice has to go through 5 parts (input mux, LUT, flipflop, async select mux, output enable) for a total delay of 70ns, so in theory one slice could do about 14MHz. Since it's a ripple counter, I guess we should divide that by the number of slices, so 4MHz seems like a reasonable upper bound.
It's a really outstanding project. Thanks for sharing it with everyone.
Regarding configuration memory, could you have the arduino read out from a serial flash? They're pretty easy to bit bang or control over SPI, and you can get a 64Mb pretty easily.
I'm guessing you're talking about the SRAM-based alternative I discussed at the end? Yes, that would be an option, as would an SD card. 64Mb would be enough for plenty of 256 kilobit slices.
I do prefer the idea of using EEPROM if I was going down that route, though, so it'd be more like a CPLD than an FPGA. I just need a good way to load the only bit of remaining discrete state - the output enables - on startup. My best idea thus far is to dedicate half the EEPROM to configuration data, store the latch states at address 0, and use two RC networks to create rising edges first on a register latch pin then on the highest address pin to latch in the config before enabling the EEPROM in 'operating mode'.
I really wouldn't trust those connections without adding solder yourself. What fab house are you using? I've generally stuck with 4pcb (advanced circuits) and there might be enough solder for a 0402 to "sort of" stick, but there is no way I'm going to trust that connection. It could just as easily be sitting in flux from a nearby wire and not actually have any connection at all.
My understanding is that the solder mask is there to only expose copper for the solder to flow, but mask off everything else with a main intention of preventing crowbarring, or shorting out traces -- not to put actual solder on the boards at the fab house.
I use APC. Perhaps their finish is thicker than others, or maybe I'm just high.
I usually get enough solder to wick up to a 0805 resistor to produce a reasonable fillet. I then give it a good tug with a pair of tweezers to make sure everything is good.
My iron usually has solder on it from tinning (not a lot though, I wipe it on one of those metal ribbon pad).
With IC's I can usually watch the solder reflow and the leg sink a bit.
All that said, I don't hesitate to put more if it's not getting a good joint. YMMV.
You're right about the solder mask, I had my terminology wrong: the solder mask is the plastic stuff that they coat boards in. I was thinking of the solder finish on the pads.
I agree that it is neat, but a CPU? Each board is one slice. I believe even the tiniest FPGA available today has thousands of slices, and I'm pretty sure even a 4-bit CPU would take quite a bit more than a couple slices.
Comments
Superneat project. Now someone needs to synthesize a CPU and build a big enough discrete fpga to run it (very slowly) on.
A few comments for those playing at home: 1) Use less solder. When you get boards done at the pcb house, they usually put a solder mask. There is enough solder on the pads that you can solder SMD parts without adding more.
Just flux it with a fluxpen, lay the part on top, and remelt it. Much neater and much faster. You just have to check that there is actually enough solder on the pad to make a solid joint (a light and a magnifier help to verify).
2) Always clean the flux off, even if it's no-clean.
3) Autorouters produce less than ideal results. If you start with an autorouter pass, you can then go back and tear up lines and reposition parts to use fewer vias and straighter lines.
When I first started doing pcbs I wanted to use autorouters, but the results were always ugly. I met a guy who had done a 6-layer ARM board in some old DOS program manually which convinced me it probably wasn't that big of a deal to route by hand. It's calming if nothing else.
The CPU is already done. The OpenRISC has been around for a while and is silicon proven [1].
Not quite an FPGA, but around 2001 Reinoud designed a "Meta FPGA" (the MPGA). This was essentially an FPGA implemented on an FPGA. Whilst not really practical, it was a demonstration of how one might get away from a proprietary tool chain, the idea being that the MPGA would be placed and routed once, then open source tools could place and route the user's design on the MPGA.
An FPGA would be an excellent candidate for a first "open source" chip. A keen university student could fabricate it via MOSIS [2], a service that provides cheap/free fabrication to Universities. The main stumbling block, from an open source point of view, is that many of the process specific libraries are locked up under layers of IP. One day desktop manufacturing might be feasible, especially if carbon (nanotube) based chips can be made to work and can be fabricated at low temperatures using self-assembly techniques.
[1] http://opencores.org/or1k/Main_Page
[2] http://www.mosis.com/
-----
Edit: It turns out that OpenCores is currently attempting to crowdfund a SoC Computer/CPU, based on the OpenRisc.
http://opencores.org/donation
I probably overdid the solder a bit, but there's no way most of the pads had enough solder on them for SOICs without my adding any. I've soldered SOICs before, but this is by far the largest volume I've done in a sitting.
As I mentioned briefly in the post, the autorouter was something I used largely as a result of time constraints - with 200-odd wires to route and very little time to do them in if I wanted the PCBs back in time, I decided to give it a go. That said, I was surprised with the quality of the results - I'd be surprised if I can find any easy-to-remove vias left in its solution. The tool is also very good for assisted hand routing, since it lets you nudge traces around without ripping them up every time.
I understand; I'm just back-seating anyway.
Where did you get the boards done?
Also, do you have any idea how fast the counter you made can go?
I got them done at Hackvana (hackvana.com, or #hackvana on irc.freenode.net); similar prices to Seeed, and excellent customer service.
I'm not sure about the maximum speed. The flipflop, for instance, has a delay of 14ns; if we take that as average, each slice has to go through 5 parts (input mux, LUT, flipflop, async select mux, output enable) for a total delay of 70ns, so in theory one slice could do about 14MHz. Since it's a ripple counter, I guess we should divide that by the number of slices, so 4MHz seems like a reasonable upper bound.
It's a really outstanding project. Thanks for sharing it with everyone.
Regarding configuration memory, could you have the arduino read out from a serial flash? They're pretty easy to bit bang or control over SPI, and you can get a 64Mb pretty easily.
I'm guessing you're talking about the SRAM-based alternative I discussed at the end? Yes, that would be an option, as would an SD card. 64Mb would be enough for plenty of 256 kilobit slices.
I do prefer the idea of using EEPROM if I was going down that route, though, so it'd be more like a CPLD than an FPGA. I just need a good way to load the only bit of remaining discrete state - the output enables - on startup. My best idea thus far is to dedicate half the EEPROM to configuration data, store the latch states at address 0, and use two RC networks to create rising edges first on a register latch pin then on the highest address pin to latch in the config before enabling the EEPROM in 'operating mode'.
I really wouldn't trust those connections without adding solder yourself. What fab house are you using? I've generally stuck with 4pcb (advanced circuits) and there might be enough solder for a 0402 to "sort of" stick, but there is no way I'm going to trust that connection. It could just as easily be sitting in flux from a nearby wire and not actually have any connection at all.
My understanding is that the solder mask is there to only expose copper for the solder to flow, but mask off everything else with a main intention of preventing crowbarring, or shorting out traces -- not to put actual solder on the boards at the fab house.
I use APC. Perhaps their finish is thicker than others, or maybe I'm just high.
I usually get enough solder to wick up to a 0805 resistor to produce a reasonable fillet. I then give it a good tug with a pair of tweezers to make sure everything is good. My iron usually has solder on it from tinning (not a lot though, I wipe it on one of those metal ribbon pad). With IC's I can usually watch the solder reflow and the leg sink a bit.
All that said, I don't hesitate to put more if it's not getting a good joint. YMMV.
You're right about the solder mask, I had my terminology wrong: the solder mask is the plastic stuff that they coat boards in. I was thinking of the solder finish on the pads.
I agree that it is neat, but a CPU? Each board is one slice. I believe even the tiniest FPGA available today has thousands of slices, and I'm pretty sure even a 4-bit CPU would take quite a bit more than a couple slices.
Yeah, it was more of a joke. (There's always bit-serial designs or 1-bit architectures...).