> Why did they go with the 64 bit Arm core
ARM Cortex-M33 is a 32-bit core, not 64-bit.
They haven't gone with a 64Bit ARM core. The ARMv8*M* isn't 64bit unlike ARMv8R and ARMv8A (the nomenclature can get confusing). The differences between ARMv7M (especially with the optional DSP and FPU extension) and ARMv8M mainline are fairly minor unless you go bigger with an M55 or M85 which (optionally) adds the Helium SIMD extension. At he low end ARMv8M baseline adds a few quality of life features over ARMv6M (e.g. the ability to reasonably efficiently load large immediate values without resorting to constant pool). Also the MPU got cleaned up to make it a little less annoying to configure.
Thanks for the clarification. Confusing terminology!
ARMv8A and ARMv8R can both be pure 32 bit as well, incidentally -- e.g. Cortex-A32 and Cortex-R52. v8A added 64 bit, but it didn't take away 32 bit. It's not until v9A that 32 bit at the OS level was removed, and even there it's still allowed to implement 32 bit support for userspace.
Not 64 bit, it’s 32-bit cortex m33.
M33 has, among other things, TrustZone. So there’s some feature, along with developer familiarity and tools that make ARM desirable for an application processor.
Mixed architecture doesn’t really cause any significant problems.
The design is fully custom in-house design.
Does having mixed architectures cause any issues, for example in developer tools or build systems? (I guess not, since already having 32 vs 64 bit cores means you have effectively a "mixed architecture" even if they were both Arm or RISC-V)
What's the RISC-V core derived from (eg. Rocket Chip? Pico?) or is it their own design?