ebenupton

Cortex-M33 timings aren't documented, but one of our security consultants has made a lot of progress reverse engineering them to support his work on trace stacking for differential power analysis of our AES implementation. I've asked him to write this up to go in a future rev of the datasheet.

No official 48 GPIO board, I think: this is slightly intentional because it creates market space for our partners to do something.

It's a fair comment. Give our VSCode extension a go: the aspiration is to provide uniform developer experience across Linux, Windows, and MacOS.

Signed boot. Unless someone at DEF CON wins our $10k bounty of course.

Significant improvements to flat-out power (switcher vs LDO) and to idle power (low quiescent current LDO for retention). Still not a coin-cell device, but heading in the right direction.

Thank you. It's been a major effort from the team, and I'm very proud of what they've accomplished.

It's actually 10 masters (I+D for 4 cores + DMA read + DMA write) versus 6 masters. Or you could pre-arbitrate each pair of I and each pair of D ports. But even there the timing impact is unpalatable.

That's correct. The Arm and RISC-V cores are entirely separate, sharing no logic.

We did look at this, but the AHB A-phase cost of putting a true arbiter (rather than a static mux) on each fabric port was excessive. Also, there's a surprising amount of impact elsewhere in the system design (esp debug).

It has: you can encrypt your code, store a decryption key in OTP, and decrypt into RAM. Or if your code is small and unchanging enough, store it directly in OTP.

It's aliiiiiive!

It is true ROM.

As did Graham Sanderson, whose Easter egg this is.

No - the Model A is still 256MB.