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

Comments

Limited utility.

[Dzimas]

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.

Re:Limited utility.

[Anonymous Coward]

I'm guessing those who don't trust market CPU's due to backdoor fears will enjoy this.

Re:Limited utility.

[Gothmolly]

You're talking about electrical engineering. This is not that.

Re:Limited utility.

[maligor]

You're talking about electrical engineering. This is not that.

From what exposure I've had with HDL, it's a language for electrical engineering. It's different from normal electrical engineering but it's even more different from normal programming.

Re:Limited utility.

[hamster_nz]

Sure, but it is a big bonus for people who need a few custom periherals and a nice, open, stable controller with a good toolchain.

Video processing? Audio processing? Driving oodles of servos? Driving oodles of Neopixels? Does your design need really tight feedback loops (e.g. high speed power control)?

Re:Limited utility.

[craigminah]

Would it be easier to just use off the shelf items to build your data center and them spend money building an open source thing that sniffs all the packets looking for suspicious crap? I'm asking because I'm not sure it'd be easy to automate identification of "suspicious crap" in the outgoing data.

Re:Limited utility.

[kesuki]

not really, until you can 3-d print it yourself and then verify with an xray will security be verified.

right now only governments and corporations are really able to build their own fabs and thus be 100% certain no backdoors are installed. 3d printing breakthroughs will take that fab and make it a expensive prototype box which can create copies of itself for material prices, as well as make devices such as routers/firewalls etc. leading to cheap devices that can make secure open hardware for defending the walled gardens of less secure devices. within 10 years of the processor printing 3-d printers and there will be a world changing event where the hobbyist can secure a network anywhere in the world and thus be totally immune to government watchdogs. they will then resort to ipv6 built in tech to find the secured routers by location and go in and try to bust their hardware for not having government required mandatory backdoors. or maybe i need to see my doc and get some of the meds back that i asked to be taken off of.

Re: Limited utility.

[Anonymous Coward]

It's a virtualized wire wrap gun.

"Now"?

[Anonymous Coward]

This matters because you can now build a device that is open hardware, open code all the way down to the CPU level!

Sort of like OpenRISC? Except, later and worse?

Re:"Now"?

[Anonymous Coward]

This matters because you can now build a device that is open hardware, open code all the way down to the CPU level!

Sort of like OpenRISC? Except, later and worse?

Sort of like LEON? Except, later and worse?

Re:"Now"?

[Anonymous Coward]

This matters because you can now build a device that is open hardware, open code all the way down to the CPU level!

Sort of like OpenRISC? Except, later and worse?

Sort of like LEON? Except, later and worse?

Sort of like SPARC Except, later and worse in a more specialized way?

Re: "Now"?

[maitas]

Opensparc delivered a gpl verilog several years ago.

Re:"Now"?

[Anonymous Coward]

This matters because you can now build a device that is open hardware, open code all the way down to the CPU level!

Sort of like OpenRISC? Except, later and worse?

Sort of like LEON? Except, later and worse?

Sort of like SPARC Except, later and worse in a more specialized way?

Sort of like RISC 1? Except, later and worse?

Re:"Now"?

[Anonymous Coward]

There have been a lot of open source cores for a long time. And to compile and actually use an open source core, you will be relying on closed tools.

Re:"Now"?

[TheRaven64]

This is precisely the issue that we have. Our core (MIPS IV compatible, 7-stage pipeline, branch predictor, SMP support) is open source (Apache-style), but it's written in a proprietary high-level HDL. After compiling it, you get Verilog, but even that isn't very useful by itself. There are a few open source Verilog simulators, but if you want to either run it on an FPGA or synthesise an ASIC, you're going to need proprietary tools. There's little incentive to produce open source versions, because they tend to be tied quite closely with their targets (either expensive FPGAs or even more expensive fabs).

Open FPGA?

[AikonMGB]

Is there an open-source FPGA design/implementation that you can run this on? Otherwise it's not really open-hardware all the way down, is it..

Re:Open FPGA?

[Austerity Empowers]

I'm not sure there is any toolchain for synthesizing RTL for either FPGAs or silicon that is open source. That's a big project unto itself.

There are a few open source simulators though, so in a sense you can "run" their design under say, Icarus (http://iverilog.icarus.com/). Still, you have to run on proprietary hardware somewhere.

Re:Open FPGA?

[Anonymous Coward]

I use synthesisers and place and route tools, the FPGA manufacturers seem to assume when we want a user friendly tool chain it means we want a graphical tool. So they make very crappy tools. For the record, we want good quality (no crashing, sensible error messages (not "unknown error")) command line tools, like how normal compilers work.

The only reason there are no open source synthesisers and place&route tools is because the specification of the silicon is unavailable.
Specification would be; the format of the bitstream and the latency of all the routes and logic and heat generation of each slice.

When specification become available, then I am pretty sure that good open source tooling will become available as well. With the format of the bit stream we may even be able to benchmark the latency and heat generation of the chip ourselves, possible even be able to disable non-functioning parts.

The problem is that FPGAs vendors believe that their tooling is what keeps them competitive against their competitor. And partly they are right the better their tooling the more use a HDL developer can get out of their chips. If everyone would use the same (open source) tool for all FPGA chips, then they have to compete on the actual silicon.

Since quite a few FPGA patents have lapsed a few years ago, I am hopeful that some Chinese silicon plant would punch out commodity FPGAs with an open specification, maybe with some basic but functional tooling for the open source community to expand upon.

And we desperately need some actual software developers building these tools. A few years ago we finally started to use VHDL '93 at the moment we expecting to be able to use VHDL2008 in 2028 and this is not a joke, that date is realistic based on historic glacial movement of the hardware industry.

Re:Open FPGA?

[sexconker]

If the premise is that you don't trust closed hardware or software, then you cannot establish trust by using any closed hardware or software.
If you have an open FPGA you'll need to program it with an open design using an open tool running in an open environment on open hardware.
Unless you've built your CPU, memory, etc. by hand from open transistors and shit, you can't really trust it.
And where are you getting your open electrons from?

Re:Open FPGA?

[pem]

Actual software developers write in C, not Ada.

Likewise, it's my understanding that most digital hardware is written in Verilog, not VHDL.

It's a bit different in the FPGA world, and in Europe, but AFAIK, in US chip development, Verilog reigns supreme.

Re: Open FPGA?

[Anonymous Coward]

What about the milkymist project

Re:Open FPGA?

[SparkEE]

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.

Re:Open FPGA?

[Anonymous Coward]

Verilog is a majority of US development, but not all. VHDL is used for a lot of aero/mil applications (I use it professionally, but not in those contexts). For example, the last time I looked at the SpaceX jobs page, they were hiring for VHDL. That said, there seems to be a movement toward SystemVerilog for some of its testing features, although VHDL2008 is also gaining support. Most hardware and simulator toolchains support both, and I have seen ASIC projects that combine the two (IP from a vendor in one or the other).

Re:Open FPGA?

[hamster_nz]

Can you give one example of Open Source Hardware that is "open hardware all the way down"?

If I could make an "Open Source Hardware" design using the actual propeller chip, then sure this makes that design "even more open", and so is a good thing IMO.

Re:Open FPGA?

[Anonymous Coward]

I am in Europe and I've used VHDL and SystemVerilog, including writing RTL in SystemVerilog. In Europe everyone used VHDL.

I first liked SystemVerilog for RTL but there are two things that makes this hard:
1. So many bugs in mixing SystemVerilog and VHDL, both in ModelSim and Precision RTL it is almost impossible to work with.
2. You can use the strict typing of VHDL to your advantage, you can use it almost as an object oriented language.

functions and procedures are overloaded and selected based on the argument and return types, so you can see them as methods to your classes. The classes are the types you create in VHDL (enums, records and arrays).

Sadly Ada has moved on a bit from VHDL, I wish VHDL makes it possible to make a new type based on another type.

In Ada you can do:
        type my_integer is new integer range 0 to 100;
This is different from:
        subtype other_integer is integer range 0 to 100;

The first one is a more stronger type without possibility to auto cast between the types, and therefor you can make specialised functions on my_integer. You can still explicitly cast because they are closely related types. For the rest they mean the same.

But I mean software developers writing in C developing actual tools, not software developers writing RTL. We need new RTL languages, simulators that have better debugging support, synthesisers that can optimise better, and place and route which can be distributed over multiple computers, gives us the possibility to hint the place and route from within our RTL code.

Re:Open FPGA?

[Anonymous Coward]

Is there an open-source FPGA design/implementation that you can run this on? Otherwise it's not really open-hardware all the way down, is it..

It's owners of turtles all the way down...

Re:Open FPGA?

[harrkev]

A few years ago we finally started to use VHDL '93 at the moment we expecting to be able to use VHDL2008 in 2028 and this is not a joke, that date is realistic based on historic glacial movement of the hardware industry.

Seriously? You have my condolences for using VHDL. You have my deepest sympathy. Second, why the glacial pace? SystemVerilog is supported by all major sim makers (at least to the extent needed to support UVM). Even synthesis tools are starting to support the SystemVerilog constructs that make sense in hardware (structs, unions, etc.).

Really, unless you are stuck using some specific tools that you can't upgrade or update, there is no reason that you can't switch to SystemVerilog today! Although, I admit that SV does not bring nearly as much to synthesis as it does to Simulation.

BTW: I come from the custom silicon world. I don't really use FPGAs much, so SystemVerilog may be beyond the capabilities of the free tools.

Re:Open FPGA?

[Teancum]

One example of some hardware that is really trying to be "open hardware all the way down" is RepRap. While not completely successful, the goal of the project is to eventually have the hardware build itself. As an open source project, if they are successful, will be quite an accomplishment. Fab@Home is another very similar project with similar goals and an open source hardware implementation. I'm personally partial to Fab@Home, but they are both worthy projects in their own right.

The Open Cores Project also tries to encourage such total vertical integration of hardware, but it is very slow in getting stuff going right now. I agree that "one example" of completely open source hardware (where all technical drawings, specs, parts, and everything from the raw plastic & metal parts) is simply not done at the moment.

Re:Open FPGA?

[TheRaven64]

So they make very crappy tools. For the record, we want good quality (no crashing, sensible error messages (not "unknown error")) command line tools, like how normal compilers work.

I have here a log file containing the output from a command-line build of our CPU using the Altera tools. This file is 10460 lines long. The relevant information it contains can be summarised as: No errors, passed timing.

Occasionally, we've had serious issues reported (the reset line on the ethernet MAC wasn't connected, so ended up being set high, which cost us over a week of time debugging the driver and trying to discover why the FIFOs weren't behaving correctly), but they're hidden in so much noise that there's absolutely no chance that a human will ever see them. They're not differentiated from trivial warnings that no one will ever care about.

In the software world, we've (with my Clang developer hat on) learned that warnings have to have a low false-positive rate or you end up with everyone ignoring them. We therefore expect reasonable developers to be able to set -Werror on large codebases and fix everything that breaks the build. If your code doesn't build with -Werror, then it's a big warning sign.

In the FPGA world, thousands of warnings (and even more 'information' lines) in the output are normal for any nontrivial build.

here it is

[raymorris]

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.

Re:here it is

[jones_supa]

Actually the AND gates come first, and are followed by OR gates. Then we can have some loopback connections to the same array. But that describes only one macrocell. The algorithms to create efficient (good performance and efficient use of cells) routing between the areas is part of the secret spice.

Re:here it is

[erice]

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.

Re:here it is

[Anonymous Coward]

It is a little bit simpler and more complicated than that.

or and and gates won't get you far, you could do this but you would actual hamper performance because routing distances between the components would become large.

FPGA vendors use something called a "slice" A slice contains two 6-to-1 (LUT) look-up-table / truth tables, 4 data flip flops, a carry chain, and a bit of multiplexer logic (to be able to select between the output of both 6 LUTs). This is a generic slice.

Then there are more specialised slices as well, such as Block RAM (a piece of memory, with an address bus and data bus, etc). And a multiply+add block, which in FPGA land they call a "DSP". And of course I/O since you need to talk to the outside work. Potentially you can put other specialised slices as well, things in the FPGA industry they call "hard-cores", such as CPUs, CRC checks or crypto blocks, etc.

Now you need to add a lot of routing, wires that go from slice to slice which can be switched based on what firmware (they call this bitstream) is loaded. The LUTs and the initial state of flip flops and RAM is loaded from this bitstream as well.

Now, currently chips still have special routing like global nets (complicated because it needs very tight propagation of signals throughout the chips), which carry signals like the clock and reset. However the industry is moving away from designs that require global signals and opting instead of resets that form a tree through the hierarchy of the design. In your own design you could opt for a letting the clock signals also follow the hierarchy of the design, *boom* no more global nets.

I am hoping that one day someone makes an FPGA an opens up the specification of it so we can build our own tools and everything.

Re:here it is

[Anonymous Coward]

I want an FPGA that is fully documented and can be configured and inserted into a design with parameters I select. Some of us get our designs into silicon. and if we can add a open hardware components that have some good community support for tools that is huge for us in-house as well as the customers for our silicon.

I'm not a huge fan of Propeller, but I appreciate the gesture. And maybe a 1 or 2 COG configuration would make a good state machine manager in an ASIC.

Re:here it is

[Anonymous Coward]

You're quite right that the vendors like to keep some things to themselves, but while we may never be completely sure what is actually in the silicon, there is a wealth of information out there, effectively sufficient to build custom tools. There is a project that provides a framework for this kind of work:

http://torc-isi.sourceforge.net/index.php

The device databases that provide logic and routing information are built from data available from the Xilinx tools and with the blessing of Xilinx. The release of the Vivado tool suite provides a Tcl interace to the same low level data with even more information than was available in the XDLRC.

What about the FPGA?

[Anonymous Coward]

What about the possibility of the FPGA being compromised?

Re:What about the FPGA?

[HiThere]

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. That would be reasonably easy to detect, and even THAT compromise wouldn't be easy, but FPGAs don't have any memory capacity, so they can't accumulate and wait to be polled.

Re:What about the FPGA?

[Anonymous Coward]

This would require that the FPGA contained an AI capable of analysing any design loaded into it, determining it's meaning and function, correctly interpreting the output, and then sending it back to the spooks without having any information about what it is connected to. All without being detected.

In other words it's totally ridiculous.

Re:What about the FPGA?

[jones_supa]

Something simple like a killswitch would still be possible.

Re:What about the FPGA?

[tlambert]

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.
 

Re:What about the FPGA?

[Anonymous Coward]

Really? If your FGA has 10,000 gates and the CPU design needs 9,800 gates to build you have to be a super-genius to add a back-door.

You would have to figure out how to make the original design in fewer gates to free up enough gates to run your back-door.

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.

ECP

Re:What about the FPGA?

[Teancum]

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.

Re:What about the FPGA?

[jones_supa]

It's not that trivial. You cannot change the hardware description on the fly, you need a cable to do that. Additionally, a private key is stored in the FPGA and the contents of the external Flash chip containing the hardware description has the data encrypted with the public key. Xilinx has a document with more info about tamper resistant designs.

Re:What about the FPGA?

[SuricouRaven]

Depends on 'compromise.' It's not always about getting data out.

Compromise could mean 'upon detecting this sequence of bytes, suspend your packet filtering for ten seconds so we can sneak our exploit through the firewall.' Or 'upon this sequence of bytes, switch the random number generator off and start using the pre-stored crypto key for new conversations so we can intercept them.'

Re:What about the FPGA?

[lister king of smeg]

Something simple like a killswitch would still be possible.

but obvious which is not something you want in a secret backdoor.

Re:What about the FPGA?

[dukeblue219]

FPGAs don't have any memory capacity? They absolutely do -- SRAM, Flash, whatever you're looking for. Some models can even self-modify their own configurations. Imagine a virus that can not only affect your OS, but actually re-wire the CPU in your computer. There are plenty of ways to compromise an FPGA both in terms of stealing the bit configuration or in terms of hiding malicious "code" inside the unused portion of the FPGA's fabric. The manufacturer could easily do this in cahoots with the NSA, or a highly-skilled operative could do it for any other reason.

Re: What about the FPGA?

[Anonymous Coward]

Nope - you just need to compromise the synthesizer or the fitter. Then you can add logic, or code to the final design.

Re:What about the FPGA?

[viperidaenz]

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.

Re:What about the FPGA?

[viperidaenz]

If you can do that on Mars, having a home desktop computer reload new firmware as some sort of malware is trivial by comparison.

Except... NASA specifically designed that functionality into the system.

Re:What about the FPGA?

[Teancum]

I currently have a network router that has similar capabilities. If you can download some firmware and flash it into a device for an update, some malware can certainly do the same thing without your permission.

If on the other hand you need a serial cable of some sort that as a completely separate port for updating the firmware that is code-wise unaddressable from the CPU, it is much harder to do that kind of update. It doesn't stop a co-worker from pulling a prank or somebody with physical access to the computer introducing malware, but it definitely is much harder. Still, if you have physical access to a computer you can do all sorts of other mischief that is harder to do through pure software processes.

Most hardware is moving in the direction of internal software updates though, where the NASA thing isn't really all that remarkable and more of the rule rather than the exception.

Re:What about the FPGA?

[Anonymous Coward]

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. That would be reasonably easy to detect, and even THAT compromise wouldn't be easy, but FPGAs don't have any memory capacity, so they can't accumulate and wait to be polled.

It could probably be done easier the other way around. Instead of trying to autodetect an internet connection you can autodetect a magic packet. Matching all data on all pins against a fixed sequence should be a non-issue.
Upon receiving the magic activation packet you temporarily connect the secret enternet device to the pins and transmit the FPGA configuration to the packet source.
The attacker now have the code you are running in the FPGA and can make modifications and upload back to you later.

Re:What about the FPGA?

[K. S. Kyosuke]

And? If you connect an FPGA (which is a programmable piece of hardware) to the outside world using some sort of (non-standard) connection, how is the FPGA going to find 1) which pins to drive 2) using what protocol, before it can establish a link home or something similar?

Re:What about the FPGA?

[Anonymous Coward]

only if the hardware is designed so that the processor can write to the memory... Also most modern FPGAs are capable of using AES encryption on the bitstream with the key permanently burned into each individual FPGA. So loading a bad bitstream into the EEPROM wouldn't work if it wasn't encrypted properly. This is also a nice protection against reverse engineering.
It's not like you can just send instructions to some random FPGA and it will simply reconfigure itself...

Performance?

[mcrbids]

I wonder how this CPU performs? Does it compare to anything I'd care about, or is it more akin to something I'd build a wifi router out of?

Re:Performance?

[bob0the0mighty]

It's an eight core microcontroller and, based off the stats on wikipedia, each core seems to have similar performance to an ATmega2560.

Re:Performance?

[ShanghaiBill]

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.

Re:Performance?

[Anonymous Coward]

Wikipedia article says it can run up to 80 Mhz, and they are working on a new model that runs up to 200 Mhz.

Re:Performance?

[ilsaloving]

Hey now...

There's plenty of things you can do with 32k of memory, like going to the moon or playing pong! (Nothing in between)

Re:Performance?

[Anonymous Coward]

I agree. At first I though this was a move towards bankruptcy. But after some thought a PP is cheaper than an fpga and easier to use which makes it just what the hobby market is looking for. Since that's there primary market then open source is a clever way to get more people useing the architecture. Plus there multi-core multi-thread aproach swimms pretty well in an fpga.

Re:Performance?

[Anonymous Coward]

That's not true, you can do plenty of things in between playing pong and going to the moon. You can count the elapsed time. Once thrusters are off, you could even load the pong program again, as long as you give yourself time to reload the lunar orbit insertion program before it is time to fire thrusters...

Re:Performance?

[Jerrry]

"I wonder how this CPU performs? Does it compare to anything I'd care about, or is it more akin to something I'd build a wifi router out of?"

The Propeller is an interesting beast. It has eight 32-bit cores they call cogs and a hub that ties them all together and gives each of them round-robin access to the 32K of hub RAM. Each core itself only has 2K of RAM it can access, so any assembly program has to fit in this small space.

Most the the time, you don't write assembly code (unless you need the speed), but use Spin instead. Spin is a proprietary, interpreted language. Each cog can host a separate version of the Spin interpreter, and tokenized Spin code is fetched out of hub RAM, which is much larger than cog RAM (32K vs 2K), so Spin programs can be larger.

There's also a C compiler that has a strange implementation given that cog RAM is too small to hold more than a trivial program if the code were entirely cog resident.

One other difference between the Propeller and most other microcontrollers (AVR, PIC, ARM, etc.) is that the Propeller has no built-in peripherals. The philosophy behind the Propeller is that if you need a peripheral, you implement it in software and run it on one of the eight cogs. Need a UART (or six)? It's just a matter of software. It is somewhat wasteful, however, to dedicate an 80 MHz 32-bit processor to a simple I/O task -- that might offend some purists. Since all peripheral functions need to be implemented in software, it's not possible to directly implement peripherals that run at high data rates, such as 480 Mb/sec USB.

The Propeller also lacks interrupts. The logic here is that since you're dedicating a full 80 MHz processor to an I/O function, you can poll without affecting any of the other processors and hence don't need interrupts.

All-in-all it's an interesting and unusual architecture, but I don't see it replacing more mainstream MCUs anytime soon.

Re:Performance?

[wonkey_monkey]

The best use of 32k (and approx 0.2 MIPS) I've ever seen is Exile. The map data alone would have been bigger than 32k if it wasn't mostly procedurally generated, and it had a physics engine and particle effects. On one more limited platform (the Acorn Electron) game data had to be visible onscreen around the playing area because memory was so tight. There was nothing left for any kind of HUD, so information (like weapon power remaining) had to be communicated to the player by sound. If you wanted to save your progress, the computer had to be crashed and (soft)-restarted first.

Re:Performance?

[EmperorArthur]

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.

Re:Performance?

[Anonymous Coward]

I remember when 20 MIPS was SMOKING fast. Amiga with 68040 accelerator ran at about that speed. So to say that's not enough speed for general computing, bah!

Speaking of Commodore, apparently the Propeller was designed by Chip Gracey, who designed one of the first freezer cartridges for the Commodore 64 (ICEPIC).

Re:Performance?

[Anonymous Coward]

.... and then Steve Jobs came along ....

Re:Performance?

[Anonymous Coward]

You have not learned much about real-time embedded systems have you?

Because if you had you would know that having a core waiting to run some code for you is equivalent to having that code run from an interrupt but with some major advantages. You would know that polling is not the way that is done. A core can sit idle, consuming very little power, until some event it is waiting on wakes it up. This has the huge advantage over interrupts that you don't need to worry about what happens when two events need servicing at the same time. You don't need to mess with interrupt priorities. You can be sure that handling a new event on a new core will in no way upset the timing of your existing event handlers. The whole system becomes much easier to reason about. Handling multiple low latency requirements becomes much easier. In fact with a single core interrupt driven system you can find you simply don't have enough processing power to handle such frequent and coincident interrupt activity.

The Propeller chip has WAIT instructions that halts the core in a very low power state until an event occurs, pin changes or time outs for example. It then runs at full speed to handle the event with very low latency.

The devices from XMOS are another example of multi-core micro-controllers that use the event driven model rather than interrupts.

       

Re:Performance?

[Anonymous Coward]

I agree completely. Mod parent up. The propeller is indeed interesting, and highly unusual.

I'd add that while the Propeller's cogs can run at 80 MHz, it takes four clock ticks to perform one operation; its "MIPS/MHz" ratio is 1:4. Once again, clock rate isn't everything. Many of its competitors have a MIPS/MHz ratio close to 1.8:1 or so.

One of the few dedicated peripherals in the Propeller is a video generator for NTSC, PAL, and VGA, which is kinda neat if you can find a device to display it.

The propeller's major problem is its cost. It has a much lower 'bang for buck' than most MCU's. It's roughly $8 for a propeller, and even more to add on the needed EPROM and oscillator. In contrast, you can get a higher level of functionality for $2-3 with more mainstream MCU's.

Still, this is great news for open source, if only because it opens up hardware-hacking with a 'reference' implementation.

Re:Performance?

[ilsaloving]

And not a single person got the reference.

So sad...

I recommend googling "Every OS sucks" by Three Dead Trolls in a Baggie

Re:Performance?

[BasilBrush]

The clock rate is software programmable - as a fraction of the crystal used. So you can run it at 12 MHz. And then there's a WAITCNT instruction that effectively sleeps till a programmable counter reaches zero. So you can put all the cogs to sleep except one, and only wake the remaining one up as infrequently as you need to poll.

Still not as power efficient for some device that's waiting a long time between events and is running from battery. But a hell of a lot of devices are not that.

And for sure it's far less complex than using interrupts. Providing that you can do all the different things you need in 7+1 different processes. If you have to share a cog to do two different things, then it suddenly becomes very hard.

The propeller is a delight to use. I hadn't had as much fun coding for years as when I used one. Though again thats's more of a selling point for hobbyists than professionals. ;-)

Why is this important?

[sinij]

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?

Re:Why is this important?

[Anonymous Coward]

because the manufacturers have a monopoly on the security, support and further development of the hardware. We cant make improvements or audit it

Re:Why is this important?

[Anonymous Coward]

depends on what's important to you.

the more that people use open source code, the more popular that app/widget/whatzit becomes, the more people will want to contribute to that code.

also the more good code there is, the more good code there is to draw from. it seems like a pretty big waste of human potential to keep re inventing the wheel, when if there was a good open source wheel, everyone could use it.

this clearly isn't as good as closed source offerings, but it leans towards good principals.

i for one would like to be able to know exactly how something works, even if i never actually look into it.

it's like voting with your wallet, but you're voting with your time

Re:Why is this important?

[Anonymous Coward]

And because sooner or later everything in a mobile device will be open source except the baseband, and we might finally get a crack at that.

Re:Why is this important?

[Anonymous Coward]

Yes, I know there is a project. I was being semi-facetious, but the point I am making is that we will have to open source the entire device before there is any meaningful pressure on telecoms firms to adopt open source basebands.

Re:Why is this important?

[Anonymous Coward]

because by now you can only be sure of one thing... that your hardware is rigged for abuse. either bei the us or the chinese government. it doesn't matter WHO you trust, because you can't trust anybody who is hiding behind an "ip wall". they either have their own backdoors, which will be found and abused by criminal elements or the backdoors are for the secret services to use. you can't even call me paranoid any more... it's just fact after fact after fact that proves my point.

Re:Why is this important?

[NotInHere]

The baseband is not an hardware-ASIC, but runs completely in software, on a general purpose CPU. And the biggest problem is missing legislation to allow for open source mobile basebands.

Re:Why is this important?

[powerlord]

I thought the same thing after watching: http://youtu.be/urglg3WimHA

Re:Why is this important?

[Type44Q]

Because backdoors.

Re:Why is this important?

[Anonymous Coward]

To avoid hidden backdoors. All proprietary hardware is untrustworthy.

Re:Why is this important?

[AmiMoJo]

TFS misses the point entirely. This isn't a CPU at all, it is a microcontroller. A CUP forms part of a computer system, where as a microcontroller is self contained with its own small memory and peripherals (serial ports, analogue to digital converters, timers etc.)

The Propeller is an interesting microcontroller because it has 8 parallel 32 bit RISC cores. That makes it suitable for some rather unusual tasks that most other micros would need to be paired or quadrupled up for. There is some rather nice library code available for it too.

This release targets FPGAs. An FPGA contains a large number of programmable logic gates and circuits. Before FPGAs you would get huge boards full of chips, which can now be condensed down to some code and compiled. You can update the thing any time you like just by changing the code. Quite often it is helpful to have some kind of CPU or microcontroller as part of the FPGA's program, and this gives people another option and the ability to use existing Propeller code.

It isn't earth shattering and won't challenge desktop CPUs or allow you to build a computer completely from source code, but it is a nice thing to have use of for free.

Re:Why is this important?

[StormReaver]

1) You're not reliant on closed hardware vendors to provide drivers for your operating system.
2) You don't have to trust that your hardware vendor isn't reporting your every move to your fascist government.
3) You don't have to worry about your hardware vendor's interests diverging from your own, and stranding you.

There are many more, but I don't have time to post them.

Re:Why is this important?

[dos1]

Actually, knowing the state of security in cellular networks - especially old 2G and availability of "downgrade to 2G" techniques for newer ones - despite of being strong FLOSS and OH supporter I'm kinda glad that any tech-curious kid next door can't easily play with baseband in his mobile phone.

Sadly, there's also kind of people that won't care that it's illegal and with enough motivation will get all needed hardware, so we're not really protected either way.

Re:Why is this important?

[Anonymous Coward]

Did you fab that FPGA yourself, or did you buy a devboard from a vendor? How do you know there isn't hidden microcode lurking in there, waiting for its signal to strike? That tinfoil hat will not protect you, particularly since the Illuminati saw to it that world governments forced tin foil to be replaced with cheap aluminum foil that doesn't protect you from their mind-control rays.

Re:Why is this important?

[Anonymous Coward]

It is important, because companies who do not open source their products frequently lie and cheat in all kinds of places. For example, nobody knows whether the random number generation in Intel chips produces real randomness or not and it is impossible to find that out without reverse engineering the chips (which is practically impossible, too).

Not everybody is a noob consumer like you.

Re:Why is this important?

[Teancum]

There is the OpenBTS software & equipment if you want to seriously get into hacking cell phone networks. The authors of that software have even used it for setting up a cell phone network at the Burning Man festivals. They chose this venue in part because being in the middle of nowhere that the Burning Man stuff happens also was unlicensed to commercial cell phone providers, thus they could get experimental FCC licenses for their project and not interfere with existing networks.

In theory, somebody could set up their own "pirate cell station" and have a whole lot of semi-legal or flat out illegal fun with this equipment. It does cost a few thousand dollars to get the rig set up, which is why more teens likely don't go playing with the technology more.

On the positive side, these guys have been setting up cell networks in pretty remote places like sub-Saharan Africa and some Pacific islands to provide people with cell phone coverage that otherwise couldn't afford to have this kind of luxury. Commercial equivalents to this equipment are at least 10x or 100x the price.

Re:Why is this important?

[Anonymous Coward]

I didn't suggest it was hardware ASIC though. I just argued that it'll be the last piece, to the point of absurdity.

Re:Why is this important?

[Anonymous Coward]

To give you just a little example: Intel AMT enables your shiny processor to "phone home" independently of the OS running on top of it. No amount of SELinux, AppArmor, disk encryption or whatnot will protect you if that is turned against you.

Need another esample?

Re:Why is this important?

[TheRaven64]

The reason that we've open sourced our CPU (not the one in TFA) is to promote research. The vast number of papers published in computer architecture conferences and journals evaluate their approach solely on a simulator and hope that there's some relationship between the simulator and reality. While a softcore CPU is not exactly like a real CPU, being able to implement your ideas in an FPGA (and pass timing!) does at least mean that it is possible to implement them in a real CPU, although it doesn't guarantee that they'd be more efficient than another approach. It also lets you do evaluation with real software: we can boot FreeBSD on our system and run real programs on it for benchmarking, which is a lot more realistic than taking some existing instruction trace, permuting it based on some assumptions, and then feeding it into your simulator.

Re:Why is this important?

[dos1]

There're also OpenBSC and OsmocomBB. However, even with all these projects there's still a pretty steep barrier to enter, which would disappear if open basebands in mobile phones would somehow become common.

Just a shift

[Anonymous Coward]

An open source soft CPU in a closed source FPGA, how is that any different from an open source software in a closed source hard CPU?

The FGPA is still closed source

[Anonymous Coward]

We need the equivalent of Shapeways for affordable hobbyist VLSI fabrication. That's the only way to know there's mo backdoors in your processor. Unfortunately maskmaking costs dominate prototype-scale fabrication runs, even at large linewidths like 0.35 micron. There was a movement some decades ago towards direct lithography on wafer to eliminate the mask step, sort of like using a laser printer instead of offset printing, but it never got traction.

Re:The FGPA is still closed source

[Anonymous Coward]

There has been some work done recently.

Finally, we show that photochemical etching can be used in combination with epi-DPM imaging to controllably vary the etch rate across the sample and thereby fabricate 'gray-scale' structures, e.g., microlenses. Thus, the use of a computer projector to display different optical masks combined with real-time feedback from epi-DPM allows for the fabrication of structures with arbitrary topographic profiles, without the need for iterative or multistep etching or expensive gray-scale lithography masks.

Windows XP?!?

[Anonymous Coward]

Spin code is written on the Propeller Tool, a GUI-oriented software development platform written for Windows XP.

Good ole Chip must heve missed the memo about the retirment party for XP in Redmond.

Re:Windows XP?!?

[Teancum]

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.

huh?

[Anonymous Coward]

But aren't all Intel and Amd cpu's(not gpu integrated portion) open sourced already, since day one? You can get any information(architecture, instruction sets, etc...) on any intel or amd from their websites. I mean isn't this why it was possible for linus and others to develop linux or freebsd. Or are we talking about non-proprietary instruction set vs intel's x86 and amd's x64?

Re:huh?

[nurb432]

just having access to the instruction set and block diagram of its registers does not mean its an opensource cpu.

While i doubt opening u[ the propeller really means much in the grand scheme of thins, you have *zero* clue what is going on here and should just shut your stupid mouth and stop wasting our bandwidth..

Re: And Stallman...

[Anonymous Coward]

Class Envy of RMS???

This is great

[spiritplumber]

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.

Re:This is great

[Anonymous Coward]

even the SAM3X8E?

Re:This is great

[Anonymous Coward]

Arduino's tools are better than Propeller. The programming model of AVR's 8-bit RISC is more reasonable than the self-modifying code used in Propeller's 32-bit environment. (There is no call stack on Propeller, you patch your return address in the op-code to create a linked list through your code segment)

Teensy(72MHz Cortex-M4) stomps all over Arduino in terms of performance, size, capabilities(lots of cool I/Os) and price.

Re:This is great

[viperidaenz]

Please explain how the Propeller blows away a Cortex M3 with 96k RAM running at 84MHz with a bunch of hardware peripherals
http://arduino.cc/en/Main/Ardu...

Re:This is great

[Anonymous Coward]

Arduino was 2005, Propeller was 2006. Are you thinking of the BASIC Stamp?

Re:This is great

[Anonymous Coward]

It's unfortunate that Spiritplumber didn't make a distinction between the Propeller (a microcontroller), and the Arduino (a hardware platform).

While most Arduino's have 8-bit AVR microcontrollers, not all do (such as the Cortex M3 version).

The Arduino hardware platform is open, and there are other Arduino compatible offerings (ChipKIT, for example) that use other cores, including ARM and MIPS.

I'm not even sure the Propeller can outclass all of the 8-bit AVR's. I'm certain there are quite a few uses where an 8-bit AVR will outperform the Propeller. Emulating hardware peripherals in software will only take you as fast as the emulator can go.

More importantly, in this space, "performance" is a red herring. Nobody cares that the controller in your keyboard can do more than the next guy's.

Hardware "Vision"??

[Quantus347]

For a second there I thought parallax had executed a machine vision sensor system driven by their micro-controller. That would have been so much cooler than this all but empty gesture.

Re:Hardware "Vision"??

[spiritplumber]

The CMUCam4 is Prop based.

Great, but

[Anonymous Coward]

Does it run Crysis?

Intimacy...

[mythosaz]

...and anyone who isn't intimately familiar with microprocessor design, along with every other step of code along the way will still have to trust someone along the chain.

Yeah yeah yeah.

[Anonymous Coward]

Shut up and take my money!

while nice...

[nurb432]

Its a real nice gesture on their part and kudos to them, but I dont see this being a huge deal in the long run. I really do not see people that need to use a propeller in their product ( are there any ? ) wanting to go to a more expensive and slower FPGA ( or even a custom ASIC )..

I could be wrong...

Re:while nice...

[harrkev]

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.

Superficially it appears so.

[Anonymous Coward]

If you know anything about the CPU microcode, update method, etc, you'd know that despite 'open documentation', there is a huge amount of unknown logic within a modern x86/x86_64/arm32/arm64 cpu. And in the former 2 cases the update-able microcode meant to help fix 'errata' could just as easily be coopted to introduce errata, assuming there aren't already 'undocumented (to the public)' backdoors included in the current iterations of the microcode, perhaps even changed between 'bugfix' microcode releases to ensure it won't be discovered there's a singular (and thus implausible as a 'design oversight') exploit available to gain privileged access inside the cpu.

That said, most of this is moot, thanks to ARM's 'Trustzone' and Intel's 'Trusted Execution Technology' combined with the remote management infrastructure.

The Clipper Chip lives again! (wikipedia it, compare it to Trustzone/the intel equiv, and ponder for yourself)

The era of 'Wild West' computing is going to rapidly close if we, the nerdy, don't put in place a commercial imperative to counteract it. Current commercial cpu design is trending in exactly the opposite direction of it.

Hopefully someone else can expand upon this comment with the details of integrated flash and other 'non-rewritable' boot code technology that will lock the aforementioned technologies in modes we can't defeat.

Re:Superficially it appears so.

[Anonymous Coward]

If you have a budget of 1 billion transistors, you can easily use 100000 to check some registers and "open the kingdom" when a certain 128 bit pattern is loaded into registers.

NSA and Unit8200 here come your victims !

Don't forget the Russkies with access to expensive electron microscopes. THEY have access, too.

Just forget "security". Focus on growing roses or something. Computers are wholly insecure craploads of faulty circuits.

Kind of small?

[jones_supa]

Looking at the source code (dismissing blank and comment lines) it seems to be only about 800 lines of Verilog.

Re:Kind of small?

[viperidaenz]

It's very basic.
There are no hardware peripherals bar a counter and it doesn't even have hardware multiplication

What's the difference?

[ShieldW0lf]

The site suggests that this can run on the DE0-Nano Cyclone FPGA Board for $90 or the Altera DE2-115 FPGA Development Board for $600. As someone who doesn't know anything about this type of computing... can anyone explain what the difference is between the two?

Re:What's the difference?

[jones_supa]

The DE0-Nano is a barebone board and the DE2-115 is populated with various common I/O ports.

Re:What's the difference?

[viperidaenz]

Approximately $510 difference between the two.

This is Fantastic!

[TheSheriff80]

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!

Re: And Stallman...

[Anonymous Coward]

I bet he's seen one. Hell, even most slashdotters have SEEN one.....

GPLv3 in hardware?

[tlhIngan]

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)

Re:GPLv3 in hardware?

[Anonymous Coward]

how do you apply the GPLv3 to that since you can't really "rebuild" the ASIC

You read the license and publish what it requires you to publish under equally-free terms to the hardware you're handing over.

Are you saying there's some file format involved in the design of an ASIC that can't be published? like, "oh sosrry Mentor 2D pattern-request files include a boilerplate template that is copyrighted by us, and the output of the chip layout software contains copyrighted shiboleths extracted from the layout software and injected into the output. We allow an exception to redistribute the output to ASIC fabrication shops that we license." It's an interesting hypothetical. I don't know about ASIC fabrication and haven't heard of something like that actually existing, but these guys do love using creative "licenses" to extract rent or tap the demand curve at multiple points.

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.

Hahahaha, serious lulz. The shoe's on the other (hypothetical) foot now, isn't it?

I don't think this is a blocking problem, though. It sounds like a reasonable position to take. If I were working on open hardware I'd probably quickly become pissed off by elitist can't-be-bothered EE types who "don't care about politics, just want to get work done. Anyone serious in this field has $200k of software licenses paid by their employer so I don't see what you are complaining about. Maybe you don't feel people should be paid for their work?" In their place I would not miss an opportunity to say "fuck you" to people like that.

However, I'm not sure that's actually happened. seems more like you're trying to tear them down with speculation. It's not necessary: companies that hate freedom will dismiss them out of hand without lathering themselves up in GPL FUD.

Re:GPLv3 in hardware?

[Anonymous Coward]

"could cause problems for those wanting to combine it with peripherals of other projects into one FPGA"
newspeak translation: could cause problems for those wanting to exploit it for their slaveware.

won't someone think of the slave traders?

Incorrect statement about interrupts

[Anonymous Coward]

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.

The last sentence is factually incorrect.

In the absence of interrupts, the average latency for responding to an input is one half the sampling time, and sampling has to be continuous (in effect, the hardware is performing a poll or busy-wait on the input).

In a level-triggered interrupt system, the interrupt can vector a CPU to the interrupt handler instantly (meaning, as fast as the semiconductor process allows), and this can occur even from a sleep state since no polling is needed.

So using a separate core for each task without interrupts actually increases the response latency over an interrupt-based system.

What the Propeller people probably mean is that dedicating a core to each task avoids timesharing and also avoids low-priority tasks losing CPU when they're interrupted. That much is true, but it's the addition of cores that provides the benefit, not the removal of interrupts.

Re:Incorrect statement about interrupts

[ShanghaiBill]

In the absence of interrupts, the average latency for responding to an input is one half the sampling time

In hard realtime, nobody gives a crap about average latency. All that matters is the maximum latency. If your timing requirements are flexible, then it is not hard realtime.

Re:Incorrect statement about interrupts

[Anonymous Coward]

No. You are factually incorrect.

A core waiting on an external event, a pin change say, effectively has it's clock stopped, hence the low power consumption. When the event occurs it can commence executing the next instruction right away.

Contrast to an interrupt where the currently executing instruction has to complete, the program counter and processor status have to be saved, the stack pointer adjusted, the interrupt vector fetched, the jump to the interrupt handler made, probably more registers have to be saved on the stack and then finally we can execute the first useful instruction of our interrupt handler.

There is no way having a core all primed and ready to respond to an event is any way slower than responding to an interrupt.

Polling is not needed.

That's all before we even think about the fact that your interrupt handling probably has to wait for some higher priority handler to complete. If both those interrupts requires such low latency you are out of luck with your single core interrupt driven machine.

Nice gesture, but not didactic

[Anonymous Coward]

I looked through the verilog code and there are little to no comments. There are no diagrams or comment blocks describing why the circuits were designed that way (k-maps, fsm tables, design trade offs, etc). It's almost like they took the generated RTL output from their designers and stripped away their comments. I think this is a great gesture by parallax, but this isn't very helpful from an instructive perspective.

Reflections on Trusting Trust; Simplicity & Fo

[Paul Fernhout]

"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:
"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 ... 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."

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

Open, but not usable

[Anonymous Coward]

Too bad there are no Open VLSI CAD tools, Open Foundries, Open FPGA tools, or Open FPGAs you can use this on. It's kind of like getting instructions for something you can only use if you have between $1k and $10M in proprietary tools to use it.

Sorta neat

[Anonymous Coward]

I've played with the Propeller CPU a little bit. I've never been able to find an application where it really shines. And the biggest thing keeping it from commercial use is the external, unencrypted program memory.

QR story

[phan79]

https://plus.google.com/101541...

truyen phat giao

[phan79]

http://tintuc.oho.vn/news/c180...