Patent Description:
A processor, or set of processors, executes instructions from an instruction set, e.g., the instruction set architecture (ISA). The instruction set is the part of the computer architecture related to programming, and generally includes the native data types, instructions, register architecture, addressing modes, memory architecture, interrupt and exception handling, and external input and output (I/O). It should be noted that the term instruction herein may refer to a macro-instruction, e.g., an instruction that is provided to the processor for execution, or to a micro-instruction, e.g., an instruction that results from a processor's decoder decoding macro-instructions. <NPL>, pertains to using cache in CPU as RAM before the RAM is initialized and describes that C code will be compiled with GCC and it will use cache in CPU as stack. The document "<NPL>, describes a processor using CAR (cache-as-RAM) technology. CAR means that hardware initialization code uses the cache as a (stack) memory (e.g. for storing variables), wherein the hardware initialization code is executed from non-volatile memory. This document also mentions that while it is possible to do a limited amount of parallel processing during the UEFI boot phase, such as during memory initialization with multiple socket designs, any true multithreading activity would require changes to be made to the DXE phase of the UEFI solutions to allow for this.

The present disclosure is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:.

In the following description, numerous specific details are set forth. However, it is understood that examples of the disclosure may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description.

References in the specification to "one example," "an example," "an example example," etc., indicate that the example described may include a particular feature, structure, or characteristic, but every example may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same example. Further, when a particular feature, structure, or characteristic is described in connection with an example, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other examples whether or not explicitly described.

A (e.g., hardware) processor (e.g., having one or more cores) may execute instructions to operate on data, for example, to perform arithmetic, logic, or other functions. A hardware processor may access data in data storage (e.g., memory). A system (e.g., a system on a chip) may include one or more processor cores (e.g., "logical processors").

As part of an enhanced user experience, applications using computer systems may demand instant (e.g., perceptibly instant to a human) system boot up time. Faster system response time is a key performance indicator (KPI) that may be used by original equipment manufacturers (OEMs) and original design manufacturers (ODMs) for their product requirements for various computing sectors, for example, personal devices (e.g., smart phone/tablet/laptop), health care (e.g., ultrasound, defibrillators, and patient monitor devices), industrial (e.g., robots changing arms), military, aerospace, and government (MAG) (e.g., firing a missile, fail-safe redundancy on airplanes, or similar single function devices), and/or office/home automation. In certain uses, the average system (e.g., platform) boot time is expected to be less than a threshold (e.g., <NUM>) from a (e.g., Advanced Configuration and Power Interface (ACPI) standard) (e.g., starting at ACPI "mechanical off" (e.g., "G3) state) system state (e.g., with no power applied) until the operating system (OS) hand off. Certain examples herein provide an improved boot flow utilizing a boot controller (e.g., circuit) that configures a cache for use as memory for hardware initialization code before executing the hardware initialization code. Turning now to <FIG>, an example system on a chip (SOC) is depicted.

<FIG> illustrates a system on a chip (SoC) <NUM> that includes a boot controller <NUM> according to examples of the disclosure. The boot controller <NUM> may be located within processor <NUM>. Depicted SoC <NUM> illustrates a hardware processor <NUM> coupled to a memory <NUM> via memory controller <NUM>. In one example, the memory <NUM> of SoC <NUM> is a system memory (e.g., dynamic random-access memory (DRAM)). Memory controller <NUM> may be included, e.g., to manage memory requests between the processor <NUM> and memory <NUM>. In one example, memory controller <NUM> is to provide (e.g., fill) data (e.g., a cache line) for a miss in the cache(s) (e.g., miss in L3 <NUM>, L4 <NUM>, or other last level cache (LLC) of processor <NUM>). Processor <NUM> includes two or more processor cores <NUM>, e.g., <NUM> to N where N is a positive integer. In one example, each of a plurality of processor cores have an instance of the circuitry discussed herein. Depicted core <NUM><NUM>(<NUM>) includes a first level (L1) of data cache <NUM>(<NUM>), a first level (L1) of instruction cache <NUM>(<NUM>), and a level two (L2) cache <NUM>(<NUM>). Depicted core <NUM><NUM>(<NUM>) includes a first level (L1) of data cache <NUM>(<NUM>), a first level (L1) of instruction cache <NUM>(<NUM>), and a level two (L2) cache <NUM>(<NUM>).

In some examples, as shown in <FIG>, processor <NUM> includes one or more next levels (e.g., level three (L3) cache <NUM> and level four (L4) cache <NUM>, e.g., with L4 the last level cache (LLC) (e.g., the last cache searched before a data item is fetched from memory <NUM>) that is coupled to, and shared by, one or more (e.g., all) of the cores. In certain examples, each of L1 data caches <NUM>, L1 instruction caches <NUM>, L2 caches <NUM>, L3 cache <NUM>, and L4 (e.g., LLC) cache <NUM> are managed by cache coherency controller <NUM> (e.g., circuitry), e.g., to cache data (e.g., and/or instructions) according to a specified cache coherency. In certain examples, the data (e.g., and/or instructions) stored within the various processor caches are managed at the granularity of cache lines which may be a fixed size (e.g., <NUM>, <NUM>, <NUM>, etc. Bytes in length). Each core <NUM> may include other components (e.g., as depicted in <FIG>), for example, an instruction fetch circuit for fetching instructions (for example, from (e.g., main) memory <NUM> via memory controller <NUM> and/or from the caches; a decode circuit (e.g., decoder or decode unit) for decoding the instructions (e.g., decoding program instructions into micro-operations or "µops"); and an execution unit (e.g., execution circuit) for executing the decoded instructions. Core may include a writeback/retire circuit for retiring the instructions and writing back the results. Depicted core <NUM><NUM>(<NUM>) further includes a set of one or more registers <NUM>(<NUM>), for example, having one or more model specific (or machine specific) registers <NUM>(<NUM>), e.g., as control register(s).

SoC <NUM> may include one or more other devices <NUM>, e.g., that are also coupled to cache coherency controller <NUM>. Devices <NUM> may include a device that is to be initialized before memory <NUM> (e.g., DRAM) initialization is attached to cache, for example, a Converged Security and Management Engine (CSME) device, a generic Serial Peripheral Interface (GSPI) device, an enhanced Serial Peripheral Interface (ESPI) device, etc..

SoC <NUM> includes graphics circuitry <NUM> (e.g., a graphics core). In certain examples, graphics circuitry <NUM> includes one or more caches <NUM>, e.g., that are coupled to one or more caches shared with the processor, e.g., L3 cache <NUM> and/or L4 cache <NUM>. SoC <NUM> may include an embedded dynamic random-access memory <NUM> (eDRAM), for example, embedded into SoC <NUM> with processor <NUM>. In certain examples, eDRAM <NUM> is used as L4 (e.g., LLC) cache <NUM> (e.g., instead of using an embedded static RAM (eSRAM) for the L4 cache). In certain examples, eDRAM <NUM> is positioned between L3 cache <NUM> and memory <NUM> (e.g., DRAM (e.g., Double Data Rate Synchronous DRAM (DDR)), e.g., on a memory bus. SoC <NUM> may include a power management integrated circuit <NUM> (PMIC), e.g., to, in response to a power on indication (e.g., pressing of a mechanical on/off switch), provide (e.g., power to the components of the SoC <NUM>.

In certain examples, SoC <NUM> (e.g., internal or external to processor <NUM>) includes hardware initialization code storage <NUM>. The hardware initialization code may be hardware initialization firmware. In certain examples, the hardware initialization code from storage <NUM>, when executed by the processor <NUM>, is to cause the booting up of the SoC <NUM> (e.g., at least the booting up of the hardware processor <NUM> thereof).

In certain examples, the hardware initialization code is responsible for transferring control of the computer (e.g., SoC <NUM>) to a program (e.g., OS) stored in memory coupled to the computer.

In certain examples, the hardware initialization code storage <NUM> includes BIOS and/or UEFI code from storage <NUM> and boot loader code from storage <NUM>. In certain of those examples, the BIOS and/or UEFI (e.g., boot ROM) code is executed as a first stage, and then the boot loader code is executed as a second stage. As one example, BIOS code is according to a BIOS standard. As another example, UEFI code is according to a UEFI standard.

In certain examples, the BIOS and/or UEFI code brings the SoC <NUM> (e.g., processor <NUM> thereof) out of (e.g., cold) reset, puts the processor into a known and stable state, and finds the second-stage boot loader code (e.g., from storage <NUM>) and passes control to the next stage. In one example, the BIOS and/or UEFI (e.g., boot ROM) code is only aware of the second-stage boot loader code <NUM> and not aware of any potential subsequent software stages. In certain examples, during this time, the BIOS and/or UEFI (e.g., boot ROM) code handles any error conditions.

In certain examples, the boot loader code (e.g., being passed control of the SoC (e.g., processor) when the BIOS and/or UEFI code stage is complete) then locates and loads (e.g., for execution by the processor) the next stage(s) of software (e.g., O. ) and so on. In one example, before control is passed to the boot loader code, it is decrypted and/or authenticated if secure boot is enabled.

In certain examples, BIOS and/or UEFI (e.g., boot ROM) code, when executed, initializes certain hardware of the SoC, checks integrity, and initializes the (e.g., first level) boot loader code. In certain examples, the boot loader code is, e.g., after being called at the completion of BIOS and/or UEFI (e.g., boot ROM) code execution, executed to cause a handoff of control of the SoC (e.g., processor) to the operating system executing of the SoC. In one example, the boot loader code knows where (e.g., the memory location of) the OS kernel image is stored in memory, for example, and loads the OS kernel image for execution.

Although BIOS and/or UEFI (e.g., boot ROM) code storage <NUM> and boot loader code storage <NUM> are shown together, in another example the BIOS and/or UEFI (e.g., boot ROM) code storage <NUM> is within processor <NUM> and the boot loader code storage <NUM> is separate from the processor <NUM> (e.g., in storage <NUM> of SoC <NUM>).

In certain examples, once boot is complete, certain control of the SoC transfers to executing OS code <NUM> (and/or application code <NUM>). In certain examples, SoC <NUM> includes authenticated code module (ACM) code <NUM>. In one example, hardware initialization code storage <NUM> includes ACM code <NUM>. In certain examples, ACM code <NUM> supports the establishment of a measured environment that enables the capability of an authenticated code execution mode, for example, with the ACM code loaded into the processor and executed using a tamper resistant mechanism. In one example, authentication is achieved by a digital signature in the header of the ACM code, for example, where the processor calculates a hash of the ACM and uses the result to validate the signature, e.g., such that the processor will only initialize processor state or execute the ACM if it passes authentication.

<FIG> illustrates an example boot flow <NUM> according to examples of the disclosure. Depicted flow <NUM> shows one example of an architecture (e.g., Intel® architecture (IA)) platform boot path. For example, from an initial "mechanical off" state (e.g., ACPI G3) to a working state (for example, ACPI G0 sleep state S0 (e.g., working S0 state, and not S0 lower-power idle (e.g., "standby") or partial SoC sleep) boot time flow. The boot flow <NUM> may include the pre-power (for example, all rails and clock stabilization, e.g., real time clock (RTC)), pre-reset (e.g., power sequencing, reset/security, authenticated code module (ACM), microcode (ucode)/ power management code (pcode), etc.), and post central processing unit (CPU) reset (e.g., boot loader) boot path components.

Depicted boot flow <NUM> includes receiving a power on at <NUM> (e.g., a G3 state exit), an initial power sequence <NUM> (e.g., as performed by a PMIC), SoC security and resets <NUM> (e.g., with the SoC (e.g., reset manager thereof) generating module reset signals based on reset requests from the various sources in the hardware processor system (e.g., processor <NUM>) and any storage (e.g., storage <NUM>), and software writing to the module-reset control registers, e.g., with the reset manager exiting SoC reset only when the secure fuses have been loaded and validated), authenticated code module <NUM> executed to ensure secure boot is completed, and then to hardware initialization code <NUM> (for example, such that BIOS and/or UEFI code 212A from storage <NUM> and boot loader code 212B from storage <NUM> are executed, e.g., in series), after the OS handoff, the O. may then execute <NUM>, and one or more (e.g., user) applications may then be executed <NUM> (e.g., under the control of the OS). Note that blocks <NUM>-<NUM> are merely examples and more or less blocks may be utilized in a boot flow. In certain examples, (e.g., in contrast to BIOS/UEFI code 210A) execution of authenticated code module <NUM> is an (e.g., additional) additional step included to ensure security as per a guideline (for example, a Boot Guard technology, e.g., that is a combination of BIOS guard, trusted execution technology (TXT), and ACM) used to validate other firmware blocks). In one example, Trusted Execution Engine (TXE) firmware is the code executed for TXT, e.g., to bring up TXE and expose runtime security services such as firmware Trusted Platform Module (fTPM) and Platform Protection Technology with Boot Guard. In certain examples, Boot Guard in TXE firmware loads and authenticates other firmware components during boot. In certain examples, processor (e.g., IA) firmware communicates with TXE firmware through a Host Embedded Controller Interface (HECI). In certain examples, firmware is provided by a manufacturer and signed with the manufacturer's private key.

In certain examples, the most time-consuming phase of a total boot path is the execution of the code (e.g., firmware) used to perform hardware initialization during the booting process (e.g., sometime referred to as the Basic Input/Output System (BIOS) process), hence making it a critical phase to optimize to provide a fast boot experience. In certain examples, the size of the hardware initialization code (e.g., BIOS/UEFI code and/or boot loader code) is growing with more workloads to execute.

Examples herein provide an improved boot flow utilizing a boot controller (e.g., circuit) that configures a cache for use as memory (e.g., memory <NUM> in <FIG>) for hardware initialization code before executing the hardware initialization code, for example, before entry into any of hardware initialization code (e.g., BIOS code or UEFI code). In one example, block of memory <NUM> is sized (e.g., pre-allocated) to store input, output, and block device, e.g., about 64MB-256MB in size.

<FIG> illustrates an example boot flow <NUM> utilizing a boot controller <NUM> that configures a cache for use as memory for hardware initialization code before executing the hardware initialization code <NUM> according to examples of the disclosure. Depicted flow <NUM> shows one example of an architecture (e.g., Intel® architecture (IA)) platform boot path. For example, from an initial "mechanical off" state (e.g., ACPI G3) to a working state (for example, ACPI G0 sleep state S0 (e.g., working S0 state, and not S0 lower-power idle (e.g., "standby") or partial SoC sleep) boot time flow. The boot flow <NUM> may include the pre-power (for example, all rails and clock stabilization, e.g., real time clock (RTC)), pre-reset (e.g., power sequencing, reset/security, authenticated code module (ACM), microcode (ucode)/ power management code (pcode), etc.), and post central processing unit (CPU) reset (e.g., boot loader) boot path components.

Depicted boot flow <NUM> includes receiving a power on at <NUM> (e.g., a G3 state exit), an initial power sequence <NUM> (e.g., as performed by a PMIC), SoC security and resets <NUM> (e.g., with the SoC (e.g., reset manager thereof) generating module reset signals based on reset requests from the various sources in the hardware processor system (e.g., processor <NUM>) and any storage (e.g., storage <NUM>), and software writing to the module-reset control registers, e.g., with the reset manager exiting SoC reset only when the secure fuses have been loaded and validated), boot controller <NUM> is to initialize a portion of a cache (e.g., L4 cache) for use by the hardware initialization code <NUM>, authenticated code module <NUM> executed to ensure secure boot is completed, and then to hardware initialization code <NUM> (for example, such that BIOS and/or UEFI code 312A from storage <NUM> and boot loader code 312B from storage <NUM> are executed via use of the portion of the cache (e.g., L4 cache) initialized by boot controller <NUM>, e.g., in parallel), after the OS handoff, the O. may then execute <NUM>, and one or more (e.g., user) applications may then be executed <NUM> (e.g., under the control of the OS). Note that blocks <NUM>-<NUM> are merely examples and more or less blocks may be utilized in a boot flow.

Certain examples herein provide for a faster boot process without using cache-as-random-access-memory(RAM) (CAR) that is setup during execution of the hardware initialization code, e.g., with CAR setup being complex and limited. Certain examples herein provide for a faster boot process without having fixed (e.g., static) memory (e.g., static random-access memory (SRAM)) provided for boot (e.g., firmware) space usage. Certain examples herein provide for a faster boot process without using the last level cache (LLC) within a processor (e.g., but can use the LLC of a SoC).

In one example, a platform's boot process does not have pre-programmed memory at (e.g., CPU) reset and is provided with a very limited cache memory size leading to an ineffective boot method with a single core processor at reset. This limits this system's ability to parallelize the boot steps within the hardware initialization code (e.g., BIOS/FW) execution, forcing it to complete the boot up sequence in a serial fashion which results in much longer boot times.

Certain examples herein provide for a compute architecture memory system augmented with several levels of caches, e.g., as shown in <FIG>. As one example, a memory system includes:.

In certain examples, a (e.g., level <NUM> (L4) and/or LLC) shared cache is of larger size than for a processor (e.g., CPU) or a GPU only, e.g., to improve performance of hybrid ecosystem with CPU(s) and GPU(s). However, a key disconnect in certain examples of this is a lack of visibility of this large chunk of (e.g., L4 and/or LLC) cache memory to the boot process that thereby makes the system resource inefficient. Examples herein address this disconnect in the memory hierarchy during the boot stage of the system (e.g., prior to executing hardware initialization code, e.g., BIOS/UEFI code).

In certain examples, the user experience key performance indicators involve a faster response of a system including a faster boot time. Certain examples herein provide a faster ecosystem boot process, e.g., that does not only run in a single core due to lack of visibility to cache memory during boot time and thus limits the capability of a multicore processor system. For example, certain examples herein allow hardware initialization code (e.g., firmware) to run in parallel, e.g., instead of running sequentially leading to slower boot time and ineffective usage of processor power. Examples herein are directed to effectively using processor power and system resources to enhance faster boot response, e.g., to provide a better user experience and not waste resources. Examples herein allow for use of multiple processing cores in a boot process, for example, in contrast to the entire boot happening (e.g., boot code executing) on a single core environment where initial boot happens with single core (e.g., microprocessor) until memory is available for all processors such that the boot sequence is completed with only a single processing core. Examples herein allow for a parallelization of the boot process (e.g., in executing a hardware and/or firmware initialization sequence).

Examples herein enhance a boot process by extending a (e.g., LLC/L4) cache memory at reset to enable a multicore environment and enable hardware initialization (e.g., boot) code (e.g., firmware) to parallelize the boot block. In certain examples, a SoC's hardware is modified/selected to treat (e.g., package) cache as static RAM (SRAM) and/or provide a larger pre-initialized memory at reset for boot firmware. In certain examples, multiple cores of a processor are available at reset and enable the boot hardware initialization (e.g., boot) code (e.g., firmware) to run the boot block in parallel to reduce the boot time. Examples herein utilize an L4 cache (e.g., persistent memory such as but not limited to, Intel® Optane™ persistent memory) as memory for use by the hardware initialization code, e.g., before secure boot (e.g., via an ACM). In one example, the access time for (e.g., L4) cache is (e.g., significantly) less than the access time for system memory (e.g., DRAM). Examples herein provide a section of (e.g., L4) cache to be visible (e.g., at boot time), for example, to enable multicore execution of hardware initialization code via that section of cache (e.g., such that execution of the hardware initialization code is not limited to a single core (e.g., to a single "bootstrap processor (core)") and/or enable parallel execution of hardware initialization code to optimize boot time and support a faster boot time compared to a single core (e.g., not requiring a serialized execution of the (e.g., entire) hardware initialization code).

Certain examples herein include a (e.g., larger than about 128GB, 256GB, and 512GB) on-package (e.g., L4) cache (e.g., having an access time that is much less than a DRAM access time, e.g., with a DRAM size of about 4GB to 32GB) which is used to improve hardware initialization code (e.g., firmware) and thus boot time. Certain examples herein provide for (e.g., more) pre-initialized memory at (e.g., power on) reset, for example, as part of a processor (e.g., CPU) reset process (e.g., but not part of a hardware initialization processes (e.g., BIOS process or UEFI process)). Certain examples herein provide for (e.g., more) pre-initialized memory at reset to nullify legacy (e.g., x86) BIOS/UEFI assumptions and/or make a faster and more efficient BIOS/UEFI solution for modern device use cases, such as, but not limited to, automotive in-vehicle infotainment (IVI) (e.g., turn on rear view camera within a faster period of time), household robots, industrial robots, etc..

The below discusses two categories of examples, (<NUM>) making (e.g., L4) cache available as part of SRAM and (<NUM>) enabling multi-threaded (e.g., multiple core) environment using shared (e.g., L4) cache as SRAM at reset. In certain examples of (<NUM>), hardware initialization code (e.g., firmware) is to know SRAM base and limit (max) to make use of it, e.g., where hardware initialization code is to use (e.g., L4) cache for all regular operations like resource allocation etc. instead of DRAM based resource. Certain of those examples ensure pre-programmed SRAM is available for hardware initialization code consumption (e.g., use by the code when it executes) and/or access time for the (e.g., L4) cache is much faster than the DRAM access time which will improve boot time (e.g., by decreasing the total time to execute hardware initialization code). In certain examples of (<NUM>), all cores (e.g., (e.g., bootstrap processor (BSP) and application processors (APs)) are available at reset (e.g., before execution of the hardware initialization code. Certain of those examples thus allow for design/redesign of hardware initialization code (e.g., firmware) to make use of multi core environment, e.g., with the cores having dependency over a significantly bigger memory available at reset.

In certain examples, the execution of a processor identification instruction (e.g., CPUID instruction) or reading of a (e.g., dedicated) model specific (or machine specific) register (MSR) indicates if the functionality discussed herein is available (e.g., for a particular system/processor).

The following discussion of the two categories of examples includes methods (e.g., and hardware) that, in certain examples, allows the entire (e.g., BIOS or UEFI) hardware initialization (e.g., boot) to take place in a multi-threaded (e.g., multiple core) environment.

In certain examples, platform boot time of a device refers to the total time it takes to show something on the screen of the device after the device is instructed to turn on (e.g., mostly comprised of the BIOS or UEFI booting time (and time for boot loader) plus the OS booting time).

<FIG> illustrates a system on a chip (SoC) <NUM> that includes a (e.g., L4) cache <NUM> according to examples of the disclosure. Depicted SoC <NUM> includes one or more cores <NUM> (e.g., and a boot controller <NUM> as discussed herein), graphics circuitry <NUM> (e.g., GFX core), and cache <NUM> shared by one or more cores <NUM> and graphics circuitry <NUM>. Depicted core(s) <NUM> and cache(s) <NUM> are coupled to memory <NUM> (e.g., DRAM). For example, with one or more cores <NUM> and graphics circuitry <NUM> in a first die(s) of the SoC <NUM>, the cache <NUM> initialized by the boot controller <NUM> in a base die(s), and memory <NUM> (e.g., DRAM) in the package of SoC <NUM>.

Thus, in certain examples, the (e.g., L4) cache <NUM> is shared by (e.g., data) processors and graphics processors, e.g., such that the shared cache (e.g., in the base die of the SoC) is significantly larger in size (e.g., having a size of about 400MB - <NUM> MB) than a cache only used by a (e.g., data) processor. In certain examples, one or more coherent memory interfaces (CMIs) are utilized as a coupling between a cache and another component (e.g., CPU and/or GPU). In certain examples, a coupling between CPU (e.g., core <NUM>) and GPU <NUM> is according to a Computer Express Link (CXL) standard.

The following are example hardware & firmware design details for (<NUM>). System memory used during a hardware initialization (e.g., boot) (e.g., hardware initialization code) phase may be very limited. One use case of system memory is to allocate resources for devices (e.g., devices coupled together according to a Peripheral Component Interconnect Express (PCI Express) standard) and read kernel blocks from boot devices before booting to an operating system. In one example, a certain amount of (e.g., about 256MB-384MB of) system memory (e.g., initialized by a boot controller) is allocated for hardware initialization code to perform device initializations in a pre-boot environment. In certain examples, a system (e.g., auxiliary processor core or controller) is to initialize a portion of shared (e.g., L4) cache (as per the discussion herein) for use (e.g., as SRAM) for platform hardware initialization code usage. Optionally, include an indication (e.g., via model specific (or machine specific) register (MSR)) of the SRAM physical start and limit for hardware initialization code design. In certain examples, the hardware initialization code flow is modified to refer to a static memory resource for (e.g., PCI) devices to avoid long waiting time for DRAM based memory training (e.g., about <NUM> seconds in first boot and about <NUM>-<NUM> milliseconds (ms) in consecutive boots). For security reason, additional security lockdown may be provided on top of the SRAM range, e.g., disable/lockdown the "(e.g., L4) cache configured as SRAM" range before booting to OS, e.g., where once disabled/locked, that cannot be overridden without platform reset. In one example, a firmware support package (FSP) is to handle this lockdown with an "End of Firmware" boot event.

Certain examples of (<NUM>) utilize the below: hardware changes to use package (e.g., L4) cache as SRAM for hardware initialization code accesses, e.g., to provide a much larger pre-initialized memory at (e.g., SoC) reset for hardware initialization code to utilize. Firmware flows can also be independent of a DRAM memory training which takes a longer time to initialize, e.g., where access to (e.g., L4) cache memory range is faster than DRAM memory access.

<FIG> illustrates example response times <NUM> for DRAM <NUM> and a plurality of caches <NUM>, <NUM>, <NUM>, <NUM> according to examples of the disclosure. Caches may include a L1 cache <NUM>, L2 cache <NUM> (e.g., both together in core <NUM>), L3 cache <NUM>, and L4 cache <NUM>.

As noted above, in certain examples it is desirable to utilize cache instead of DRAM based memory accesses owing to the longer time that the DRAM access takes relative to a cache access.

<FIG> illustrates an example boot flow 600A according to examples of the disclosure. Depicted flow 600A shows one example of an architecture (e.g., Intel® architecture (IA)) platform boot path. For example, from an initial "mechanical off" state (e.g., ACPI G3) to a working state (for example, ACPI G0 sleep state S0 (e.g., working S0 state, and not S0 lower-power idle (e.g., "standby") or partial SoC sleep) boot time flow. The boot flow 600A may include the pre-power (for example, all rails and clock stabilization, e.g., real time clock (RTC)), pre-reset (e.g., power sequencing, reset/security, authenticated code module (ACM), microcode (ucode)/ power management code (pcode), etc.), and post central processing unit (CPU) reset (e.g., boot loader) boot path components.

Depicted boot flow 600A includes receiving a power on at <NUM> (e.g., a G3 state exit), an initial power sequence <NUM> (e.g., as performed by a PMIC), SoC security and resets <NUM> (e.g., with the SoC (e.g., reset manager thereof) generating module reset signals based on reset requests from the various sources in the hardware processor system (e.g., processor <NUM>) and any storage (e.g., storage <NUM>), and software writing to the module-reset control registers, e.g., with the reset manager exiting SoC reset only when the secure fuses have been loaded and validated), optionally) boot controller <NUM> is to initialize a portion of a cache (e.g., L4 cache) for use by the hardware initialization code <NUM>, authenticated code module <NUM> executed to ensure secure boot is completed, and then to hardware initialization code <NUM> (for example, such that BIOS and/or UEFI code 612A from storage <NUM> and boot loader code 612B from storage <NUM> are executed via use of the portion of the cache (e.g., L4 cache) initialized by boot controller <NUM>, e.g., in parallel), after the OS handoff, the O. may then execute <NUM>, and one or more (e.g., user) applications may then be executed <NUM> (e.g., under the control of the OS). Note that blocks <NUM>-<NUM> are merely examples and more or less blocks may be utilized in a boot flow.

<FIG> illustrates an example flow 600B for hardware initialization code of <FIG> without configuring cache (e.g., L4/LLC) as random-access memory (RAM) (e.g., SRAM) before running hardware initialization code <NUM> according to examples of the disclosure. In flow 600B, BIOS/UEFI code 612A includes a boot block <NUM>, and ROM stage <NUM> (e.g., ROM being the hardware initialization storage <NUM> in <FIG>), post cache-as-RAM (CAR) <NUM>, and RAM stage <NUM> (e.g., for memory <NUM> in <FIG>). For example, with boot block <NUM> including reset vector, processor mode switch, setting up CAR, and console enabling. For example, with ROM stage <NUM> including (e.g., processor) chipset initialization, filing memory initialization configuration regions (e.g., FSP-M UPD), calling memory initialization code (e.g., FSP-M), and creating a console (e.g., CBMEM). For example, with post CAR stage <NUM> including tearing down (e.g., removing) CAR and setting up memory type range registers (MTRRs). For example, with RAM stage <NUM> calling silicon initialization code (e.g., FSP-S), (e.g., PCI) enumeration and resource allocations, and creating memory and power tables for the OS in memory (e.g., e820 and ACPI tables).

In certain examples, once BIOS/UEFI code 612A has executed, it causes boot loader code 612B to execute. For example, boot loader code 612B executing to cause a read of block device for kernel partitions, and booting to OS.

In certain examples, memory type range registers (MTRRs) are a set of processor supplementary capabilities control registers that provide system software with control of how accesses to memory ranges by the processor (e.g., CPU) are cached.

In certain examples, a firmware support package (FSP) is a binary distribution of silicon initialization code, for example, with each FSP module containing a configurable data region which can be used by the FSP during initialization. In certain examples, this configuration region is a data structure called the Updateable Product Data (UPD) and will contain the default parameters for FSP initialization. , e.g., with the UPD data structure only used by the FSP when the FSP is being invoked. In certain examples, there are a FSP-M: Memory initialization phase to initialize the permanent memory along with any other early silicon initialization, a FSP-S: Silicon initialization phase to complete the silicon initialization including processor (e.g., CPU) and input/output (I/O) controller initialization, and a FSP-T: Temporary RAM initialization phase to initialize the temporary RAM along with any other early initialization. In certain examples, e820 is shorthand for the facility by which the BIOS/UEFI of a (e.g., x86-based) computer system reports the memory map to the operating system or boot loader. In one example, it is accessed via the int <NUM> call, by setting the AX register to value E820 in hexadecimal and reports which memory address ranges are usable and which are reserved for use by the BIOS/UEFI.

In certain examples, BIOS/UEFI is to load the ACPI tables in system memory. ACPI table may indicate the available computer hardware components and functions to the OS kernel, for example, indicate the available computer hardware components, e.g., to allow the OS to perform power management by (for example) putting unused components to sleep, and to perform status monitoring.

In certain examples of <FIG>, boot block <NUM> and ROM stage <NUM> are run from mapped memory (e.g., according to a Serial Peripheral Interface (SPI) standard) and using CAR cache that is setup by BIOS/UEFI code 612A (e.g., boot block <NUM> thereof). In certain examples of <FIG>, post CAR <NUM> through boot loader code 612B utilize a move of all context into DRAM mapped memory and a tear down of CAR.

In the depicted example, once the hardware initialization code <NUM> is complete, the OS handoff is performed to transfer control of the system (e.g., processor) to the OS <NUM> (e.g., OS kernel).

<FIG> illustrates an example flow 600C for hardware initialization code of <FIG> with configuring cache (e.g., L4/LLC) (e.g., by boot controller <NUM>) as random-access memory (RAM) (e.g., SRAM) before running (e.g., entering) hardware initialization code <NUM> according to examples of the disclosure. In flow 600C, BIOS/UEFI code 612A includes a RAM stage <NUM>. For example, with RAM stage <NUM> comprising a subblock <NUM> including reset vector, processor mode switch, console enabling, and creating a console (e.g., CBMEM), a subblock <NUM> including (e.g., processor) chipset initialization, initializing I/O devices, (e.g., PCI) enumeration and resource allocations, and creating memory and power tables for the OS in memory (e.g., e820 and ACPI tables), and subblock <NUM> including initializing DRAM memory, setting up MTRR based on DRAM resources, and locking down the portion of the (e.g., L4) cache used as memory for the hardware initialization code (e.g., SRAM range).

In certain examples, once BIOS/UEFI code 612A has executed, it causes boot loader code 612B to execute. For example, with boot loader code 612B to cause running from DRAM mapped memory, read of cached kernel partitions, and boot to OS.

In certain examples, RAM stage <NUM> is run from (e.g., SPI) mapped memory and using (e.g., L4) cache as memory (e.g., SRAM) and all context is moved into DRAM mapped memory before jumping to boot loader code 612B from BIOS/UEFI code 612A.

In the depicted example, once the hardware initialization code <NUM> is complete, the OS handoff is performed to transfer control of the system (e.g., processor) to the OS <NUM> (e.g., OS kernel). An example security policy is to lock down that SRAM memory range used by the hardware initialization code before booting to operating system.

As one example, the example of <FIG> results in a time savings compared to the example depicted in <FIG>, and thus a faster boot.

Certain category (<NUM>) examples allow early hardware initialization code stages (e.g., before DRAM initialization) to be avoided in order to reduce the footprint of the hardware initialization code, e.g., without using cache-as-ram (CAR) ( "tempRAM init") in BIOS/UEFI flow and reducing complicated assembly programming in boot loader space. Certain category (<NUM>) examples allow CPU, chipset, and PCI enumeration to be performed early without being dependent on DRAM initialization. Certain category (<NUM>) examples do not utilize the time and resources to perform a CAR tear down. Certain category (<NUM>) examples avoid switching between temporary memory (CAR) to permanent memory (e.g., DRAM based) in boot loader space, e.g., the entire boot loader execution can be driven out of (e.g., SRAM based) fixed memory. Certain category (<NUM>) examples allow DRAM initialization at end of boot loader boot sequence to make sure payload or OS can use DRAM based resources for higher memory requirement. BIOS may still run on a single threaded environment, e.g., with further boot time optimization added for a multiple threaded environment as discussed in reference to the category (<NUM>) examples herein.

Certain category (<NUM>) examples use shared (e.g., L4) cache as a larger and faster memory available at reset, and modify the hardware initialization code to utilize those pre-initialized memory rather than define a hardware initialization code (e.g., BIOS or UEFI) flow which has a dependency on DRAM resources. Certain examples of this method make use of a multi-threaded (e.g., multiple core) environment at pre-boot stage to achieve fast system boot.

Example hardware and firmware design details include a shared (e.g., L4) cache that is accessible by processor (e.g., CPU) as part of SRAM, overcome limited memory available at reset constraint (e.g., using category (<NUM>) examples above), and may bring a plurality (e.g., all) cores (e.g., boot strap processor (BSP) and application processors (APs)) from reset early and allocate resources for those cores (e.g., APs the same as the BSP) to perform parallel tasks. Certain examples herein disable/lockdown the (e.g., L4) cache range (e.g., cache used as boot SRAM) before booting to OS.

<FIG> discussed below illustrates a modified firmware boot flow of a system where (e.g., L4) cache is configured as SRAM at pre-reset and all cores (e.g., BSP and APs) are enabled at reset, e.g., without any memory constraint, to optimize hardware initialization code execution (e.g., boot stage) for faster boot process.

<FIG> illustrates an example boot flow 700A according to examples of the disclosure. Depicted flow 700A shows one example of an architecture (e.g., Intel® architecture (IA)) platform boot path. For example, from an initial "mechanical off" state (e.g., ACPI G3) to a working state (for example, ACPI G0 sleep state S0 (e.g., working S0 state, and not S0 lower-power idle (e.g., "standby") or partial SoC sleep) boot time flow. The boot flow 700A may include the pre-power (for example, all rails and clock stabilization, e.g., real time clock (RTC)), pre-reset (e.g., power sequencing, reset/security, authenticated code module (ACM), microcode (ucode)/ power management code (pcode), etc.), and post central processing unit (CPU) reset (e.g., boot loader) boot path components.

Depicted boot flow 700A includes receiving a power on at <NUM> (e.g., a G3 state exit), an initial power sequence <NUM> (e.g., as performed by a PMIC), SoC security and resets <NUM> (e.g., with the SoC (e.g., reset manager thereof) generating module reset signals based on reset requests from the various sources in the hardware processor system (e.g., processor <NUM>) and any storage (e.g., storage <NUM>), and software writing to the module-reset control registers, e.g., with the reset manager exiting SoC reset only when the secure fuses have been loaded and validated), optionally) boot controller <NUM> is to initialize a portion of a cache (e.g., L4 cache) for use by the hardware initialization code <NUM>, authenticated code module <NUM> executed to ensure secure boot is completed, and then to hardware initialization code <NUM> (for example, such that BIOS and/or UEFI code 712A from storage <NUM> and boot loader code 712B from storage <NUM> are executed via use of the portion of the cache (e.g., L4 cache) initialized by boot controller <NUM>, e.g., in parallel), after the OS handoff, the O. may then execute <NUM>, and one or more (e.g., user) applications may then be executed <NUM> (e.g., under the control of the OS). Note that blocks <NUM>-<NUM> are merely examples and more or less blocks may be utilized in a boot flow.

<FIG> illustrates an example flow 700B for hardware initialization code of <FIG> without configuring cache (e.g., L4/LLC) as random-access memory (RAM) (e.g., SRAM) before running (e.g., entering) hardware initialization code <NUM> according to examples of the disclosure. In flow 700B, BIOS/UEFI code 712A includes a boot block <NUM>, and ROM stage <NUM> (e.g., ROM being the hardware initialization storage <NUM> in <FIG>), post cache-as-RAM (CAR) <NUM>, and RAM stage <NUM> (e.g., for memory <NUM> in <FIG>). For example, with boot block <NUM> including reset vector, processor mode switch, setting up CAR, and console enabling. For example, with ROM stage <NUM> including (e.g., processor) chipset initialization, filing memory initialization configuration regions (e.g., FSP-M UPD), calling memory initialization code (e.g., FSP-M), and creating a console (e.g., CBMEM). For example, with post CAR stage <NUM> including tearing down (e.g., removing) CAR and setting up memory type range registers (MTRRs). For example, with RAM stage <NUM> calling silicon initialization code (e.g., FSP-S), (e.g., PCI) enumeration and resource allocations, and creating memory and power tables for the OS in memory (e.g., e820 and ACPI tables).

In certain examples, once BIOS/UEFI code 712A has executed, it causes boot loader code 712B to execute. For example, boot loader code 712B executing to cause a read of block device for kernel partitions, and booting to OS.

In certain examples of <FIG>, boot block <NUM> and ROM stage <NUM> are run from mapped memory (e.g., according to a Serial Peripheral Interface (SPI) standard) and using CAR cache that is setup by BIOS/UEFI code 712A (e.g., boot block <NUM> thereof). In certain examples of <FIG>, post CAR <NUM> through boot loader code 712B utilize a move of all context into DRAM mapped memory and a tear down of CAR.

<FIG> illustrates an example flow 700C for hardware initialization code of <FIG> with configuring cache (e.g., L4/LLC) (e.g., by boot controller <NUM>) as random-access memory (RAM) (e.g., SRAM) before running hardware initialization code <NUM> according to examples of the disclosure. In flow 700C, BIOS/UEFI code 712A includes a RAM stage <NUM>. For example, with RAM stage <NUM> comprising a subblock <NUM> including reset vector, processor mode switch, console enabling, and creating a console (e.g., CBMEM), a subblock <NUM> including (e.g., processor) chipset initialization, initializing I/O devices, (e.g., PCI) enumeration and resource allocations, and creating memory and power tables for the OS in memory (e.g., e820 and ACPI tables), and subblock <NUM> including initializing DRAM memory, setting up MTRR based on DRAM resources, and locking down the portion of the (e.g., L4) cache used as memory for the hardware initialization code (e.g., SRAM range).

In certain examples, once BIOS/UEFI code 712A has executed, it causes boot loader code 712B to execute. For example, with boot loader code 712B to cause running from DRAM mapped memory, read of cached kernel partitions, and boot to OS.

As one example, subblock <NUM> is executed by a (e.g., single) bootstrap processor core, and subblocks <NUM> and <NUM> are executed by auxiliary processor core(s), for example, with a first auxiliary processor core executing subblock <NUM> and a second auxiliary processor core executing subblock <NUM>.

Certain category (<NUM>) examples utilize a (e.g., larger than L1, L2, or L3 caches) pre-initialized memory at reset for hardware initialization code to utilize. Hardware initialization code (e.g., firmware) flows can be independent of DRAM memory training, e.g., which takes a longer time to initialize. Early hardware initialization code stages (e.g., before DRAM initialization) can be avoided in order to reduce hardware initialization code footprint. An auxiliary processor core and/or controller (e.g., microcontroller) inside the SoC can initialize the (e.g., L4) cache as SRAM, for example, without requiring use of a (e.g., IA) processor (e.g., BSP) core. In certain examples, memory (e.g., L4 cache) is available before any (e.g., processing) core is released from reset. The invention allows the loading of hardware initialization code (e.g., BIOS or UEFI) image into SRAM (e.g., implemented as L4 cache) even before any core is out from reset. Certain category (<NUM>) examples do not use cache-as-ram (CAR) ("tempRAM init") in hardware initialization code flow, e.g., to reduce complicated assembly programming in bootloader space. Certain category (<NUM>) examples allow CPU, chipset, and PCI enumeration to be performed early without being dependent over DRAM initialization, and instead make use of SRAM to do all CPU/chipset programming. Certain category (<NUM>) examples allow CAR tear down logic to be avoided. Certain category (<NUM>) examples avoid switching between temporary memory (e.g., CAR) to permanent memory (e.g., DRAM based) in boot (e.g., boot loader) space and entire boot loader execution can be driven out of SRAM based fixed memory. Certain category (<NUM>) examples perform DRAM initialization at end of hardware initialization code (e.g., boot loader) sequence, e.g., to ensure payload or OS can use DRAM based resources for higher memory requirement. Certain category (<NUM>) examples allow all cores to be available at reset and BSP may bring APs in operable condition early without any memory bottleneck. Certain category (<NUM>) examples allow hardware initialization code (e.g., BIOS/UEFI) to run on a multi-threaded (e.g., multiple core) environment. Certain category (<NUM>) examples allow the execution of a firmware support package (e.g., FSP-M for DRAM initialization and FSP-S for chipset initialization) over parallel threads to optimize boot time. Certain category (<NUM>) examples allow an entire hardware initialization code (e.g., firmware) boot sequence to be spread across all cores and execution happening over parallel threads, for example, (i) boot event of bootstrap processor (BSP) for handling reset vector, processor mode switching, console enabling, creating bootloader memory layout, and chipset initialization, (ii) boot event of one AP core (e.g., AP0, AP1. APn, where n=index to the maximum core available) for filling required configuration parameter(s) to initialize DRAM, e.g., FSP-M, running memory reference code (MRC) to initialize DRAM, running independent security boot operations (e.g., verified boot), initializing independent I/O programming (e.g., embedded Multi-Media Controller (eMMC), trusted platform module (TPM), Embedded Controller, etc.), and (iii) Boot event of another AP core (e.g., AP0, AP1. APn,) for filling required configuration parameter to initialize hardware blocks, e.g., FSP-S, running FSP-S for detailed chipset initialization, reading kernel partitions from block device use for booting OS, and locking down the portion of cache (e.g., L4 SRAM range) used by execution of the hardware initialization code for security compliance.

<FIG> is a flow diagram illustrating operations <NUM> for system boot according to examples of the disclosure. Some or all of the operations <NUM> (or other processes described herein, or variations, and/or combinations thereof) are performed under the control of one or more computer components configured to execute and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications). The code is stored on a computer-readable storage medium, for example, in the form of a computer program comprising instructions executable by one or more processors. The computer-readable storage medium is non-transitory. In some examples, one or more (or all) of the operations <NUM> are performed by a boot service.

The operations <NUM> include, at block <NUM>, initializing, by a controller of a system (e.g., in response to a power on of the system) comprising a processor core coupled to a cache, a portion of the cache as memory for hardware initialization code usage before beginning execution of the hardware initialization code. The operations <NUM> further include, at block <NUM>, executing the hardware initialization code on the processor core to initialize the system. The operations <NUM> further include, at block <NUM>, transferring control of execution of the system from the hardware initialization code to operating system code executing on the system.

Exemplary architectures, systems, etc. that the above may be used in are detailed below.

At least some examples of the disclosed technologies can be described in view of the following examples:
An exemplary hardware processor comprises: a processor core; a cache coupled to the processor core; and a controller circuit to initialize a portion of the cache as memory for hardware initialization code usage before beginning execution of the hardware initialization code after a power on of the hardware processor. For example, the hardware initialization code is according to a Basic Input/Output System standard. For example, the hardware initialization code is according to a Unified Extensible Firmware Interface standard. For example, the processor core is one of a plurality of processor cores, and the hardware initialization code executes on the plurality of processor cores in parallel using the portion of the cache as the memory. For example, the cache is shared by the plurality of processor cores and a graphics core. For example, the controller circuit is to initialize the portion of the cache as byte read and write accessible memory for the hardware initialization code usage. For example, the controller circuit is to cause the portion of the cache to be hidden from access by operating system code executing on the hardware processor. For example, the controller circuit is to cause the portion of the cache to be hidden from access by user application code executing on the hardware processor.

An exemplary non-transitory machine readable medium that stores code that when executed by a machine causes the machine to perform a method comprising: initializing, by a controller of a system comprising a processor core coupled to a cache, a portion of the cache as memory for hardware initialization code usage before beginning execution of the hardware initialization code; executing the hardware initialization code on the processor core to initialize the system; and transferring control of execution of the system from the hardware initialization code to operating system code executing on the system. For example, the hardware initialization code is according to a Basic Input/Output System standard. For example, the hardware initialization code is according to a Unified Extensible Firmware Interface standard. For example, the executing comprises executing the hardware initialization code on a plurality of processor cores that includes the processor core in parallel using the portion of the cache as the memory to initialize the system. For example, the cache is shared by the plurality of processor cores and a graphics core. For example, the initializing comprises initializing the portion of the cache as byte read and write accessible memory for the hardware initialization code usage. For example, the method further comprises causing the portion of the cache to be hidden from access by operating system code executing on the system before the transferring control of execution of the system from the hardware initialization code to the operating system code. For example, the method further comprises causing the portion of the cache to be hidden from access by user application code executing on the system before the transferring control of execution of the system from the hardware initialization code to the operating system code.

An exemplary system comprises: a hardware processor comprising a processor core; a cache coupled to the hardware processor; storage for hardware initialization code; and a controller circuit to initialize a portion of the cache as memory for usage by the hardware initialization code before beginning execution of the hardware initialization code after a power on of the system. For example, the hardware initialization code is according to a Basic Input/Output System standard. For example, the hardware initialization code is according to a Unified Extensible Firmware Interface standard. For example, the processor core is one of a plurality of processor cores, and the hardware initialization code executes on the plurality of processor cores in parallel using the portion of the cache as the memory. For example, the system further comprises a graphics core, and the cache is shared by the plurality of processor cores and the graphics core. For example, the controller circuit is to initialize the portion of the cache as byte read and write accessible memory for usage by the hardware initialization code. For example, the controller circuit is to cause the portion of the cache to be hidden from access by operating system code executing on the system. For example, the controller circuit is to cause the portion of the cache to be hidden from access by user application code executing on the system.

In yet another example, an apparatus comprises a data storage device that stores code that when executed by a hardware processor causes the hardware processor to perform any method disclosed herein. An apparatus may be as described in the detailed description. A method may be as described in the detailed description.

An instruction set may include one or more instruction formats. A given instruction format may define various fields (e.g., number of bits, location of bits) to specify, among other things, the operation to be performed (e.g., opcode) and the operand(s) on which that operation is to be performed and/or other data field(s) (e.g., mask). Some instruction formats are further broken down though the definition of instruction templates (or subformats). For example, the instruction templates of a given instruction format may be defined to have different subsets of the instruction format's fields (the included fields are typically in the same order, but at least some have different bit positions because there are less fields included) and/or defined to have a given field interpreted differently. Thus, each instruction of an ISA is expressed using a given instruction format (and, if defined, in a given one of the instruction templates of that instruction format) and includes fields for specifying the operation and the operands. For example, an exemplary ADD instruction has a specific opcode and an instruction format that includes an opcode field to specify that opcode and operand fields to select operands (source1/destination and source2); and an occurrence of this ADD instruction in an instruction stream will have specific contents in the operand fields that select specific operands. A set of SIMD extensions referred to as the Advanced Vector Extensions (AVX) (AVX1 and AVX2) and using the Vector Extensions (VEX) coding scheme has been released and/or published (e.g., see <NPL>; and see <NPL>).

Processor cores may be implemented in different ways, for different purposes, and in different processors. For instance, implementations of such cores may include: <NUM>) a general purpose in-order core intended for general-purpose computing; <NUM>) a high performance general purpose out-of-order core intended for general-purpose computing; <NUM>) a special purpose core intended primarily for graphics and/or scientific (throughput) computing. Implementations of different processors may include: <NUM>) a CPU including one or more general purpose in-order cores intended for general-purpose computing and/or one or more general purpose out-of-order cores intended for general-purpose computing; and <NUM>) a coprocessor including one or more special purpose cores intended primarily for graphics and/or scientific (throughput). Such different processors lead to different computer system architectures, which may include: <NUM>) the coprocessor on a separate chip from the CPU; <NUM>) the coprocessor on a separate die in the same package as a CPU; <NUM>) the coprocessor on the same die as a CPU (in which case, such a coprocessor is sometimes referred to as special purpose logic, such as integrated graphics and/or scientific (throughput) logic, or as special purpose cores); and <NUM>) a system on a chip that may include on the same die the described CPU (sometimes referred to as the application core(s) or application processor(s)), the above described coprocessor, and additional functionality. Exemplary graphics processors are described next. Followed by exemplary core architectures, and descriptions of exemplary processors and computer architectures.

<FIG> is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue/execution pipeline according to examples of the disclosure. <FIG> is a block diagram illustrating both an exemplary example of an in-order architecture core and an exemplary register renaming, out-of-order issue/execution architecture core to be included in a processor according to examples of the disclosure. The solid lined boxes in <FIG> illustrate the in-order pipeline and in-order core, while the optional addition of the dashed lined boxes illustrates the register renaming, out-of-order issue/execution pipeline and core. Given that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

The decode unit <NUM> (or decoder or decoder unit) may decode instructions (e.g., macro-instructions), and generate as an output one or more micro-operations, micro-code entry points, micro-instructions, other instructions, or other control signals, which are decoded from, or which otherwise reflect, or are derived from, the original instructions. Examples of suitable mechanisms include, but are not limited to, look-up tables, hardware implementations, programmable logic arrays (PLAs), microcode read only memories (ROMs), etc. In one example, the core <NUM> includes a microcode ROM or other medium that stores microcode for certain macro-instructions (e.g., in decode unit <NUM> or otherwise within the front end unit <NUM>).

The execution engine unit <NUM> includes the rename/allocator unit <NUM> coupled to a retirement unit <NUM> and a set of one or more scheduler unit(s) <NUM>. The scheduler unit(s) <NUM> represents any number of different schedulers, including reservations stations, central instruction window, etc. The scheduler unit(s) <NUM> is coupled to the physical register file(s) unit(s) <NUM>. Each of the physical register file(s) units <NUM> represents one or more physical register files, different ones of which store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point,, status (e.g., an instruction pointer that is the address of the next instruction to be executed), etc. In one example, the physical register file(s) unit <NUM> comprises a vector registers unit, a write mask registers unit, and a scalar registers unit. These register units may provide architectural vector registers, vector mask registers, and general purpose registers. The physical register file(s) unit(s) <NUM> is overlapped by the retirement unit <NUM> to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer(s) and a retirement register file(s); using a future file(s), a history buffer(s), and a retirement register file(s); using a register maps and a pool of registers; etc.). The retirement unit <NUM> and the physical register file(s) unit(s) <NUM> are coupled to the execution cluster(s) <NUM>. The execution cluster(s) <NUM> includes a set of one or more execution units <NUM> and a set of one or more memory access units <NUM>. The execution units <NUM> may perform various operations (e.g., shifts, addition, subtraction, multiplication) and on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some examples may include a number of execution units dedicated to specific functions or sets of functions, other examples may include only one execution unit or multiple execution units that all perform all functions. The scheduler unit(s) <NUM>, physical register file(s) unit(s) <NUM>, and execution cluster(s) <NUM> are shown as being possibly plural because certain examples create separate pipelines for certain types of data/operations (e.g., a scalar integer pipeline, a scalar floating point/packed integer/packed floating point/vector integer/vector floating point pipeline, and/or a memory access pipeline that each have their own scheduler unit, physical register file(s) unit, and/or execution cluster - and in the case of a separate memory access pipeline, certain examples are implemented in which only the execution cluster of this pipeline has the memory access unit(s) <NUM>). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue/execution and the rest in-order.

In one exemplary example, the memory access units <NUM> may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit <NUM> in the memory unit <NUM>. The L2 cache unit <NUM> is coupled to one or more other levels of cache and eventually to a main memory <NUM>.

In one example, the core <NUM> includes logic to support a packed data instruction set extension (e.g., AVX1, AVX2), thereby allowing the operations used by many multimedia applications to be performed using packed data.

It should be understood that the core may support multithreading (executing two or more parallel sets of operations or threads), and may do so in a variety of ways including time sliced multithreading, simultaneous multithreading (where a single physical core provides a logical core for each of the threads that physical core is simultaneously multithreading), or a combination thereof (e.g., time sliced fetching and decoding and simultaneous multithreading thereafter such as in the Intel® Hyper-Threading technology).

While register renaming is described in the context of out-of-order execution, it should be understood that register renaming may be used in an in-order architecture. While the illustrated example of the processor also includes separate instruction and data cache units <NUM>/<NUM> and a shared L2 cache unit <NUM>, alternative examples may have a single internal cache for both instructions and data, such as, for example, a Level <NUM> (L1) internal cache, or multiple levels of internal cache. In some examples, the system may include a combination of an internal cache and an external cache that is external to the core and/or the processor. Alternatively, all of the cache may be external to the core and/or the processor.

<FIG> illustrate a block diagram of a more specific exemplary in-order core architecture, which core would be one of several logic blocks (including other cores of the same type and/or different types) in a chip. The logic blocks communicate through a high-bandwidth interconnect network (e.g., a ring network) with some fixed function logic, memory I/O interfaces, and other necessary I/O logic, depending on the application.

<FIG> is a block diagram of a single processor core, along with its connection to the on-die interconnect network <NUM> and with its local subset of the Level <NUM> (L2) cache <NUM>, according to examples of the disclosure. In one example, an instruction decode unit <NUM> supports the x86 instruction set with a packed data instruction set extension. An L1 cache <NUM> allows low-latency accesses to cache memory into the scalar and vector units. While in one example (to simplify the design), a scalar unit <NUM> and a vector unit <NUM> use separate register sets (respectively, scalar registers <NUM> and vector registers <NUM>) and data transferred between them is written to memory and then read back in from a level <NUM> (L1) cache <NUM>, alternative examples of the disclosure may use a different approach (e.g., use a single register set or include a communication path that allow data to be transferred between the two register files without being written and read back).

The local subset of the L2 cache <NUM> is part of a global L2 cache that is divided into separate local subsets, one per processor core. Each processor core has a direct access path to its own local subset of the L2 cache <NUM>. Data read by a processor core is stored in its L2 cache subset <NUM> and can be accessed quickly, in parallel with other processor cores accessing their own local L2 cache subsets. Data written by a processor core is stored in its own L2 cache subset <NUM> and is flushed from other subsets, if necessary. The ring network ensures coherency for shared data. The ring network is bi-directional to allow agents such as processor cores, L2 caches and other logic blocks to communicate with each other within the chip. Each ring data-path is <NUM>-bits wide per direction.

<FIG> is an expanded view of part of the processor core in <FIG> according to examples of the disclosure. <FIG> includes an L1 data cache 1006A part of the L1 cache <NUM>, as well as more detail regarding the vector unit <NUM> and the vector registers <NUM>. Specifically, the vector unit <NUM> is a <NUM>-wide vector processing unit (VPU) (see the <NUM>-wide ALU <NUM>), which executes one or more of integer, single-precision float, and double-precision float instructions. The VPU supports swizzling the register inputs with swizzle unit <NUM>, numeric conversion with numeric convert units 1022A-B, and replication with replication unit <NUM> on the memory input. Write mask registers <NUM> allow predicating resulting vector writes.

<FIG> is a block diagram of a processor <NUM> that may have more than one core, may have an integrated memory controller, and may have integrated graphics according to examples of the disclosure. The solid lined boxes in <FIG> illustrate a processor <NUM> with a single core 1102A, a system agent <NUM>, a set of one or more bus controller units <NUM>, while the optional addition of the dashed lined boxes illustrates an alternative processor <NUM> with multiple cores 1102A-N, a set of one or more integrated memory controller unit(s) <NUM> in the system agent unit <NUM>, and special purpose logic <NUM>.

Thus, different implementations of the processor <NUM> may include: <NUM>) a CPU with the special purpose logic <NUM> being integrated graphics and/or scientific (throughput) logic (which may include one or more cores), and the cores 1102A-N being one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, a combination of the two); <NUM>) a coprocessor with the cores 1102A-N being a large number of special purpose cores intended primarily for graphics and/or scientific (throughput); and <NUM>) a coprocessor with the cores 1102A-N being a large number of general purpose in-order cores. Thus, the processor <NUM> may be a general-purpose processor, coprocessor or special-purpose processor, such as, for example, a network or communication processor, compression engine, graphics processor, GPGPU (general purpose graphics processing unit), a high-throughput many integrated core (MIC) coprocessor (including <NUM> or more cores), embedded processor, or the like. The processor may be implemented on one or more chips. The processor <NUM> may be a part of and/or may be implemented on one or more substrates using any of a number of process technologies, such as, for example, BiCMOS, CMOS, or NMOS.

The memory hierarchy includes one or more levels of cache within the cores, a set or one or more shared cache units <NUM>, and external memory (not shown) coupled to the set of integrated memory controller units <NUM>. The set of shared cache units <NUM> may include one or more mid-level caches, such as level <NUM> (L2), level <NUM> (L3), level <NUM> (L4), or other levels of cache, a last level cache (LLC), and/or combinations thereof. While in one example a ring based interconnect unit <NUM> interconnects the integrated graphics logic <NUM>, the set of shared cache units <NUM>, and the system agent unit <NUM>/integrated memory controller unit(s) <NUM>, alternative examples may use any number of well-known techniques for interconnecting such units. In one example, coherency is maintained between one or more cache units <NUM> and cores <NUM>-A-N.

In some examples, one or more of the cores 1102A-N are capable of multi-threading. The system agent <NUM> includes those components coordinating and operating cores 1102A-N. The system agent unit <NUM> may include for example a power control unit (PCU) and a display unit. The PCU may be or include logic and components needed for regulating the power state of the cores 1102A-N and the integrated graphics logic <NUM>. The display unit is for driving one or more externally connected displays.

The cores 1102A-N may be homogenous or heterogeneous in terms of architecture instruction set; that is, two or more of the cores 1102A-N may be capable of execution the same instruction set, while others may be capable of executing only a subset of that instruction set or a different instruction set.

<FIG> are block diagrams of exemplary computer architectures. Other system designs and configurations known in the arts for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, micro controllers, cell phones, portable media players, hand held devices, and various other electronic devices, are also suitable. In general, a huge variety of systems or electronic devices capable of incorporating a processor and/or other execution logic as disclosed herein are generally suitable.

Referring now to <FIG>, shown is a block diagram of a system <NUM> in accordance with one example of the present disclosure. The system <NUM> may include one or more processors <NUM>, <NUM>, which are coupled to a controller hub <NUM>. In one example the controller hub <NUM> includes a graphics memory controller hub (GMCH) <NUM> and an Input/Output Hub (IOH) <NUM> (which may be on separate chips); the GMCH <NUM> includes memory and graphics controllers to which are coupled memory <NUM> and a coprocessor <NUM>; the IOH <NUM> is couples input/output (I/O) devices <NUM> to the GMCH <NUM>. Alternatively, one or both of the memory and graphics controllers are integrated within the processor (as described herein), the memory <NUM> and the coprocessor <NUM> are coupled directly to the processor <NUM>, and the controller hub <NUM> in a single chip with the IOH <NUM>. Memory <NUM> may include boot code 1240A, for example, to store code that when executed causes a processor to perform any method of this disclosure.

The optional nature of additional processors <NUM> is denoted in <FIG> with broken lines. Each processor <NUM>, <NUM> may include one or more of the processing cores described herein and may be some version of the processor <NUM>.

The memory <NUM> may be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of the two. For at least one example, the controller hub <NUM> communicates with the processor(s) <NUM>, <NUM> via a multi-drop bus, such as a frontside bus (FSB), point-to-point interface such as Quickpath Interconnect (QPI), or similar connection <NUM>.

In one example, the coprocessor <NUM> is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like. In one example, controller hub <NUM> may include an integrated graphics accelerator.

In one example, the processor <NUM> executes instructions that control data processing operations of a general type. Embedded within the instructions may be coprocessor instructions. The processor <NUM> recognizes these coprocessor instructions as being of a type that should be executed by the attached coprocessor <NUM>. Accordingly, the processor <NUM> issues these coprocessor instructions (or control signals representing coprocessor instructions) on a coprocessor bus or other interconnect, to coprocessor <NUM>. Coprocessor(s) <NUM> accept and execute the received coprocessor instructions.

Referring now to <FIG>, shown is a block diagram of a first more specific exemplary system <NUM> in accordance with an example of the present disclosure. As shown in <FIG>, multiprocessor system <NUM> is a point-to-point interconnect system, and includes a first processor <NUM> and a second processor <NUM> coupled via a point-to-point interconnect <NUM>. Each of processors <NUM> and <NUM> may be some version of the processor <NUM>. In one example of the disclosure, processors <NUM> and <NUM> are respectively processors <NUM> and <NUM>, while coprocessor <NUM> is coprocessor <NUM>. In another example, processors <NUM> and <NUM> are respectively processor <NUM> coprocessor <NUM>.

Processors <NUM> and <NUM> are shown including integrated memory controller (IMC) units <NUM> and <NUM>, respectively. Processor <NUM> also includes as part of its bus controller units point-to-point (P-P) interfaces <NUM> and <NUM>; similarly, second processor <NUM> includes P-P interfaces <NUM> and <NUM>. Processors <NUM>, <NUM> may exchange information via a point-to-point (P-P) interface <NUM> using P-P interface circuits <NUM>, <NUM>. As shown in <FIG>, IMCs <NUM> and <NUM> couple the processors to respective memories, namely a memory <NUM> and a memory <NUM>, which may be portions of main memory locally attached to the respective processors.

Processors <NUM>, <NUM> may each exchange information with a chipset <NUM> via individual P-P interfaces <NUM>, <NUM> using point to point interface circuits <NUM>, <NUM>, <NUM>, <NUM>. Chipset <NUM> may optionally exchange information with the coprocessor <NUM> via a high-performance interface <NUM>. In one example, the coprocessor <NUM> is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like.

In one example, first bus <NUM> may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another third generation I/O interconnect bus, although the scope of the present disclosure is not so limited.

As shown in <FIG>, various I/O devices <NUM> may be coupled to first bus <NUM>, along with a bus bridge <NUM> which couples first bus <NUM> to a second bus <NUM>. In one example, one or more additional processor(s) <NUM>, such as coprocessors, high-throughput MIC processors, GPGPU's, accelerators (such as, e.g., graphics accelerators or digital signal processing (DSP) units), field programmable gate arrays, or any other processor, are coupled to first bus <NUM>. In one example, second bus <NUM> may be a low pin count (LPC) bus. Various devices may be coupled to a second bus <NUM> including, for example, a keyboard and/or mouse <NUM>, communication devices <NUM> and a storage unit <NUM> such as a disk drive or other mass storage device which may include instructions/code and data <NUM>, in one example. Further, an audio I/O <NUM> may be coupled to the second bus <NUM>. Note that other architectures are possible. For example, instead of the point-to-point architecture of <FIG>, a system may implement a multi-drop bus or other such architecture.

Referring now to <FIG>, shown is a block diagram of a second more specific exemplary system <NUM> in accordance with an example of the present disclosure. Like elements in <FIG> and <FIG> bear like reference numerals, and certain aspects of <FIG> have been omitted from <FIG> in order to avoid obscuring other aspects of <FIG>.

Referring now to <FIG>, shown is a block diagram of a SoC <NUM> in accordance with an example of the present disclosure. Similar elements in <FIG> bear like reference numerals. Also, dashed lined boxes are optional features on more advanced SoCs. In <FIG>, an interconnect unit(s) <NUM> is coupled to: an application processor <NUM> which includes a set of one or more cores 202A-N and shared cache unit(s) <NUM>; a system agent unit <NUM>; a bus controller unit(s) <NUM>; an integrated memory controller unit(s) <NUM>; a set or one or more coprocessors <NUM> which may include integrated graphics logic, an image processor, an audio processor, and a video processor; an static random access memory (SRAM) unit <NUM>; a direct memory access (DMA) unit <NUM>; and a display unit <NUM> for coupling to one or more external displays. In one example, the coprocessor(s) <NUM> include a special-purpose processor, such as, for example, a network or communication processor, compression engine, GPGPU, a high-throughput MIC processor, embedded processor, or the like.

Examples (e.g., of the mechanisms) disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementation approaches. Examples of the disclosure may be implemented as computer programs or program code executing on programmable systems comprising at least one processor, a storage system (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device.

One or more aspects of at least one example may be implemented by representative instructions stored on a machine-readable medium which represents various logic within the processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein.

Accordingly, examples of the disclosure also include non-transitory, tangible machine-readable media containing instructions or containing design data, such as Hardware Description Language (HDL), which defines structures, circuits, apparatuses, processors and/or system features described herein. Such examples may also be referred to as program products.

Claim 1:
A system (<NUM>) comprising:
a processor core (<NUM>(<NUM>), <NUM>(<NUM>));
a cache (<NUM>, <NUM>) coupled to the processor core (<NUM>(<NUM>), <NUM>(<NUM>));
characterized in that the system (<NUM>) further comprises:
a controller circuit (<NUM>) to load a hardware initialization code into a portion of the cache (<NUM>, <NUM>) before beginning execution of the hardware initialization code after a power on of the system (<NUM>);
wherein the processor core (<NUM>(<NUM>), <NUM>(<NUM>)) is one of a plurality of processor cores, and the hardware initialization code executes on the plurality of processor cores in parallel using the portion of the cache (<NUM>, <NUM>) as the memory, wherein the cache (<NUM>, <NUM>) is shared by the plurality of processor cores and a graphics core.