Multicore processing and memory array
The MCDM architecture addresses memory bottlenecks in von Neumann systems by distributing core-local memory and eliminating caches, enhancing processing efficiency and adaptability through operation graphs, suitable for existing computing systems.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- TRUSTEES OF DARTMOUTH COLLEGE THE
- Filing Date
- 2022-01-29
- Publication Date
- 2026-05-13
AI Technical Summary
Conventional von Neumann architectures face bottlenecks such as high memory latency, unpredictable memory access times, and the need for large cache structures that consume a significant portion of transistors, limiting processing power and efficiency, especially in multi-core and SIMD architectures like GPUs.
A multi-core distributed memory (MCDM) architecture with core-local memory and a virtually cache-less design, allowing predictable low-latency memory access and adaptive code flow through operation graphs, implemented on a PCIe daughter card compatible with von Neumann systems.
Enables efficient execution of parallel processing with reduced transistor count, lower manufacturing costs, and improved throughput by distributing memory and processing functions across silicon dies, supporting flexible programming techniques like CUDA Graphs.
Smart Images

Figure 0007857950000001 
Figure 0007857950000002 
Figure 0007857950000003
Abstract
Description
Technical Field
[0001] The present invention relates to computer processing and memory architecture using a multi-core configuration. Background of the Invention
[0002] General computing devices (servers, PCs, laptop computers, etc.) are currently constructed using a conventional (e.g.) von Neumann architecture. This generally consists of a conventional processor / CPU, such as those commercially available from Intel, AMD, Qualcomm, etc. The CPU is interconnected with a dynamic RAM (DRAM) or similar "memory" configuration that provides a working memory for data processing to be executed by the CPU. In the initial von Neumann design, this was provided by a tape drive or magnetic core memory. The CPU also incorporates an arithmetic logic unit (ALU) and processor registers. More specifically, such an architecture is characterized by (a) a control unit including an instruction register and a program counter, (b) a memory for storing data and instructions, (c) an external mass storage device (generally) for data not currently being processed by the CPU, and (d) input and output mechanisms.
[0003] Also, a general design defines that a processor core consists of several memory slots called "registers" and a set of indivisible operations, and has code with a relationship between them (in von Neumann code, the relationship is an ordered list). The code is a mixture of three important types of indivisible operations. That is, (a) "Load": Copy memory (at address A) to a register, (b) "Store": Copy a register to memory, and (c) Operation / "Math (calculation, operation)": Operate on data in a register (e.g., add two numbers together to get a total) In this type of architecture, operations (arithmetic operations) must generally be loaded from memory using a single, large memory store (or address space). To avoid using a single memory store for all operations, a restriction must be defined on which operations may share memory (for example, two operations that cannot share memory may use separate memory stores). Thus, the conventional von Neumann architecture faces several theoretical and practical bottlenecks, which include, but are not limited to, (a) the operations themselves must be loaded from memory that occupies substantial processing power; (b) because the required memory address space is large, a simple lookup of content consumes a large block of processor time, and (during this latency / delay) the content at this address cannot be used (similar to picking a randomly selected book from a shelf in the Library of Congress); and (c) because the memory is large, it cannot be fitted onto the same silicon die as the CPU configuration, and therefore requires a physically constrained bus (e.g., copper trace) interface between the CPU and the memory configuration. Literally, modern architectures cannot accommodate enough wires to support high-bandwidth communications. One example of this is high-bandwidth memory (known as "HBM2"), which has a higher bandwidth than commercially available GDDR6 memory, because the manufacturing process has been modified to increase the physical size of the wiring interface.
[0004] Based on the shortcomings mentioned above, computing processors / CPUs dedicate a substantial number of their transistors (usually >90%) to a "cache," which is an active process that effectively provides a scratchpad and also provides copies of memory content that is expected to be needed soon. In particular, reading from the cache is considerably faster than reading from memory. However, if the requested memory content is not in the cache, the architecture must spend the time spent checking the cache plus the full memory latency to find and retrieve the content. Since memory latency differs depending on whether the data being accessed is in the cache or not, memory latency becomes variable and unpredictable. This unpredictability adds further problems to writing code because it is not possible to design the system so that memory content arrives in the register exactly when it is needed (since the arrival itself cannot be accurately predicted). A drawback of cache-based architectures is that the total number of transistors is a significant factor in processor manufacturing costs, and the cache increases the total number of transistors by an order of magnitude.
[0005] Figure 1 shows a typical von Neumann processing configuration 100 as an example. Configuration 100 provides multiple processor cores / CPUs 110, all exemplified on a common or single die 120, governed by a data cache structure 112. The number of cores 110 and the size of the cache 112 are variable within the parameters and / or manufacturing technology limitations of the silicon die. In particular, memory (e.g., DRAM) 130 is located separately from the die 120 and interconnected via a suitable bus architecture 140.
[0006] Unstructured parallelism (e.g., multi-core CPUs and hyperthreading) executes multiple sets of code simultaneously, sharing monolithic memory. Unstructured parallelism increases performance per dollar by combining multiple processor "cores" or by integrating code execution electronics into a single product. However, such unstructured parallelism is further hampered by memory bottlenecks because a single memory is used by multiple cores. Single-instruction multiple-data ("SIMD") operations (operations, actions) favorably mitigate the aforementioned problem by executing a single instruction on multiple datums. During operation, SIMD performs a single load to retrieve an instruction (singular) for multiple addresses of memory content. Often, a single SIMD load / store operation operates in a larger, contiguous region of memory, allowing the architecture to utilize predictable load / store addresses (only within a SIMD operation, and between operations, with limited predictability). A single SIMD operation can be executed in parallel across multiple cores. Memory contents addressed within the same SIMD operation (e.g., addresses A and B) are considered to have a readily structured relationship (e.g., A is not read in the computing process at B, and vice versa). Recent examples of SIMD instruction sets include Intel's AVX-512, Nvidia's CUDA, and OpenCL.
[0007] In particular, and as further background, CUDA is more adaptable than a simple instruction set in that it consists of an instruction set, a compiler, and a list of higher-level programming interfaces. Furthermore, a CUDA kernel is a long string of instructions that can be executed in parallel on a large list of data, and CUDA can be described as having structured parallelism beyond a simple SIMD model. That is, CUDA has concurrent (parallel) or sequential parallelism (but never both). Also, a CUDA kernel can perform N operations in parallel on each input, and a CUDA kernel cannot pass the output of an intermediate operation on input A as input to a subsequent operation performed on input B. Instead, the intermediate output must be written to main memory and then reloaded by kernel 2. It should be noted that Nvidia recently introduced CUDA Graphs, which allow low-level programmers to specify an arbitrary flow of data through operations (not limited to concurrent or sequential parallelism). However, despite its various advantages, NVIDIA's graphics processing units (GPUs) that utilize CUDA cannot optimally execute these graphs. This is because they still have monolithic memory. Furthermore, unfortunately, SIMD (and CUDA) instructions are too simple and unadaptive to efficiently execute many modern parallelizable algorithms and cannot capture most of the limitations in the flow of data across the codebase (set of operations). For example, there is no way to tell any of the aforementioned architectures that a small set of operations is being executed repeatedly.
[0008] Therefore, the related data dealing with conventional computing architectures and schemes have various shortcomings, and even SIMD architectures often contain the same elements as serial processors (large cache, off-die memory, etc.), and thus SIMD architectures still retain most of the negative aspects of serial processors.
[0009] Summary of the Invention This invention overcomes the shortcomings of prior art by providing a computer processor architecture and associated memory that utilize a Multi-Core Distributed Memory (MCDM) architecture to more optimally enable the execution of instructions using specific programming techniques such as CUDA Graphs, thereby efficiently distributing processing and memory functions across silicon dies. This technology allows low-level programmers to specify any flow of data through computation (not limited to concurrent or sequential parallel processing).
[0010] In exemplary embodiments, a multicore processing system, and the programming and methods for use herein, provide a general-purpose electronic computer architecture having multicores, inter-core distributed memory (core-local memory). This configuration provides predictable low-latency memory response times and an adaptive code flow of memory from one particular operation to another (using an operation graph). In one specific example, the operation graph consists of a set of mathematical operations, each accompanied by an ordered list of one or more input addresses. The input addresses may be specific addresses in memory, references to other mathematical operations in the graph, or references to the next item in a particular data stream, where the data stream is an iterator across contiguous blocks of memory. More specifically, according to exemplary embodiments, the system and methods may be configured such that the core-local memory is an "autonomous module" as described in International Publication No. 2019 / 023500 incorporated above. In one embodiment, the configuration may be cache-free. Therefore, local memory is read with L1 cache latency. Furthermore, this configuration can be packaged as a PCIe daughter card that can be selectively plugged into a host server / PC built / configured according to the conventional von Neumann architecture. Moreover, the compiler for this configuration can run on the host processor. Code stored and executed on the host is used to initiate compilation and computation. The arithmetic can also be based on an existing (e.g., RISC) instruction set. Therefore, mathematical operations are defined using standards such as IEEE 754. Limiting the set of arithmetic instructions and optimizing for a low total number of transistors and high throughput can be advantageous in simplifying the ALU. A smaller ALU obviously increases the number of cores mounted on a given die, thus increasing the overall processing power.The operation graph can be communicated to the cores through store operations on specific pre-reserved false memory addresses. Furthermore, memory content and operations (arithmetic, operations) can be communicated from the von Neumann processor to the multicore processing configuration via a standard interface (e.g., PCIe).
[0011] The source code of an operation graph can be modified. For example, software can translate SIMD operations into operations written to a compatible instruction set. Alternatively, existing APIs (e.g., map-reduce, TensorFlow, NumPy) can be recreated as operation graphs, and users can use their own APIs for systems and methods as fully compatible alternatives to existing ones. These embodiment forms can be binary equivalents, but can be executed more efficiently due to the advantages of the exemplary systems and methods.
[0012] In an exemplary embodiment, the computing system includes a plurality of processing cores, each of which has discrete, separate core-local memory associated with that processing core, and the core-local memory is interconnected to provide potentially unlimited bandwidth for data transfer between the processing core and the core-local memory, defining a plurality of separate core-memory pairs. The core-memory pairs are further interconnected by a switching configuration and a data bus, which enables data transfer between various core-memory pairs in the overall architecture. The core-memory pairs as defined herein do not need to be different physical instances, but rather may reside in different physical locations on the die and be interconnected by a bus. Furthermore, the core-memory pairs have virtually no cache for the data transferred between each processing core and the core-local memory (compared to current conventional (e.g., von Neumann) processor / memory configurations). Such a virtually cache-less architecture enables generally low latency and high-throughput memory I / O without relying on (or not relying on) the dedicated and / or larger caches associated with conventional architectures. This further enables highly predictable memory latency for the application software chosen to use it. Exemplarily, at least one of the core memory pairs resides on either a single die or separate dies. A processing core may be constructed and configured to manipulate the flow of code supply from one particular operation to another using an operation graph. The operation graph may include a set of mathematical operations, each accompanied by an ordered list of one or more input addresses. The input addresses may also include specific addresses in memory, references to other mathematical operations in the graph, and references to the next item in a data stream. Thus, the data stream may iterate over contiguous blocks of core-local memory. Core memory pairs may be defined by an autonomous module configuration (see below).A die containing multiple core memory pairs can be implemented on a PCIe daughter card, which is adapted to selectively plug into a host server / PC having a host processor built according to the conventional von Neumann architecture. A compiler for program data can be processed by the core memory pairs. The compiler can operate on (a) one or more core memory pairs and (b) at least one of the host processors. Program data stored for and operating on the host processor can be adapted to initiate compilation and computation. The core memory pairs can operate based on an operation graph, and the source code of the operation graph can be based on (a) program data that translates SIMD operations into operations written to a given instruction set, and (b) an existing API that is recreated as an operation graph, with the new API being used as a fully compatible replacement for the existing API.
[0013] The following description of the present invention will be made with reference to the accompanying drawings. [Brief explanation of the drawing]
[0014] [Figure 1] This block diagram shows a typical multi-core processor configuration with on-die cache and off-die working memory, based on the conventional von Neumann processor architecture.
[0015] [Figure 2] This is a block diagram illustrating an exemplary embodiment of a computer multi-core distributed memory (MCDM) on-die processor architecture.
[0016] [Figure 3] Figure 2 shows an exemplary configuration of a processor configured on a single ASIC chip, and more specifically, an exemplary embodiment that utilizes an H-tree intercore network structure.
[0017] [Figure 4] This figure shows a PCIe-compliant PC card having multiple ASIC chips, as shown in Figure 3.
[0018] [Figure 5] This flowchart illustrates various exemplary instruction compilation paths for use with a multicore processing configuration of an exemplary embodiment.
[0019] [Figure 6] This is an operation graph, represented as pseudocode, for use with a multicore processing architecture of an exemplary embodiment. [Figure 7] This is an operation graph for use with an exemplary multicore processing architecture, illustrating the data flow in typical operations.
[0020] Detailed explanation I. Design considerations.
[0021] Neuromorphic computers are non-von Neumann architectures inspired by the human brain. The brain is an organ that operates with extreme parallel processing, using a whole-body "clock speed" (i.e., data transfer between nerves (neurons)) that is actually 100,000 times slower than the latest silicon processors. In particular, the brain stores memory not separately at the place of computation. In practice, neuromorphic computers utilize various configurations in an attempt to emulate the workings of the brain. Some configurations avoid digital transistors for analog computation. Some utilize memristors or other electronic components instead of transistors to store the previous state of switches over time, and some use conventional digital transistors but redesign the architecture so that multiple cores are wired sequentially / in series (and in parallel).
[0022] In the context of designing neuromorphic computers, as is recognized, field-programmable gate arrays (FPGAs) are increasingly being used as an alternative to GPUs for high-performance parallel processing. Such FPGAs are programmable circuits, which means that many processes / algorithms can be rewritten to custom hardware and, instead of being compiled into an instruction set and executed on a von Neumann processor, are executed on the FPGA. Also, FPGAs offer maximum flexibility (adaptability) and are much easier to redesign compared to application-specific integrated circuits (ASICs). However, FPGAs are wasteful in terms of providing adaptability, and FPGA circuits generally contain many elements that are not used by any particular circuit design. Also, unfortunately, FPGAs do not currently have sufficient spare transistors to build a fairly large on-die memory.
[0023] Various other modern alternative computer architectures include, but are not limited to, the following platforms: (a) Mythic AI, which provides substantially stable (robust) memory integration for hybrid analog and digital computing (this platform is designed to outperform GPUs in deep learning (e.g., traditional neural networks (CNNs)), training, and / or enterprise-scale real-time testing); (b) Wave Computing's Triton AI (MIPS / RISC); (c) Amazon's AWS Inferentia; (d) Google's Tensor Processing Unit; (e) ARM's Ethos Machine Learning Processor; (f) Intel's Habana (designed to run pre-trained deep networks in real-time embedded settings); (g) Intel's Movidius Vision Processing Unit (Intel Neural Compute Stick 2); (h) Apple's Bionic chip; and (i) ARM's Trillium. Similarly, the following technologies are provided as background to the issues considered herein and are incorporated herein by reference: U.S. Patent No. 8,200992, entitled “Parallel Processing Computer Systems with Reduced Power Consumption and Methods for Providing the Same”; U.S. Patent No. 8,209597, entitled “System and Method for Achieving Improvement Achievement from Optiment Computer Architectures”; U.S. Patent No. 9,281026, entitled “Parallel Processing Computer Systems with Reduced Power Consumption and Methods for Providing the Same”; and International Publication No. 2019 / 023500, entitled “Entitled Computer-Implemented Perceptual Apparatus”.
[0024] II. Multicore Processor and Memory Configuration.
[0025] Referring to FIG. 2, FIG. 2 shows a generalized configuration 200 for a multi-core distributed memory (MCDM) and associated processor architecture that includes a plurality of CPU cores 210 each governed by a directly connected (bus 212) memory 230, all of which are fabricated on the same discrete silicon (semiconductor) die 240. It should be noted that such a memory configuration may also be referred to as "core-local memory". The processor and memory pairs 210, 230 are provided separately. As will be described later, the pairs 210, 230 can be coupled by an appropriate on-die switching (switching, exchange) configuration for an appropriate external bus architecture such as PCI Express (PCIe) that enables interconnection with external storage devices such as disk drives and / or solid state storage. As will be described later, pairing the processor and core-local memory can be based on a bus interconnection and not on physical proximity on the die.
[0026] It should be noted that although the processor cores and memory configuration are shown on a single die in the exemplary embodiment, it is clearly contemplated that in alternative embodiments, the processor cores and memory can be provided on separate dies or chips. In alternative embodiments, each core can be provided on a chip(s) or die(s), and a physical (e.g., wire trace in the form of bus 212) interface having substantially unlimited bandwidth can be wired-connected between the core and the memory. Accordingly, this description should be construed broadly to include such configurations, and the term "substantially unlimited bandwidth" should be construed to mean an on-die or off-die connection between the core and the memory that can effectively transfer data between the core and the memory as long as the connected components can process the transferred data.
[0027] Referring to Figure 3, the multicore ASIC 300 as a whole, constructed according to the principles of Figure 2, is shown in more detail. This ASIC represents a single chip or die for manufacturing. The illustrated ASIC 300 is shown configured in (e.g.) four clusters, each containing multiple (e.g., 32) discrete CPU and memory pairs 310, governed by a switch architecture 320. The clusters of four CPU / core-local memory pairs are governed by another second-level switch architecture 330. This switch allows various cores to be accessed in a predetermined order for the execution of operations. The second-level switch 330 is interconnected to a PCIe bridge architecture 340, which adapts the core data to the PCIe bus standard, enabling off-chip communication via the bus 350. It should be noted that the exemplary embodiments herein utilize an H-tree intercore network structure. In alternative embodiments, other network structures may be used, including structures that do not utilize NoC switches (structures without NoC switches).
[0028] The ASIC300 can be constructed according to conventional or custom technology and may be part of a Processing Printed Circuit (PC) daughter card 400 shown in Figure 4. As illustrated, the exemplary card holds at least 20 ASIC300s, all connected via a common (copper) PCI bus connection using a third-party PCIe 4.0 switch. The switch interconnects to connection tabs 420 having multiple contact pads (not shown) that interconnect to a suitable (e.g.) motherboard-based card slot using a conventional configuration. The motherboard may include a main processor or CPU that coordinates the overall processing operations and communicates with input / output devices (e.g., a display, a graphical user interface (GUI), etc.). Thus, the card 400 can be one of a bank of processors for performing high-overhead operations in a conventional or custom server.
[0029] III. Operation.
[0030] Referring to Figure 5, which illustrates various instruction compilations for use with a CPU and processor configuration according to an exemplary embodiment. A first compilation 510 utilizes SIMD instructions 514 from existing architecture / user application code 512, which are directly translated into custom code 540 using a custom compiler 542 that adapts the operation graph plus custom code 540 to the unique architecture of the custom core ASIC 544.
[0031] In the second variant 520, the third-party library 524 is reimplemented in custom code (library) 526 based on the user application code 522. These reimplementations function as fully compatible versions acted upon by the compiler 542.
[0032] In the third variant 530, the programmer user can write programming software code 532, particularly for an exemplary multi-core architecture 544, and design their own custom operation graph 534. The resulting code library 536 and graph 534 are provided to the compiler 542. This approach offers the best flexibility (adaptability) and performance, but slightly inferior user compatibility with competing architectures.
[0033] The custom CPU core 544 transfers that data to the host computer's CPU 570 via a custom device driver 560 on the bus architecture, and the CPU 570 computes the associated host code 572 adapted to process the data about the core 544. The host 570 can run the compiler 542 locally, either as part of or in conjunction with the host code 572.
[0034] A brief reference to Figures 6 and 7 illustrates the basic data flow through the core in a typical operation (operation). Thus, Figure 6 defines a pseudocode representation 600, and Figure 7 defines the corresponding data graph 700 of the data flow. In particular, in Figure 7, two datums, data 1 (710) and data 2 (712), are provided to a multiplexer function 720, but data 2 is also provided to a buffer 730. The values of the multiplexer 720 and the buffer are then added (740) to produce the final output 750.
[0035] As further consideration, and also as a summary above, exemplary embodiments provide a generalized electronic computer architecture having multiple cores and memory distributed among the cores (core-local memory). This configuration provides predictable low-latency memory response times and an adaptive code flow of memory from one particular operation to another (using an operation graph). In one specific example, the operation graph consists of a set of mathematical operations, each accompanied by an ordered list of one or more input addresses. The input addresses may be specific addresses in memory, references to other mathematical operations in the graph, or references to the next item in a particular data stream, where the data stream is an iterator across contiguous blocks of memory. More specifically, according to exemplary embodiments, the system and method are such that the core-local memory is an "autonomous module" as described in International Publication No. 2019 / 023500 incorporated above. In one embodiment, the configuration may be substantially cache-less. Generally, an autonomous module (AM) is a processing configuration that allows a memory bank to be updated independently of processor core calculations. Memory values can be updated in the context of an input by sending an input to the AM's Autonomous Memory Operator (AMO). The autonomous memory operator may then fetch the relevant data from the memory bank, update it in the context of the input value, and send the result back to the memory bank. Furthermore, it may perform updates to other data held in memory in response to the results of calculations. For example, an autonomous module embodied in an FPGA can perform countless different tasks and, unlike a GPU, can be programmed to perform well even when the data is not yet ordered in memory.
[0036] As used herein, the term “substantially cache-less” can be defined to mean an architecture that does not have a valid and / or dedicated cache data storage device along the bus (or other data transfer conduit) between the processing core and the individual core-local memory (data memory) as defined herein, more specifically, having significantly less storage than required to support data transfer between the processor(s) and memory(s) in current conventional processing and storage architectures. It should be noted that the core-memory pairs as defined herein do not have to be different physical instances, but rather may be in different physical locations on the die and interconnected by a bus. In many conventional computer processing architectures, approximately 90% of the on-die transistors are allocated to cache memory, and the substantially cache-less configuration of this embodiment(s) eliminates such structure, reduces the associated power demand, or allows for more cores on a given area of the die. More specifically, the architecture described herein offers advantages in that a configuration with virtually no cache generally provides simpler / easier circuit design, along with fewer components and a more predictable data flow through the system, thereby reducing the manufacturing cost per core. This predictability also makes it easier to create optimal programming code for the architecture described herein compared to current conventional cache-dependent systems.
[0037] Therefore, local memory is read with L1 cache latency. Furthermore, this configuration can be packaged as a PCIe daughter card that can be selectively plugged into a host server / PC built / configured according to the conventional von Neumann architecture. Moreover, the compiler of this configuration can run on the host processor. Alternatively, the compiler can be instantiated and is explicitly intended to run entirely or partially on one or more daughter cards embodying the system herein. Code stored and executed on the host is used to initiate compilation and computation. Furthermore, the computation can be based on an existing (e.g., RISC) instruction set. Therefore, mathematical operations are defined using standards such as IEEE 754. The operation graph can be communicated to the core through store operations (operations) to specific pre-reserved false memory addresses. Furthermore, memory content and operations can be communicated from the von Neumann processor to the multicore processing configuration through a standard (e.g., PCIe) interface.
[0038] In exemplary embodiments, the source code of the operation graph can be modified. For example, the software translates SIMD operations into operations written into our instruction set. Alternatively, existing APIs (e.g., map-reduce, TensorFlow, NumPy) can be recreated as operation graphs, and users can use their own APIs for the system and methods as fully compatible alternatives to existing ones. These embodiment forms can be binary equivalents, but can be executed more efficiently due to the advantages of the exemplary system and methods.
[0039] IV. Conclusion.
[0040] As is evident, the multi-core and memory architectures described above, along with the associated program instructions, enable a highly scalable and stable computing environment that fully utilizes the available power of such parallel designs. This configuration can be adapted to existing host computers using available commercial bus architectures and card slots, such as PCIe. The configuration can be manufactured using existing semiconductor and printed circuit board manufacturing technologies.
[0041] The above is a detailed description of exemplary embodiments of the present invention. Various modifications and additions can be made without departing from the spirit and scope of the present invention. Each feature of the various embodiments described above may be combined with features of other described embodiments as needed to provide a variety of combinations of features in related new embodiments. Furthermore, although the above describes numerous distinct embodiments of the apparatus and methods of the present invention, what is described herein is merely illustrative of application forms relating to the principles of the present invention. For example, as used herein, the terms “process” and / or “processor” should be interpreted broadly to include various electronic hardware and / or software based on functions and components (alternatively, they may be called functional “modules” or “elements”). Furthermore, illustrated processes or processors may be combined with other processes and / or processors, or may be divided into various subprocesses or subprocessors. Such subprocesses and / or subprocessors may be combined in various ways according to the embodiments herein. Similarly, any function, process, and / or processor described herein may be implemented using electronic hardware, software consisting of persistent computer-readable programming instructions, or a combination of hardware and software. Furthermore, as used herein, various directional and orientational terms such as “vertical,” “horizontal,” “up,” “down,” “bottom,” “top,” “side,” “front,” “back,” “left,” and “right” are used only as relative arrangements, and not as absolute directions / arrangements with respect to a fixed coordinate space, such as the direction of gravity. Moreover, the terms “substantially” or “about” are used with respect to a given measurement, value, or characteristic and mean a quantity that is within the normal operating range for achieving the desired result, but includes some variation due to inherent inaccuracies and errors within the tolerance of the system (e.g., 1% to 5%). Accordingly, this description is intended to be interpreted as merely illustrative and is not intended to limit the scope of the invention in any other respect.
Claims
1. A computing system, A plurality of processing cores, each of which has a discrete, individual core-local memory associated with that processing core, and the core-local memory is directly interconnected with the processing core by a switchless bus for data transfer between the processing core and the core-local memory, defining a plurality of individual core-memory pairs. The configuration includes a switching configuration and a data bus that interconnect the core memory pairs to transfer data between them, respectively. A computing system in which each of the aforementioned buses of the plurality of core memory pairs does not have a dedicated cache data storage device along the bus.
2. The computing system according to claim 1, wherein at least one of the core memory pairs is located on a single die.
3. The computing system according to claim 1, wherein the processing core is constructed and configured to manipulate the flow of code delivery from one specific operation to another in a core memory pair using an operation graph.
4. The computing system according to claim 3, wherein the operation graph includes a set of mathematical operations, each accompanied by an ordered list of one or more input addresses.
5. The computing system according to claim 4, wherein the input address includes a specific address in memory, a reference to another mathematical operation in the graph, and a reference to the next item in the data stream, and the data stream is repeated across a contiguous block of the core-local memory.
6. The computing system according to claim 5, wherein the core memory pair is defined by an autonomous module configuration.
7. The computing system according to claim 1, wherein at least one of the core memory pairs is located on a separate die.
8. The computing system according to claim 1, wherein a die containing multiple core memory pairs is mounted on a PCIe daughter card, and the PCIe daughter card is adapted to be plugged into a host server / PC having a host processor built according to a conventional von Neumann architecture.
9. The computing system according to claim 1, further comprising a compiler for program data processed by the core memory pairs, the compiler operating on (a) one or more of the core memory pairs and (b) at least one of the host processors.
10. The computing system according to claim 9, further comprising program data stored in and running on the host processor, adapted to initiate compilation and computation.
11. The computing system according to claim 9, wherein the operations performed by the host processor and the core memory pair are based on an existing RISC-based instruction set.
12. The computing system according to claim 11, wherein the operation graph is communicated to each of the core memory pairs through store operations to specific pre-reserved false memory addresses.
13. The computing system according to claim 1, wherein memory contents and operations are transmitted from a von Neumann processor on a host computer to each of the core memory pairs via a standard bus interface through store operations.
14. The computing system according to claim 1, wherein the core memory pair operates based on an operation graph, and the source code of the operation graph is based on (a) program data that translates SIMD operations into operations written to a predetermined set of instructions, and (b) existing APIs that are recreated as an operation graph, and the new APIs are configured to replace the existing APIs.