Arm’s partners have shipped over 125 billion chips since 1990, with 55 billion of these chips shipped just in the last four years. Arm expects another 100 billion chips to be shipped in the next four years, with most of this staggering growth driven by Internet of Things (IoT). IoT encompasses applications ranging from home automation and smart cities, including smart metering and lighting) to logistics and retail applications, including asset tracking and inventory management, to automotive applications, including parking sensors, and much more. Such applications thrive on small code size, low data storage, easy implementation and minimal management. In many cases, embedded flash becomes the default memory choice to run and store such small code.
Fig 1: example use cases for embedded flash applications
Non-Volatile Memory (NVM) is important to a lot of SoC designs and industry markets, but in particular brings a lot of benefits to the IoT market. One of the key benefits of NVM is its ability to store information, even after a power cycle, which is incredibly important in a market prone to attacks. One kind of NVM is NOR flash, which provides many other benefits that are important to the IoT market, including low-power consumption, reliability and execute in place (XIP) capabilities.
NOR flash has the ability to be integrated on the same piece of silicon as a processor-based system (commonly referred to as embedded flash or eFlash), allowing a reduction of the number of components and the size of the board, leading to lower system costs, easy integration, and smaller and more efficient products.
On top of the ability to resist a power cycle hack, eFlash memory has many other security benefits, which is a fundamental requirement that needs to be considered and implemented in any chip design. Firstly, as the memory is embedded directly on the chip, it makes it harder to observed. Secondly, re-programming of eFlash is a fairly simple process, which allows product updates (fixing potential vulnerabilities) to be securely pushed throughout the lifetime of the device.
With all these great benefits in mind, it’s easy to see why designers are encouraged to use eFlash. In short, eFlash enables systems that are low-cost, whilst providing security, easy provisioning and update, even in remote areas. Alongside eFlash, other forms of eNVM (embedded Non-Volatile Memory) such as MRAM or RRAM, bring high-capacity, low-cost, fast-access and energy-efficiency to SoC design. Thus, for the IoT to truly scale, the ability to interface to eNVM (embedded Non-Volatile Memories) in an easy way, and migrate from one to the other, will allow the industry to scale faster.
Arm identified that a big pain point for its partners building SoCs for IoT is the need to modify the eFlash controller, due to the difference in the eFlash interface between foundry and process variants. The complexity and the modification time associated with adapting the flash controller for each foundry or technology migration is huge, meaning that the focus of the SoC designers gets deviated from further innovating their designs. Because of this design problem, mass adoption and scalability for eNVM (flash, MRAM, RRAM and others) across the IoT ecosystem becomes a challenge and is something that needs to be solved.
To overcome this barrier, Arm has developed a generic eFlash interface standard called the Generic Flash Bus interface (GFB). GFB is now published as a brand new AMBA standard, building on years of heritage of Arm AMBA guidance. Arm AMBA is a group of open-standard specifications, which now form the de-facto standard for on-chip communications – so it’s a great fit for GFB to join the Arm AMBA family! Arm is committed to fostering its innovation platform for designers and has made the AMBA GFB standard available free of charge. You can access the AMBA GFB specification now here.
Fig 2: introducing Arm AMBA GFB
AMBA GFB simplifies the integration of embedded flash controllers in large subsystems, by splitting the Flash Controller in two parts and providing a simple interface between the system side and the flash (or other non-volatile storage technology). It defines a boundary between two sides of the flash controller: the Generic Part and the Process-Dependent Part.
The Generic Part is closely related to the system and contains only the process-independent part of the flash controller. This part can feature system-level functions including, but not limited to:
Third party IP providers or design teams can also decide to create their own variants of functionalities and release GFB-compatile IP.
The Process-Dependent side is closely related to the eFlash macro used for a specific process. This part only has to be designed once for a family of eNVM macros. This ensures reusability of the general functions with different processes and easy migration of designs. GFB targets the data path only for simplifying accesses to the eNVM. The control path signalling towards the Process-Dependent Part (e.g. power and configuration) is handled over other standardized interfaces like AMBA APB and LPI.
This model gives partners full flexibility to build their systems around the GFB interface standard, with a complete abstraction of the process-specific features of the eNVM. The Process-Dependent Part contains specific foundry IP (such as interfaces, protocol and the timings) and translation to AMBA GFB interface. Foundries can now provide a clean and compatible interface to their eNVM. Migration to future technologies (such as MRAM, RRAM) is also made easier as the Generic Part of the flash controller applies to any Non-Volatile memory.
Fig 3: How Arm AMBA GFB fits with other standards
To make the conversion simple, the AMBA GFB is similar to AHB in its operation but with some additional features to accommodate to the needs of an eNVM. This further complements the benefits of the Generic Part described above.
Along with the launch of the AMBA GFB standard, Arm also announces its own ‘Generic Part’, which we’ve named Arm CoreLink GFC-100 Generic Flash Controller. This helps partners to license this technology IP from Arm and either use an existing Process-Dependent Part, or create one if it does not already exist. This enables Arm partners to spend more time on their system design and differentiation, instead of writing eFlash controllers. The CoreLink GFC-100 is independent of the foundry process technology being used and can be connected to any eNVM, provided that the Process-Specific Part exists. It does not contain any third-party IP and offers complete flexibility to partners. This new controller reduces the development time and the development costs, allowing you to free up engineering hours to focus on your product differentiation.
CoreLink GFC-100 is a component in the Arm SDK-101 System Design Kit, an improvement to the existing SDK-100 System Design Kit, which has been successfully used by the Arm’s partner ecosystem for some time. The Arm System Design Kit family includes a variety of products, which make up toolboxes for SoC designers. The Arm System Design Kits (SDKs) are foundations for bringing an SoC to market quickly, with minimal risk. They include components such as interconnects, bridges, essential peripherals and now products such as CoreLink GFC-100 to speed up your IoT SoC development.
Fig 4: Some of the ecosystem partners supporting AMBA GFB
We are excited to share the list of Arm partners that are already onboard with supporting the idea of AMBA GFB adoption. Many others are joining soon!
[CTAToken URL = "https://developer.arm.com/-/media/Files/pdf/IHI0083A_amba_generic_flash_bus_architecture_specification.pdf?revision=53222ffa-96af-4410-a17f-349a1946163a&_ga=2.100511198.1740061504.1532434626-1795311865.1531756513" target="_blank" text="Download the AMBA GFB specification" class ="green"]
[CTAToken URL = "http://infocenter.arm.com/help/topic/com.arm.doc.101147_0000_00_en/corelink_sdk_101_system_design_kit_technical_overview__use_profiling_101147_0000_00_en.pdf" target="_blank" text="Technical overview of Arm SDK-101 System Design Kit" class ="green"]