Open Sourcing something doesn’t actually acquire meaning until someone actually uses what has been unleashed in the wild. We’re happy to see a working example of Propeller 1 on an FPGA dev board. That link takes you to a short description and some remapping of the pins to work with a BeMicro CV board. But you’ll want to watch the video below, or rather listen to it, for a bit more explanation of what [Sylwester] did to get this working.
You’ll remember that Parallax released the Propeller 1 as Verilog code a few weeks back. This project first loads the code onto the FPGA, then proves it works by running SIDcog, the Commodore 64 sound emulation program written in Spin for p8x32a processors.
We do find this to be an interesting first step. But we’re still waiting to see what type of hacks are made possible because of the newly available Verilog code. If you have a proof of concept working on other hardware, certainly tell us about it below. If you’ve been hacking on it and have something you want to show off, what are you waiting for?
While it might not seem very useful to emulate a $8 chip with a $50 FPGA, it’s a neat demo and a bit reassuring that even if something happens to Parallax there will be a way to move Propeller based legacy designs forward.
To be fair that FPGA is only 30, the dev board is 50. Would be interesting to see the cheapest chip that can implement this.
Is it the speed or the gates that will be most limiting?
If it’s gates, can’t you just pull out 7 of the cores and still run single thread firmware?
The propeller doesn’t have interrupts, so multiple cores are pretty much required.
You could, but single thread firmware is pretty limited, as [dorl] pointed out. And there’s also no reason to use the Prop then, as other open-source cores could be used instead. Perhaps four cores would be a more useful compromise.
I’m no expert in Prop or FPGA, so I can’t really answer your question; but I can suggest another potentially limiting factor. Low end FPGAs tend to be quite poor on RAM. If I recall correctly, the Prop has 2K dedicated per core, plus 32K shared, for 48K total. You could probably use external memory for the shared portion if needed, as it’s accessed round-robin by each core in turn.
But the 2K dedicated memory per core must be available in the FPGA. And merely having a total of 16K available somewhere won’t cut it. It must be functionally separate RAM areas, to provide for true simultaneous access by each core.
To my untrained eye, if all eight cores are desired *and* external shared memory is provided, this still rules out the three cheapest families of Altera Cyclone on basis of RAM alone. Real experts please correct me if I’m wrong.
What about the flip side of this question? Is eight cores a hard limit, or could the architecture support more with simple software-side changes and a huge, top-o’-the-line FPGA (or even custom silicon)?
Each core gets round-robin access to shared memory every eight cycles. This is *always* the case. Even if you disable one or more cores on a real Prop, the timing doesn’t change; as the memory arbiter doesn’t skip over the disabled cores. 100% predictable timing is the key to making virtual peripherals without timers or interrupts.
Simply adding a ninth core and expanding the memory arbiter to accommodate it would change the timing, so that each core gets access every ninth cycle. That would break existing software compatibility. You’d need to run the memory and arbiter on a separate clock, at 9/8 (or a round 16/8) the speed of the cores. That in turn may introduce other timing issues. I won’t say it’s impossible, but it would be challenging.
Fortunately, there’s probably not much of a reason to do this, because Props are easily connected together using their I/O pins for massively parallel computing. You could use a full eight-core Prop, alongside a stripped down Prop for whatever additional cores are needed. I haven’t looked, but I bet most of the logic elements used are in the cores, so the overhead for the first core of an additional Prop wouldn’t be too bad.
My wild guess is that 16-cores could be done fairly painlessly. The hub normally runs at half the clock speed of the cores. Bring it up to the same clock speed and hub access timing stays the same with 16-cores. I suspect the block-ram is fast enough, (it runs the cores just fine) but I’d expect the faster hub would need a 2-stage pipeline to avoid having to change the cores.
There’s a lively discussion in the Parallax forums where members have already proposed, implemented and shared many improvements. For example: more I/O pins, more memory, ports of the original Altera code to Xilinx FPGA’s…
Personally, I’m interested in adding debugging features: making it possible to plug an FPGA board into existing Propeller-based designs and doing things that can’t currently be done, such as single-stepping through the code, setting breakpoints etc.
A couple of people including myself have been working on Github to track the Parallax release and a few bug fixes and the Xilinx port. New features will be implemented in new forks and new branches, but we’re still getting organized so stay tuned.
Chip Gracey of Parallax has mentioned that he’s open to the idea of creating an actual chip based on ideas of the community. So get one of those cheap FPGA boards and start hacking :-)
For being such a short time since the code has been released, there has already been some interesting mods such as “port B” which increases the number of IOs from 32 to 64, as well as a new VGA and audio circuits.
I think someone has successfully replaced the ROM with pre-filled RAM as well. If I remember correctly, 48KB hub ram fit on the DE0.
As a practical matter, this isn’t much as reassurance of a way to move forward with extant Propeller-based products should Parallax go away.
What “open sourcing” the design might accomplish, however, is to prompt Parallax to release a few variants of the P1 that have improvements/additions for which people have been begging for some while. Design on the P2, which drones on and on and on…, has shifted focus from more practical applications. So I see this move as a possible (roundabout) way to get off that seemingly dead-end road and shore up the semiconductor product catalog with tangible, useful ICs.
Otherwise, really this isn’t anything other than a bone for the dozen or so fanbois who frequent the Parallax forums and appear to hold, for whatever reason, the full attention of Parallax management.