Microchip's ARM MCU

[Sal Ammoniac]

Microchip has a new MCU based on the ARM Cortex-M4. It appears to be targeted to cryptographic applications.

http://www.microchip.com/wwwproducts/en/CEC1302

Is this something they inherited from Atmel, or is it a sign that Microchip might be moving away from MIPs and embracing ARM?

[jnz]

Well, that's at least ONE smart thing Microchip has done in the past... However many years now. Not that I would EVER go back to them.

I'm sure it has a lot to do with them buying Atmel.

Not sure what they're talking about on the prive and shared busses or crypto stuff, but it's Microchip, so I don't really care to find out. One good step, but they have about a million more to make for me to put them on equal footing with STM/NXP/TI/etc.

[nctnico]

IMHO it is a big fail. Cortex M4 at 48MHz External flash required Only commercial temperature range 

[ade]

Look at the peripheral feature set...  TACH counter, PWM-RPM fan controller, keyboard scan interface, LED blinking circuit...

It seems this MCU was originally designed as a keyboard / auxiliary controller for laptops.

[Kjelt]

This is not a standalone master microcontroller it is an add on security coprocessor just like Infineon and Maxim to name a few has lots of.
Its purpose is to boot and verify the code before the master micro boots from it, look at terms like chain of trust and hardware trust anchor, this is such an anchor. 

It communicates with the system host using the I2C bus.

That is the only big fail for me 

[nctnico]

If it is just a co-processor it still leaves the question why a Cortex M4 CPU is needed to manage some DMA transfers.

[jnz]

If it is just a co-processor it still leaves the question why a Cortex M4 CPU is needed to manage some DMA transfers.

Exactly what I was wondering... but... Here we are talking about it. What does that say about the non-arm Microchip line up that wouldn't have even slightly gained a second look?

In actual seriousness, dumping MC and going to ARM was so good for my mental health!

[westfw]

This sounds like something from the SMSC portfolio; didn't they do various support chipsets?

On the bright side, I guess the merger is over.  I got the following notice from my brokerage:

Wed Apr 06 00:04:33 2016 Corporate Actions Notice  
Account Number: XXXX-yyyy
 
ATML has merged with MCHP. Each share of ATML has been exchanged with 0.02 shares of MCHP and $7.00 per share. Your positions and tax records will be updated to reflect this change. This notice is for your information only and no action is required by you.

[andersm]

It was only last year they launched the MEC140x/1x line, which uses the MIPS M14K core.

[Jeroen3]

There is not that much choice in encryption mcu's. At least not freely available.
It looks indeed like this was intended as low level processor in a larger system. With 4 SMBUS ports and fan inputs/control.

It has an M4 for the floating point unit.

[Kjelt]

If it is just a co-processor it still leaves the question why a Cortex M4 CPU is needed to manage some DMA transfers.

Because it has to verify (read and calculate a digital signature and/or decrypt at the fly) the program and or data and or boot memory, then reset and start the host microcontroller. So speed is urgent , the user is waiting!
There are lots of applications with these chips btw , some from infineon can set up an entirely secure tls connection standalone and after the handshake decrypt the data and sent it back to the host.
Just to name a few for those interested:

Maxim: Maxq1050, DS28E35
Inside secure: VaultIC 4x0 (x=2,4,6)
Atmel: ATECC508A, also other copros doing AES, SHA etc.
ST: SAFE
Infineon: Optiga series TPM's and secure access modules (SAM) etc.

[Kleinstein]

A 48 MHz maximum clock is not really much for a µC running code from RAM.  Especially for a security product I would prefer having the code in the on chip flash, like many other ARM µCs do it. Also a simpler µC might be more reliable - who needs an FPU for encryption ?

There might be a need for this chip - but I don't see it. So for me this looks more like a not so promising chip.

[nctnico]

If it is just a co-processor it still leaves the question why a Cortex M4 CPU is needed to manage some DMA transfers.

Because it has to verify (read and calculate a digital signature and/or decrypt at the fly) the program and or data and or boot memory, then reset and start the host microcontroller. So speed is urgent , the user is waiting!

And how is it going to do things fast at 48MHz? It seems to me the DMA is there do shuffle data around between the crypto hardware and the external interfaces. If a 48MHz CPU has to to operations on a large amount of data it is going to be the bottleneck.

[ade]

Interesting note from the datasheet:

[Kjelt]

And how is it going to do things fast at 48MHz? It seems to me the DMA is there do shuffle data around between the crypto hardware and the external interfaces. If a 48MHz CPU has to to operations on a large amount of data it is going to be the bottleneck.

I am not aware of this particular microcontroller but to give another example some of these external crypto coprocessors have a 1024bit hardware multiplier onboard an can do ECC calculations at 10MHz even 10 times faster than a 120MHz Cortex M4. So clock frequencies are not everything in crypto country.
But your example of the copro being a throughput for encrypted data, yes it will be the bottleneck but than encrypted data is always the bottleneck
What this chip could do is not decrypt the data and act as a throughput to the host but just check the integrity and confidentiality of the external data by calculating a digital signature across the data, if it matches with the stored signature it can give a green signal to the microcontroller to start booting and decrypting the code itself, hence no bottleneck.