The xCORE devices are 32-bit 10ns cycle time and are quoted at up to 4000MIPS for a 32-core chip. If that isn't enough, the on-chip comms hardware and software also work between chips - so 32 cores and 4000MIPS isn't the limit.
This is an interesting way of measuring performance.
Fairly standard, and quite relevant when moving away from the old-fashioned single core processors. (And the instructions in each IPS are relatively high level; they certainly aren't microcode!)
Other mechanisms avoid those problems. (xCORE latency <100ns 
)
PIC18 interrupt latency is 125ns 
Does the IDE guarantee that at compile time? And what is it when it is
simultaneously dealing with i/o from a USB link plus a front-panel, plus a motor, plus control-loop processing, plus data presentation processing, plus some DSP, plus... That's what
hard realtime systems
have to do.
With xCORE the IDE guarantees maximum timings, for the entire chip with all its cores. That's "FPGA like"!
Lots of tasks the MCU is performing are standard. For example, you often will need UART. You can create a core to do UART. However, low cost MCUs, such as PIC16, already have several UART "cores" and cost much less. So, you often can get by with a small CPU and diverse specialized peripherals. In such case, multicore will be an overkill.
Shrug. Anyone can come up with small systems with relaxed non-critical timing. Boring.
Apart from that, UARTs are boringly and trivially slow. Can a "conventional" processor implement a 100Mb/s ethernet link in software, while also doing other things? Or a USB endpoint? The XMOS devices can - but obviously that isn't always a good choice, so some xCORE devices also have dedicated USB and Ethernet links in them.
This example illustrates my point well. 100BaseT Ethernet controller is cheaper when done in hardware. Software implementations will be more expensive. Thus, when you can do things in hardware, it is more cost-efficient.
UART may look boring to you, but if you need it what do you do?
- Small MCUs have hardware modules - very little silicon, low cost, low power.
- XMOS needs to sacrifice a full core - the one that could do much much more than simple UART. The capabilities get unused, but the core still uses power.
No, and no.
No, it doesn't need to use a full core. In some circumstances it is possible for the compiler to merge tasks onto a single core (see the xC [[composable]] annotation). Even when not, it is easy to manually interleave processing from several sources in a single core. (Currently I'm using a single core for several independent tasks: UART IO plus protocol, reading front panel controls, and a few other things as well)
No, it doesn't use power. If a core is waiting for an incoming event (e.g. an input or timeout) then it consumes zero power.
- FPGA uses a very tiny part of the logic. Xilinx FPGA requires 4 or 5 slices. It is way more silicon that hardware implementation, but it is much less than is needed to build the whole core. And there's no waste - you use only your 5 slices.
Two can play that (rather unenlightening) game, viz: presumably you are either using a tiny part of an FPGA and have an additional processor, or you have a very inefficient soft-processor in the FPGA. Either way is wasteful
Now imagine you need 3 UARTs, 4 SPI, and I2C, 5 simple PWMs. Each task uses its own core but does very little. The same could've been accomplished by a small MCU with diverse peripheral, or by very small part of FPGA logic. And the cost (in terms of used silicon, power etc.) would be less in both cases.
Many of my designs have non-standard IO devices for which there are no standard protocols. xCORE can deal with those without needing extra external hardware; standard MCUs need extra external custom hardware.
xCORE can even "suck in" some traditional external logic, thus reducing the board cost. A neat example that is simple to explain is LCD processors. They guarantee LCDs have zero DC voltage applied across the segments. You couldn't safely do that in a bog-standard MCU, but the guaranteed timing in an xCORE processor makes it possible.
So, multi-core sounds like a good idea, but when you look at the economy of things, it really isn't. And you can see how this is reflected in the prices of XMOS devices.
That entirely depends on your application. Don't presume that your limited view of the world encompasses all applications.
That's reflected in the company's (XMOS's) valuation, in the number of companies that have invested and are continuing to invest in XMOS.
Home
Help
Search
Login
Register
