ARM Technologies

 CORTEX A & MOBILE

big.LITTLE

Here's a detailed explanation of big.LITTLE ARM Technology:

Concept:

big.LITTLE is a heterogeneous processing architecture developed by ARM. It combines two different types of processor cores within a single system-on-chip (SoC):

• big cores: These are powerful, high-performance cores designed for demanding tasks like gaming, video editing, or running complex applications. They can handle heavy workloads efficiently but consume more power.
• LITTLE cores: These are energy-efficient cores optimized for low power consumption. They are suitable for lighter tasks like web browsing, music playback, or background processes.

Benefits:

big.LITTLE technology offers several advantages:

• Improved Battery Life: By switching between big and LITTLE cores based on workload demands, big.LITTLE helps conserve battery life. When performing less demanding tasks, the system can utilize the low-power LITTLE cores, significantly reducing power consumption compared to using big cores all the time.
• Enhanced Performance: When needed, the big cores can take over and provide superior performance for resource-intensive applications. This ensures a smooth user experience without compromising on responsiveness during demanding tasks.
• Scalability: big.LITTLE allows manufacturers to customize the configuration of big and LITTLE cores within an SoC. This caters to different device categories and user needs. For instance, a budget smartphone might prioritize LITTLE cores for extended battery life, while a high-performance phone might have more big cores for raw processing power.

How it Works:

The operating system plays a crucial role in managing big.LITTLE technology. Here's a breakdown of the process:

1. Task Detection: The OS constantly monitors the workload on the processor.
2. Core Allocation: Based on the task requirements, the OS decides whether to allocate the task to a big core for high performance or a LITTLE core for better power efficiency.
3. Dynamic Switching: The OS can seamlessly switch between big and LITTLE cores as needed. This often happens transparently to the user.

Software Support:

For big.LITTLE to function effectively, the operating system and applications need to be optimized to utilize both types of cores efficiently. ARM provides tools and libraries to help developers write software that can leverage the capabilities of big.LITTLE architecture.

Use Cases:

big.LITTLE technology is widely used in various mobile devices, including:

• Smartphones
• Tablets
• Wearables

It's a popular choice for manufacturers as it helps strike a balance between performance and battery life, which are critical user concerns in mobile devices.

Beyond Mobile Devices:

While primarily used in mobile SoCs, big.LITTLE technology can potentially be applied in other areas where balancing performance and power consumption is important. This could include:

• Laptops
• IoT devices
• Edge computing systems

ARM big.LITTLE with 3 cores (recent development):

While the traditional big.LITTLE uses two core configurations (big and LITTLE), ARM has introduced a solution with three dedicated processors:

• High-performance core: This core can handle demanding tasks similar to traditional big cores.
• Mid-range cores: These cores offer a balance between performance and power efficiency, suitable for a wider range of tasks.
• Energy-efficient cores: These cores are optimized for low power consumption for background activities.

This 3-core configuration allows for even more granular control over power consumption and performance, potentially catering to an even broader range of applications.

Conclusion:

big.LITTLE ARM Technology is a significant innovation that has helped shape modern mobile computing. By combining powerful big cores with energy-efficient LITTLE cores, it allows devices to achieve both high performance and extended battery life. As technology continues to evolve, big.LITTLE architecture is likely to find applications beyond mobile devices, offering a versatile approach to managing performance and power consumption in various computing scenarios.

Perf Vs Power Core

In a big.LITTLE architecture with ARM processors, the operating system (OS) relies on several factors to determine whether a task is suitable for a performance (big) core or a power-efficient (LITTLE) core. Here's how the OS makes this decision:

1. Workload Characteristics:

• CPU Intensity: The OS analyzes the CPU requirements of the task. Tasks requiring high processing power and sustained CPU usage, like video editing or gaming, are better suited for big cores. Conversely, less demanding tasks like web browsing or music playback can be efficiently handled by LITTLE cores.
• I/O Bound vs. CPU Bound: The OS can identify if the task is I/O bound (waiting for data from storage or network) or CPU bound (heavily utilizing the processor). I/O bound tasks might not benefit significantly from a big core, and a LITTLE core might be sufficient while waiting for data.

2. Historical Data:

The OS might leverage past experiences with similar tasks to make scheduling decisions. If a particular app historically exhibited high CPU usage, the OS might prioritize assigning it to a big core in the future.

3. Battery Level:

When battery life is critical (e.g., low battery), the OS might favor scheduling tasks on LITTLE cores even for moderately demanding workloads to conserve power.

4. Thermal Management:

Big cores generate more heat than LITTLE cores. The OS can monitor processor temperature and prioritize LITTLE cores to avoid overheating, especially when the device is already warm.

5. Power Management Policies:

The OS might offer user-configurable power management policies. Users can choose between prioritizing performance or battery life, influencing the OS's core selection criteria.

Techniques for Workload Characterization:

The OS utilizes various techniques to understand the workload characteristics:

• CPU Usage Monitoring: The OS constantly monitors CPU utilization and identifies tasks with high CPU demands.
• Process Accounting: The OS tracks historical data on resource usage by different processes, which can inform future scheduling decisions.
• Load Balancers: The OS might employ load balancers to distribute tasks across available cores, considering factors like core capabilities and current workload.

It's important to note that the decision-making process is not always straightforward. There might be situations where a task initially starts on a LITTLE core but migrates to a big core if its CPU demands increase unexpectedly. The OS continuously monitors the workload and core performance to ensure optimal resource utilization.

Additionally, big.LITTLE with 3 cores (a recent development) adds another layer of complexity. The OS might choose the mid-range cores for tasks requiring a balance between performance and power efficiency.

Overall, the OS plays a crucial role in effectively managing big.LITTLE architectures by intelligently scheduling tasks based on workload characteristics, battery life considerations, and user preferences. This dynamic allocation of tasks between performance and power-efficient cores helps achieve a balance between performance and battery life in modern devices.

DynamIQ

DynamIQ ARM Technology Explained

DynamIQ is a significant advancement in ARM's multi-core processor technology designed for the next generation of computing. It builds upon the foundation of big.LITTLE but offers several improvements and new features:

Key Characteristics:

• Single Cluster Design: Unlike big.LITTLE, which utilizes separate clusters for big and LITTLE cores, DynamIQ employs a single, unified cluster. This allows for more flexibility in core configuration and improved communication between cores.
• Heterogeneous Cores: DynamIQ supports a mix of up to 14 different processor cores within a single cluster. This includes big cores for high performance, LITTLE cores for efficiency, and potentially even mid-range cores for tasks requiring a balance between the two.
• Scalability: DynamIQ offers greater scalability compared to big.LITTLE. The ability to integrate various core types in a single cluster enables SoC designers to create configurations tailored to specific device categories and user needs.
• Shared L3 Cache: DynamIQ introduces a shared L3 cache accessible by all cores within the cluster. This improves memory access latency and overall system performance, especially for tasks that benefit from data sharing between cores.
• Intelligent Power Management: DynamIQ incorporates advanced power management features. It allows for fine-grained control over individual core speeds and voltage levels, enabling efficient operation under varying workloads.
• Safety Features: DynamIQ is designed to support safety-critical applications in areas like automotive and industrial systems. It provides mechanisms for ensuring reliable operation and handling potential failures.

Benefits of DynamIQ:

• Enhanced Performance: The combination of powerful cores, shared L3 cache, and improved communication within the cluster leads to significant performance gains compared to big.LITTLE architecture.
• Improved Power Efficiency: Granular power management features in DynamIQ help optimize power consumption for different workloads. This extends battery life in mobile devices and reduces energy usage in other applications.
• Greater Flexibility: DynamIQ offers more flexibility in core configuration, allowing manufacturers to create SoCs catering to diverse device segments and user requirements.
• Scalability for Future Needs: DynamIQ's architecture is adaptable to accommodate future advancements in core designs and functionalities.

Use Cases:

DynamIQ technology is well-suited for various computing applications, including:

• Mobile Devices (Smartphones, Tablets): It can deliver a balance of performance and battery life for mobile users.
• Automotive Systems: The safety features and scalability of DynamIQ make it suitable for in-vehicle computing applications requiring reliable performance.
• Internet of Things (IoT): The ability to configure low-power cores can benefit battery-powered IoT devices.
• Wearables: DynamIQ can enable wearables with improved processing power while maintaining power efficiency.
• Cloud Computing: The scalability of DynamIQ can be beneficial for servers and cloud-based solutions.

Overall, DynamIQ represents a significant leap forward in ARM's multi-core processor technology. It offers improved performance, better power efficiency, greater flexibility, and support for safety-critical applications, making it a versatile solution for the evolving needs of modern computing.

Neon

What is ARM Neon?

ARM Neon is an advanced Single Instruction Multiple Data (SIMD) architecture extension for ARM processors. It allows processors to perform the same operation on multiple data elements simultaneously, significantly improving performance for specific tasks compared to traditional single-core execution.

How Does it Work?

• Neon technology utilizes vector registers that can hold multiple data elements of the same type (e.g., four 32-bit integers or eight 16-bit values).
• Neon instructions operate on these vectors, performing the same operation on each element simultaneously. This approach is highly efficient for tasks involving repetitive operations on large data sets.

Benefits of ARM Neon:

• Significant Performance Improvement: For workloads suited to SIMD processing, Neon can deliver substantial performance gains compared to non-SIMD execution. This is particularly beneficial for multimedia applications, image processing, and various signal processing algorithms.
• Reduced Power Consumption: By performing multiple operations in a single instruction, Neon can help optimize power usage for workloads that benefit from SIMD processing.
• Wide Range of Supported Data Types: Neon supports various data types, including integers, floating-point numbers, and booleans, enabling its use in diverse applications.

Use Cases for ARM Neon:

• Multimedia Processing: Encoding and decoding of audio and video formats is a prime example where Neon excels.
• Image Processing: Tasks like image filtering, resizing, and color space conversion can be significantly accelerated with Neon.
• Signal Processing: Many digital signal processing algorithms benefit from SIMD instructions, making Neon a valuable tool in this domain.
• Scientific Computing: Applications involving complex mathematical operations on large datasets can leverage Neon for performance gains.
• Machine Learning: Some fundamental operations in machine learning, like matrix multiplication, can be optimized using Neon.

Programming with Neon:

There are several ways to develop applications that leverage ARM Neon:

• Neon Intrinsics: These are low-level assembly instructions specifically designed for Neon. They offer the most control but require a deeper understanding of the architecture.
• Neon compiler optimizations: Modern compilers can automatically vectorize code for tasks suitable for Neon, reducing the need for manual assembly coding.
• Libraries: Various libraries like NEON library and OpenCL provide optimized functions that exploit Neon capabilities, simplifying development.

ARM Neon Versions:

Neon technology has evolved alongside ARM architecture. Newer versions of ARMvX often introduce enhancements to Neon capabilities. Here's a brief overview of some notable versions:

• Neon in ARMv7: Introduced the foundation of Neon with support for basic vector operations.
• Neon in ARMv8: Added features like scalable vector extensions (SVE) for improved performance on workloads with variable-length vectors.

Future of Neon:

As the computing landscape continues to evolve, ARM is likely to further develop Neon technology. Potential areas of focus could include:

• Enhanced Support for Machine Learning: Optimizations for specific machine learning algorithms and data types.
• Improved Configurability: More granular control over vector lengths and instruction selection for better performance tailoring.
• Integration with Other Technologies: Closer collaboration with other ARM technologies like GPUs for even more powerful parallel processing capabilities.

Overall, ARM Neon is a powerful technology that has become an essential component of modern ARM processors. By enabling efficient SIMD processing, it plays a critical role in accelerating various applications across multimedia, image processing, and other computationally intensive tasks.

Neon a co proc?

No, Neon is not a separate co-processor alongside the main core in Cortex families. It's an instruction set extension built into the main core of ARM Cortex processors.

Here's a breakdown of the key points:

• Cortex Family: This refers to the family of processor cores designed by ARM and licensed to various manufacturers. These cores implement the ARM instruction set architecture (ARMvX).
• Instruction Set Extension: Neon is an extension to the base ARM instruction set. It provides additional instructions specifically designed for SIMD (Single Instruction Multiple Data) processing.
• Integration with Main Core: The Neon instructions are executed by the same processing core as the main ARM instructions. There's no separate co-processor hardware for Neon.

Benefits of Integration:

• Efficiency: Tight integration with the main core allows for efficient communication and data transfer between Neon vector registers and the core's general-purpose registers.
• Simplicity: Programmers don't need to manage separate co-processor code or context switching between the main core and a co-processor.

ARM Terminology:

It's important to distinguish between co-processors and instruction set extensions in ARM terminology:

• Co-processor (CP): This refers to a separate processor chip that can be attached to the main processor to provide additional functionality. ARM processors do have some co-processors for specific tasks, but Neon is not one of them.
• Instruction Set Extension (ISE): This extends the capabilities of the main processor by adding new instructions. Neon is a well-known example of an ISE for ARM processors.

In summary, ARM Neon technology is an integral part of the main core in Cortex processors, not a separate co-processor. This design approach simplifies development and improves efficiency for tasks that can leverage its SIMD processing capabilities.

Disabling Neon

There are two main ways to disable Neon technology in an ARM system:

1. Disabling Neon at the SoC Design Phase:

   • This happens during the design and manufacturing process of the System-on-Chip (SoC).
   • Advantages:
     • Saves silicon area: Removing Neon hardware reduces the overall chip size, potentially leading to lower manufacturing costs and improved power efficiency for the entire SoC.
     • Simplifies design: Excluding Neon reduces design complexity, potentially shortening development time and lowering design costs.
   • Disadvantages:
     • Limits functionality: Applications that rely on Neon for performance will not function as intended on this SoC.
     • Less future-proof: As software and workloads increasingly leverage SIMD instructions, the SoC might become less versatile over time.

2. Disabling Neon Through Software Configuration:

   • This is done through software settings after the SoC is manufactured.
   • Advantages:
     • More flexibility: The SoC retains the Neon hardware, allowing software to enable or disable it based on needs. This caters to a wider range of applications.
     • Future-proof: The SoC can benefit from future software optimizations for Neon.
   • Disadvantages:
     • Minor performance overhead: Even when disabled in software, the unused Neon hardware might introduce a slight overhead in terms of power consumption and die size compared to an SoC without Neon entirely.
     • Requires software control: Disabling Neon requires specific software configuration, which might add complexity for some users or embedded systems with limited software control.

Choosing the Right Approach:

The decision of whether to disable Neon at the design phase or through software configuration depends on several factors:

• Target application: If the intended use case for the SoC does not involve applications that benefit from Neon, disabling it at the design phase might be a reasonable choice for cost and power efficiency.
• Future-proofing: If the SoC is intended for a longer lifespan or wider range of applications, keeping Neon enabled with software control offers more flexibility.
• Manufacturing cost vs. performance: The cost savings from a smaller die size (without Neon) need to be weighed against the potential performance benefits that Neon can offer for some applications.

In conclusion, both methods have their advantages and disadvantages. The optimal approach depends on the specific needs and priorities of the SoC design.

PAC

ARM Pointer Authentication Code (PAC) is a security feature introduced in ARMv8.1 architecture to mitigate certain memory corruption vulnerabilities. Here's a detailed explanation:

What is it?

PAC is a cryptographic technique that adds an authentication code to pointers in memory. This code helps verify the integrity of the pointer, ensuring it hasn't been tampered with by malicious software.

How it Works:

1. PAC Generation: When a pointer is created, the CPU calculates a PAC value using a cryptographically secure key. This PAC value is a small hash (typically 32 bits) based on the pointer address and a secret modifier.
2. PAC Storage: The PAC value is stored alongside the pointer itself, typically in unused bits within the pointer address.
3. PAC Verification: When the CPU needs to use a pointer, it recalculates the PAC value based on the stored pointer address and the same secret modifier used during generation. It then compares this newly calculated PAC with the stored PAC value.
4. Integrity Check: If the calculated PAC matches the stored PAC, the pointer is considered valid. This indicates that the pointer hasn't been modified and points to the intended memory location.
5. Error Handling: If the PAC values don't match, it signifies a potential security breach (e.g., a buffer overflow attack attempting to overwrite a pointer). The CPU can then take various actions like raising an exception, halting execution, or initiating a secure boot process to recover from a potentially compromised state.

Benefits of ARM PAC:

• Enhanced Security: PAC helps prevent attacks that exploit vulnerabilities related to pointer manipulation. By verifying pointer integrity, it makes it more difficult for malicious code to redirect program execution or access unauthorized memory locations.
• Performance Overhead: While PAC adds an extra step to pointer operations, the overhead is typically minimal (around a few clock cycles).
• Transparent Operation: The PAC verification process happens in hardware, making it transparent to the software running on the system.

Limitations of ARM PAC:

• Not Foolproof: PAC is not a complete security solution. It primarily protects against pointer corruption but might not be effective against all types of memory corruption attacks.
• Key Management: The security of PAC relies heavily on the secrecy and proper management of the cryptographic key used for PAC generation.

Overall, ARM PAC is a valuable security feature that strengthens the defenses against memory corruption vulnerabilities in ARM processors. It offers a balance between security enhancements and minimal performance impact.

Here are some additional points to consider:

• PAC variants: ARMv8.3 introduced variants of PAC and AUT (Authenticate) instructions for each of the four keys used in the system. This allows for more granular control over PAC usage.
• Combined Instructions: ARMv8.3 also introduced combined instructions like verify-then-return (RETA*) and verify-and-branch (BRA*, BLRA*), which streamline the process of PAC verification and control flow.

By understanding ARM PAC and its limitations, developers can make informed decisions about incorporating it into their software for improved system security.

MTE 

ARM Memory Tagging Extension (MTE) is a hardware feature introduced in Armv9 architecture that improves memory safety in code written in languages like C and C++. These languages are considered unsafe because they allow programmers to directly manipulate memory addresses, which can lead to errors like buffer overflows and use-after-free vulnerabilities.

MTE works by adding an extra layer of security to memory access. Each memory allocation is tagged with a unique identifier, and pointers to that memory are also tagged with the corresponding identifier. When the CPU tries to access memory, it checks to make sure that the tag on the pointer matches the tag on the memory location. If there's a mismatch, it indicates a potential memory safety violation, and the CPU can take action to prevent a crash or security exploit.

ARM MTE architecture

MTE has two main benefits:

• Improved security: By catching memory safety errors early, MTE can help to prevent security vulnerabilities from being exploited.
• Increased stability: MTE can also help to prevent crashes caused by memory safety errors.

MTE is a relatively new technology, but it has the potential to significantly improve the security and stability of software written in unsafe languages.

Here are some additional details about ARM MTE:

• MTE can be used in two modes: synchronous and asynchronous. Synchronous mode is more accurate but has a higher performance overhead. Asynchronous mode is faster but may not catch all memory safety errors.
• MTE is currently supported on a limited number of ARM processors. However, support for MTE is expected to grow in the future.
• MTE is not a silver bullet for memory safety. It is still important to write code that is free of memory safety errors. However, MTE can provide an additional layer of protection against errors that do occur.

PAC Vs MTE

Both PAC (Pointer Authentication Code) and MTE (Memory Tagging Extension) are security features in ARM processors that aim to improve memory safety, but they work in different ways:

Pointer Authentication Code (PAC):

• Focuses on control flow protection: PAC protects against Return-Oriented Programming (ROP) attacks. Attackers exploit vulnerabilities to chain together existing code snippets (gadgets) to gain control flow.
• Method: PAC adds a cryptographic signature (PAC) to pointers, particularly function return addresses. Before using a pointer for a jump or call, the CPU verifies the PAC using pre-defined keys.
• Benefits:
  • Makes ROP attacks significantly harder by requiring knowledge of valid PACs.
  • Relatively low performance overhead.
• Limitations:
  • Primarily protects against control-flow hijacking, not general memory errors.
  • Requires compiler support or manual code modification for stack protection.

Memory Tagging Extension (MTE):

• Focuses on general memory access protection: MTE safeguards against various memory errors like buffer overflows and use-after-free vulnerabilities.
• Method: MTE assigns unique tags to memory allocations and pointers referencing them. During memory access, the CPU checks if the pointer tag matches the memory tag. A mismatch indicates a potential error.
• Benefits:
  • Broader protection against memory safety violations.
  • Can catch errors in legacy code without recompilation (for heap allocations).
• Limitations:
  • Higher performance overhead compared to PAC.
  • Requires hardware support from the processor (ARMv8.3 onwards).

In essence:

• PAC is like a special handshake between pointers and the CPU to ensure they belong together, preventing unauthorized jumps and calls.
• MTE is like labeling memory and pointers with matching IDs, ensuring the CPU accesses the correct memory location.

Working together:

While PAC and MTE address different threats, they can be complementary for enhanced security:

• MTE can identify general memory errors, and PAC can further secure control flow if a compromised pointer somehow bypasses MTE checks.
• However, enabling both might reduce some virtual address space due to overlapping tag requirements.

Ultimately, the choice between PAC and MTE depends on the specific security needs and performance considerations of your application.

Disabling MTE and PAC

Disabling MTE (Memory Tagging Extension) and PAC (Pointer Authentication Code) can be achieved at two stages:

1. SOC Design Phase (Disabling by Design):

• During Chip Design: This involves modifying the ARM processor core itself at the hardware level to disable MTE and PAC functionalities.
• Pros:
  • Removes MTE/PAC entirely, eliminating any potential performance overhead they might introduce.
  • Can offer a cleaner and more streamlined design if MTE/PAC are not required for the specific application.
• Cons:
  • Permanent solution: Once the chip is manufactured, MTE/PAC cannot be re-enabled later.
  • Less flexibility: If software needs change in the future and MTE/PAC become desirable, the hardware cannot adapt.
  • Potentially higher development costs due to modifications in the chip design.

2. Software Configuration (Disabling at Runtime):

• Configurable options: ARM processors and some SoCs (System on Chip) provide options to enable or disable MTE/PAC features through software settings. This might be done via boot configuration or BIOS/UEFI menus.
• Pros:
  • More flexibility: MTE/PAC can be enabled or disabled based on software requirements, offering better adaptability.
  • No hardware modifications needed: This is a simpler approach that doesn't require chip design changes.
• Cons:
  • Performance overhead remains: Even if disabled, MTE/PAC might occupy some hardware resources, potentially impacting performance to a lesser extent.
  • Requires software control: Disabling needs to be implemented in the boot process or user settings, adding complexity.

Choosing the Right Approach:

The decision depends on several factors:

• Application needs: If the application has strict security requirements, MTE/PAC might be essential and shouldn't be disabled. Conversely, for performance-critical applications where security is less of a concern, disabling them might be preferable.
• Development stage: During early development, software configuration might be sufficient for testing purposes. But for final production, disabling by design at the SoC phase might be preferred for a streamlined hardware solution.
• Flexibility requirements: If future software updates might require MTE/PAC, then software configuration offers more flexibility.

In conclusion, both methods have their advantages and disadvantages. Carefully consider your specific needs to determine the most suitable approach for disabling MTE and PAC.

Secure Boot 

ARM processors offer a secure boot feature designed to safeguard devices during the boot process. Here's a breakdown of how it works:

Core Concept: Chain of Trust

Secure boot establishes a chain of trust, ensuring only authorized software executes on the device. This chain typically involves several stages, each cryptographically verified by the previous one. Think of it like a series of padlocks, where each unlocked padlock allows access to the next level.

Implementation:

• Boot stages: The boot process involves loading and executing various firmware images (software) in a specific order. Secure boot focuses on the Secure World portion, which handles security-sensitive tasks.
• Cryptographic verification: Each firmware image is signed using cryptographic techniques. The verifying code (often residing in tamper-resistant hardware) checks the signature against a trusted key. If the signature matches, the code is considered legitimate and allowed to execute.
• Hardware Root of Trust: The initial trust anchor in this chain is often a hardware component like a Trusted Platform Module (TPM) or a Programmable Read-Only Memory (eFuse). These elements store the root keys used for verification.

Benefits:

• Prevents unauthorized code execution: By verifying the boot chain, secure boot safeguards against malware or tampered firmware from loading, protecting the system from potential security vulnerabilities.
• Enhanced device security: This feature is particularly crucial for devices handling sensitive data or requiring a high level of security.

Implementation Details (may vary):

• ARM TrustZone Technology: This technology often underpins secure boot on ARM processors. It creates a secure world partition isolated from the regular operating system for handling security-sensitive tasks.
• Firmware implementation: The specific implementation details of secure boot vary depending on the SoC (System on Chip) vendor and device model. The boot process might involve stages like Boot Loader (BL) stages (BL1, BL2, etc.) with each stage verifying the subsequent one.

Things to Consider:

• Customization: Some platforms might allow customizing the trusted keys or enabling/disabling secure boot functionality. However, these options may be restricted depending on the device and vendor.
• Performance impact: Secure boot can introduce a slight overhead to the boot process due to the cryptographic verification involved.

Overall, ARM secure boot plays a vital role in protecting devices by ensuring only authorized code runs during the critical boot sequence.