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.
I am concerned how fast IT evolves to DRM-locked devices. The PC will become obsolete by tablets so we will lose control over our computers. Currently DRM looks harmless but when you consider the long-term consequences it doesn't look good at all.
First we fought TCPA and Trusted Computing, now we have the first global players (Apple, Microsoft) put DRM into their gadgets to get maximum control and minimum competition. And the customers buy, consume, and play, without considering the consequences.
Our technology today is the foundation for the political systems of tomorrow, and when you consider the global demographic development you know what I mean. Within the next twenty years we will have a completely different global political and economical system, and I don't want to have them total control over us with their super-safe cascaded DRM chips which nobody will be able to break.
Unfortunately we can't stop Apple, Microsoft & Co. from using DRM. That's why I appreciate pioneer projects like this selfmade FPGA very much as they help to jump over the big hurdle from open source to true open hardware. Someday when all commercial chips will be DRM-locked I hope we will be able to 3D-print our own processors and RAM chips.
I am convinced that Open Hardware will become vital for the survival of our freedom of speech and liberty in general.
Check out Jeri Ellsworth's homebrow NMOS transistor for some real fun. Just get your bare silicon wafer from E-bay and have at it. http://www.youtube.com/watch?v=w_znRopGtbE
I know that there are several open hardware projects (Opencores for instance). But I consider _true_ open hardware as hardware were we always will have _full_ control over _every_ tiny detail of the system.
The TTL level is the right foundation for that. If we could go down to the NMOS level or so for 3D printing, that would be even better. We'll see what the future shows.
You've been able to build your own hardware from 74xx series chips for decades now, infact about half a century! Infact, that was the only option you had back in the day. This is retro rather than new, like making a ham radio out of thermionic valves, say. Nothing new, but kinda cool and certainly educational if you're new to the field.
I think that's why the GP took objection to your rather statesmanly proclamation that this was heralding some kind of revolution in open hardware. It isn't, it's just a rather neat project.
However, in your followup comment I definitely agree with you in that as soon as I can fab my own silicon in my garage, the world will be my mollusc. But we're pretty close nowadays with a $20 FPGA from digikey.
diy silicon is definitely a cool concept but this project, while cool in itself, is not a step towards that goal. and that was (one of) my issue with GP post.
I understand what you mean, and you are basically correct. But nevertheless I see this project as a milestone as it helps to focus on selfmade FPGAs instead of soldering TTL chips to copy some hard wired retro systems.
If we someday will be able to print our own chips then they will surely be FPGAs because debugging and reprinting hardwired chips would be likely too expensive.
I agree with your entire comment except for the first sentence. When working for a ideological goal, it is important to continually and earnestly evaluate what goals the imagined solution will actually fulfill, lest one end up misplacing faith in an implementation that can never achieve the desired ends.
First, this FPGA is still not implemented by things that are the lowest level - how do you know that 7404 doesn't actually contain secret logic looking for specific patterns on the 6 "independent" inputs (based on your widely-propagated design) that alter it's behavior?
Second, if one wanted to build an auditable CPU, they would not start by building auditable reconfigurable logic in order to develop a soft core CPU on top of it. This is a needless extra layer of interpretation, and the number one constraint you're trying to overcome is the constant factors that are left out of the Big-Oh notation.
We don't buy Intel processors because we're lazy and have money to burn, but because they contain a billion transistors switching a billion times a second. If you build something with 10k transistors switching at 10M Hz, something that would take 1 second on the modern CPU will take roughly 3 months.
So I think there's two properties to be achieved for actual Free Computing. The first is roughly getting something that can compute. These days, this can be done by buying a standard PC and installing your own software on it. This may not continue to be possible (so we would have to eg rely on integrating our own ARM chips, then FPGAs, then microcontrollers, etc), but trying to put a solution forward before it is necessary isn't going to get very far. There also is available computation that is unlikely to go away - Javascript in web browsers, available to all but sandboxed programming toy apps, etc.
Which brings us to the second quality of Free Computing, which is auditability - guaranteeing that the code running is doing what it says, rather than a subtle corruption which renders the whole sensitive algorithm broken. To get performance, we would like it if such a CPU could be made in a necessarily non-trusted fab, rather than independently assembled from discrete transistors. This seems like a harder, but yet better defined problem - meaning it might actually be possible to solve through some combination of clever proofs and bootstrapping trust up from an extremely simple auditable CPU.
> I agree with your entire comment except for the first sentence.
I meant the term "first step" historically. It is really the first step to true open hardware because it is the first project (as far as I know) that solely relies on basic electronics you can solder together on your own pcb.
There are many open hardware projects but all of them are based on complex hardware (FPGA kits etc.). There are several good open cores you can download into your fpga but what if someday your fpga stops working and you can't buy another one because these fpgas are not produced anymore?
I agree with you that selfmade processors will never be able to compete with modern processors. But even a 1 MHz 8 bit cpu can do a lot of things. Remember the huge success of Commodore 64. And if you are able to 3d-print one such a cpu you can also print many, and build a multicore system.
Who says that selfmade processors have to work with silicon and copper? If someone finds a way to produce cheap conductive plastic filaments that would be a huge leap forward for printed circuits. I believe that there are several smart hardware hackers who could achieve a solution we could live well with. 3D printing is just in the beginning. I expect amazing times to come.
1. Plenty of CPUs have been built from discrete logic.
2. As soon as you start talking about complex printed items (including PCBs), you're necessitating either a trusted computational device to compile the design and drive the printer, or the ability to audit the output of the printer (eg read and understand the traces on a 2-layer PCB).
First, this FPGA is still not implemented by things that are the lowest level - how do you know that 7404 doesn't actually contain secret logic looking for specific patterns on the 6 "independent" inputs (based on your widely-propagated design) that alter it's behavior?
Don't let your paranoia get the better of you.
With only 6 inputs, if there is any anomalous behavior, it will quickly be noticed. And this subverted 7404 would need to have all its gates used on the same bus to have a hope of seeing that you're illegally copying a movie, and that is a rare application.
And I think someone would notice that these inverters are using 6 orders of magnitude more power than necessary.
Even for more complicated parts like CPUs, such tampering would be readily evident.
For a long time to come, it will be a lot easier to hide nefarious code in software in some corner of a general purpose system (PC, tablet, etc.) than to put it into the hardware layer. Even nefarious code needs network communication these days, otherwise there's not much point.
I hadn't considered the added power draw due to the likely complexity involved in making a good backdoored hex inverter, good point there. It seems like there's a natural contour such that as the individual component gets smaller and less complex, the amount of circuitry required for a backdoor increases.
Software certainly is easier to backdoor, but hardware is much more insidious. At this point I'd be surprised if there weren't backdoors in the widely used processors for at least the NSA. (Remember that innocent time when the question whether the 'net was tapped and recorded was up for discussion? :P)
So I guess I view both of my aforementioned properties as mandatory due to the use case for my analysis (trustable function execution), while the OP was really just talking about the first one. I'd originally considered this question in the context of cryptographic key generation and management, where the second property is of utmost importance to be confident that there aren't low level backdoors giving bias to your crypto keys and nonces. Plus if you're spending the time to bootstrap trustable computation up from a hand-built circuit, you might as well go all the way instead of trusting something like an MCU.
... where the second property is of utmost importance to be confident that there aren't low level backdoors giving bias to your crypto keys and nonces.
If there are backdoors in modern processors, it is likely located in the on-chip firmware for the boot sequence and/or in the secure key store. Those are the two main areas I'd worry about, and I'd also keep a close eye on any binary blobs needed for the secondary processors cores on a modern SoC. And also the firmware for the WLAN chip.
This is what I like about FPGAs and soft-cpus. Some "open-hardware" designs use ARM cpus, that are as closed and patented as they can be (I.E. Arduino, Raspberry PI, etc.)
You may argue that commercial FPGAs are also closed and while it's true, the principle of operation is so simple (lots of interconnected gates) that can be easily replicated, like this cool project shows.
> You may argue that commercial FPGAs are also closed and while it's true, the principle of operation is so simple (lots of interconnected gates) that can be easily replicated, like this cool project shows.
Basic CPUs are not all that complex either, there are plenty of homebrew CPU projects made of discrete components. Both those and this project share the common trait that they are almost impossible to scale up to be useful.
I would also be very surprised if FPGAs aren't also heavily patented.
Nothing to discourage the efforts here but close to 10 companies were closed which tried to enter in FPGA market in last 10 years alone. Here is the list : TierLogic , CSwitch, Ambric, MathStar, Agate Logic, Nusym, AboundLogic (M2000)
Only one successful acquisiton.
Lattice acquired --> Silicon Blue
In the past, ST Micro tried 2 times to enter in FPGA Market, once even with the "open Source " concept - GOSPL. Intel for once for sure. Other several companies failed too.
Xilinx and Altera hold close to 90% market share in FPGA market. 90% of other efforts to enter this market have failed earlier. Mostly because, companies underestimated Software importance.
Enough parts for 20 boards cost me about 100 pounds; the board fabrication cost about $60, but a lot of that was because I wanted it in a rush. All up, that works out to about 8 pounds, or 13 USD per board. It'd be somewhat cheaper - around $10-$11 - if you're not in a rush for the boards, and of course cheaper again in larger quantities.
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.