Virtualized cache

By dividing the L1 cache into multiple logical L1 caches and utilizing synonym addresses of the external memory system, the problem of L1 cache synonym limitation is solved, and the computing performance and efficiency of the consistency protocol are improved.

CN120653584APending Publication Date: 2025-09-16SIFIVE INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510661833.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2019-11-25
Filing Date
2020-11-24
Publication Date
2025-09-16

AI Technical Summary

Technical Problem

In the prior art, the synonym problem of L1 cache limits the cache size, resulting in a limited SRAM tag array depth, which affects computing performance and pipeline efficiency.

Method used

Coherency management is performed with the L2 cache by splitting the L1 cache into multiple logical L1 caches that share the same underlying physical implementation and utilize the external memory system to disambiguate via synonym addresses (SAs).

Benefits of technology

Enables secure synonym management for larger L1 caches, reducing pipeline impact and improving computational performance and the efficiency of the coherence protocol.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120653584A_ABST
    Figure CN120653584A_ABST
Patent Text Reader

Abstract

The invention relates to a virtualized cache. Systems and methods for virtualizing a cache are disclosed. For example, an integrated circuit (e.g., a processor) for executing instructions includes a virtually indexed physically tagged first level (L1) cache configured to output one or more bits of a virtual index of a cache access to an external memory system as one or more bits of a requester identifier. For example, an L1 cache may be configured to operate as a plurality of logical L1 caches having a cache path having a size less than or equal to a virtual memory page size. For example, an integrated circuit may include an L2 cache of an external memory system configured to receive a requester identifier and implement a cache coherency protocol to disambiguate L1 synonyms occurring in multiple portions of a virtually indexed physically tagged L1 cache associated with different requester identifier values.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application is a divisional application of the application with PCT application number PCT / US2020 / 061983, international application date November 24, 2020, Chinese application number 202080080524.X, and invention name “Virtualized Cache”, which entered the Chinese national phase on May 20, 2022. Technical Field

[0002] The present disclosure relates to virtualized caches. Background Art

[0003] Integrated circuits are typically designed and tested in a multi-step process that involves multiple specialized engineers performing various design and verification tasks on the IC design. These engineers typically use a variety of in-house or proprietary (e.g., company-specific) IC design tool chains to handle different parts of the IC design workflow using commercial electronic design automation (EDA) tools. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The present disclosure will be best understood from the following detailed description when read in conjunction with the accompanying drawings. It should be emphasized that, according to common practice, the various features of the drawings are not drawn to scale. Instead, the sizes of the various features are arbitrarily expanded or reduced for clarity.

[0005] Figure 1 is a block diagram of an example integrated circuit for executing instructions using a virtualized cache.

[0006] Figure 2 is a diagram illustrating examples of effective memory addresses for accessing memory through a virtualized cache.

[0007] Figure 3 is a block diagram of an example of a system for facilitating the design and fabrication of integrated circuits.

[0008] Figure 4 is a block diagram of an example of a system for facilitating integrated circuit design.

[0009] Figure 5 is a flow chart of an example of a process for generating an integrated circuit design including a processor core with a virtualized L1 cache based on design parameters that specify multiple logical L1 caches for the processor core. DETAILED DESCRIPTION

[0010] Overview

[0011] In some microprocessor level 1 (L1) caches, a virtual address can be used to index the cache static random access memory (SRAM), and the corresponding physical address can be used to tag the entry (i.e., a virtually indexed physically tagged (VIPT) cache). Because the virtual address is available earlier, using the virtual address for indexing allows designs that overlap or parallelize physical address computation (e.g., using a translation lookaside buffer (TLB)) and cache accesses. However, using a VIPT cache can introduce the possibility of synonyms, where the same physical cache block appears at two different virtual indices in the cache, depending on the active virtual-to-physical translation.

[0012] One solution to the synonym problem is to limit the L1 cache size to no larger than the virtual memory page size (e.g., 4KiB, 8KiB, 16KiB, or 64KiB) multiplied by the number of ways in the L1 cache. For example, in a system with 4KiB pages and a 4-way set-associative L1 cache, the L1 cache size would be limited to 16KiB. Limiting the cache size to the virtual memory page size multiplied by the number of ways in the cache works because the index bits of the virtual and physical addresses are the same below the virtual memory page size. However, for larger caches, limiting the cache way size to the virtual memory page size may require using more ways and checking more candidate tags. Limiting the cache way size to the virtual memory page size also limits the depth of the SRAM tag array (e.g., to 64 entries in a typical system with 64-byte cache blocks).

[0013] Described herein are techniques to overcome this limitation by splitting the L1 cache into multiple logical L1 caches that share the same underlying physical implementation. As a normal consequence of cache coherence, these techniques can use the L2 cache to disambiguate L1 synonyms. In some implementations, these techniques enable the L1 cache to safely store two shared synonyms. Compared to way speculation, these techniques are simpler and can reduce or eliminate pipeline impact.

[0014] There are three key observations that underlie this approach. First, external memory systems typically have the ability to resolve ownership conflicts between multiple cores with corresponding L1 caches. Second, only the upper bits of a virtual address can actually cause synonyms. Third, synonyms are relatively uncommon in real software because physical pages shared between processes are likely to be similarly aligned. For example, larger RISC-V mega / gigapage mappings are always more aligned.

[0015] For example, in an L1 cache with 8KiB per way in a system with 4KiB pages, the highest virtual index bit can result in synonyms. This highest bit can be called the Synonym Address (SA). To prevent synonyms, requests with SA = 0 can be processed as coming from logical L1 cache ID = 0, and requests with SA = 1 can be processed as coming from logical L1 cache ID = 1. If another core with the same L1 cache configuration exists, it will use cache IDs 2 and 3, respectively. When Core 1 requests a cache block owned by Core 2, the external memory system must probe Core 2 to retrieve permissions for the block. Similarly, if synonyms exist, when Core 1 with ID = 0 requests a block, if the block is owned by the same core but under ID = 1, the memory system will probe Core 1. In other words, whenever a synonym is created in the L1 cache, the external memory subsystem eliminates the second copy via loopback probing. An implementation supporting two logical L1 caches associated with a core can use the same coherency policy used between Cores 1 and 2.

[0016] These techniques can work similarly to the modified exclusive shared invalidate (MESI) scheme. In this scenario, two synonyms can both be in a shared state. When one copy is updated, the other copy is invalidated by a loopback probe. In a modified exclusive shared invalidate (MOESI) system, "transfers" between virtual L1 caches on the same core cover short distances. For example, in an update-based system, synonyms can be transferred between virtual L1 caches on the same core, and the L2 cache directory is then notified of the transfer.

[0017] In some embodiments, the external memory system is automatically configured to accommodate a variable number of L1 caches. Thus, this technique can operate without changing the L2 caches, physical topology, or underlying coherence protocol. In some embodiments, the only change is that the parameterization describing the L1 cache to the memory system now describes two L1 caches.

[0018] For directory-based L2 cache implementations, the physical consequence of this technique is that the L2 cache now maintains more ownership bits (e.g., two ownership bits) for each inner cache, where it previously stored one ownership bit. This is not particularly expensive given the relative size of the tags.

[0019] Implementing these techniques in an L1 cache simply requires that requests from the L1 cache indicate which "virtual L1 cache" the request originated from. Most coherence protocols (e.g., TileLink) include some form of requestor identifier. Therefore, this identifier is expanded by the number of bits in the synonym address (SA) (e.g., 1 or 2 bits), and this value is derived from the SA. Conversely, when receiving a probe request, the L1 cache must retrieve the SA from the destination identifier and use it as the high bit(s) when checking the state of the cache block. In some implementations, no other changes to the L1 cache are required.

[0020] These techniques can be extended to more than a single SA bit. For example, to support 16KiB per way with a 4KiB virtual memory page size, two SA bits can be used. For example, there can be four virtual L1 caches, and the L2 cache can include four ownership bits per L1 cache. Larger synonym addresses can be used (e.g., 3 bits), but increasing the number of SA bits results in an exponential increase in the cost in the L2 cache directory. In some embodiments, if the exponential increase in cost in the L2 cache directory is undesirable, the directory can be forced to be excluded in the virtual L1 cache, allowing the cost to grow linearly with the number of SA bits. These techniques can be combined with way speculation to implement a large VIPT L1 cache.

[0021] These techniques can be applied to most coherence protocols (e.g., TileLink).

[0022] These techniques can be applied to most consistency policies (e.g., MOESI, MESI, and MI).

[0023] These techniques can be applied to a coherent VIPT L1 instruction cache and a VIPT L1 data cache. These techniques can be applied to a virtually indexed, virtually tagged (VIVT) L1 instruction cache and a VIVT L1 data cache. These techniques can be applied to a virtually indexed or virtually tagged L2 cache, or at any level other than L1 or L2.

[0024] Some of these techniques can be combined with any coherent storage system, not just directory-based ones.

[0025] As used herein, the term "circuit" refers to an arrangement of electronic components (e.g., transistors, resistors, capacitors, and / or inductors) configured to implement one or more functions. For example, a circuit may include one or more transistors interconnected to form logic gates that collectively implement a logic function.

[0026] detail

[0027] Figure 1 is a block diagram of an example of an integrated circuit 110 for executing instructions using a virtualized cache. The integrated circuit 110 includes a processor core (e.g., an IP core) that includes a physical L1 cache 130. The physical L1 cache 130 is configured to include multiple logical L1 caches, a logical L1 cache A 132 and a logical L1 cache B 134. The integrated circuit 110 also includes an external memory system 140. In this example, the external memory system 140 includes an L2 cache 150, which can be configured to implement a cache coherence protocol / policy to maintain cache coherence across the multiple L1 caches. In this example, the L2 cache 150 includes ownership bits 160 for the multiple logical L1 caches, including the logical L1 cache A 132 and the logical L1 cache B 134. Although in Figure 1 Although not shown, in some embodiments, integrated circuit 110 may include multiple processor cores. Figure 1 Not shown, but the external memory system 140 may include multiple layers.

[0028] The physical L1 cache 130 may be configured to output one or more bits of a virtual index (e.g., a synonym address (SA)) of a cache access to the external memory system 140 as one or more bits of a requestor identifier. In some embodiments, the physical L1 cache 130 is configured to receive one or more bits of a destination identifier of a probe request from the external memory system 140 and use the one or more bits of the destination identifier as part of an index (e.g., as a synonym address) to check the status of a cache block. For example, the physical L1 cache may be a virtually indexed L1 cache (e.g., a VIPT or VIVT cache). For example, the logical L1 cache A 132 and the logical L1 cache B 134 may have a cache way size that is less than or equal to the virtual memory page size used by the processor core 120. For example, the size of the cache way in the physical L1 cache 130 may be equal to twice the virtual memory page size used by the processor core 120 of the integrated circuit 110 associated with the physical L1 cache 130, and the one or more bits of the virtual index may be a single bit. Although in Figure 1 Although not shown in the example, the physical L1 cache can be divided into more than two logical caches (e.g., four logical caches) to support even larger physical cache sizes. For example, the physical L1 cache can be a data cache. For example, the physical L1 cache can be an instruction cache.

[0029] L2 cache 150 may be configured to receive a requestor identifier and implement a cache coherence protocol to disambiguate L1 synonyms that appear in multiple portions of physical L1 cache 130 (e.g., logical L1 cache A 132 and logical L1 cache B 134) associated with different requestor identifier values. For example, L2 cache 150 may include an ownership bit 160 corresponding to each of the multiple portions of physical L1 cache 130 (e.g., logical L1 cache A 132 and logical L1 cache B 134) associated with different requestor identifier values. For example, L2 cache 150 may be directory-based.

[0030] Figure 2 1 is a schematic diagram illustrating an example of an effective memory address 200 for accessing memory via a virtualized cache (e.g., physical L1 cache 130). Effective memory address 200 includes a cache block offset 210, a virtual index 220 used to select a cache block for access by a processor core (e.g., processor core 120), and a tag 230 (e.g., a physical tag or a virtual tag). Virtual index 220 includes a synonym address 240 (SA), which includes one or more bits that can be used to select from multiple logical caches within the physical cache. For example, synonym address 240 can be a single bit used to select from two logical caches. For example, synonym address 240 can be a pair of bits that select from four logical caches. Synonymous address 240 can be used to determine a requestor identifier for a logical cache of the physical cache, which is used to identify the logical cache associated with a cache access operation when communicating with an external memory system (e.g., external memory system 140).

[0031] Figure 3 3 is a block diagram of an example of a system 300 for facilitating the design and manufacture of integrated circuits. System 300 includes a network 306, an integrated circuit design service infrastructure 310, an FPGA / simulator server 320, and a manufacturer server 330. For example, a user can utilize a network client or a scripting API client to instruct the integrated circuit design service infrastructure 310 to automatically generate an integrated circuit design based on a set of design parameter values ​​selected by the user for one or more template integrated circuit designs. In some embodiments, the integrated circuit design service infrastructure 310 can be configured to automatically generate an integrated circuit design (e.g., encoded in a register transfer logic data structure, a field programmable gate array simulation data structure, and / or a physical design data structure, such as a GDSII file) that includes a processor core with multiple logical L1 caches.

[0032] For example, the integrated circuit design service infrastructure 310 can invoke (e.g., via network communications over the network 306) a test of the resulting design executed by an FPGA / simulation server 320 running one or more FPGAs or other types of hardware or software simulators. For example, the integrated circuit design service infrastructure 310 can invoke a test using a field programmable gate array (FPGA) programmed with a field programmable gate array simulation data structure to obtain simulation results. The field programmable gate array can be run on the FPGA / simulation server 320, which can be a cloud server. The test results can be returned by the FPGA / simulation server 320 to the integrated circuit design service infrastructure 310 and relayed to the user in a useful format (e.g., via a web client or scripting API client).

[0033] The integrated circuit design service infrastructure 310 may also facilitate the fabrication of integrated circuits using integrated circuit designs in fabrication facilities associated with the manufacturer server 330. In some embodiments, a physical design specification (e.g., a GDSII file) based on the physical design data structure of the integrated circuit is sent to the manufacturer server 330 to initiate fabrication of the integrated circuit (e.g., using the associated manufacturer's fabrication equipment). For example, the manufacturer server 330 may host a foundry tapeout website configured to receive the physical design specification (e.g., as a GDSII file or OASIS file) to schedule or otherwise facilitate the fabrication of the integrated circuit. In some embodiments, the integrated circuit design service infrastructure 310 supports multi-tenancy to allow multiple integrated circuit designs (e.g., from one or more users) to share fixed costs of fabrication (e.g., reticle / mask generation and / or shuttle wafer testing). For example, the integrated circuit design service infrastructure 310 may utilize a fixed package (e.g., a quasi-standardized package) that is defined to reduce fixed costs and facilitate the sharing of reticle / mask, wafer testing, and other fixed manufacturing costs. For example, a physical design specification may include one or more physical designs from one or more corresponding physical design data structures to facilitate multi-tenant fabrication.

[0034] In response to the transmission of the physical design specifications, a manufacturer associated with the manufacturer server 330 may fabricate and / or test integrated circuits based on the integrated circuit design. For example, the associated manufacturer (e.g., a foundry) may perform optical proximity correction (OPC) and similar post-tapeout / pre-production processing, fabricate the integrated circuit(s) 332, periodically or asynchronously update the integrated circuit design service infrastructure 310 (e.g., via communication with a controller or a web application server) regarding the status of the fabrication process, perform appropriate testing (e.g., wafer testing), and send the integrated circuits to the packaging house for packaging. The packaging house may receive the completed wafers or dies from the manufacturer and test the materials, and periodically or asynchronously update the integrated circuit design service infrastructure 310 regarding the status of the packaging and delivery process. In some embodiments, status updates may be relayed to users when they register using a web interface, and / or the controller may notify users via email when updates are available.

[0035] In some embodiments, the resulting integrated circuits 332 (e.g., physical chips) are delivered (e.g., by mail) to a silicon test service provider associated with the silicon test server 340. In some embodiments, the resulting integrated circuits 332 (e.g., physical chips) are installed in a system controlled by the silicon test server 340 (e.g., a cloud server) so that they can be quickly accessed to be run and tested remotely using network communications to control the operation of the integrated circuits 332. For example, a login to the silicon test server 340 that controls the fabrication of the integrated circuits 332 can be sent to the integrated circuit design service infrastructure 310 and relayed to the user (e.g., via a web client). For example, the integrated circuit design service infrastructure 310 can implement Figure 5 The process 500 is to automatically generate an integrated circuit design (eg, including register transfer logic data structures and / or physical design data structures) and control the fabrication and silicon testing of one or more integrated circuits 332 that may be constructed based on the integrated circuit design.

[0036] Figure 4 is a block diagram of an example of a system 400 for facilitating integrated circuit design. The system 400 is an example of a system that can be used to integrate the integrated circuit design service infrastructure 310 as a whole or Figure 3 An example of the internal configuration of a computing device implemented by one or more components of the integrated circuit design service infrastructure 310 of the illustrated system 300. The system 400 can include components or units such as a processor 402, a bus 404, a memory 406, peripherals 414, a power supply 416, a network communication interface 418, a user interface 420, other suitable components, or a combination thereof.

[0037] Processor 402 can be a central processing unit (CPU), such as a microprocessor, and can include a single or multiple processors having a single or multiple processing cores. Alternatively, processor 402 can include another type of device, or multiple devices capable of manipulating or processing information. For example, processor 402 can include multiple processors interconnected in any manner, including hardwired or networked, including wirelessly networked. In some embodiments, the operations of processor 402 can be distributed across multiple physical devices or units, which can be coupled directly or via a local area network or other suitable type of network. In some embodiments, processor 402 can include a cache or cache memory for local storage of operating data or instructions.

[0038] Memory 406 can include volatile memory, nonvolatile memory, or a combination thereof. For example, memory 406 can include: volatile memory, such as one or more dynamic random access memory (DRAM) modules, such as double data rate (DDR) synchronous dynamic random access memory (SDRAM); and nonvolatile memory, such as a disk drive, a solid-state drive, flash memory, phase change memory (PCM), or any form of nonvolatile memory capable of persistent electronic information storage, such as in the absence of an active power source. Memory 406 can include another type of device or devices, now existing or later developed, capable of storing data or instructions for processing by processor 402. Processor 402 can access or manipulate data in memory 406 via bus 404. Although in Figure 4 Although shown as a single block in FIG, memory 406 can be implemented as multiple units. For example, system 400 can include volatile memory such as RAM and persistent memory such as a hard drive or other memory.

[0039] Memory 406 can include executable instructions 408; data, such as application data 410 or an operating system 412; or a combination thereof, for immediate access by processor 402. Executable instructions 408 can include, for example, one or more application programs that can be loaded or copied, in whole or in part, from non-volatile memory to volatile memory for execution by processor 402. Executable instructions 408 can be organized into programmable modules or algorithms, functional procedures, codes, code segments, or a combination thereof to perform the various functions described herein. For example, executable instructions 408 can include instructions executable by processor 402 to cause system 400 to automatically generate an integrated circuit design and associated test results based on a design parameter data structure in response to a command. For example, executable instructions 408 can include instructions, such as the Chisel code snippet in Appendix A, for generating an integrated circuit design including a processor core with multiple logical L1 caches based on a set of design parameters. Application data 410 can include, for example, user files, database directories or dictionaries, configuration information, or functional procedures, such as a web browser, a web server, a database server, or a combination thereof. Operating system 412 can be, for example, Microsoft Windows®, Mac OS X®, or Linux®; an operating system for a small device such as a smartphone or tablet device; or an operating system for a large device such as a mainframe computer. Memory 406 can include one or more devices and can utilize one or more types of storage, such as solid-state or magnetic storage.

[0040] Peripheral devices 414 can be coupled to processor 402 via bus 404. Peripheral devices 414 can be sensors or detectors, or devices containing any number of sensors or detectors, that can monitor system 400 itself or the environment surrounding system 400. For example, system 400 can contain a temperature sensor for measuring the temperature of a component of system 400, such as processor 402. In some embodiments, power supply 416 can be a battery, and system 400 can operate independently of an external power distribution system. Any component of system 400, such as peripheral devices 414 or power supply 416, can communicate with processor 402 via bus 404.

[0041] The network communication interface 418 can also be coupled to the processor 402 via the bus 404. In some embodiments, the network communication interface 418 can include one or more transceivers. The network communication interface 418 can, for example, provide a connection or link to a network, such as the network 306, via a network interface, which can be a wired network interface such as Ethernet or a wireless network interface. For example, the system 400 can communicate with other devices via the network communication interface 418 and a network interface using one or more network protocols, such as Ethernet, TCP, IP, power line communication (PLC), WiFi, infrared, GPRS, GSM, CDMA, or other suitable protocols.

[0042] User interface 420 can include: a display; a pointing input device such as a mouse, touchpad, or touchscreen; a keyboard; or other suitable human or machine interface devices. User interface 420 can be coupled to processor 402 via bus 404. In addition to or in lieu of a display, other interface devices can be provided to allow a user to program or otherwise use system 400. In some embodiments, user interface 420 can include a display, which can be a liquid crystal display (LCD), a cathode ray tube (CRT), a light-emitting diode (LED) display (e.g., an OLED display), or other suitable display. In some embodiments, a client or server can omit peripheral device 414. The operations of processor 402 can be distributed across multiple clients or servers, which can be coupled directly or via a local area network or other suitable type of network. Memory 406 can be distributed across multiple clients or servers, such as network-based storage or storage within multiple clients or servers performing client or server operations. Although depicted here as a single bus, bus 404 can be comprised of multiple buses, which can be interconnected via various bridges, controllers, or adapters.

[0043] Figure 5is a flow chart of an example of a process 500 for generating an integrated circuit design that includes a processor core with a virtualized L1 cache based on design parameters that specify multiple logical L1 caches for the processor core. The process 500 includes: accessing 510 design parameters for the processor core, the design parameters indicating a multiple logical L1 caches to be included in the processor core; automatically generating 520 a register transfer logic data structure that specifies an integrated circuit design that includes the processor core with the multiple logical L1 caches based on the design parameters; storing 530 the register transfer logic data structure; automatically generating 540 a physical design data structure that specifies an integrated circuit design that includes the processor core with the multiple logical L1 caches based on the register transfer logic data structure; and, based on the physical design data structure, invoking 550 fabrication of an integrated circuit that includes the processor core with the multiple logical L1 caches. For example, the process 500 may be performed by Figure 3 For example, the process 500 may be implemented by the integrated circuit design service infrastructure 310 of FIG. Figure 4 The system 400 is implemented.

[0044] Process 500 includes accessing 510 design parameters for a processor core, the design parameters indicating a number of logical L1 caches to be included in the processor core. In some embodiments, the design parameters may include a count of logical caches to be included in the processor core (e.g., an IP core). In some embodiments, the design parameters may include a size of the logical caches to be included in the processor core. In some embodiments, the design parameters may include a virtual memory page size for the processor core. For example, the design parameters may be accessed 510 by receiving the design parameters (e.g., via network communication using network communication interface 418). For example, the design parameters may be accessed 510 by reading the design parameters from memory (e.g., from memory 406 via bus 404).

[0045] Process 500 includes automatically generating 520 a register transfer logic data structure (e.g., a file, database, repository, or bitstream) that specifies an integrated circuit design including a processor core (e.g., processor core 120) having multiple logical L1 caches (e.g., logical L1 cache A 132 and logical L1 cache B 134) based on design parameters. For example, automatically generating 520 a register transfer logic data structure for the integrated circuit design may include invoking a register transfer level service with input data based on the design parameters. For example, the multiple logical L1 caches of the processor core may be multiple portions of a single physical L1 cache in the processor core. For example, the multiple logical L1 caches of the processor core may each have a cache way size equal to a virtual memory page size used by the processor core. In some embodiments, the multiple logical L1 caches of the processor core are virtually indexed, physically tagged caches. In some embodiments, automatically generating 520 the register transfer logic data structure includes executing Chisel code (e.g., including the code snippet in Appendix A) that takes the design parameters as input.

[0046] Process 500 includes storing 530 a register transfer logic data structure (e.g., a file, a database, a repository, or a bitstream). For example, the register transfer level data structure may be stored 530 in a memory (e.g., the memory 406). For example, the register transfer level data structure may be sent to an external device (e.g., a personal computing device) for display or storage. For example, the register transfer level data structure may be sent via a network communication interface (e.g., the network communication interface 418).

[0047] The process 500 includes automatically generating 540 a physical design data structure (e.g., a physical design file) based on a register transfer logic data structure, the physical design data structure specifying an integrated circuit design including a processor core having a plurality of logical L1 caches. For example, generating 540 the physical design data structure for the integrated circuit may include invoking a physical design service using data based on the register transfer level data structure and / or the design parameter data structure. For example, generating 540 the physical design data structure for the integrated circuit may include invoking a synthesis and place-and-route tool (e.g., Synopsys TM 、Cadence TM and / or Mentor TMtools). For example, generating 540 the physical design data structure for the integrated circuit may include performing a logical equivalence check. For example, generating 540 the physical design data structure for the integrated circuit may include invoking a static timing analysis tool. For example, generating 540 the physical design data structure for the integrated circuit may include performing a design rule check (DRC) and / or a layout and schematic (LVS) check. For example, generating 540 the physical design data structure for the integrated circuit may include determining power, performance, and area estimates for the resulting integrated circuit design and providing these estimates as feedback to a user (e.g., a user of a web client). For example, the physical design data structure may include, in non-technical terms, whether there are any issues with the physical design. For example, the physical design data structure may highlight important components of the output of a synthesis and place-and-route tool. For example, the physical design data structure may include a GDSII file or an OASIS file. For example, generating 540 the physical design data structure for the integrated circuit may include managing and orchestrating a physical design tool chain in the cloud. For example, generating 540 the physical design data structure for the integrated circuit may include handling database movement from tool to tool and managing access to third-party IP cores. For example, generating 540 the physical design data structure for the integrated circuit may include accessing template designs, which may allow for significant design reuse. For example, generating 540 a physical design data structure for an integrated circuit may include identifying those combinations to reduce effort. For example, generating 540 a physical design data structure for an integrated circuit may provide better or more compact error / problem reporting by converting tool issues into manageable feedback and providing the actual errors / output of the tool to a user (e.g., a user of a web client) in a deliverable format.

[0048] Process 500 includes initiating 550 fabrication of an integrated circuit based on a physical design data structure, the integrated circuit including a processor core having multiple logical L1 caches. In some embodiments, a physical design specification (e.g., a GDSII file) based on the physical design data structure for the integrated circuit is sent via a network (e.g., network 306) to a manufacturer server (e.g., manufacturer server 330) to initiate 550 fabrication of the integrated circuit (e.g., using fabrication equipment of an associated manufacturer). For example, manufacturer server 330 may host a foundry tapeout website configured to receive the physical design specification (e.g., as a GDSII file or OASIS file) to schedule or otherwise facilitate fabrication of the integrated circuit. In some embodiments, fabrication of the integrated circuit may be initiated 550 by directly controlling the fabrication equipment (e.g., via communication via a bus or serial port).

[0049] It should be noted that one or more steps of process 500 may be omitted. For example, steps 540 and / or 550 may be omitted. One or more steps may be added to process 500, such as automatically generating a software development kit (SDK), documentation, field programmable gate array simulation data structures, and / or a test plan for an integrated circuit design, and / or invoking a test of the integrated circuit and receiving a test result data structure.

[0050] In a first aspect, the subject matter described in this specification can be embodied in an integrated circuit for executing instructions, the integrated circuit comprising a virtually indexed, physically tagged L1 cache configured to output one or more bits of a virtual index of a cache access as one or more bits of a requestor identifier to an external memory system.

[0051] In a first aspect, an integrated circuit may include an L2 cache of an external memory system configured to receive a requestor identifier and implement a cache coherence protocol to disambiguate L1 synonyms that appear in multiple portions of a virtually indexed, physically tagged L1 cache associated with different requestor identifier values. In the first aspect, the L2 cache may include an ownership bit corresponding to each of the multiple portions of the virtually indexed, physically tagged L1 cache associated with different requestor identifier values. In the first aspect, the L2 cache may be directory-based. In the first aspect, the virtually indexed, physically tagged L1 cache may be configured to receive one or more bits of a destination identifier for a snoop request from the external memory system and use the one or more bits of the destination identifier as part of an index to check a cache block status. In the first aspect, a cache way size in the virtually indexed, physically tagged L1 cache is equal to twice the size of a virtual memory page used by a core of the integrated circuit associated with the virtually indexed, physically tagged L1 cache, and the one or more bits of the virtual index are single bits. In some embodiments, the size of a cache way in a virtually indexed physically tagged L1 cache is equal to four times the size of a virtual memory page used by a core of an integrated circuit associated with the virtually indexed physically tagged L1 cache, and one or more bits of the virtual index are two bits. In a first aspect, the virtually indexed physically tagged L1 cache can be a data cache. In a first aspect, the virtually indexed physically tagged L1 cache can be an instruction cache. The first aspect can include any combination of the features described in this paragraph.

[0052] In a second aspect, the subject matter described in this specification can be embodied in a method comprising the steps of: accessing design parameters of a processor core, the design parameters indicating a number of logical L1 caches to be included in the processor core; automatically generating a register transfer logic data structure specifying an integrated circuit design based on the design parameters, the integrated circuit design including the processor core having the plurality of logical L1 caches; and storing the register transfer logic data structure.

[0053] In a second aspect, the multiple logical L1 caches of a processor core may be portions of a single physical L1 cache in the processor core. In some embodiments, the multiple logical L1 caches of the processor core each have a cache way size equal to the size of a virtual memory page used by the processor core. In a second aspect, the multiple logical L1 caches of the processor core may be virtually indexed physically tagged caches. In some embodiments, automatically generating a register transfer logic data structure includes executing Chisel code that takes design parameters as input. In a second aspect, automatically generating the register transfer logic data structure may include executing the Chisel code snippet of Appendix A. In some embodiments, the method further includes: automatically generating a physical design data structure based on the register transfer logic data structure, which specifies an integrated circuit design including a processor core having multiple logical L1 caches. In some embodiments, the method further includes: invoking fabrication of an integrated circuit including a processor core having multiple logical L1 caches based on the physical design data structure. The second aspect may include any combination of the features described in this paragraph.

[0054] In a third aspect, the subject matter described herein can be embodied in a system comprising a memory and a processor, wherein the memory comprises instructions executable by the processor to cause the system to: access design parameters of a processor core, the design parameters indicating a number of logical L1 caches to be included in the processor core; based on the design parameters, automatically generate a register transfer logic data structure specifying an integrated circuit design, the integrated circuit design including the processor core having the plurality of logical L1 caches; and store the register transfer logic data structure. In some embodiments, the memory comprises instructions executable by the processor to cause the system to: automatically generate a physical design data structure specifying an integrated circuit design, based on the register transfer logic data structure, the integrated circuit design including the processor core having the plurality of logical L1 caches.

[0055] In a third aspect, a memory may include instructions executable by a processor to cause a system to: based on a physical design data structure, invoke a design of an integrated circuit comprising a processor core having a plurality of logical L1 caches. In the third aspect, the plurality of logical L1 caches of the processor core may be portions of a single physical L1 cache in the processor core. In some embodiments, the plurality of logical L1 caches of the processor core each have a cache way size equal to a virtual memory page size used by the processor core. In the third aspect, the plurality of logical L1 caches of the processor core may be virtually indexed physically tagged caches. In some embodiments, automatically generating a register transfer logic data structure includes executing Chisel code having design parameters as input. For example, the memory may include the Chisel code snippet of Appendix A. The third aspect may include any combination of the features described in this paragraph.

[0056] In a fourth aspect, the subject matter described in this specification can be embodied in a non-transitory computer-readable storage medium comprising instructions that, when executed by a processor, facilitate performing operations comprising: accessing design parameters for a processor core, the design parameters indicating a number of logical L1 caches to be included in the processor core; automatically generating a register transfer logic data structure specifying an integrated circuit design based on the design parameters, the integrated circuit design including a processor core having the plurality of logical L1 caches; and storing the register transfer logic data structure.

[0057] In a fourth aspect, the multiple logical L1 caches of a processor core can be portions of a single physical L1 cache in the processor core. In some embodiments, the multiple logical L1 caches of the processor core each have a cache way size equal to the virtual memory page size used by the processor core. In a fourth aspect, the multiple logical L1 caches of the processor core can be virtually indexed physically tagged caches. In some embodiments, automatically generating a register transfer logic data structure includes executing Chisel code that takes design parameters as input. For example, a non-transitory computer-readable storage medium can store the Chisel code snippet of Appendix A. In some embodiments, the non-transitory computer-readable storage medium includes instructions that, when executed by a processor, facilitate performing operations comprising: automatically generating a physical design data structure for a specified integrated circuit design based on the register transfer logic data structure, the integrated circuit design including a processor core having multiple logical L1 caches. The fourth aspect can include any combination of the features described in this paragraph.

[0058] While the present disclosure has been described in conjunction with certain embodiments, it should be understood that the present disclosure is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims, which scope should be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures.

[0059] Appendix A

[0060] packagesifive.enterprise.core.bullet

[0061] import chisel3._

[0062] import freechips.rocketchip.util._

[0063] import freechips.rocketchip.tile.HasTileParameters

[0064] import freechips.rocketchip.tilelink._

[0065] import freechips.rocketchip.diplomacy._

[0066] import freechips.rocketchip.config.Parameters

[0067] class DCache(hartid: Int, crossing: ClockCrossingType)(implicit p:Parameters)

[0068] extends freechips.rocketchip.rocket.DCache(hartid, crossing)(p) withHasTileParameters {

[0069] override protected def cacheClientParameters = cfg.scratch.map(x =>Seq()).getOrElse {

[0070] val untagBits = lgCacheBlockBytes + cfg.nSets.log2

[0071] val nCacheClients = if (usingVM) 1 << (0 max (untagBits - pgIdxBits))else 1

[0072] (0 until nCacheClients).map(i =>

[0073] TLClientParameters(

[0074] name= s"Core ${hartid} DCache",

[0075] sourceId= IdRange(i, i + 1),

[0076] supportsProbe = TransferSizes(cfg.blockBytes, cfg.blockBytes)))}

[0077] override lazy val module = new DCacheModule(this)

[0078] }

[0079] class DCacheModule(outer: DCache) extends freechips.rocketchip.rocket.DCacheModule(outer) {

[0080] override def tagLSB: Int = if (usingVM) untagBits min pgIdxBits elseuntagBits

[0081] override def probeIdx(b: TLBundleB): UInt =

[0082] b.source.extractOption(untagBits-tagLSB-1, 0) ## b.address(tagLSB-1,idxLSB)

[0083] override def addressToProbe(vaddr: UInt, paddr: UInt): TLBundleB = {

[0084] val res = Wire(new TLBundleB(edge.bundle), chisel3.DontCare)

[0085] res.address := paddr

[0086] res.source := vaddr.extract(untagBits-1, tagLSB)

[0087] res

[0088] }

[0089] override def acquire(vaddr: UInt, paddr: UInt, param: UInt):TLBundleA = {

[0090] val block_addr = paddr >> lgCacheBlockBytes << lgCacheBlockBytes

[0091] if (!edge.manager.anySupportAcquireT) {

[0092] Wire(new TLBundleA(edge.bundle), DontCare)

[0093] } else {

[0094] edge.AcquireBlock(vaddr.extract(untagBits-1, tagLSB), block_addr,lgCacheBlockBytes.U, param)._2

[0095] }

[0096] }

[0097] }

Claims

1. A method comprising: accessing design parameters of a processor core, the design parameters indicating a number of logical L1 caches to be included in the processor core; automatically generating a register transfer logic data structure for a specified integrated circuit design based on the design parameters, the integrated circuit design including the processor core having a plurality of logical L1 caches; as well as The register transfer logic data structure is stored.

2. The method according to claim 1, wherein The plurality of logical L1 caches of the processor core are parts of a single physical L1 cache in the processor core.

3. The method according to any one of claims 1 to 2, wherein: The plurality of logical L1 caches of the processor core each have a cache way size equal to a virtual memory page size used by the processor core.

4. The method according to any one of claims 1 to 3, wherein: The plurality of logical L1 caches of the processor core are virtually indexed, physically tagged caches.

5. The method according to any one of claims 1 to 4, wherein: Automatically generating the register transfer logic data structure includes executing Chisel code having the design parameters as input.

6. The method according to any one of claims 1 to 5, comprising: A physical design data structure specifying an integrated circuit design including the processor core having a plurality of logical L1 caches is automatically generated based on the register transfer logic data structure.

7. The method according to claim 6, comprising: Fabrication of an integrated circuit is invoked based on the physical design data structure, the integrated circuit including the processor core having a plurality of logical L1 caches.

8. A system comprising: Memory; as well as a processor, wherein the memory includes instructions executable by the processor to cause the system to: accessing design parameters of a processor core, the design parameters indicating a number of logical L1 caches to be included in the processor core; automatically generating a register transfer logic data structure for a specified integrated circuit design based on the design parameters, the integrated circuit design including the processor core having a plurality of logical L1 caches; and The register transfer logic data structure is stored.

9. The system according to claim 8, wherein: The memory includes instructions executable by the processor to cause the system to: A physical design data structure specifying an integrated circuit design including the processor core having a plurality of logical L1 caches is automatically generated based on the register transfer logic data structure.

10. The system according to claim 9, wherein: The memory includes instructions executable by the processor to cause the system to: Fabrication of an integrated circuit is invoked based on the physical design data structure, the integrated circuit including the processor core having a plurality of logical L1 caches.

11. The system according to any one of claims 8 to 10, wherein: The plurality of logical L1 caches of the processor core are parts of a single physical L1 cache in the processor core.

12. The system according to any one of claims 8 to 11, wherein: The plurality of logical L1 caches of the processor core each have a cache way size equal to a virtual memory page size used by the processor core.

13. The system according to any one of claims 8 to 12, wherein: The plurality of logical L1 caches of the processor core are virtually indexed, physically tagged caches.

14. The system according to any one of claims 8 to 13, wherein: Automatically generating the register transfer logic data structure includes executing Chisel code having the design parameters as input.

15. A non-transitory computer-readable storage medium comprising instructions that, when executed by a processor, facilitate performing the following operations, the operations comprising: accessing design parameters of a processor core, the design parameters indicating a number of logical L1 caches to be included in the processor core; automatically generating a register transfer logic data structure for a specified integrated circuit design based on the design parameters, the integrated circuit design including the processor core having a plurality of logical L1 caches; as well as The register transfer logic data structure is stored.

16. The non-transitory computer-readable storage medium of claim 15, wherein: The plurality of logical L1 caches of the processor core are parts of a single physical L1 cache in the processor core.

17. The non-transitory computer-readable storage medium according to any one of claims 15 to 16, wherein: The plurality of logical L1 caches of the processor core each have a cache way size equal to a virtual memory page size used by the processor core.

18. The non-transitory computer-readable storage medium according to any one of claims 5 to 7, wherein: The plurality of logical L1 caches of the processor core are virtually indexed, physically tagged caches.

19. The non-transitory computer-readable storage medium according to any one of claims 15 to 18, wherein: Automatically generating the register transfer logic data structure includes executing Chisel code having the design parameters as input.

20. The non-transitory computer-readable storage medium of any one of claims 15 to 19, comprising instructions that, when executed by a processor, facilitate performing operations comprising: A physical design data structure specifying an integrated circuit design including the processor core having a plurality of logical L1 caches is automatically generated based on the register transfer logic data structure.