Slashdot Mirror
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.
Forget the future, they are here and they are advertised as features:
https://en.wikipedia.org/wiki/...
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.
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.
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?
world was created 5 seconds before this post as it is.
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