Archive

Posts Tagged ‘arm’

Moly PcPhone Runs Windows 10 Continuum on Qualcomm Snapdragon 617 Processor, Costs Less than $400

May 9th, 2016 2 comments

Mobile and PC convergence is slowly happening both on Ubuntu with devices like BQ Aquaris M10 Ubuntu Edition tablet, and various Windows 10 Continuum smartphones. The most affordable offering is likely to come from mainland China vendors, such as Moly PcPhone 6″ smartphone based on Qualcomm 617 octa-core Cortex A53 processor with 3GB RAM, and running Windows 10 Continuum.

Moly_PcPhoneMoly PcPhone specifications:

  • SoC – Qualcomm Snapdragon 617 Octa core Coretex A53 processor @ 1.5 GHz with Adreno 405 GPU
  • System Memory – 3 GB RAM
  • Storage – 32 GB flash + micreo SD slot up to 200 GB
  • Display – 6″ Full HD (1920×1080) LTPS display; Gorilla Glass 3
  • Cellular Connectivity
    • Dual SIM Dual Standby, Adaptive SIM Slot
    • 2G GSM: Band 2/3/5/8
    • 3G WCDMA: Band 1/6/8/9/19
    • 4G FDD-LTE: Band 1/2/3/4/7/8/9/19/26/28B
    • 4G TDD-LTE: Band 38/40/41
  • Wireless Connectivity – Wi-Fi: 802.11 a/b/g/n/ac, Bluetooth 4.0, and NFC
  • Camera – 13MP auto-focus rear camera with flash LED, 5MP front-facing camera
  • USB – 1x micro USB 2.0 OTG port
  • Sensors – G-sensor, PS sensor, Ambient Light sensor,E-Compass
  • Misc – Volume and power keys; FM radio
  • Battery – 3,900 mAh (non replaceable)  good for 400 hours on standby, 16 hours of 3G talk time
  • Dimensions – 160 x 82.3 x 79 mm
  • Weight – 176 grams

Windows_10_Continuum_ARM_China

The phone runs Windows 10 Mobile with Continuum,  Office apps, Outlook, Skype, Adobe Reader, OneDrive, OneNote, and Microsoft Edge. The phone does not features a USB type C port, nor MHL  support, so that means the only way to use it as a computer is to get a WiDi dongle such as ScreenBeam mini 2 to connect the smartphone to your TV or monitor over WiFi. Charbax filmed a demo of the system connected over a WiDi dongle, and everything worked pretty well, except possibly the PowerPoint presentation animations were not especially smooth.

Bear in mind that only a subset of apps will work with Continuum, and if you intend to print the printer must be compatible with Windows 10 Mobile.

The goods news is that Moly PcPhone should cost less than $400 retail, adding a $60 WiDi will bring the total to $450 to have a device acting as both your phone and computer. More details cmay be available on Moly PcPhone website.

Via ARMDevices.net

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

Open Source Mali-200 / Mali-400 GPU Lima Driver Gets New Commits

April 3rd, 2016 6 comments

The Lima driver, a project aimed at providing an open source driver for ARM Mali-400 and Mali-200 GPUs, was introduced 4 years ago, and after some reverse engineering work, a Quake 3 demo was showcase later in 2013 with an intermediate version of the Lima drivers. However, the main developer (libv) eventually lost interest or lacked time to further work, and the latest commit was made in June 9, 2013. But another developer (oklas) committed some code to limadriver-ng just a few days ago.

Lima_Driver_Pull_RequestBut don’t get too excited, as the modifications are minor with some build fixes, some other Makefile modifications, and only one C file modified with 6 new lines of code. But maybe that’s just the beginning… We’ll see.

Mali-400 GPU is now rather old, so why would somebody work on this? One explanation could be C.H.I.P and Pine A64 boards are both based on Allwinner SoCs with a Mali-400 GPU, but a more likely explanation is that libv invited new developers on limadriver.org:

2015-12-20: this project looking for developers, if you’d like to try, come to our IRC #lima :)

So we’ll have to see how this all turns out, and if somebody is indeed motivated on working on the port. If so, C.H.I.P and Pine A64 boards, as well as other Mali-400 based platforms, could get open source GPU drivers.

Thanks to Luka via Reddit, where you can find some more details about the timeline.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

M2.COM is a Standard for IoT Sensors Based on M.2 Form Factor

March 25th, 2016 No comments

The IoT ecosystem really feels like a jungle now, not because of a lack of standards, but because everybody thinks about doing their own, so we’ve ended up with a wide range of communication protocols, initiatives, and consortia, and it will take some time until the winners and losers are sorted out. One the of the latest standard is M2.COM platform form factor for sensors that “adopts the standardized M.2 form factor and is defined as an evolutionary module that combines general wireless connectivity with additional built-in computing ability powered by MCU”.

M2.COM_ArchitectureM2.COM architecture diagram above describes both software and hardware requirements, but the specifications themselves only define the form factor, as well as mechanical and electrical characteristics:

  • Consistent with M.2 standard
    • Module size: 22 mm x 30 mm
    • PCB thickness: 0.8 mm ± 10%
    • Pin count: 75 pins
    • Module input voltage: 3.3V DC-in
    • Connector mating force: 30N Maximum
    • Connector current rating: 0.5A / Power contact
    • Connector operation temperature range: -45°C to +85°C
  • Suitable pin definitions for IoT solution
    • USB – A common interface for extending storage
    • SDIO – Another common interface for extending storage through SD/MMC
    • I2C – The most popular interface for sensors. Ex: pressure sensor, temperature sensor, moisture sensor and lightning sensor
    • I2S – Supports audio codec for broadcasting and playing audio through external speakers
    • UART – A commonly used protocol for device control, such as for motor and electric control units
    • GPIO – Basic I/O control, such as indicating lights, alarm and buzzer
    • SPI – Supports LCM to display values collected from the sensor or transmitted by an external device
    • ADC – Common pins of GPIO, the ADC transforms the analog signal from the sensor into a digital signal so that data can be readable and meaningful to the data analyzer

M2.COM_Architecture_2

So the idea is basically to be able to exchange one M2.COM compliant module with another one with better features or a lower cost as needed. You can download the specifications 1.0, design guide, and mechanical information on M2.COM website.

Companies behind the initiative include ARM, Advantech, Bosch, Texas Instruments, and Sensirion. Two products compliant with the standard are currently available: Advantech WISE-1520 M2.COM module and the corresponding WISE-DB1500 carrier board / development board using pico-ITX form factor (100 x 72 mm).

M2COM_module

Advantech M2.COM Module and Carrier Board

WISE-1520 M2.COM module specifications:

  • SoC – Texas Instruments CC3200MOD Cortex-M4 MCU with 256KB RAM, 1MB flash
  • Connectivity – 802.11 b/g/n @ 2.4 GHz up to 16Mbps (UDP)
  • I/O interfaces – 1x 4-wire UART, 1x I2C, 2 GPIOs, 2x PWM, 1x SPI, 2x ADC as per the specs (but no USB)
  • Debug Port – 1x developer and debug port.
  • Power – 3.3V
  • Dimensions – 30 x 22 mm – M.2 type 2230-D3-E form factor
  • Weight – 3 grams

The module runs TI RTOS or ARM mbed OS, and supports multiple IoT communication protocols including LWM2M, OSGI, AllJoyn and MQTT. Software documentation and SDK do not appear to be available publicly.

The development board features a M.2 socket and brings out an SD card slots, expansion headers, a RS-232/422/485 DB9 connector, and a micro USB OTG port, as well as an on-board  humidity & temperature sensor.

You can find out more about Advantech solution on M2.COM product page.

Via Embedded.com

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

Telechips TCC898x (Alligator) 64-bit ARM SoC is Designed for High-end 4K Set-Top Boxes

March 18th, 2016 2 comments

Telechips processors were often found in consumer devices such as Android tablets, mini PCs and TV Sticks a few years ago, but it’s been a while since I have seen a devices based on Telechips. So after seeing an automotive SoC from the company, I decided to visit the company website to check if they were still designing processors for the consumer market, and found TCC898x quad core Cortex A53 processor for “Smart Stick, IP-Client and STB with 4K 60fps decoding” with some interesting features.

Telechips_TCC8980Telechips TCC898x SoC specifications:

  • CPU- Quad core Cortex A53 processor with NEON, TrustZone, 32KB/32KB L1 cache and 512KB L2 cache
  • MCU – Cortex-M4 micro-controller
  • GPU
    • 2D – Vivante GC420 composition processing core for 4K user interfaces
    • 3D – ARM Mali-400MP2
  • VPU – Multi-format VPU and 4K VPU with HEVC and VP9 support
  • Memory I/F – DDR3/4
  • Storage I/F – NAND controller (60-bit ECC), SD/eMMC controller
  • Peripherals
    • Video Output – Display Controller, LVDS transmitter, HDMI 2.0 with HDCP 2.x, video composite
    • Video Input – Yes, but no details.
    • Audio – S/PDIF Tx and Rx, 9.1 channels I2S , stereo I2S
    • USB – USB 2.0 host, USB 2.0 OTG, USB 3.0
    • Gigabit Ethernet MAC
    • TS and TS demux (normally used to interface tuners)
    • PCIe interface
    • I2C, UART, GPSB (General Purpose Serial Bus), SDIO
    • Timer/RTC, DMA, IR receiver

The overall concept is pretty similar to their Telechips TCC893x Cortex A9 + Cortex-M3 processor, except most items have been upgraded, except notably the 3D GPU which remains a Mali-400MP2.

Telechips TCC898x supports Linux (with HTML5 interface) and Android operating systems, and contrary to most other Android TV boxes and set-top boxes, devices based on the new processor will support 4K user interfaces too thanks to Vivante GC420 2D GPU.  The chip also support hardware cyphers and conditional access (CAS) for “full compliance with 4K contents security guideline for variable STB applications”. I could not find much more information, and Googling for TCC8980 processor (and others up to TCC8989) did not return anything interesting so far. The last update to Telechips open source page shows the company released Linux 3.4.45 source code in February 2015.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

Linux 4.5 Released – Main Changes, ARM and MIPS Architectures

March 15th, 2016 1 comment

Linus Torvalds released Linux Kernel 4.5 on Sunday:

So this is later on a Sunday than my usual schedule, because I just couldn’t make up my mind whether I should do another rc8 or not, and kept just waffling about it. In the end, I obviously decided not to,but it could have gone either way.

We did have one nasty regression that got fixed yesterday, and the networking pull early in the week was larger than I would have wished for. But the block  layer should be all good now, and David went through all his networking commits an extra time just to make me feel comfy about it, so in the end I didn’t see any point to making the release cycle any longer than usual.

And on the whole, everything here is pretty small. The diffstat looks a bit larger for an xfs fix, because that fix has three cleanup refactoring patches that precedes it. And there’s a access type pattern fix in the sound layer that generated lots of noise, but is all very simple in the end.

In addition to the above, there’s random small fixes all over-shortlog appended for people who want to skim the details as usual.

Go test, and obviously with 4.5 released, I’ll start the merge window for 4.6.

Linux 4.4 added support for a faster and leaner loop device, 3D support in virtual GPU driver, TCP improvements, various file systems improvements for BTRFS, EXT-4, CIFS, XFS etc… Some notable changes made to Linux 4.5 include:

  • Copy offloading with new copy_file_range(2) system call – Performance improvements on local file systems are marginal, but for networked file systems such as NFS, you could copy a file internally on a server drive without transferring file data over the network.
  • Experimental PowerPlay for amdgpu driver
  • Btrfs free space handling scalability improvements – New, experimental way of representing the free space cache that takes less work overall to update on each commit and fixes the scalability issues for large drives (30TB+). It can be enabled with -o space_cache=v2 mount option, and you can revert to the one method with -o clear_cache,space_cache=v1.
  • Support for GCC’s Undefined Behavior Sanitizer (-fsanitize=undefined) UBSAN (Undefined Behaviour SANitizer) is a debugging tool available since GCC 4.9. It inserts instrumentation code during compilation that will perform checks at runtime before operations that could cause undefined behaviors. Linux 4.5 supports compiling the kernel with the Undefined Behavior Sanitizer enabled.
  • Next gen media controller whose “goal is to improve the media controller to allow proper support for other types of Video4Linux devices (radio and TV ones) and to extend the media controller functionality to allow it to be used by other subsystems like DVB, ALSA and IIO”. See lkml for details

Some new features and improvements specific to the ARM architecture:

  • Allwinner:
    • Allwinner A80 support – IR receiver driver, NMI controller,PRCM driver, R_PIO support, and RSB driver
    • Allwinner H3 SoC support – H3 USB PHY clocks
    • A10/A20 Video Engine clocks
    • MIC1 capture for sun4i codec
    • Audio codec enabled on various boards
    • Added board – Orange Pi Plus
  • Rockchip:
    • Crypto module and io-domain driver enabled in multi_v7_defconfig
    • Tweaks for RK3368 SoC and eval board
    • Added Rockchip RK3228 SoC and eval board
    • New RK3228 subdriver in pinctrl
    • SPI driver fix
    • Added support for RK3399 in thermal driver
    • RK3036: Added SMP support, emac support
    • Expose USB PHY PLLs
  • Amlogic
    • Device tree changes – Add watchdog node to meson8b, add status LED for ODROID-C1
    • Watchdog timer modifications
  • Samsung
    • eMMC/SDIO minor fixes usage of bindings on Snow and Peach chromebooks.
    • Remove FIMD from Odroid XU3-family because on XU3 it cannot be used yet and on XU3-Lite and XU4 it is not supported.
    • Remove deprecated since June 2013 samsung,exynos5-hdmi.
    • Add support for Pseudo Random Generator on Exynos4 (Trats2 for now). This depends on new SSS clock.
    • Add rotator nodes for Exynos4 and Exynos5.
    • Switch DWC3_1 on Odroid XU3 and XU3-Lite to peripheral mode because  now it cannot be used as OTG.
    • Cleanup the G2D usage on Exynos4 and add it to a proper domain in case of Exynos4210.
    • Put MDMA1 in proper domain on Exynos4210 as well.
    • Minor cleanups
  • Qualcomm
    • New pinctrl subdrivers for Qualcomm MSM8996, PM8994,  PM8994 MPP support
    • Added Qualcomm PCIe controller driver
    • Qualcomm ARM64:  Add fixed rate oscillators to dts, fixup PMIC alias and properties, change 8916-MTP compatible to be compliant with new scheme, fix 8×16 UART pinctrl configuration, add SMEM, RPM/SMD, and PM8916 support on MSM8916
  • ARM SoC multiplatform code – “This branch is the culmination of 5 years of effort to bring the ARMv6 and ARMv7 platforms together such that they can all be enabled and boot the same kernel”
  • ARM64 – hugetlb: add support for PTE contiguous bit; perf: add support for Cortex-A72;
  • Other new hardware or SoCs – Sigma Designs ARM Cortex-A9 Tango4 “Secure Media Processor” platforms (SMP8756, SMP8758, and SMP8759), TI-based DM3730 from LogicPD (Torpedo), Cosmic+ M4 (nommu) initial support (Freescale Vybrid), Veyron-mickey (ASUS Chromebit), BCM2836 and Raspberry Pi 2 B.

MIPS changes:

  • Add support for PIC32MZDA platform
  • bcm963xx: Add Broadcom BCM963xx board nvram data structure
  • dts: Add initial DTS for the PIC32MZDA Starter Kit
  • math-emu: Add IEEE Std 754-2008 ABS.fmt and NEG.fmt emulation
  • math-emu: Add IEEE Std 754-2008 NaN encoding emulation
  • math-emu: Add IEEE Std 754 conformance mode selection
  • pci: Add MT7620a PCIE driver
  • ralink: add MT7621 support
  • zboot: Add support for serial debug using the PROM

If you want to get the full details, I’ve generated Linux 4.5 Changelog with comments only (12.2MB) using git log v4.4..v4.5 --stat, but it’s probably a better idea to simply check out Linux 4.5 changelog on kernelnewbies.org.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

LeMaker Cello 96Boards EE Board Powered by AMD Opteron A1120 Processor Targets Server Applications

March 7th, 2016 14 comments

There are two versions of Linaro’s 96Boards specifications the Consumer Edition (CE) and the Enterprise Edition (EE) with higher hardware requirements, and while several boards mostly compliant with 96Boards CE are available such as DragonBoard 410c and Hikey boards, the only board announced to be compliant with 96Boards EE specifications was AMD Huskyboard based on Opteron A1100 series processor and is yet to be available for sale. LeMaker has now designed a similar EE boards called Cello.

Lemaker_Cello_AMD_Opteron_A1100_BoardLeMaker Cello board specifications:

  • Processor – AMD Opteron A1120 quad core Cortex A57 processor @ 1.7 GHz with 2MB L2 cache, 8MB L3 cache
  • System Memory – 2x DDR3 SO-DIMM sockets
  • Storage – 2x SATA 3.0 ports, micro SD slot
  • Connectivity – 1x Gigabit Ethernet RJ45 port
  • USB – 2x USB 3.0 ports
  • Expansions
    • x16 PCIe G3 slot
    • 40-pin Low Speed (LE) expansion header
  • Debugging – micro USB port for console access, 10-pin JTAG connector
  • Power Supply – 4-pin power connector
  • Dimensions – 160×120 mm as per 96Boards EE specifications
  • Weight – 500 grams (Package weight)

The board don’t show an heatsink, but the holes are there, and considering the SoC has a whopping 25W TDP, an heatsink and likely fan will likely be required. There’s also no information about operating systems, but the latest Linaro Reference Platform release for Enterprise supports Debian 8.3 and an image based on Centos 7.2, as well as UEFI with ACPI, KVM and PCIe support.

96boards_EE_BoardThe board can be pre-ordered for $299 on LeMaker Cello product page with shipping schedules for Q2 2016.

Via Mininodes

[Update: So I’ve been watching Linaro BKK 2016 keynote, and there was a demo with Huskyboard (similar to Cello featured in that post) running the developer preview of Red Hat Enterprise Linux Server release 7.2 (MaiPo). That’s what the board is supposed to look like with a heatsink and fan. They’ve also added a PCIe network card to show that PCIe is also working

Click to Enlarge

Click to Enlarge

]

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

64-bit ARM (Aarch64) Instructions Boost Performance by 15 to 30% Compared to 32-bit ARM (Aarch32) Instructions

March 1st, 2016 12 comments

Yesterday was quite an eventful day with the launch of two low cost 64-bit ARM development boards, namely Raspberry Pi 3 and ODROID-C2, and as usual there were some pretty interesting discussions related to the launch of the boards in the comments section. One of the subject that came is that while Raspberry Pi 3 board is using a 64-bit processor, the operating systems are still compiled with 32-bit instructions (Aarch32) and even optimized for ARMv6, and they intend to keep it that way according to Eben Upton interview:

Eben readily admits that not all the capabilities of the new parts are going to be used at launch, however. “Although it is a 64‑bit core, we’re using it as just a faster 32-bit core,” he reveals about the Pi 3’s central processing unit. “I can imagine there’d be some real benefits [to 64-bit code]. The downside is that you do really create a separate world. To access that benefit, you’d have to have two operating systems. I’m hoping that someone will come and demonstrate to me that this is a good idea. But there are some really compelling advantages to still being basically ARMv6, and because it’s [Cortex-]A53 it’s a really good 32‑bit processor.”

So the clear advantage of running ARMv6 32-bit code is that a single image can be used for all Raspberry Pi boards, while of they had to optimize code for each board, they’d have one image for Raspberry Pi (ARMv6), one for Raspberry Pi 2 (ARMv7), and a final one for Raspberry Pi 3 (ARMv8), and obviously that would require a lot of work behind the scene. In theory, there should be a performance advantage of running 64-bit ARM instructions, but the question is how much?

ARM brings some perspective to performance improvement in their presentation “ARMv8: Advantages for Android”  where they compare performance improvements of Aarch64 (64-bit ARM instructions) over  Aarch32 (32-bit ARM instructions) running benchmarks compiled with either instructions set on Juno development board.

Click to Enlarge

Click to Enlarge

The first charts show native (C/C++ code) performance is between 15% to about 20% faster in bionic benchmarks, and Antutu 5.0 single thread and multi-thread CPU tests.

Click to Enlarge

Click to Enlarge

The second chart shows ART (Java runtime) performance is also about 15% better with Aarch64 using Quadrant 2.0 CPU score, and close to 30% faster with Linpack multi-threaded benchmark.

Broadcom BCM2837 processor’s Cortex A53 cores are likely to be further impacted since they are running a code compiled for the older ARMv6, which is slower than ARMv7. Let’s take another fun example. Raspberry Pi 3 benchmarks released on MagPi reveal sysbench completes in 49.02 seconds for multi-threaded CPU test, and tkaiser, an active developer for armbian project, ran sysbench on Pine A64 development on Ubuntu 16.04 64-bit, and the results are quite surprising considered Allwinner A64 is also a quad core Cortex A53 processor @ 1.2 GHz:

So it took only 3.25 seconds on Pine A64 with ARMv8 instructions compared to 49.02 seconds on Raspberry Pi 3 with ARMv6 instructions, so it appears that if you are specifically looking for prime numbers it does pay big time (15 times faster) to switch to Aarch64 instructions. Bear in mind that Sysbench command line benchmark has options that can affect the results, and sadly we don’t have  the exact command line use for Raspberry Pi 3, but they’ve most likely used the default options as above (maximum prime number: 10,000), since another person ran the benchmark with 20,000 max on RPi3, which completed in around 119 seconds.

Which specific improvements of ARMv8 may bring the extra performance? Reader and commenter “Blu” explains:

Well, for one, compiler’s autovectorization actually works with aarch64 NEON, whereas in armv7 you had mostly to rely on manual vectorization via inline asm. Another big win is the twice-larger GPR & FPR files (when it comes to fp64: D16 -> D32), largely reducing register pressure in compiled (and not only) code. Last but not least, recent compilers have been more focused on AArch64, where they could produce better code vs armv7 not so much because of hw resource discrepancies, but because more man-effort went into AArch64 backends (and the arch provides a bunch of small tweaks that make compiler writer’s lives easier).

To sum it up, one can observe a significant speedup from armv7 to AArch64 for both objective (i.e. larger hw resources) and subjective (i.e. greater man-effort) reasons.

Now the Raspberry Pi 3 is not the only platform to use 32-bit operating systems, as most Android devices and boards I’ve tested so far, excluding DragonBoard 410c combine a 64-bit kernel with 32-bit user space. ODROID-C2 board, however, will support with Ubuntu 16.04 64-bit ARM (aka ARM64).

There’s however a side effect of compiling code with 64-bit instructions, the size gets bigger. Another reader “Jon” compiled code for Rockchip RK3128 Cortex A7 processor (ARMv7/32-bit) and Pine A64 Cortex A53 processor (ARMv8/64-bit), and found some large differences in memory size.

Binary ARMv7 Size (Bytes) ARMv8 Size (Bytes) Ratio
libcrypto.so  1,052,920  1,673,400  1.59x
toolbox Android 5.1  150,836  255,280  1.69x

So in case you are really tight on storage or memory, 32-bit code might be a better option.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

ARM Unveils Ultra-efficient Cortex-A32 32-bit Processor Based on ARMv8 Architecture

February 23rd, 2016 1 comment

So far you could safely equate 64-bit ARM processors with ARMv8 architecture. Not anymore. A few months after introducing Cortex A35 low power ARMv8 64-bit processor, ARM has now announced Cortex-A32 processor, even more power efficient, support ARMv8-A architecture, and designed for 32-bit embedded and IoT applications.

ARM_Cortex_A32Key features of Cortex-A32 cores:

  • Architecture – ARMv8-A (AArch32)
  • Multicore – 1-4x SMP within a single processor cluster, and multiple coherent SMP processor clusters through ARM AMBA 4 ACE, AXI 4 or AMBA 5 CHI technology
  • ISA Support
    • A32+T32 with full backward compatibility with ARMv7-A
    • ARM TrustZone security technology
    • ARM NEON Advanced SIMD
    • DSP & SIMD extensions
    • VFPv4 Floating point
    • Hardware virtualization support
  • Debug & Trace – ARM CoreSight DK-A32

So they’ve got rid of AArch64 instruction set out of ARMv8 architecture in order to improve power efficiency, while keeping the 100 new instructions part of Aarch32 to improve performance, and keeping ARMv7-A compatibility.

Cortex_A32_Instruction_Set

ARM also claims the performance will be the same as Cortex A35, and close to Cortex A9, with gains in integer workload efficiency of respectively 10, 25, and 30% over  Cortex A35, Cortex A7, and Cortex A5. Thanks to the lack of 64-bit support, Cortex A32 is also 13% smaller than Cortex A35.

Cortex-A32_PerformanceCortex-A32 can also be used in configurations optimized for either performance and power consumption. At the top ends of the spectrum, a quad core Cortex A32 processor @ 1.0+ GHz with FPU + NEON + Crypto engine, and 2x 32KB cache would consume less than 75mW/core, while a single Cortex A32 processor @ 100 MHz 2x 8KB cache, and no extra options would consume less than 4 mW. Typically, SoCs based on Cortex-A32 should be manufactured with 28nm process.

The processor specifically targets consumer embedded products, wearable devices running Linux or Android, Internet of Things (IoT) “rich” nodes, multi function printers (MFCs), and industrial applications.

More details can be found on ARM Cortex-A32 product page, and ARM community blog. You can also learn more by attending “The Future of ARM Cortex-A Processors for Embedded Compute” at Embedded World 2016 on February 24 at 10:30am.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter