GHz Microcontrollers? You Bet!

[mark03]

The increase in MHz is good, the increase in Watts not..

The pattern that I have seen thus far is newer processors which run at faster speeds, can be under-clocked to run at the same speed as the old tech, with lower power.  Hopefully that remains the case.  I know that there are leakage issues at the smaller process nodes.  NXP was talking up FD-SOI a while back, but that seems to have been delayed...

Edit: press release says this chip *is* built on FD-SOI.  So I would expect the power numbers to be significantly better than STM32F7/H7 and the prior iterations of iMX RT.  Will be interesting to see when it actually ships in quantity (at Digikey).

A shame about the high-pin-count package though.  Hopefully they will migrate the 28nm FDSOI stuff into the more mainstream parts eventually.

[Marco]

The I.mx7ulp seems finally in production, so they seem to be getting fdsoi in grip ... 2 years behind schedule.

[lucazader]

I am really liking the trend towards flashless MCU's.

They are much cheaper than the flash based ones, and then you can use off the shelf QSPI memory that is a fraction of the cost per KB that the on hip flash costs.

It allows manufacturers to produce smaller higher yield dies, which results in cheaper processors.
Or it allows them to switch to smaller more power efficient production nodes.
Or put that die area towards on chip dcdc subsystems instead of the LDO's traditionally used to scale 3v3 down to the core voltage. Which again improves power consumption.

I very much like the idea of this chip.
Ability to run a few motors in a dedicated M4 core with low interrupt latency, and then have HMI, USB and WiFi/Ethernet comms on the other processor, all while maintaining low power consumption sounds like a great idea to me.

[radioactive]

What do they have for A/D converters on the new NXP parts?  I'm impressed with the 16-bit converters on the stm32h743 as well as the dsp capabilities.

[lucazader]

From what I can see they have only specified the sample rate of the ADC's in the literature released so far for this new chip (2MSPS).
This is faster than previous chips in the same line which are 12-bit 1MSPS units.

However i couldn't see any spec for the bit depth of the ADC ont he new processor.

[nctnico]

Everyone talks up Linux for these high end applications but it comes with a huge amount of development burden just getting Yocto setup so you can end up with a small, tight binary that just boots and runs.

On the other hand, you get real memory. I don't understand why these faster MCUs don't get LPDDR3/4 support ... why only support SDRAM? It's 3 decades old, are they taking the piss?

I think these kind of MCUs are designed to put on a 4 layer board. An LPDDR4 design needs 8 layers at the very least.

[jhpadjustable]

A lot more MCUs are likely to run from RAM in the next few years, many booted from a local serial flash die in an MCM.

Wouldn't that be stealing intellectual property from China?   

[Marco]

ST maintains you can use the stm32mp1 with lpddr3 on a 4 layer PCB, without blind vias even. See their routing application note.

[thm_w]

Let me know when a 1GHz beast is available in QFN or QFP48 

I am really liking the trend towards flashless MCU's.

They are much cheaper than the flash based ones, and then you can use off the shelf QSPI memory that is a fraction of the cost per KB that the on hip flash costs.

It allows manufacturers to produce smaller higher yield dies, which results in cheaper processors.
Or it allows them to switch to smaller more power efficient production nodes.
Or put that die area towards on chip dcdc subsystems instead of the LDO's traditionally used to scale 3v3 down to the core voltage. Which again improves power consumption.

Good point, 1MB of flash is ~50c digikey, whereas moving from 256kB to 2MB for an STM32 is a massive $5-10 increase in price. The question is, how much of that is profit margin and how much is actual inherent cost of the chip? We know with other consumer goods the margin is much higher on the larger parts, and that the low end parts are often remarks/bins of the high end ones.
So many manufacturers may be reluctant to do this.

[lucazader]

Good point, 1MB of flash is ~50c digikey, whereas moving from 256kB to 2MB for an STM32 is a massive $5-10 increase in price. The question is, how much of that is profit margin and how much is actual inherent cost of the chip? We know with other consumer goods the margin is much higher on the larger parts, and that the low end parts are often remarks/bins of the high end ones.
So many manufacturers may be reluctant to do this.

It also allows you to more freely pick the MCU performance, and or package/pin count that fits your application, and then decide on the amount of flash your application will need (and potentially up or down size this amount as needed before or during production).
This would be an ideal world scenario of course. But to some extent we have used this in some of our products allowing us to get the correct amount of flash in a product rather than paying for 1MB of internal flash, and then also 4MB of external (which has happend previously) when we could and should have just used the external 4MB.

[coppice]

1MB of flash is ~50c digikey, whereas moving from 256kB to 2MB for an STM32 is a massive $5-10 increase in price. The question is, how much of that is profit margin and how much is actual inherent cost of the chip? We know with other consumer goods the margin is much higher on the larger parts, and that the low end parts are often remarks/bins of the high end ones.
So many manufacturers may be reluctant to do this.

This is market pricing. Adding 2MB of flash doesn't blow up an MCU's cost by several dollars. Adding 2MB of RAM costs more than 2MB of flash, at least down to 40nm. So, a RAM based MCU that boots from serial flash will be more expensive than a flash MCU. The main argument for using RAM is to allow faster execution. At 28nm and below flash can be problematic, so a different set of constraints will apply.

[westfw]

A lot more MCUs are likely to run from RAM in the next few years, many booted from a local serial flash die in an MCM.

Wouldn't that be stealing intellectual property from China?

No.  "Obvious" and also "Prior Art" (FPGAs loading from serial EEPROM.)

[OwO]

I think most applications that use a 1GHz MCU are really better served by an FPGA. For example high speed concurrent I/O, realtime DSP, or anything requiring low latency. Microprocessors can NOT multitask no matter how you dress it up, so they are no good for I/O. They also suck at DSP. I had an application that needed to demodulate a certain signal, and the most optimized NEON implementation on a cortex-A9 took a few hundred clock cycles per sample to do it. In contrast a half decent hardware implementation using very few FPGA resources (only one multiplier) would take no more than 30 cycles per sample.

The sad state of affairs is simply because most people can't be bothered to learn hardware design, and even when they do they stick to software -ism like "processes" or behavioral logic design. IMO FPGA design should be like designing a circuit - you describe the circuit elements at a high level (for example in terms of adders, multipliers, and sub-modules), but in the end you are still wiring up a circuit and not describing "operations" to be performed.

[mark03]

The sad state of affairs is simply because most people can't be bothered to learn hardware design, and even when they do they stick to software -ism like "processes" or behavioral logic design. IMO FPGA design should be like designing a circuit - you describe the circuit elements at a high level (for example in terms of adders, multipliers, and sub-modules), but in the end you are still wiring up a circuit and not describing "operations" to be performed.

The big players in FPGA-land are making this worse, in a way, by going all-in on tools and wizards which try to make engineers productive without knowing any HDL at all (see the recent Xilinx Vitis announcement).  This may well be the future, but in the meantime, it tends to obfuscate the lower-level tricks and techniques for those just starting out.  E.g. years ago Xilinx had app notes on topics like how to optimize FIR filtering or DDC/DUC; now they just tell you to use the closed-source wizard instead.  Great (?) for productivity and time to market, not so good for actual understanding.  Also, just try finding a good text on DSP design in Verilog/VHDL.

[mark03]

Let me know when a 1GHz beast is available in QFN or QFP48 

I am really liking the trend towards flashless MCU's.

They are much cheaper than the flash based ones, and then you can use off the shelf QSPI memory that is a fraction of the cost per KB that the on hip flash costs.

It allows manufacturers to produce smaller higher yield dies, which results in cheaper processors.
Or it allows them to switch to smaller more power efficient production nodes.
Or put that die area towards on chip dcdc subsystems instead of the LDO's traditionally used to scale 3v3 down to the core voltage. Which again improves power consumption.

Good point, 1MB of flash is ~50c digikey, whereas moving from 256kB to 2MB for an STM32 is a massive $5-10 increase in price. The question is, how much of that is profit margin and how much is actual inherent cost of the chip? We know with other consumer goods the margin is much higher on the larger parts, and that the low end parts are often remarks/bins of the high end ones.
So many manufacturers may be reluctant to do this.

There is a *lot* more to this than price per MB.  On-chip flash is way faster than external QSPI.  Even if you go for the latest and greatest Octo- or Hyper-flash or whatever, AFAIK the basic on-chip flash in something like an STM32 is still faster.  (Isn't the flash 128 bits wide in STM32?)  And of course you are also paying a significant power penalty when the flash moves off-chip.

I don't see much point in running code from flash on an iMXRT.  All of the applications I have in mind would treat the part more like an FPGA:  Load the program into internal RAM at boot time, and run from there.

[techman-001]

I never thought I'd see this happen so soon:

https://media.nxp.com/news-releases/news-release-details/nxp-launches-ghz-microcontroller-era

This beast has a Cortex-M7 core running at 1 GHz and a Cortex-M4 core running at 400 MHz.

Do they have a low power version, you know, one that only draws 5 Amps at 1.8 volts ?

Actually, forget it ....  I'm waiting for the new STM32 with the 50 qubit quantum core so I factor my Primes in 100 seconds instead of having to wait 28 Billion years with a NXP Cortex-M7.

[jhpadjustable]

A lot more MCUs are likely to run from RAM in the next few years, many booted from a local serial flash die in an MCM.

Wouldn't that be stealing intellectual property from China?

No.  "Obvious" and also "Prior Art" (FPGAs loading from serial EEPROM.)

FPGAs, and the EZ-USB FX, too. But there are major details to attend to when the flash is inside a multi-chip package, such useful, patentable details as loading the application code into the flash, copying the application from the flash to the program RAM on startup, and controlling application read/write access according to lock bits and control signals. GigaDevice implemented a serial flash translator emulating the ST embedded flash controller including memory-mapped writes, and got a Chinese patent issued August 2016 on it. I guess other vendors can still use the system ROM.

Great (?) for productivity and time to market, not so good for actual understanding.

Great for lock-in, too. Xilinx can't seem to say no to a walled garden.

[tggzzz]

Let me know when a 1GHz beast is available in QFN or QFP48 

1000MIPS, 64 pin tqfp. Other packaging available. Other memory, interface, and i/o options available.
https://www.digikey.co.uk/product-detail/en/xmos/XUF208-256-TQ64-I10/XUF208-256-TQ64-I10-ND/5401103

If you want more horsepower...

2000MIPS, 128 pin tqfp. Other packaging available. Other memory, interface and i/o options available.
https://www.digikey.co.uk/product-detail/en/xmos/XLF216-512-TQ128-I20/XLF216-512-TQ128-I20-ND/5148715

4000MIPS, 374 pin fpga. Other packaging available. Other memory, interface and i/o options available.
https://www.digikey.co.uk/product-detail/en/xmos/XEF232-1024-FB374-C40/880-1107-ND/5358020

[tggzzz]

If you want a flash based MCU the flash brings severe speed constraints, even if paired with a reasonable amount of cache. Use ROM or RAM for the code and gigahertz MCUs are not a problem. A lot more MCUs are likely to run from RAM in the next few years, many booted from a local serial flash die in an MCM. While most MCU applications only need the MCU to run at a few megahertz, a lot of potential applications open up if you can get cheap MCUs that will compute fast enough to do some serious signal processing.

1MByte flash 1000MIPS, no cache to get in your way, nowhere near the top of the range.
https://www.digikey.co.uk/product-detail/en/xmos/XUF208-256-TQ64-I10/XUF208-256-TQ64-I10-ND/5401103

When you hit a brick wall, change direction!

[donotdespisethesnake]

If you want a flash based MCU the flash brings severe speed constraints, even if paired with a reasonable amount of cache. Use ROM or RAM for the code and gigahertz MCUs are not a problem. A lot more MCUs are likely to run from RAM in the next few years, many booted from a local serial flash die in an MCM. While most MCU applications only need the MCU to run at a few megahertz, a lot of potential applications open up if you can get cheap MCUs that will compute fast enough to do some serious signal processing.

1MByte flash 1000MIPS, no cache to get in your way, nowhere near the top of the range.
https://www.digikey.co.uk/product-detail/en/xmos/XUF208-256-TQ64-I10/XUF208-256-TQ64-I10-ND/5401103

When you hit a brick wall, change direction!

Not sure it's a direction many people will want to go:

6.1 Logical cores
The tile has 8 active logical cores, which issue instructions down a shared five-stage
pipeline. Instructions from the active cores are issued round-robin. If up to five
logical cores are active, each core is allocated a fifth of the processing cycles. If
more than five logical cores are active, each core is allocated at least 1
/n cycles
(for n cores). Figure 3 shows the guaranteed core performance depending on the
number of cores used.
Speed MIPS Frequency Minimum MIPS per core (for n cores)
grade 1 2 3 4 5 6 7 8
5 500 MIPS 500 MHz 100 100 100 100 100 83 71 63
Figure 3:
Logical core
performance
There is no way that the performance of a logical core can be reduced below these
predicted levels (unless priority threads are used: in this case the guaranteed
minimum performance is computed based on the number of priority threads
as defined in the architecture manual). Because cores may be delayed on I/O,
however, their unused processing cycles can be taken by other cores. This means
that for more than five logical cores, the performance of each core is often higher
than the predicted minimum but cannot be guaranteed.

[Sal Ammoniac]

Not sure it's a direction many people will want to go:

They seem to be focused on audio applications, which fits well with their architecture. Higher data rates, such as SDR applications, are probably better served by FPGAs.

[tggzzz]

If you want a flash based MCU the flash brings severe speed constraints, even if paired with a reasonable amount of cache. Use ROM or RAM for the code and gigahertz MCUs are not a problem. A lot more MCUs are likely to run from RAM in the next few years, many booted from a local serial flash die in an MCM. While most MCU applications only need the MCU to run at a few megahertz, a lot of potential applications open up if you can get cheap MCUs that will compute fast enough to do some serious signal processing.

1MByte flash 1000MIPS, no cache to get in your way, nowhere near the top of the range.
https://www.digikey.co.uk/product-detail/en/xmos/XUF208-256-TQ64-I10/XUF208-256-TQ64-I10-ND/5401103

When you hit a brick wall, change direction!

Not sure it's a direction many people will want to go:

Youngsters will have to change direction during their career. The xCORE devices are currently the best starting point in a solid different direction. They won't be the end word, but I've yet to see better.

I'm looking for alternatives, but haven't seen anything interesting.

6.1 Logical cores
The tile has 8 active logical cores, which issue instructions down a shared five-stage
pipeline. Instructions from the active cores are issued round-robin. If up to five
logical cores are active, each core is allocated a fifth of the processing cycles. If
more than five logical cores are active, each core is allocated at least 1
The point of the post was to illustrate that coppice's contention wasn't
/n cycles
(for n cores). Figure 3 shows the guaranteed core performance depending on the
number of cores used.
Speed MIPS Frequency Minimum MIPS per core (for n cores)
grade 1 2 3 4 5 6 7 8
5 500 MIPS 500 MHz 100 100 100 100 100 83 71 63
Figure 3:
Logical core
performance
There is no way that the performance of a logical core can be reduced below these
predicted levels (unless priority threads are used: in this case the guaranteed
minimum performance is computed based on the number of priority threads
as defined in the architecture manual). Because cores may be delayed on I/O,
however, their unused processing cycles can be taken by other cores. This means
that for more than five logical cores, the performance of each core is often higher
than the predicted minimum but cannot be guaranteed.

The point of the post was to illustrate that coppice's contention wasn't strictly correct.

The IDE calculates the maximum number of processor cycles to get from here to there in your application. That includes the effects of compiler optimisation and the number of cores in use. It doesn't need to take account of variations due to caches and interrupts, because there aren't any.

All other MCUs I've seen require max time to be measured, while keeping your fingers crossed that you have blundered across the worst case.

[tggzzz]

Not sure it's a direction many people will want to go:

They seem to be focused on audio applications, which fits well with their architecture. Higher data rates, such as SDR applications, are probably better served by FPGAs.

I'd use an FPGA for SDR applications too!
There will always be applications that are outside any processor's computational capabilities; boring
There will always be the tension embodied in Amdhal's law.

However, the xCORE devices are halfway between conventional MCUs and FPGAs:

• very FPGA-like IO structures, e.g. 250Mb/s SERDES, strobed interfaces
• very FPGA-like control flow, e.g. wait for any of N conditions (e.g. timeout, i/o complete, message tx/rx) and resume computation on the next clock cycle
• very FPGA-like timing guarantees. Each i/o port contains a timer, allowing output to be setup to occur on a specific clock cycle, or the capture the clock cycle when input arrived
• very FPGA-like clocking: multiple clocks at different frequencies
• very FPGA-like solution composition: multiple simultaneous non-interfering processing, communicating results where necessary

As a demonstration of "kicking the tyres" I was able to count use software alone to guarantee counting all the transitions on two 62.5Mb/s input streams. That's not impossible in a standard MCU, but I'd like to see someone guarantee that when front panel-i/o and USB comms is occurring at the same time.

The whole process was delightfully simple; the hardware and software manuals were short and accurate - with neither errata nor gotchas.

[nctnico]

Not sure it's a direction many people will want to go:

They seem to be focused on audio applications, which fits well with their architecture. Higher data rates, such as SDR applications, are probably better served by FPGAs.

I'd like to add that controllers like these are another nail in the coffin of typical DSPs.

[MT]

This blends the line between MCUs and MPUs and not in a good way. It makes no sense to me. Programming and hardware design for something like this is not at all like for typical MCUs. So why not just put Cortex-A5 at that point?

I guess NXP sees some market for this, but I just don't get it. There is no need for the clock frequency race in the MCU world, I'd rather see companies put out better peripherals.

There are a big and multiple markets for speed, audio is one, images another. I look forward to even more speed, more cores and smaller pin packages and for ST they really have to fix their pin mapping mess!