Project IceStorm Passes Another Milestone: Building a CPU

beckman101 writes: FPGAs — specialized, high speed chips with large arrays of configurable logic — are usually highly proprietary. Anyone who has used one is familiar with the buggy and node-locked accompanying tools that FPGA manufacturers provide. Project IceStorm aims to change that by reverse-engineering some Lattice FPGAs to produce an open-source toolchain, and today it passed a milestone. The J1 open-source CPU is building under IceStorm, and running on real hardware. The result is a fairly puny microcontroller, but possibly the world's most open one.

Comments

An open cpu?

[Anonymous Coward]

I'm pretty sure CPUs are supposed to be closed so as to keep dust out.

Re:An open cpu?

[davester666]

No, the fan you put on the CPU blows the dust away.

What's special here??

[Anonymous Coward]

There are plenty of fully open source CPUs around.

There is a community building CPUs from discrete logic (http://mycpu.selfhost.it/), from transistors (http://www.extremetech.com/computing/128035-how-to-build-an-8-bit-computer-from-scratch) and even from relays (http://www.nablaman.com/relay/).

There are also Forth CPUs which are freely embeddable into a FPGA (the J1: http://www.excamera.com/sphinx/fpga-j1.html) and which can be purchased now (http://excamera.com/sphinx/gameduino/).

Re:What's special here??

[egladil]

What is special is that they are making an open toolchain to program an FPGA and that toolchain is now capable enough to program a working CPU into the FPGA.

If you had read the entire summary you would have seen that the CPU design they were using was the J1 that you mention.

Re:What's special here??

[gl4ss]

yeah so why it's marketed in the blurb as an open source cpu when the interesting thing is an open source toolchain for a closed silicon fpga?

Re:What's special here??

[alvieboy]

A few notes regarding your comment.

This is not actually about an "open toolchain to program an FPGA". It's not actually about programming at all. Let me try to explain here (in a simple way) what IceStorm is, or better, what an open-source can do for the FPGA design flow.

So, you start with a description of your design. Your design usually describes the behavour of your system, which is often done in HDL (Hardware Description Languages), like VHDL and Verilog, or even higher-level ones (SystemC, even Python). But, as with every digital design (imagine classical design with TTL 74/CMOS 40 series), you often need more than "logic" - you may need a PLL, you may need a dedicated multiplier (hey, you don't want to design this by hand with gates and flip flops, do you?), or other complex, often mixed-signal primitives.
FPGAs are basically a set of basic blocks (think again 74/40 series), which can be interconnected almost at will. The blocks actually differ from classic chips: what you'll find in FPGAs [I'll speak about Xilinx but Lattice should be similar] are LUT (Look-Up Tables), which can provide any N-input/Y-output digital function (often 4 to 6 inputs, and one output), and Flip Flops (with enable, set, reset, so on). In addition, FPGA provide "hard IP cores", like PLLs, Multipliers, Serializers, Multiplexers, so on, so on.
Now, to have your design to work on the FPGA, you need to synthesize it - convert the behavioural model into these building blocks (LUTs, so on). This is the first phase - and it depends on the target FPGA because the available IP hard blocks differ from manufacturer to manufacturer, from family to family, and even from small to larger, same family devices. This synthesis process will get you a "netlist" - a list of all used primitives and the interconnections needed between them.
Next step is to place the design - pick up each of those primitives, and choose an instance on the FPGA where it will be assigned. This can be tricky, because routing inside FPGA is not 1-to-all, and timing is more affected by routing than anything else - so you'll want your critical (timing critical) paths to be placed where you can later route signals faster. This is really FPGA dependant, much more than synthesis.
Then you have routing: after placing all primitives, you need to decide how to route all signals (this is very complex, FPGA dependant). After routing is done, you have the whole design for that FPGA done - everyting is placed, routed.
Well, you have not.
The next step is to generate a bitstream, based on the netlist output from Route, that can be sent to the FPGA (usually via JTAG). This is actually where less information is known - where each bit from the bitstream maps inside the FPGA switch fabric or LUT configuration or SRAM cells, others, ...
Then comes programming: sending the bitstream to FPGA. This is usually simple, and many open tools exist (at least for Xilinx).

Now, do these tools do?

Yosys: Verilog synthesis
Arachne-pr: Place & Route
IceStorm: Last part, which is the hardest - to map the final, routed netlist into the "proprietary" bitstream.

Hope I shed some light on the matter.
And yes, being J1 or any another CPU (like my own ZPUino or XThunderCore) is irrelevant - what's relevant is to prove that IceStorm seems to generate correct bitstreams for this platform.

Alvie

Re:Most people won't care

[xophos]

Forget the future, they are here and they are advertised as features:
https://en.wikipedia.org/wiki/...

Re:Most people won't care

[Balthisar]

It's kind of the same issue with open source software, as far as the "most people don't care" aspect, but at an even greater disadvantage that open source software. I don't have a chip fab (at least I could compile open source software), and so even if I were capable of understanding the chip design, there's not much of a guarantee that the physical chip I purchase doesn't have some proprietary back door built into it.

Like most people, I'm even lazy about the open source software I use. While I try to download from trusted sources, there's no guarantee that what I actually install matches the current stable version in the repo. I'm taking a leap of faith.

In both cases (including the former where I indicated my ignorare about chip design), presumably I am counting on other experts to understand the chip or understand the source code for me, but only in the latter case could I actually assemble the product myself in order to guarantee matching the reviewed, stable code.

Re:Most people won't care

[Anonymous Coward]

Most people don't care because they aren't even interested in computers.

If you talk about Slashdot readers then they have all read enough articles to know that open source itself doesn't provide a perfect protection against backdoors.
You also have to read the source to see that no backdoors are put in place, and you need to build the executable to make sure that the version you are running isn't built from a version of the source with backdoors in it.
Now, assume that a processor like this becomes as mainstream as Intel and AMD CPUs, do you really think it is impossible to manufacture an FPGA with backdoors?
For people to use the CPU it has to reach a stable point at some time. A stable CPU and a stable toolchain to build it will have a known layout and can be targeted with backdoors in the FPGA in the same way the CPU would have backdoors.

So knowing that it isn't sufficient to just have an open design but that you also need to verify the hardware, why just not just skip the open part and verify the hardware directly?
As a Slashdot reader you should at least have seen the reverse engineered 6502 visualizer. It is a much simpler CPU, but it has been reverse-engineered and its function is emulated in javascript with the transistors of the chip lit up. No room for backdoors there.
A similar analysis has been done for the M68000, I couldn't find the slides from the presentation on it I saw, but here is a pdf with a rough overview that doesn't go into as much detail.

Since you need to do that kind of analysis of the FPGA anyway it seems to me that the open source CPU part is more about "Not Invented Here" than about protecting against backdoors.
That means that most people who you would think would care. They like the idea of it, but not this implementation since it isn't the one they did themselves.

Forth?

[Anonymous Coward]

? Program Forth in who want

Re:Forth?

[jimtheowl]

It is presumably an attempt at a joke based on the fact that Forth makes use of RPN.
https://en.wikipedia.org/wiki/...

I for one find Forth to be a fascinating language. The fact that it has been around for a while does not diminish it in any way.

I first heard of it back in the 80's while learning assembler on the 6502. I noticed it again while getting to know FreeBSD (loader stage 3) and decided to finally learn it when I came across some old manuals and software for my newly acquired PET CBM 8032 just a few weeks ago.

Ever since, I seem to notice it mentioned more and more, perhaps partly because of renewed interest in stack machines, but also because it offers an interactive way to boot strap a very small system with minimal resources.

It is available in some form on almost every platform that I know.

Following are some resources that I have found to be of interest. Hopefully those sites will not get badly hurt.

http://www.forth.com/starting-...
http://thinking-forth.sourcefo...
http://playground.arduino.cc/C....
https://www.freebsd.org/cgi/ma...
https://uwaterloo.ca/independe...
http://www.ultratechnology.com...

...

Re:Most people won't care

[Joce640k]

They don't understand that Intel/AMD CPUs could or will have backdoors. If not now, then very soon in the future.

I usually decap my CPUs and inspect them before installing them. I haven't seen anything suspicious so far.

The real problem is Windows. Having to disassemble/inspect the OS before installing wasn't too bad, it's the constant stream of patches that gets me down.

Re:Most people won't care

[Bert64]

At some point you have to trust someone, be it the distributor from whom you're getting the os, the manufacturer or reseller supplying the hardware or even the supplier of the compiler...

The only thing you can practically do, is ensure everything you use is available from multiple opposing sources... Something that's in use by both the us and russian governments is unlikely to be backdoored as both organisations have sufficient resources to perform the due diligence checks.

Re:Most people won't care

[KGIII]

I am not much better. I do, sometimes, review the source for interesting parts. At best, absolute best, I will find a bug and then go through the code and see if I can actually determine a fix. If I find a fix I send the code to the authors for inclusion and, obviously, with no strings attached. I have been able to do that on only a trivial number of occasions, I can think of three though it may have been more for I am old and my memory is faulty.

Re:Most people won't care

[KGIII]

You can actually see some of the Windows source code if you want. You must sign an NDA and you have to justify your access (at least you did while I was still in the MVP program - and that was as an MVP, some of the most trusted folks) but the program to do so is called the Shared Source Initiative or at least was. Meh, a quick Google indicates it still is.

So you can see the source, in part, if you want to. We had to tell them what we wanted to do with it (usually it involves tying an application in cleaner or a security review) but I never saw or heard of anyone getting denied when the program started and for the first few years that I was involved in it. Hell, they let *me* access it and I was known as the Linux geek amongst the group. (It took correction, on my part, to point out that I was a Unix geek. I have only recently switched to almost all Linux and little Unix.)

Anyhow, for those curious, I was an MVP in Shell, Security, and IE/OE. It was kind of fun. The rewards were nice and the community was cool. They accepted that I was not a zealot for Unix (nor a Microsoft zealot). I just use what suits my needs best for the task at hand. I stuck around for quite a while, helping many thousands of people in their newsgroups and on a site/forum that I ran at the time. Eventually I had some issues where I fell in love with a girl and we meandered across the planet without much direction. I had little time and stopped participating and was not re-awarded. She is gone and I just pay for my MSDN subscription. Life is easier.

Re:Most people won't care

[tigersha]

An Intel i7 Quadcore has 1.7 Billions transistors on board. A Haswell E 18 Core monster chip 5.5 billion. Even a simple ARM Cortex has 26 million transistors.

Do you think any single person at Intel knows everything about such a chip? Even the experts of the experts? How do do you think you are going to even comprehend such a thing even if it is open source? It really makes no difference, and no open source community is going to design a modern high-performance CPU. Intel invested 10.6 billion in R&D in 2013.

At some point you are going to have to start trusting someone. Why everything has to be open is beyond me.

Re:Most people won't care

[K. S. Kyosuke]

Do you think any single person at Intel knows everything about such a chip? Even the experts of the experts? How do do you think you are going to even comprehend such a thing even if it is open source? It really makes no difference, and no open source community is going to design a modern high-performance CPU. Intel invested 10.6 billion in R&D in 2013.

Intel is bound by the requirement to run legacy software. Even an ARM system effectively has to be able to run it. A designer of a new open system would have no such constraints. Thus, no need to invest $10.6B and 5.5 billion transistors to reach a reasonable result for a wide range of applications. Attempting to review or redesign an Intel system would of course be a folly, but also completely pointless to begin with.

Re:Most people won't care

[meta-monkey]

Eh. When laying out silicon, you generally use libraries of simple parts you chain together. You make a register once, and then you replicate it each place you need a register. A TON of those transistors are cache, which is the same pattern repeating over and over again.

I'm not saying there's anyone who's looked at every transistor, but there's probably somebody who's looked at the layout of a cache cell, a register, an ALU, standard multiplexers, etc.

more OSS FPGA tools

[Kishin]

This is cool stuff. Here's some other stuff I found recently for anyone interested in messing with bitstreams, creating an open-source FPGA, or doing hardware more easily. Hardware designers feedback is appreciated.

Open Source Bitstream Generation without R.E. or license violations: http://www.isi.edu/~nsteiner/p...

Archipelago - an open-source FPGA with toolflow support: http://www.eecs.berkeley.edu/P...

Cx, open-source, hardware & synthesis language: http://cx-lang.org/

QFlow Open-source Flow from behavioral synthesis to detail routing: http://opencircuitdesign.com/q...

Have fun people! Especially building on the first two. I'd appreciate experienced people telling me how good the Cx system is for (a) people doing FPGA with high-level synthesis tools and/or (b) beginners using behavioral verilog wanting something better.