So maybe the idea chip is a merger of the two -- a P1 with 8 cogs for device drivers and a single high speed processor with interrupts, such as an ARM core.
An idea that has bee suggested here many times. Welcome to the madness that is XMOS: http://www.xmos.com/products/silicon
See diagram at the bottom of that page.
I think there's a bit more hardware required than just that. When Chip did this over a year ago he also had to dedicate a return stack for each task, and there were a few other things needed. The tasks aren't completely independent of each other either. They have to ensure that they don't use the same resources that other tasks are using. And there's no way to ensure cycle accuracy for a task because other task will stall the pipeline waiting for hub access or some other kind of wait.
Perhaps a bit more hardware, but not much. You are probably thinking of a more complex system than I am. This would be two independent blocks of code running in the cog. All of the code would be loaded when the cog is started. The first block of code that is executed would be the default thread. It would start the second thread by executing a "start thread" (got to get away from mentioning interrupts) instruction. It would be the job of the programmer to ensure the threads do not step on each other. Since they are both running in the same cog they both have access to all the registers in the cog so they can share data and code if desired. Again, it is the job of the programmer to keep them from stepping on each other.
In hindsight this idea may be more suited to an enhanced P1 than the P2. The P2 has more cogs and much more memory so it may not need the extra horsepower, and the pipelining makes implementation more difficult. For the P1 it would be simpler to implement and provide a noticeable boost to it.
Wish I could try it on an FPGA but I have neither the expertise or the time. Hope someone else gives it a try.
And continuing to improve that idea is one of the very compelling aspects of this whole exercise. (Reference to heaters post)
Re: Space X
They also have those systems doing a lot more than control. The idea of highly automated, reusable space craft likely requires more compute than other efforts to date.
This software heavy approach can be seen in the Tesla cars too.
I've been trying to think of a reason not to buy one of these...The Parallella Epiphany III Desktop Computer
I can tell you exactly why you don't want to buy one of those:
Firstly I have to say that I backed the Parallella Epiphany Kickstarter campaign to the tune of a 100 Euros or so and I have one of the first boards.
0) As a "Desktop computer" there are better cheaper options. Now that the Raspberry Pi 2 is out even more so.
1) As an ARM board you will get better support from the Raspberry Pi community. That's not to say anything bad about the Parallella community it's just the way it is.
2) A Raspi has better graphics. A first Parallella project that amused, and amazed me was piping OpenGl commands from a Parallella board to a Pi over ethernet so as to get faster graphics!
3) Performance wise you are not gaining much, if any.
Unless...
4) You are really into developing parallel algorithms for that 16 core Epiphany chip. If that kind of thing is your obsession go for it. That is the whole point of the board in the first place.
5) You are really into developing in Verilog or VHDL for the FPGA fabric on that board.
The Parallella is in no way comparable to an MCU like the Propeller. Those 16 floating point cores are not tightly coupled to the I/O.
The Parallella is not a super fast "Desktop computer"
It will require dedication to that Epiphany chip for it to be appreciated.
You know what? My Parallella board has never been booted up. I realized I just don't have the skill or time to get to grips with it.
They also have those systems doing a lot more than control. The idea of highly automated, reusable space craft likely requires more compute than other efforts to date.
This software heavy approach can be seen in the Tesla cars too.
SpaceX's argument for going with C++ and Linux is that it was easier to find good programmers than if they went with some less common programming language and OS. Not to undermine the significance and complexity of returning a first stage for reuse the way they do (I'm a big fan of SpaceX), it just seems the software development route they've chosen was for the sake of convenience rather than strict necessity.
So maybe the idea chip is a merger of the two -- a P1 with 8 cogs for device drivers and a single high speed processor with interrupts, such as an ARM core.
There are a few solutions out there like that already.
* NXP have Dual Core MCUs, with a M0 core for the local, real time stuff.
* Most Power meters ( 8 bit and 32 bit) have a second DSP for the Power calculations.
* Microsemi have FPGA and ARM,
* Xilinx have FPGA and ARM in Zynq, and one of those may even run P1V, in a small module.
( see Antti's project here http://forums.parallax.com/showthread.php/158636-Open-Propeller-Project-Soft-Propeller-40P14)
I would expect a P2 to slave often to a (much) larger ARMs, not always MCUs, but larger Processor Arms like RaspPi Quad cores running Linux. It does not have to be a one chip system design.
I would expect a P2 to slave often to a (much) larger ARMs, not always MCUs, but larger Processor Arms like RaspPi Quad cores running Linux. It does not have to be a one chip system design.
You know, if that's going to be a common pairing (P2 slaved to a MCU/CPU), then maybe we should be asking whether the hardware trivially supports the bus hardware that's going to be expected by the MCU/CPU. I realize that you could dedicate a cog to be an SPI slave (for instance), but I suspect that's not the sort of integration that will make the P2 attractive for this use case. It means that you will always be down one or two cogs just to allow the MCU/CPU to communicate with it. It seems to me that a P2 variant with only 8 cogs, lots of smart I/O, and dedicated hardware for SPI slave (or whatever) would make this a very attractive choice.
Taking this thought even further, you could arguably shrink the hub memory and keep the 16 cogs. You keep just enough hub memory to use as buffering for the communication with the host chip. When you want a "big" central program, you do that on an ARM, Edison, etc. You can still do numerous stand-alone applications (P1 is proof of that), but for "large" applications of the sort that begot HUBEXEC mode (and endless discussions on whether we could have a "super cog"), the design approach is obvious: use an MCU/CPU of your choice.
Fast off-chip communications to a separate ARM processor is probably the way to go. I imagine that licensing the ARM core to place it on the P2 chip would be expensive and would also break the open source model that Parallax seems to be following. I don't think ARM is likely to open source their design.
Taking this thought even further, you could arguably shrink the hub memory and keep the 16 cogs.
The large memory is one key feature of P2, and lets it behave like Smart-Memory.
It also places it separately from the CPLD end of FPGAs, which tend to be memory-starved.
Check the price of Dual Port memories, to see what price special memory can command.
I seriously hope that Chip does not read any of these pie-in-the-sky musings or, at least if he does, is not distracted by them. None of this discussion has any value whatsoever in influencing the P2's direction at this point, and I trust -- at least hope -- that it will not. Perfect is the enemy of good, and doing something -- even if it's wrong -- is better than further hand-wringing delay.
I guess that Chip maybe is busy traveling between Rocklin and Colorado Springs. I hope that the design house (already mentioned by Ken) let Chip to use some of their design tools and not only be a "specs designer" but also another IC designer among the team. The design house looks very experienced and according to their location and website info maybe they are not used to public announcements of their work (mil customers?). I wish that they get involved with Chip and someday proud to say 'we made the P2 together with parallax'. I like to think that when Chip cames again to the forum he will say: look, this is the new P2. And we will have something that nobody ever expected, even us.
Thanks Heater; sounds like I'll give it a miss then.
Oh well, someday someone will make the perfect processor.
To paraphrase another acronym, TANSTAAPP. There might be a perfect processor for a particular application but the range of applications is just too broad for a single processor to fit them all.
To paraphrase another acronym, TANSTAAPP. There might be a perfect processor for a particular application but the range of applications is just too broad for a single processor to fit them all.
What was that quote?
One processor to rule them all.
One processor to find them.
One processor to bring them all
And in the darkness bind them.
There's no way to do preemptive multi-tasking with deterministic cycle accuracy (except for the highest priority task). On the other hand, you've got 16 cogs. Some of them can be used for deterministic cycle accurate tasks (one per cog) and the other cogs can do preemptive multi-tasking without affecting the deterministic cogs.
On a multi-core processor there actually is a very easy way to to do preemptive multitasking with deterministic cycle accuracy. That is to put the code requiring deterministic cycle accuracy in their own cores and never interrupt them. Most of the stuff I do seems to be event driven and I have to say that interrupts would make a lot of my code easier. Kind of along the line of "do this until you get this input, then forget about that and do something else". I can save as much or as little of the state as I need to.
By definition no definition defines no definition. re-examination may define a new definition or keep the definition undefined if the process creates the same definition.
By definition no definition defines no definition. re-examination may define a new definition or keep the definition undefined if the process creates the same definition.
This is awesome!
This must mean we continue to move forward as outlined in Parallax's plan. Since Parallax's plan is to have or not have a P2 at some point in the future, then if we divert from Parallax's plan, we will miss the P2 if there is one.
My P2 = P1V+ in an Altera 10M25 or 10M50 Max10 FPGA with 101 I/O. Now I just have to get a module board done for the EQFP package...
It may be 'expensive' compared to a P2 chip, but then I can order a 10M50 now (well almost now).
I think Parallax should just drop the P2 physical chip and do a P2V virtual chip based on the Altera Max10 line. Make a couple of different module boards up say one for the 10M25 (when it comes out) and one with the 10M50 (available very soon now). With the EQFP package they could make the boards in house.
But what about the crazy expensive chip costs? Well, they are only crazy expensive in small quantities. If Parallax invested the $$$$$$$$ that will still have go to into a physical P2 chip into a big Altera buy in I bet they could get those prices WAY down.
Yes, the module boards will be more expensive than a P2 chip would be BUT it could be done much faster, be constantly updated, contain support circuits that the customer would have to do themselves otherwise and be customizable for their volume customers and new markets. From what Ken says price is not that big of a factor for their industrial customer base. And those are the ones that have been clamoring for a P1+ or P2 for years now.
I want Parallax to keep being successful. Chip is BRILLIANT with his out of the box thinking for the design of the P1 / P2. A virtual P2 would really let Parallax maximize that resource! Instead of poor Ken looking at every new great idea Chip has as "omg, another delay?" it would be "GREAT! Another option module we can offer our customers! $$$".
Comments
See diagram at the bottom of that page.
Do you really want to program that beast?
Perhaps a bit more hardware, but not much. You are probably thinking of a more complex system than I am. This would be two independent blocks of code running in the cog. All of the code would be loaded when the cog is started. The first block of code that is executed would be the default thread. It would start the second thread by executing a "start thread" (got to get away from mentioning interrupts) instruction. It would be the job of the programmer to ensure the threads do not step on each other. Since they are both running in the same cog they both have access to all the registers in the cog so they can share data and code if desired. Again, it is the job of the programmer to keep them from stepping on each other.
In hindsight this idea may be more suited to an enhanced P1 than the P2. The P2 has more cogs and much more memory so it may not need the extra horsepower, and the pipelining makes implementation more difficult. For the P1 it would be simpler to implement and provide a noticeable boost to it.
Wish I could try it on an FPGA but I have neither the expertise or the time. Hope someone else gives it a try.
Re: Space X
They also have those systems doing a lot more than control. The idea of highly automated, reusable space craft likely requires more compute than other efforts to date.
This software heavy approach can be seen in the Tesla cars too.
Firstly I have to say that I backed the Parallella Epiphany Kickstarter campaign to the tune of a 100 Euros or so and I have one of the first boards.
0) As a "Desktop computer" there are better cheaper options. Now that the Raspberry Pi 2 is out even more so.
1) As an ARM board you will get better support from the Raspberry Pi community. That's not to say anything bad about the Parallella community it's just the way it is.
2) A Raspi has better graphics. A first Parallella project that amused, and amazed me was piping OpenGl commands from a Parallella board to a Pi over ethernet so as to get faster graphics!
3) Performance wise you are not gaining much, if any.
Unless...
4) You are really into developing parallel algorithms for that 16 core Epiphany chip. If that kind of thing is your obsession go for it. That is the whole point of the board in the first place.
5) You are really into developing in Verilog or VHDL for the FPGA fabric on that board.
The Parallella is in no way comparable to an MCU like the Propeller. Those 16 floating point cores are not tightly coupled to the I/O.
The Parallella is not a super fast "Desktop computer"
It will require dedication to that Epiphany chip for it to be appreciated.
You know what? My Parallella board has never been booted up. I realized I just don't have the skill or time to get to grips with it.
SpaceX's argument for going with C++ and Linux is that it was easier to find good programmers than if they went with some less common programming language and OS. Not to undermine the significance and complexity of returning a first stage for reuse the way they do (I'm a big fan of SpaceX), it just seems the software development route they've chosen was for the sake of convenience rather than strict necessity.
* NXP have Dual Core MCUs, with a M0 core for the local, real time stuff.
* Most Power meters ( 8 bit and 32 bit) have a second DSP for the Power calculations.
* Microsemi have FPGA and ARM,
* Xilinx have FPGA and ARM in Zynq, and one of those may even run P1V, in a small module.
( see Antti's project here
http://forums.parallax.com/showthread.php/158636-Open-Propeller-Project-Soft-Propeller-40P14)
I would expect a P2 to slave often to a (much) larger ARMs, not always MCUs, but larger Processor Arms like RaspPi Quad cores running Linux. It does not have to be a one chip system design.
Well, if they are smart about what they use, they have control over the whole stack.
If they are doing the right tests, they should be able to reach goals.
You know, if that's going to be a common pairing (P2 slaved to a MCU/CPU), then maybe we should be asking whether the hardware trivially supports the bus hardware that's going to be expected by the MCU/CPU. I realize that you could dedicate a cog to be an SPI slave (for instance), but I suspect that's not the sort of integration that will make the P2 attractive for this use case. It means that you will always be down one or two cogs just to allow the MCU/CPU to communicate with it. It seems to me that a P2 variant with only 8 cogs, lots of smart I/O, and dedicated hardware for SPI slave (or whatever) would make this a very attractive choice.
Taking this thought even further, you could arguably shrink the hub memory and keep the 16 cogs. You keep just enough hub memory to use as buffering for the communication with the host chip. When you want a "big" central program, you do that on an ARM, Edison, etc. You can still do numerous stand-alone applications (P1 is proof of that), but for "large" applications of the sort that begot HUBEXEC mode (and endless discussions on whether we could have a "super cog"), the design approach is obvious: use an MCU/CPU of your choice.
The large memory is one key feature of P2, and lets it behave like Smart-Memory.
It also places it separately from the CPLD end of FPGAs, which tend to be memory-starved.
Check the price of Dual Port memories, to see what price special memory can command.
I agree, and hopefully the Smart Pins will deliver IO at ARM speeds.
Bill Henning is also doing reviews on the 'Large ARM' modules, see
http://forums.parallax.com/showthread.php/159936-Raspberry-Pi-2-released.-PropellerIDE-faster-on-ARM.?p=1315657&viewfull=1#post1315657
& I've asked for those benchmarks to included 'fastest SPI' and 'Fastest Baud' & Baud-rate granularity numbers.
We know USB runs at 12Mbps, but it is not clear yet if P2 will properly manage USB FS.
50MHz seems to be a common ARM SPI rate, and a growing number also support Quad_SPI, especially in the higher end parts.
I did find this
http://www.raspberrypi.org/forums/viewtopic.php?f=44&t=43442
that seems to indicate a Virtual SPI clock of 250MHz and Baud = VSC/(2*N)
Practical speeds could be in the region of 31.25MHz / 41.666Mhz / 62.5MHz
-Phil
Give me the damn chip already.
I've learned something every time this topic has come up BTW.
Thanks Heater; sounds like I'll give it a miss then.
Oh well, someday someone will make the perfect processor.
To paraphrase another acronym, TANSTAAPP. There might be a perfect processor for a particular application but the range of applications is just too broad for a single processor to fit them all.
Or something like that...
On a multi-core processor there actually is a very easy way to to do preemptive multitasking with deterministic cycle accuracy. That is to put the code requiring deterministic cycle accuracy in their own cores and never interrupt them. Most of the stuff I do seems to be event driven and I have to say that interrupts would make a lot of my code easier. Kind of along the line of "do this until you get this input, then forget about that and do something else". I can save as much or as little of the state as I need to.
The original quote is "There ain't no such thing as a free lunch".
This is awesome!
This must mean we continue to move forward as outlined in Parallax's plan. Since Parallax's plan is to have or not have a P2 at some point in the future, then if we divert from Parallax's plan, we will miss the P2 if there is one.
1) There has to actually be a P2.
.....
Yep.
My P2 = P1V+ in an Altera 10M25 or 10M50 Max10 FPGA with 101 I/O. Now I just have to get a module board done for the EQFP package...
It may be 'expensive' compared to a P2 chip, but then I can order a 10M50 now (well almost now).
I think Parallax should just drop the P2 physical chip and do a P2V virtual chip based on the Altera Max10 line. Make a couple of different module boards up say one for the 10M25 (when it comes out) and one with the 10M50 (available very soon now). With the EQFP package they could make the boards in house.
But what about the crazy expensive chip costs? Well, they are only crazy expensive in small quantities. If Parallax invested the $$$$$$$$ that will still have go to into a physical P2 chip into a big Altera buy in I bet they could get those prices WAY down.
Yes, the module boards will be more expensive than a P2 chip would be BUT it could be done much faster, be constantly updated, contain support circuits that the customer would have to do themselves otherwise and be customizable for their volume customers and new markets. From what Ken says price is not that big of a factor for their industrial customer base. And those are the ones that have been clamoring for a P1+ or P2 for years now.
I want Parallax to keep being successful. Chip is BRILLIANT with his out of the box thinking for the design of the P1 / P2. A virtual P2 would really let Parallax maximize that resource! Instead of poor Ken looking at every new great idea Chip has as "omg, another delay?" it would be "GREAT! Another option module we can offer our customers! $$$".