Slashdot Mirror
Parallax Completes Open Hardware Vision With Open Source CPU
First time accepted submitter PotatoHead (12771) writes "This is a big win for Open Hardware Proponents! The Parallax Propeller Microcontroller VERILOG code was released today, and it's complete! Everything you need to run Open Code on an Open CPU design. This matters because you can now build a device that is open hardware, open code all the way down to the CPU level! Either use a product CPU, and have access to its source code to understand what and how it does things, or load that CPU onto a suitable FPGA and modify it or combine it with your design."
I run a company that releases all its hardware designs and am a huge proponent of OSHW. This gesture has limited utility simply because the people who use MCUs in designs aren't typically interested in delving into the minutiae of how the processor that runs the system is built. They're more interested in open source circuits which have real-world applications -- a low pass filter for smoothing PWM signals, a nice clean USB power supply, and so on.
Sort of like OpenRISC? Except, later and worse?
Aside from absolutists positions like Stallman's, why is it important to have OS hardware? Why AMD64, Intel x86, or ARM is not good enough?
I wonder how this CPU performs? Does it compare to anything I'd care about ...?
The Parallax Propeller CPU is mainly used for hard realtime applications. It has eight 32-bit cores (called "cogs"), each with 2k of dedicated memory, and 32k or shared memory. Each cog runs at 20 MIPS. That is not nearly enough speed or memory for any sort of general computing, but is enough for control loops in embedded systems. The most interesting thing about the PP, is that the general design philosophy is to use a separate core for each task, thus completely eliminating the need for interrupts. So real time latency is drastically reduced.
So how important is any of this? Well, the PP is not very popular, to say the least, and I have never seen one used outside of a hobby project. That is probably why they figure they have nothing to lose by opening it up.
Here's an open FPGA design:
Put a buttload of OR gates in parallel.
Follow them with a buttload of AND gates
There just isn't that much design in a basic FPGA to open up, not that I can see.
Said the blind man.. What you describe is the end user description of a PAL. FPGA's are completely different and PALs are not actually designed that way either. It is just the end user description, much like knowing the x86 instruction set doesn't mean you know how to design a modern x86 processor.
An Altera or Xillinx FPGA is predominately a sea of small SRAM's but there are also many many muxes, complicated interconnects, configurable special function blocks (like multiply/accumulators, IO cells, and Ethernet interfaces). There is also a great deal of logic just to efficiently move configuration bitstreams into the chip. The complexity per unit area is less than a typical ASIC, which makes FPGA's good subjects for bringing up on new process flows but it is definitely not trivial work. Much is low level and structural rather than logical but that doesn't make it easy.
That said, an open FPGA design would be pretty useless. The hardest part is that low level process dependent optimization and that is just not repeatable without an army of engineers, expensive closed source tools, and access to bleeding edge foundries.
What people want, though, isn't to be able to make their own FPGA's. They just want an FPGA that is fully documented. Xilinx and Altera like to keep certain details secret. You have to use their tools because they won't tell you want you need to write your own and, even if you figure it out, they will sue you.
the Prop came out before the Arduino and still blows anything in the Arduino family out of the water, except for needing some external parts to do ADC. Can't wait for the Prop 2.
Liberty - Security - Laziness - Pick any two.
As customization reaches lower and lower levels, it becomes increasingly difficult to meaningfully compromise it. Probably the only way to meaningfully compromise an FPGA is to autodetect an internet connectin, and stream out to it everything you receive, possibly only on receiving a particular activation signal.
The "FP" in "FPGA" stands for "Field Programmable"; it's possible to compromise in the field, in a rather meaningful way.
Only if by "reigns supreme" you mean "is used more" :)
I've gone back and forth between Verilog and VHDL depending on the company I am at throughout my career. Verilog is used more often, but it is absolutely horrible. I know people find the strict typing of VHDL painful, but it really does save a lot of time later during verification. I think people would be surprised at how much VHDL is still used. A large part of Qualcomm uses it still for modem chips and for mobile SOCs.
I've always liked the PP for its novel approach to a multi-core micro. Opening up the hardware design like this can really grow its application space. Just because you can't imagine a use for this doesn't mean there is no use for it. And these days, FPGAs are making great strides in their accessibility. Verilog is the language of choice for most because of its similiarities with C. VHDL is mostly relegated to defense, because it has its roots in Ada (the syntax is almost identical). If you're into functional languages, check out BlueSpec, which will auto-generate SystemVerilog. And writing HDL is no longer for just EEs (which is a misnomer, btw). Tools like HDL Coder let anyone create a digital circuit. And there is greater selection these days for low-cost hobby boards. Plus, softcore micros have a long history in digital designs. Think microBlaze, NIOS II, even ARMs. Not to mention the OpenRISC core that's really quite capable. Imagine a robot where all of the software and control circuits are built into one chip, complete with ADC/DAC and PWM, all custom, and entirely reconfigurable. And FPGAs are getting better about power consumption, although they're still a long way away from 5V, 100mA, and more like 5V, 500mA for the smaller ones, but still. The big thing holding back OSHW, IMO, is access to tools that actually let you run a circuit on a chip without having to give blood to the tool vendor. Otherwise, AFAIC, the sky's the limit with this!
Well, apparently the license to everything is GPLv3, which could cause problems for those wanting to combine it with peripherals of other projects into one FPGA.
Or even if you decide you really want to make lots of them and make an ASIC out of it - how do you apply the GPLv3 to that since you can't really "rebuild" the ASIC...
Also, the tools they have are open-source too, under GPLv3. But since they're the toolchain, I don't think they include the output exemption, which would mean that not only is the processor hardware GPLv3, the software that it runs is also GPLv3. (GCC and the like have an output exemption that states the output of the compiler is NOT GPL)
True, but it would take some sort of hardware port to access the programming in the device and be capable of performing that sort of extremely low-level programming to rewrite the chip. I agree with you that it isn't impossible, but to be able to not just detect to also explicitly exploit that vector from much higher level protocols would be very tricky.
This sort of remote reworking of a FPGA was done with the Spirit & Opportunity rovers that are currently on Mars, where NASA (specifically the Jet Propulsion Lab) uploaded some new firmware through the Deep Space Network to another planet. If you can do that on Mars, having a home desktop computer reload new firmware as some sort of malware is trivial by comparison.
The DE0-Nano is a barebone board and the DE2-115 is populated with various common I/O ports.
Well, I can see a use for this. If you HAVE an existing FPGA, you could throw a processor on there for free. Some FPGAs have a CPU built-in (such as an ARM), but those parts cost more. With this, if you need some processor, this is not a bad choice. You could go for something like an 8051, but more options are nice to have. This also apparently has a nice software chain (compilers, interpreters, etc.).
If you really need a well-supported embedded soft processor, your choices are OpenRISC, 8051, Z80, 6502, or this (off of the top of my head, let me know if I missed something). Xilinx makes a MicroBlaze, but they charge money to unlock it.
"-1 Troll" is the apparently the same as "-1 I disagree with you."
The most interesting thing about the PP, is that the general design philosophy is to use a separate core for each task, thus completely eliminating the need for interrupts. So real time latency is drastically reduced.
So how important is any of this? Well, the PP is not very popular, to say the least, and I have never seen one used outside of a hobby project. That is probably why they figure they have nothing to lose by opening it up.
Yeah, because to those of us who've done microcontroller development the lack of interrupts just no sells the whole thing, plus it's not like polling is any less complex. Here's an example:
The system is running on battery power, and you want it to use minimal energy. In normal design, you have the chip sleep while waiting for an event that only happens occasionally. (In this context anything under 1kHz can probably be counted as occasionally. Without interupts this thing has to stay awake and have at least one of its cores polling for the event.
There are quite a few other cases where interrupts are useful. Polling can get the job done, but is horribly inefficient and needs code to be written to handle things that other microcontrollers handle in hardware.
The multiple cores are neat though.
So lets pretend that we've just completed writing this code, as opposed to having just completed sabotaging it -Altera
You write this response as if Windows XP has no market share at all, and that somehow software written for XP won't run on any newer operating systems or computers.
We aren't talking about something written in floating-point BASIC running on ProDOS 1.0 Surprisingly, emulators to run even that software exist on modern computers, so even that can be used.
"not really, until you can 3-d print it yourself and then verify with an xray will security be verified."
What if both your 3D printer and X-Ray data analysis software are compromised? See also: ... The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect."
"Reflections on Trusting Trust" by Ken Thompson
http://cm.bell-labs.com/who/ke...
"The final step is represented in Figure 7. This simply adds a second Trojan horse to the one that already exists. The second pattern is aimed at the C compiler. The replacement code is a Stage I self-reproducing program that inserts both Trojan horses into the compiler. This requires a learning phase as in the Stage II example. First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere
Still, the more angles you look at something from, the more likely you might detect some discrepancy... Like excess power usage, processing delays, slightly different electromagnetic signatures, etc...
In any case, the less you want, perhaps the easier it is to secure. Look into creating or using Forth chips for simplicity... The less gates you need, and the less cycles they need, the easier it would be to make your own hardware from scratch, even from discrete components if it is simple enough.
http://www.colorforth.com/
http://www.greenarraychips.com...
For software more complex than Forth that is still fairly understandable from the ground up, see also the FONC project by Alan Kay as well as Squeak on bare metal.
http://www.viewpointsresearch....
https://www.google.com/search?...
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
No-one with brains or a budget is going to use a 15-20,000 gate FGA to do a job that a 10,000 gate chip can do.
If you need lots of pins on an FPGA, you pretty much have to get one with lots of gates, even if you don't need them all.
Other requirements can also dictate the part you choose.
It's very basic.
There are no hardware peripherals bar a counter and it doesn't even have hardware multiplication