If someone actually bothered to make a serious Prop based PLC package(at the very least like Rabbit Semiconductors PLC kit) with software that made a attempt to conform to IEC 61131 programming standard then it might happen.
But folks in the industry need tools they can compare and test in the field and so far there aren't any.
Also theres another element to consider, no one ever got fired for going with the industry big dogs. When I was a instrument and controls electrician at the local cement plant/quarry the company was wedded to Gould/Modicon PLC's and the only alternatives they were considering when I left were from Allen Bradley. In short they only dealt with outfits with proven track records.
The reason a cog running spin code takes more current than assembly is that the memory drivers in hub are being used. Swinging the lines around and thier associated capacitance requires extra current. When the hub does nothing on a cog's slot it leaves the memory drivers inactive therefore consuming less current.
I started a new thread on the subject here, so as not to diverge from the original topic of this one. After reading it, you may wish to revise your explanation a little.
The reason that other microcontroller forum types show disdain for the prop or basic stamp has nothing to to with its technical strengths or weaknesses. You see, parallax products can be used by regular people, not just electrical engineers. (Although many good engineers do) People like to think of themselves as special (having special knowledge, privileges ,etc). They stick with their chips precisely because they are harder to get started with or use because it is a 'barrier to access'. In their mindset, a chip with a very low barrier to use is unwelcome.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Thomas Talbot, MD
Gunpowder, MD, USA
you know how absurd that sounds? That people whose living depends on delivering working products would not use
something that would be easier/cheaper/better to use, particularly in the ruthlessly competitive electronics industry?
Engineering is not an easy profession and there are lots of balancing acts and tradeoffs required to make a product
meet its requirements (price/performance/features/etc). The propeller doesn't always (or possibly even often) fit in
that sweet spot.
[noparse][[/noparse]yeah, I am a professional engineer]
I can totally see that dynamic in play. Good observation!
It's not all that uncommon for people to be insecure about their value, instead leveraging tech as some sort of ante they've paid.
As technology continues to improve and the rate of improvement continues to escalate, the good stuff trickles down to common knowledge. This is happening with micros right now, and the Propeller is one of the leaders in this. (That's why I like the thing! I can get into complex stuff, if I have to, but when learning, or enjoying it as a hobby, why bother?)
Anyway, what happens is either a person needs to continue to reinvest in new gateway skills, (and this is both annoying and productive at the same time) or come to some level of acceptance on the greater importance of people skills. Been through that. I'm better now!
The thing about staying on the ramp is that a considerable portion of time that could be used to build value, either for the person or the enterprise they work for, is used to stay on the ramp itself. The appeal of that ramp leads to lock in, and all sorts of games played by vendors who compete not only on the core value proposition of their offerings, but on how they can exclude the value of others! Total mind share game.
Once you step off of that, then tech is much easier to evaluate, apply and how you do business, who you do business with and other basic things carry a lot more weight.
The "special" part in this maybe understanding or niche skills. All good. It may also be in how you work with others, the kinds of relationships you build, or some combination of the two. Experience over time does tend to make climbing the ramp easier, so that's a plus. However, climbing it often has diminishing returns as a given market segment matures.
The key then, in all of this, if one wants to preserve their "entitlement" is not to downplay or marginalize other tech. That's just annoying. Really, what is of interest is:
1. identification of disruptive technologies
2. building the relationships necessary to apply them.
IMHO, Propeller is somewhat disruptive in that it lowers the barrier to entry on dedicated computing or embedded computing solutions. There is a significant movement on this right now, with Arduino and others introducing more friendly packages, and a growing amount of activity surrounding this kind of thing in general. This is good to see!
Have seen it before, multiple times. In my industry, it's been going on for a while now. At first there is a split where the lower barrier to entry products remain limited enough to not seriously impact the entrenched higher barrier products and services. Over time, that split fades as both camps bend a little to close the gap. Saturation happens, and consolidation happens. Sometimes legal things happen to keep the barriers in play artificially too. I can see that happening in this space big time.
When all of that plays out, the people who end up with the best overall value proposition are those with the people and business savvy to play well with others, not the ones with the "best" overall tech.
Of course, for those who have earned entitlements, and who have not focused on both those and general business people skills, this is a significant threat! LOL!!! Always happens. Always will. Either get along, or keep jumping to the next niche! Either is fine.
You guys are rational, and of course are gonna apply stuff to the best of your ability. That's not where the dynamic plays out! This is an artifact of business and the dual obligation to develop new stuff, and preserve existing revenue at the same time! The dynamic in play actually makes your job tougher, as there are often barriers put into place, just for the purpose of biasing those otherwise rational decisions!
Sucks, but that's how the major leaguers play. This is always how they play, and it does not matter what industry you are talking about. The core rules are the same. Head games are the same.
Working as a contract professional, for a smaller company, or as an originator of technology, such as Parallax, are the few niches where it's possible to avoid all of this Smile!
My day job involves being in the sales channel. We work with larger firms, who originate software technology, and to some degree hardware. (that's gotten really ugly, so we largely stay out) They do this Smile constantly! Our value is in sorting that out, helping people to use the tech for their means, and to get it to play together. This is not easy every year.
Anyway, I know it's a bit off topic for the detail, but Invent-O-Doc does have a valid contribution to this topic!
The good news is that influence is in play now, and will diminish over time as the tech rolls over a cycle or two, leaving us with a lower barrier across the board.
There's more truth to Invent-O-Doc's comments than there should be. The people who think this way think of it in terms of job security (If I'm the only one that understands how it works, then they aren't going to fire me, I'm too indespesible). This type of thinking is prevelant in the IT field, and it creeps into the engineering fields as well. It typically happens in small to mid size companies where the engineer to non-engineer ratio is rather small (the same criteria when it happens with IT guys).
Engineers work in logic, but that doesn't mean that thier actions are always guided by logic.
At my old high school, we had one guy who knew how to work the computer system, and they fired him. He was replaced with a guy who didn't know anything about networking or computers, and (no surprise) the system started having all sorts of problems. Yet for all that, he started instituting new rules that gave him more power... Moral of the story is that a one-track design team works.
I've already pointed out that the XMOS chip could be considered to be better value - four cores and 32 hardware threads (it's like having 32 processors) giving 10 times the performance (1600 MIPS), 256 I/Os, 256k RAM, and better development tools, for $33:
It's not as hobbyist-friendly, coming in a 512BGA or 144BGA package, but they will soon have a single-core device giving 400 MIPS with eight threads in a QFN package. That will cost $1 in quantity.
They are intended for professionals, replacing FPGAs and DSPs in many applications, but many hobbyists are using them, including several Propeller-heads.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Yeah, but it's not a multi-processing micro controller. In this, the Propeller is unique at this time. Multi-core carries with it some functional implications, many of which are the subject of this thread!
Those impact the value proposition. And I'll highlight just a couple.
Some differences from the data sheet
said...
From a software design standpoint, this means that the minimum performance
of a thread can be calculated by counting the number of concurrent threads at
a specific point in the program. In practice, performance will almost always be
higher than this because individual threads will sometimes be delayed waiting
for input or output and their unused processor cycles taken by other threads.
Further, the time taken to re-start a waiting thread is always at most one thread
cycle.
The set of n threads can therefore be thought of as a set of virtual processors
each with clock rate at least 1=n of the clock rate of the processor itself. The only
exception to this is that if the number of threads is less than the pipeline depth
p, the clock rate is at most 1=p.
Each thread has a 64 bit instruction buffer which is able to hold four short instructions
or two long ones. Instructions are issued from the runnable threads
in a round-robin manner, ignoring threads which are not in use or are paused
waiting for a synchronization or input-output operation.
This is one of the areas where multi-core designs differ from the multi-processor design of the Propeller. The peak computer of the XMOS chip is high, because it does not execute it's instructions in a simultaneous and concurrent way, like a COG does. This higher peak compute is then necessary, because it's really more of a linear computing device, with a lot of silicon dedicated to making it perform well on simultaneous tasks.
said...
Certain instructions cause threads to become non-runnable because, for example,
an input channel has no available data. When the data becomes available,
the thread will continue from the point where it paused. A ready request to a
thread must be received and an instruction issued rapidly in order to support a
high rate of input and output.
To achieve this, each thread has an individual ready request signal. The thread
identifier is passed to the resource (port, channel, timer etc) and used by the
resource to select the correct ready request signal. The assertion of this will
cause the thread to be re-started, normally by re-entering it into the round-robin
sequence and re-issuing the input instruction. In most situations this latency is
acceptable, although it results in a response time which is longer than the virtual
cycle time because of the time for the re-issued instruction to pass through the
pipeline.
So, this is more of a latched system than a deterministic one. (I think they are being less than honest about this!) In addition, the overhead required to understand it runs considerably higher than that required on the Propeller. If this were not the case...
said...
The XCore scheduler therefore allows threads to be treated as virtual processors
with performance predicted by tools. There is no possibility that the performance
can be reduced below these predicted levels when virtual processors are combined.
...they would not be stating that performance is "predicted by tools" and exhibits a minimum level of such. Also, there are a lot of various states the scheduler can be in. This increases complexity and indeterminate behavior.
A Propeller user, by contrast can simply know what their performance is going to be, and also know response times, because the system is deterministic throughout. It being a multi-processor actually simplifies this calculation further, due to the fact that instructions are running concurrently, not round robin. The high level of compartmentalization the COGs bring to the table, means also being able to isolate timing touchy code, from the body of more relaxed code without having to worry about interdependence to the degree required on XMOS.
The big innovation here, on the part of XMOS, is really more about encoding a scheduling kernel into silicon.
This is a very different value statement, than the one presented to us on the Propeller! IMHO, one that impacts the overall worth of that $33. And that's just comparing 8 COG's to the multi-core design of the XMOS. Frankly, this is apples and oranges.
It's save to say, $33 worth of parts and a breadboard gets you doing the same kinds of things, and arguably same kinds of performance in many cases. That's a wash.
From the looks of things, and granted I've not looked all that far, Propeller is much simpler in many ways.
Don't get me wrong. The XMOS stuff looks pretty cool. There are enough differences, many of which are the subject of this thread, that make simple performance and hardware specifications worthless where overall value judgments are concerned.
In what sense is the XMOS chip not a multiprocessing controller? Each core operates independently, in parallel, with very high-speed communication links between cores. Operation is fully deterministic, with 10 ns I/O granularity. Threads are implemented in hardware, with single-cycle switching between threads. Proper debugging facilities are available via a standard JTAG interface. The XMOS instruction set was designed to support efficient compilers, assembly language is rarely required. Parallel processing is very easy with the XC language, here is a small program of mine which tests communication with an prototyping board I made for my XC-1 kit:
#include <xs1.h>
#include <platform.h>
// LED on proto board (X2D2)
on stdcore : out port led_port = XS1_PORT_4A;
void flash_LED(out port led_port)
{
timer t;
unsigned time;
unsigned onOff = 1;
t :> time;
while(1)
{
led_port <: onOff;
time = time + 100000000;
t when timerafter(time) :> time;
onOff = !onOff;
}
}
int main(void)
{
par
{
on stdcore : flash_LED(led_port);
}
return 0;
}
It's basically standard C with extensions for parallel processing and threads. The par construct enables execution of a function on any core.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
potatohead said...
It is possible to have one thread, read the state of an I/O pin set by another one directly?
Does the number of threads impact the number of instructions per second executed?
The value of an input can be read by one thread and passed to another thread, or another core. There is some latency, of course, but it is deterministic. It's very low between threads.
Each thread is allocated up to 100 MIPS, so four threads can be running on one core at 100 MIPS each. Conceptually, I don't think it is very different from the Propeller, if you think of threads as cogs. Threads communicate directly, whereas cogs communicate via the hub on the Propeller. It doesn't really make much difference to the programmer.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
On the matter of the cores, given one thread is running, do they run concurrently, as in two instructions happening at the same moment in time?
It's difficult to consider threads as COGs. They are not the same thing.
A thread is one element in a greater body of code. A COG is a discrete compute unit, that may or may not exhibit threaded program flow. A COG may run it's own body of code, apart from bodies running on other COG's. These things can be quite different!
One thing I don't yet grok is if the cores can do this. And if they do, are their instructions happening at the same moment in time, or in a scheduled fashion?
Edit: Again, my point not being to diminish the XMOS stuff. We are however having a discussion that compares micro-controllers. A related topic is their relative value proposition.
The differences I highlighted impact the value proposition of the two designs, and that of course then hints at where their strengths are.
My understanding of a thread on the XMOS is that of an active state. Essentially, an XMOS processor has several sets of registers and can switch among them. Each set of registers contains the current state of an execution thread (including the program counter). The processor executes one at a time. I don't know whether there's some automatic switching or if one thread gives up control to another.
By comparison, a Propeller cog has only a single execution thread. You can construct several different threads, but their state is not completely saved automatically, only the program counter (with JMPRET). The carry and sign flags have only one copy and would have to be explicitly saved. I consider the special registers to be shared resources from a threading standpoint.
While there are several things XMOS seems to do very well, I think there is importance to one of potatohead's points.
That is the issue of determinism, from what I can tell there is no way of getting it on a XMOS unless you only have a single thread on a core. XMOS states repeastedly about how the timing of threads interplay and how threads can be placed in wait states thereby releasing cycles to the other threads.
This is proof that XMOS when having more than one thread is non-deterministic because a thread doesn't know when it's being given extra cycles due to another thread being placed in a wait state. While this approach has the advantage of being able to eek out as much power as possible out of the chip, it vastly complicates being able to pick up a piece of code that is timing critical and being able to make it work right off the bat unless you dedicate an entire core to it.
This is an area where the Propeller absoutely excels at, it is a simple matter to pick up an object from the exchange place it in your code and have it work from the get go.
potatohead said...
On the matter of the cores, given one thread is running, do they run concurrently, as in two instructions happening at the same moment in time?
It's difficult to consider threads as COGs. They are not the same thing.
A thread is one element in a greater body of code. A COG is a discrete compute unit, that may or may not exhibit threaded program flow. A COG may run it's own body of code, apart from bodies running on other COG's. These things can be quite different!
One thing I don't yet grok is if the cores can do this. And if they do, are their instructions happening at the same moment in time, or in a scheduled fashion?
Edit: Again, my point not being to diminish the XMOS stuff. We are however having a discussion that compares micro-controllers. A related topic is their relative value proposition.
The differences I highlighted impact the value proposition of the two designs, and that of course then hints at where their strengths are.
Threads operate consecutively. That is why I said that they are similar to cogs. XMOS threads are different from threads used on conventional processors.
As Mike has said, each thread has a set of registers which are used for inter-thread communication. Switching between threads only takes 1 clock.
Using multiple threads is completely deterministic:
"The instruction set includes instructions that enable the threads to communicate
and perform input and output. These
• provide event-driven communications and input-output with waiting threads
automatically descheduled.
• support streamed, packetised or synchronised communication between
threads anywhere in a system.
• enable the processor to idle with clocks disabled when all of its threads are
waiting so as to save power.
• allow the interconnect to be pipelined and input-output to be buffered."
If it wasn't it would be impossible to replace FPGAs with XMOS chips, which is a major market for them.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Im sorry Leon but this quoted directly from thier datasheet contradicts your statements on determinism:
said...
From a software design standpoint, this means that the minimum performance
of a thread can be calculated by counting the number of concurrent threads at
a specific point in the program. In practice, performance will almost always be
higher than this because individual threads will sometimes be delayed waiting
for input or output and their unused processor cycles taken by other threads.
If a thread gains extra cycles, it simply cannot be deterministic.
That is dealt with by the development tools: there is a cycle-accurate simulator, and a timing tool is under development. I'm getting a copy for beta testing. The minimum performance can be calculated, as you say, and the actual performance can then be predicted. It's essentially the same sort of procedure as carrying out a timing analysis for an FPGA.
David May, who designed the chip, has written this document on the XMOS architecture:
We had this same discussion on Propeller II attributes actually. Determinism is a very strong attribute. Lots of value there. I would argue symmetry also is strong. A COG is a COG.
I think the single cycle thread switching on the XMOS is cool actually. I also think it's performance / instruction size ratio is very good. Want to keep it friendly, after all! If you need some significant peak compute, that design can deliver it. The trade-off there is a nice one. The cost is complexity overall however.
I would add the overall utility of the Propeller, given only discrete components to work with, is arguably higher also. It's a simpler design all the way around, both hardware and software. That's highly likely to be more important to hobby / prototype projects however. Don't know.
With respect then to "better value" on XMOS, this is highly subjective. Really depends on what tools and modes of working one is used to. I think there is a strong case to be made that having to learn something new is a factor with both designs. On Propeller, there is SPIN and PASM, with C now too. So there is new learning on the languages, and about the COG / HUB relationship. On XMOS, there is the intricate scheduler, and understanding how code snippets are going to run together. Straightforward debugging facilities are necessary, where they arguably are not always so on Propeller. Plenty of learning there too, with the reality that once the learning is done, there will be less fussing around with code to be combined. IMHO, that's a clear plus for Propeller in the longer term.
Plus we've got tricks on Propeller! Having one COG display on the TV, the pin state changes made by another one is pretty damn cool! Makes me wonder about other things also. Look at the 6502 project Dennis did. I've been following a few other projects like this, and interfacing with other CPU's isn't always easy. Lots of little states to track down, and determinism plays a big factor in making it manageable.
I think if we were to duplicate that effort, with the two chips being discussed, the complexity and overall malleability of the Propeller design would both be significantly lower.
My point is that at the hardware level, the Propeller does exhibit some of the same characteristics it does at the code level.
From a business standpoint, that may well mean faster time to market, and more products per cycle to market. Both are very potent multipliers. Potent enough to be a consideration on this thread.
My .02
(plus a little, and I'll be quiet now, for a while.)
Having used both chips, I feel that including video circuitry on the Propeller, and the use of Spin, make it less useful in professional applications. I'd rather have had JTAG debugging and programming, more memory, and a proper compiler.
A major advantage of the XMOS architecture is scalability - if one chip doesn't have enough performance it's very easy to add additional chips. Five-wire Xlinks can be used for high-speed on-board inter-chip comms, and two-wire Xlinks for connecting boards together. The two-wire links can operate over several feet, if necessary. The whole system will still be deterministic. They are working on a 16 chip board - 25,600 MIPS!
XMOS is thinking of putting eight cores on a chip, they probably won't go any further. The existing silicon uses the TSMC 90nm process, eight cores would presumably mean using the TSMC 45 nm process.
XMOS is a very small company, like Parallax, with only 50 people. They spent $16 million over three years getting the chip designed and into production, they have just received a second tranche of $16 million. Three well-known VC companies provided the funding. It's also British!
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Having finally looked at the XMOS instruction set, I realize even more how lucky I am to using the Propeller. As is typical of architectures optimized for high-level languages, it's a rather baroque edifice, which I would not want to program in assembly. The Propeller's architecture and instruction set, by comparison, are much more regular and predictable. Plus, being able to make any instruction conditionally executable is a huge advantage for efficient assembly code. The Propeller's power lies not only in its speed and parallelism, but also in its simplicity.
I'm sure the XMOS chip will create its own priesthood of skilled conjurors, accomplished in the intricate incantations that make it function and to whom its acolytes will be beholden. Fortunately for Propeller users, that power rests in the hands of us laypeople.
Gotcha Leon, don't get me wrong I think there's alot of cool things going for the XMOS, but I personally like to have an inate uderstanding of whats going on in a chip rather than having to rely on a tool chain to tell me what's going on for me. I like to be able to think on the silicon level rather than having a nebulous cloud seperating me from the chip. It's much like my first car a Pinto station wagon, it was a clunker but I was able to do repairs on it myself when something went wrong. Now I barely trust myself to change the oil in my current car, and while I wouldn't go back because of safety and better fuel efficiency etc, I do miss being able to tinker.
@Phil, yeah I had noted the·sparseness of the instruction set in a Sandbox thread, what I was most disturbed by is that the only conditionals it supports is·whether a register is or isn't a 0, never could figure out how to test for overflow.
Several people have written sizeable applications in XMOS assembler. Ones that spring to mind are VGA and high-speed (480 Mbps) USB. I agree that it isn't easy - I'm learning to use it myself and finding it somewhat challenging. Most users will use XC or C (the two may be mixed in the same application), or other HLLs.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
LOL@ Phil and Paul --> That is exactly why I am here! (having a good time of it too)
@Leon That document linked is the one I was quoting from.
And for what it's worth, a scheduler in silicon is a nice innovation that has it's merits. No question. I just know it's not my cup of tea.
"The whole system will still be deterministic."
Being able to determine the timing characteristics of the code running isn't the same thing as the predictable instruction execution time, and parallel instruction processing found on the Propeller.
The former requires a scheduler, and the results can only be expressed in terms of not to exceed. (thus your incoming beta timing analysis tool)
The latter does not, and is expressed as a discrete precise quantity, easily obtained from a look at the program code.
Edit: If a thread can run @100MIPS, how come VGA is not written in C?
I just looked at the code and he seems to have used assembler to get the timings he needed (he actually used nops in places to get exact short delays), although he also used the timer hardware. He came up against a memory limitation, with only 64k available, which limited the resolution. He could have used external memory, of course. Resolution is 320x200 with 64 colours.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Comments
If someone actually bothered to make a serious Prop based PLC package(at the very least like Rabbit Semiconductors PLC kit) with software that made a attempt to conform to IEC 61131 programming standard then it might happen.
But folks in the industry need tools they can compare and test in the field and so far there aren't any.
Also theres another element to consider, no one ever got fired for going with the industry big dogs. When I was a instrument and controls electrician at the local cement plant/quarry the company was wedded to Gould/Modicon PLC's and the only alternatives they were considering when I left were from Allen Bradley. In short they only dealt with outfits with proven track records.
FWIW
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
I started a new thread on the subject here, so as not to diverge from the original topic of this one. After reading it, you may wish to revise your explanation a little.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Thomas Talbot, MD
Gunpowder, MD, USA
you know how absurd that sounds? That people whose living depends on delivering working products would not use
something that would be easier/cheaper/better to use, particularly in the ruthlessly competitive electronics industry?
Engineering is not an easy profession and there are lots of balancing acts and tradeoffs required to make a product
meet its requirements (price/performance/features/etc). The propeller doesn't always (or possibly even often) fit in
that sweet spot.
[noparse][[/noparse]yeah, I am a professional engineer]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jo
It's not all that uncommon for people to be insecure about their value, instead leveraging tech as some sort of ante they've paid.
As technology continues to improve and the rate of improvement continues to escalate, the good stuff trickles down to common knowledge. This is happening with micros right now, and the Propeller is one of the leaders in this. (That's why I like the thing! I can get into complex stuff, if I have to, but when learning, or enjoying it as a hobby, why bother?)
Anyway, what happens is either a person needs to continue to reinvest in new gateway skills, (and this is both annoying and productive at the same time) or come to some level of acceptance on the greater importance of people skills. Been through that. I'm better now!
The thing about staying on the ramp is that a considerable portion of time that could be used to build value, either for the person or the enterprise they work for, is used to stay on the ramp itself. The appeal of that ramp leads to lock in, and all sorts of games played by vendors who compete not only on the core value proposition of their offerings, but on how they can exclude the value of others! Total mind share game.
Once you step off of that, then tech is much easier to evaluate, apply and how you do business, who you do business with and other basic things carry a lot more weight.
The "special" part in this maybe understanding or niche skills. All good. It may also be in how you work with others, the kinds of relationships you build, or some combination of the two. Experience over time does tend to make climbing the ramp easier, so that's a plus. However, climbing it often has diminishing returns as a given market segment matures.
The key then, in all of this, if one wants to preserve their "entitlement" is not to downplay or marginalize other tech. That's just annoying. Really, what is of interest is:
1. identification of disruptive technologies
2. building the relationships necessary to apply them.
IMHO, Propeller is somewhat disruptive in that it lowers the barrier to entry on dedicated computing or embedded computing solutions. There is a significant movement on this right now, with Arduino and others introducing more friendly packages, and a growing amount of activity surrounding this kind of thing in general. This is good to see!
Have seen it before, multiple times. In my industry, it's been going on for a while now. At first there is a split where the lower barrier to entry products remain limited enough to not seriously impact the entrenched higher barrier products and services. Over time, that split fades as both camps bend a little to close the gap. Saturation happens, and consolidation happens. Sometimes legal things happen to keep the barriers in play artificially too. I can see that happening in this space big time.
When all of that plays out, the people who end up with the best overall value proposition are those with the people and business savvy to play well with others, not the ones with the "best" overall tech.
Of course, for those who have earned entitlements, and who have not focused on both those and general business people skills, this is a significant threat! LOL!!! Always happens. Always will. Either get along, or keep jumping to the next niche! Either is fine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
You guys are rational, and of course are gonna apply stuff to the best of your ability. That's not where the dynamic plays out! This is an artifact of business and the dual obligation to develop new stuff, and preserve existing revenue at the same time! The dynamic in play actually makes your job tougher, as there are often barriers put into place, just for the purpose of biasing those otherwise rational decisions!
Sucks, but that's how the major leaguers play. This is always how they play, and it does not matter what industry you are talking about. The core rules are the same. Head games are the same.
Working as a contract professional, for a smaller company, or as an originator of technology, such as Parallax, are the few niches where it's possible to avoid all of this Smile!
My day job involves being in the sales channel. We work with larger firms, who originate software technology, and to some degree hardware. (that's gotten really ugly, so we largely stay out) They do this Smile constantly! Our value is in sorting that out, helping people to use the tech for their means, and to get it to play together. This is not easy every year.
Anyway, I know it's a bit off topic for the detail, but Invent-O-Doc does have a valid contribution to this topic!
The good news is that influence is in play now, and will diminish over time as the tech rolls over a cycle or two, leaving us with a lower barrier across the board.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Engineers work in logic, but that doesn't mean that thier actions are always guided by logic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Post Edited (Paul Baker) : 1/12/2009 1:14:54 AM GMT
Does this mean that the Propeller is currently the cheapest multi-core microcontroller in the world?
It must be one hell of a deal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
www.xmos.com
It's not as hobbyist-friendly, coming in a 512BGA or 144BGA package, but they will soon have a single-core device giving 400 MIPS with eight threads in a QFN package. That will cost $1 in quantity.
They are intended for professionals, replacing FPGAs and DSPs in many applications, but many hobbyists are using them, including several Propeller-heads.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2009 3:56:49 AM GMT
Those impact the value proposition. And I'll highlight just a couple.
Some differences from the data sheet
This is one of the areas where multi-core designs differ from the multi-processor design of the Propeller. The peak computer of the XMOS chip is high, because it does not execute it's instructions in a simultaneous and concurrent way, like a COG does. This higher peak compute is then necessary, because it's really more of a linear computing device, with a lot of silicon dedicated to making it perform well on simultaneous tasks.
So, this is more of a latched system than a deterministic one. (I think they are being less than honest about this!) In addition, the overhead required to understand it runs considerably higher than that required on the Propeller. If this were not the case...
...they would not be stating that performance is "predicted by tools" and exhibits a minimum level of such. Also, there are a lot of various states the scheduler can be in. This increases complexity and indeterminate behavior.
A Propeller user, by contrast can simply know what their performance is going to be, and also know response times, because the system is deterministic throughout. It being a multi-processor actually simplifies this calculation further, due to the fact that instructions are running concurrently, not round robin. The high level of compartmentalization the COGs bring to the table, means also being able to isolate timing touchy code, from the body of more relaxed code without having to worry about interdependence to the degree required on XMOS.
The big innovation here, on the part of XMOS, is really more about encoding a scheduling kernel into silicon.
This is a very different value statement, than the one presented to us on the Propeller! IMHO, one that impacts the overall worth of that $33. And that's just comparing 8 COG's to the multi-core design of the XMOS. Frankly, this is apples and oranges.
It's save to say, $33 worth of parts and a breadboard gets you doing the same kinds of things, and arguably same kinds of performance in many cases. That's a wash.
From the looks of things, and granted I've not looked all that far, Propeller is much simpler in many ways.
Don't get me wrong. The XMOS stuff looks pretty cool. There are enough differences, many of which are the subject of this thread, that make simple performance and hardware specifications worthless where overall value judgments are concerned.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
On Propeller, we get 20 MIPS * 8 COG's = 160MIPS.
:P
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
#include <xs1.h> #include <platform.h> // LED on proto board (X2D2) on stdcore : out port led_port = XS1_PORT_4A; void flash_LED(out port led_port) { timer t; unsigned time; unsigned onOff = 1; t :> time; while(1) { led_port <: onOff; time = time + 100000000; t when timerafter(time) :> time; onOff = !onOff; } } int main(void) { par { on stdcore : flash_LED(led_port); } return 0; }It's basically standard C with extensions for parallel processing and threads. The par construct enables execution of a function on any core.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2009 5:44:01 AM GMT
Does the number of threads impact the number of instructions per second executed?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
The value of an input can be read by one thread and passed to another thread, or another core. There is some latency, of course, but it is deterministic. It's very low between threads.
Each thread is allocated up to 100 MIPS, so four threads can be running on one core at 100 MIPS each. Conceptually, I don't think it is very different from the Propeller, if you think of threads as cogs. Threads communicate directly, whereas cogs communicate via the hub on the Propeller. It doesn't really make much difference to the programmer.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2009 5:59:15 AM GMT
It's difficult to consider threads as COGs. They are not the same thing.
A thread is one element in a greater body of code. A COG is a discrete compute unit, that may or may not exhibit threaded program flow. A COG may run it's own body of code, apart from bodies running on other COG's. These things can be quite different!
One thing I don't yet grok is if the cores can do this. And if they do, are their instructions happening at the same moment in time, or in a scheduled fashion?
Edit: Again, my point not being to diminish the XMOS stuff. We are however having a discussion that compares micro-controllers. A related topic is their relative value proposition.
The differences I highlighted impact the value proposition of the two designs, and that of course then hints at where their strengths are.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 1/12/2009 6:47:56 AM GMT
By comparison, a Propeller cog has only a single execution thread. You can construct several different threads, but their state is not completely saved automatically, only the program counter (with JMPRET). The carry and sign flags have only one copy and would have to be explicitly saved. I consider the special registers to be shared resources from a threading standpoint.
That is the issue of determinism, from what I can tell there is no way of getting it on a XMOS unless you only have a single thread on a core. XMOS states repeastedly about how the timing of threads interplay and how threads can be placed in wait states thereby releasing cycles to the other threads.
This is proof that XMOS when having more than one thread is non-deterministic because a thread doesn't know when it's being given extra cycles due to another thread being placed in a wait state. While this approach has the advantage of being able to eek out as much power as possible out of the chip, it vastly complicates being able to pick up a piece of code that is timing critical and being able to make it work right off the bat unless you dedicate an entire core to it.
This is an area where the Propeller absoutely excels at, it is a simple matter to pick up an object from the exchange place it in your code and have it work from the get go.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Post Edited (Paul Baker) : 1/12/2009 7:22:15 AM GMT
Threads operate consecutively. That is why I said that they are similar to cogs. XMOS threads are different from threads used on conventional processors.
As Mike has said, each thread has a set of registers which are used for inter-thread communication. Switching between threads only takes 1 clock.
Using multiple threads is completely deterministic:
"The instruction set includes instructions that enable the threads to communicate
and perform input and output. These
• provide event-driven communications and input-output with waiting threads
automatically descheduled.
• support streamed, packetised or synchronised communication between
threads anywhere in a system.
• enable the processor to idle with clocks disabled when all of its threads are
waiting so as to save power.
• allow the interconnect to be pipelined and input-output to be buffered."
If it wasn't it would be impossible to replace FPGAs with XMOS chips, which is a major market for them.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2009 7:34:48 AM GMT
If a thread gains extra cycles, it simply cannot be deterministic.
Synchronization is not the same as determinism.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Post Edited (Paul Baker) : 1/12/2009 7:36:56 AM GMT
David May, who designed the chip, has written this document on the XMOS architecture:
http://forums.parallaxinc.com/www.xmos.com/system/files/xs1-87.pdf
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2009 7:44:36 AM GMT
We had this same discussion on Propeller II attributes actually. Determinism is a very strong attribute. Lots of value there. I would argue symmetry also is strong. A COG is a COG.
I think the single cycle thread switching on the XMOS is cool actually. I also think it's performance / instruction size ratio is very good. Want to keep it friendly, after all! If you need some significant peak compute, that design can deliver it. The trade-off there is a nice one. The cost is complexity overall however.
I would add the overall utility of the Propeller, given only discrete components to work with, is arguably higher also. It's a simpler design all the way around, both hardware and software. That's highly likely to be more important to hobby / prototype projects however. Don't know.
With respect then to "better value" on XMOS, this is highly subjective. Really depends on what tools and modes of working one is used to. I think there is a strong case to be made that having to learn something new is a factor with both designs. On Propeller, there is SPIN and PASM, with C now too. So there is new learning on the languages, and about the COG / HUB relationship. On XMOS, there is the intricate scheduler, and understanding how code snippets are going to run together. Straightforward debugging facilities are necessary, where they arguably are not always so on Propeller. Plenty of learning there too, with the reality that once the learning is done, there will be less fussing around with code to be combined. IMHO, that's a clear plus for Propeller in the longer term.
Plus we've got tricks on Propeller! Having one COG display on the TV, the pin state changes made by another one is pretty damn cool! Makes me wonder about other things also. Look at the 6502 project Dennis did. I've been following a few other projects like this, and interfacing with other CPU's isn't always easy. Lots of little states to track down, and determinism plays a big factor in making it manageable.
I think if we were to duplicate that effort, with the two chips being discussed, the complexity and overall malleability of the Propeller design would both be significantly lower.
My point is that at the hardware level, the Propeller does exhibit some of the same characteristics it does at the code level.
From a business standpoint, that may well mean faster time to market, and more products per cycle to market. Both are very potent multipliers. Potent enough to be a consideration on this thread.
My .02
(plus a little, and I'll be quiet now, for a while.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
A major advantage of the XMOS architecture is scalability - if one chip doesn't have enough performance it's very easy to add additional chips. Five-wire Xlinks can be used for high-speed on-board inter-chip comms, and two-wire Xlinks for connecting boards together. The two-wire links can operate over several feet, if necessary. The whole system will still be deterministic. They are working on a 16 chip board - 25,600 MIPS!
XMOS is thinking of putting eight cores on a chip, they probably won't go any further. The existing silicon uses the TSMC 90nm process, eight cores would presumably mean using the TSMC 45 nm process.
XMOS is a very small company, like Parallax, with only 50 people. They spent $16 million over three years getting the chip designed and into production, they have just received a second tranche of $16 million. Three well-known VC companies provided the funding. It's also British!
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2009 12:04:07 PM GMT
I'm sure the XMOS chip will create its own priesthood of skilled conjurors, accomplished in the intricate incantations that make it function and to whom its acolytes will be beholden. Fortunately for Propeller users, that power rests in the hands of us laypeople.
-Phil
@Phil, yeah I had noted the·sparseness of the instruction set in a Sandbox thread, what I was most disturbed by is that the only conditionals it supports is·whether a register is or isn't a 0, never could figure out how to test for overflow.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Post Edited (Paul Baker) : 1/12/2009 8:03:38 AM GMT
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
@Leon That document linked is the one I was quoting from.
And for what it's worth, a scheduler in silicon is a nice innovation that has it's merits. No question. I just know it's not my cup of tea.
"The whole system will still be deterministic."
Being able to determine the timing characteristics of the code running isn't the same thing as the predictable instruction execution time, and parallel instruction processing found on the Propeller.
The former requires a scheduler, and the results can only be expressed in terms of not to exceed. (thus your incoming beta timing analysis tool)
The latter does not, and is expressed as a discrete precise quantity, easily obtained from a look at the program code.
Edit: If a thread can run @100MIPS, how come VGA is not written in C?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 1/12/2009 8:50:38 AM GMT
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2009 8:50:02 AM GMT