Computing at the Edge



Editor’s note:

During a recent discussion with ARM® regarding applications of its recently introduced Cortex®-M7 processor core, ARM introduced a new concept it dubbed the intelligent flexible cloud that defines how devices connected to the cloud communicate, how data is managed as it makes its way through the cloud and how its Cortex-M7 can deliver the performance needed for the edge-connected devices. The following questions and answers are excerpts from our conversation.

Dave Bursky (DB): Is the term Intelligent Flexible Cloud (IFC), a term coined by ARM, or is it a generic term accepted by the industry? I have not come across this term before so I was wondering about its familiarity to the design community.

Ian-Johnson-Bio-smallIan Johnson, Senior Product Manager at ARM Ltd.: The term was coined by ARM. We created a new term in order to elevate the impact of multiple merging trends that when viewed in isolation, do not necessarily convey the full transformation taking place in terms of hardware and software platforms. IFC is a combination of the trends toward distributed computing, network function virtualization and software defined networking. It is built on scalable, heterogeneous hardware and a common software framework (see the figure). Together, these trends will enable applications (both networking applications and overlay applications such as analytics) to be deployed across the network—enabling agility, resilience and business model evolution. Applications will be able to reside where the data does, reducing capacity constraints and meeting real world demands for latency.

Figure: The intelligent flexible cloud as defined by ARM lets applications run where the data is, independent of the network node. Each of the devices in the data flow—IoT devices as well as access, edge and aggregation products—can leverage scalable ARM processors and acceleration offload to handle the data flow.

Figure: The intelligent flexible cloud as defined by ARM lets applications run where the data is, independent of the network node. Each of the devices in the data flow—IoT devices as well as access, edge and aggregation products—can leverage scalable ARM processors and acceleration offload to handle the data flow.

DB: What is ARM’s definition of the network edge—is it where IoT devices connect to the network, or where devices such as data aggregators or preprocessors prepare data for transmission to the cloud, or somewhere else in the network architecture? What types of products do you propose would leverage the M7 core?

Johnson: Generically, we term the network edge as the point where end devices access the network. These same points may also be data aggregators and/or pre-processors of data depending on the network architecture. The higher performance point of the Cortex®-M7 processor is well suited to intelligent end point devices in markets such as industrial or lighter-weight access points. We expect Cortex-M7 to be used in applications that require real-time response and high performance. So it will be used in endpoints where processing demands exceed the performance of Cortex-M3/M4, but where a Cortex-A processor cannot be used because of the requirement to respond in a few cycles to interrupts or to have real-time deterministic behavior. It will be able to run mbed™ OS for secure, reliable communications.
DB: Who are some of the Cortex-M7 core licensees who are willing to talk regarding their use of the Cortex-M7 core in an IoT or other device that becomes part of the IFC?

Johnson: I would suggest talking to STMicroelectronics—the company demonstrated a home gateway based on Cortex-M7 at Embedded World 2015 in Nuremberg, Germany. Also talk to Atmel—its SAM70 microcontroller is based on Cortex-M7, and Atmel has stated that “IoT” products are a target application area for SAM70. Additionally, Freescale has incorporated the Cortex-M7 core in several members of its Kinetis family of embedded processors.
DB: Aside from the DSP capabilities of the Cortex-M7 core, which other hardware or software features do you feel contribute the most to designs of IoT and Edge-connected solutions?

Johnson: Some of the features to focus on include the various efficient memory and bus interfaces available on Cortex-M7—such as tightly-coupled memories (TCMs) for real-time response, the instruction and data caches for efficient access to large memories and powerful peripherals, direct-memory access (DMA) into the tightly couple memories via the advanced high-performance bus (AHB) and the AHB-Lite peripheral interface (AHBP) for access to existing AHB peripherals and memories. Other core features include the general high-performance delivered by the superscalar microarchitecture (not just for DSP) and the ability to perform double-precision floating-point calculations for added accuracy (such as required by precise positioning in the home or the enterprise and by GPS). Lastly, systems based on the Cortex-M7 will be more reliable thanks to built-in error checking and correction (ECC) and memory built-in-self test (MBIST) on the memory interface.
DB: In terms of positioning the Cortex-M7 core vs. other industry solutions, can you provide some comparisons or pros and cons that discuss some of the design tradeoffs that a designer might have to make when selecting the most appropriate core for their application?

Johnson: Design trade-off number 1: how much memory to use and how to partition it. With Cortex-M7 you can dedicate some SRAM to tightly-coupled memory, ensuring that functions which need to be executed within a given time window meet their real-time constraints. I- and D-caches on the AXI bus provide efficient access to large external (slow) memories, which would normally cause execution delays (if there were no caches). The extensive buffering used in Cortex-M7 minimizes the cases where the processor will stall waiting for memory operations to complete. The processor also allows you to control access to given regions of memory.

Design trade-off number 2: power/area vs. performance. The core has a number of optional features that allow the system designer to trade off performance and area/power consumption. Designers can optionally include the floating point unit (and configure as single- or double-precision), specify the number of interrupts and priority levels supported, specify cache and tightly-coupled-memory sizes, and more.

Design trade-off number 3: development environment. Since the Cortex-M7 is compatible with existing Cortex-M processors, the designer has access to a vast array of development tools, real-time operating system software (RTOS) and middleware which can be used across all Cortex-M designs, amortizing costs and increasing code re-use.

This article was sponsored by ARM.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google