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

[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

[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.