KR20240064467A - Task Manager, Neural processing device and Method for Managing task thereof - Google Patents

Abstract

The present invention discloses a task manager, a neural processing device, and a task management method thereof. The neural core according to the embodiment includes a core global that generates task information corresponding to a task descriptor, receives the task information from the core global, performs a task according to the task information, and generates a completion signal for completion of the task. and a task manager that monitors the execution time for the task of the task performance unit and generates a timeout detection signal, and generates a timeout report according to the timeout detection signal.

Description

Task Manager, Neural processing device and Method for Managing task thereof}

The present invention relates to a task manager, a neural processing device, and a task management method thereof. Specifically, the present invention can perform control to temporarily wait a task process and re-proceed the task process according to the wait field included in the task descriptor. Accordingly, the present invention relates to a task manager that supports more efficient task processing, a neural processing device, and a task management method thereof.

Over the past few years, artificial intelligence (AI) technology has been mentioned as the most promising technology worldwide as a core technology of the 4th Industrial Revolution. The biggest problem with these artificial intelligence technologies is computing performance. For artificial intelligence technology that realizes human learning, reasoning, perception, and natural language translation abilities, the most important thing is to quickly process a lot of data.

The central processing unit (CPU) or graphics processing unit (GPU) of existing computers were used for deep learning learning and inference in early artificial intelligence, but deep learning learning and inference tasks with a high workload were used. Due to its limitations, the Neural Processing Unit (NPU), which is structurally specialized for deep learning tasks, is gaining attention. This neural network processing device has a plurality of calculation units inside, and each calculation unit operates in parallel to increase calculation efficiency.

Here, even if the tasks distributed to each computing device are processed in parallel, if the types of tasks are different or if distinction between tasks is necessary, appropriate control of the execution timing of the tasks is required. That is, controlling the execution timing of tasks by managing tasks so that there is a temporary waiting time between distributed tasks may be important in terms of processing efficiency and management as well as sequential processing of overall tasks.

Registered Patent Publication No. 10-2258566

The object of the present invention is to provide a task manager that efficiently performs task management.

Another object of the present invention is to provide a neural processing device that efficiently performs task management.

Another object of the present invention is to provide a task management method for a neural processing device that efficiently performs task management.

The objects of the present invention are not limited to the objects mentioned above, and other objects and advantages of the present invention that are not mentioned can be understood by the following description and will be more clearly understood by the examples of the present invention. Additionally, it will be readily apparent that the objects and advantages of the present invention can be realized by the means and combinations thereof indicated in the patent claims.

A task manager according to some embodiments of the present invention for solving the above problem includes a task buffer that receives a task from a command processor and creates a task descriptor for the task, and a task descriptor in which the task descriptor received from the task buffer waits. It includes a task queue and a runtime handle that generates task information corresponding to a task descriptor delivered from the task queue and delivers it to the core global, wherein the runtime handle is configured to store the task descriptor in the case where the task descriptor includes a wait field. Wait in the task queue.

Additionally, the runtime handle may release the waiting state of the task descriptor in response to a progress signal provided from the command processor.

Additionally, the runtime handle may include a progress signal counter through which the progress signal is received.

Additionally, the runtime handle may release the waiting state of the task descriptor through the progress signal previously received at the progress signal counter.

Additionally, the progress signal counter may be configured to receive at least two progress signals.

In addition, the runtime handle generates task information corresponding to the task descriptor from which the waiting state has been released or a task descriptor that does not include the waiting field and transmits it to the core global, and a task corresponding to the task information transmitted to the core global. The descriptor can be provided in a passage as check-in data.

Additionally, the Dawn Passage may receive a completion signal for the task information provided through the core global and check out the checked-in task descriptor in response to the completion signal to generate a completion report.

Additionally, the runtime handle may stop transmitting task information to the core global according to a danger signal provided from the dawn passage.

Additionally, the task queue includes a first queue that receives the task descriptor from the task buffer, a dependency checker that receives the task descriptor from the first queue and performs a dependency check of the received task descriptor, and the dependency checker that receives the task descriptor from the task buffer. It may include a second queue that receives a task descriptor for which the dependency check has been completed from the dependency checker.

Additionally, the second queue includes a first task descriptor and a second task descriptor stored sequentially, and as the first task descriptor is waited in the second queue by the runtime handle, the second task descriptor is also stored in the second queue. You may end up waiting in the second queue.

A neural processing device according to some embodiments of the present invention for solving the above other problems includes a task manager that generates task information corresponding to the task descriptor depending on whether the task descriptor includes a waiting field, and a task according to the task information. a neural core that performs the task and generates a completion signal for the task; and a core global that receives task information about the task, transmits the task information to the neural core, and receives the completion signal of the task from the neural core. Includes.

In addition, the task manager generates the task descriptor, selectively generates the task information according to the task descriptor and transmits it to the core global, checks in the task descriptor from the task passage, and sends the completion signal. It may include a Dawn passage that receives and checks out the task descriptor to generate the completion report.

In addition, the task passage receives a task from a command processor, a task buffer that generates a task descriptor for the task, a task queue in which the task descriptor received from the task buffer waits, and a task descriptor delivered from the task queue. It includes a runtime handle that creates corresponding task information and delivers it to the core global, wherein the runtime handle waits the task descriptor in the task queue when the task descriptor includes a wait field, and the runtime handle waits for the command The standby state of the task descriptor may be released in response to a progress signal provided from the processor.

In addition, the runtime handle generates task information corresponding to the task descriptor from which the waiting state has been released or a task descriptor that does not include the waiting field and transmits it to the core global, and a task corresponding to the task information transmitted to the core global. The descriptor can be provided as check-in data in the Dawn passage.

A task management method of a neural processing device according to some embodiments of the present invention for solving the above further problem includes receiving a task descriptor in a task queue, checking whether the task descriptor includes a waiting field, and the task If the descriptor includes the waiting field, queuing the task descriptor in the task queue.

In addition, the step of releasing the standby state of the task descriptor in response to a progress signal provided from a command processor may be further included.

Additionally, the progress signal may be a signal provided after the waiting state of the task descriptor.

Additionally, the progress signal may be a signal provided before the task descriptor waiting state.

Additionally, generating task information corresponding to a task descriptor from which the waiting state has been released or a task descriptor not including the waiting field and transmitting it to the core global; And it may further include providing a task descriptor corresponding to the task information delivered to the core global as check-in data in a Dawn passage.

In addition, receiving the task descriptor in the task queue includes receiving a task from a command processor, generating a task descriptor for the task, storing the task descriptor in a first queue, and defining the task descriptor in the first queue. It may include checking the dependency and storing the task descriptor for which the dependency check has been completed in a second queue.

In the task manager, neural processing device, and task management method of the present invention, the execution timing of a task can be controlled through a runtime handle configured in the task manager. That is, it can be managed to have a temporary waiting time between distributed tasks, and the efficiency of task processing and management as well as sequential processing of overall tasks can be further increased.

In addition to the above-described content, specific effects of the present invention are described below while explaining specific details for carrying out the invention.

1 is a block diagram for explaining a neural processing system according to some embodiments of the present invention.
FIG. 2 is a block diagram for explaining the neural processing device of FIG. 1 in detail.
FIG. 3 is a block diagram for explaining the neural core SoC of FIG. 2 in detail.
FIG. 4 is a structural diagram for explaining the global interconnection of FIG. 3 in detail.
FIG. 5 is a block diagram for explaining the flow of control signals of the neural processing device of FIG. 1.
FIG. 6 is a block diagram for explaining the neural processor of FIG. 3 in detail.
FIG. 7 is a diagram illustrating the hierarchical structure of a neural processing device according to some embodiments of the present invention.
FIG. 8 is a block diagram for explaining the neural core of FIG. 6 in detail.
FIG. 9 is a block diagram for explaining the LSU of FIG. 8 in detail.
FIG. 10 is a block diagram for explaining the processing unit of FIG. 8 in detail.
FIG. 11 is a block diagram for explaining the L0 memory of FIG. 8 in detail.
FIG. 12 is a block diagram for explaining the local memory bank of FIG. 11 in detail.
FIG. 13 is a block diagram for explaining the flow of data and control signals of the neural processing device of FIG. 1.
FIG. 14 is a block diagram for explaining the relationship between the command processor and task manager of FIG. 13.
FIG. 15 is a block diagram to explain in detail the structure of the task manager of FIG. 8.
FIG. 16 is a block diagram for explaining the table passage of FIG. 15 in detail.
FIG. 17 is a block diagram for explaining the task passage of FIG. 15 in detail.
Figure 18 is a block diagram to specifically explain the function of the runtime handle.
Figure 19 is an example diagram for explaining a process of processing a task descriptor included in queue 2_1 in response to a progress signal.
Figure 20 is an example diagram for explaining a process of processing a task descriptor included in queue 2_1 in response to a previously received progress signal.
Figure 21 is an example diagram for explaining a process of processing a task descriptor included in the 2_1 queue in response to a plurality of progress signals.
Figure 22 is an example diagram for explaining a process of processing a task descriptor included in the 2_1 queue (Q2_1) through a plurality of progress signals received by the counter.
FIG. 23 is a block diagram for explaining the Dawn passage of FIG. 15 in detail.
FIG. 24 is a block diagram for explaining the report management module of FIG. 23 in detail.
FIG. 25 is a diagram illustrating data exchanged between the core global and neural core of FIG. 15.
Figure 26 is a diagram for explaining the types of task descriptors stored in the first queue, second queue, and check-in buffer.
FIG. 27 is a diagram illustrating a first queue, a second queue, and a check-in buffer of a neural processing device according to some embodiments of the present invention.
FIG. 28 is a diagram illustrating a first queue, a second queue, and a check-in buffer of a neural processing device according to some embodiments of the present invention.
FIG. 29 is a block diagram for explaining in detail the structure of the neural processing device of FIG. 1.
FIG. 30 is a diagram illustrating the hierarchical structure of a command processor and a task manager of a neural processing device according to some embodiments of the present invention.
FIG. 31 is a diagram illustrating the hierarchical structure of command processors and task managers of a neural processing device according to some embodiments of the present invention.
FIG. 32 is a block diagram for explaining memory reorganization of the neural processing system of FIG. 1.
FIG. 33 is a block diagram showing an example of memory reorganization of the neural processing system of FIG. 1.
Figure 34 is an enlarged block diagram of part A of Figure 32.
FIG. 35 is a diagram for explaining the first memory bank of FIG. 34 in detail.
FIG. 36 is a block diagram for explaining the software hierarchy of the neural processing device of FIG. 1.
FIG. 37 is a conceptual diagram illustrating a deep learning operation performed by the neural processing device of FIG. 1.
FIG. 38 is a conceptual diagram for explaining the learning and inference operations of the neural network of the neural processing device of FIG. 1.
Figure 39 is a flow chart to explain a task management method of a neural processing device according to some embodiments of the present invention.
FIG. 40 is a flowchart illustrating in detail the step of receiving a task descriptor from the task queue of FIG. 39.

Terms or words used in this specification and patent claims should not be construed as limited to their general or dictionary meaning. According to the principle that the inventor can define the term or word concept in order to explain his or her invention in the best way, it should be interpreted with a meaning and concept consistent with the technical idea of the present invention. In addition, the embodiments described in this specification and the configurations shown in the drawings are only one embodiment of the present invention and do not completely represent the technical idea of the present invention, so they cannot be replaced at the time of filing the present application. It should be understood that there may be various equivalents, variations, and applicable examples.

Terms such as first, second, A, and B used in the present specification and claims may be used to describe various components, but the components should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another. For example, a first component may be named a second component without departing from the scope of the present invention, and similarly, the second component may also be named a first component. The term 'and/or' includes any of a plurality of related stated items or a combination of a plurality of related stated items.

The terms used in the specification and claims are merely used to describe specific embodiments and are not intended to limit the invention. Singular expressions include plural expressions unless the context clearly dictates otherwise. In this application, terms such as "include" or "have" should be understood as not precluding the existence or addition possibility of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification. .

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by a person of ordinary skill in the technical field to which the present invention pertains.

Terms defined in commonly used dictionaries should be interpreted as having meanings consistent with the meanings they have in the context of the related technology, and unless clearly defined in the present application, should not be interpreted in an ideal or excessively formal sense. No.

Additionally, each configuration, process, process, or method included in each embodiment of the present invention may be shared within the scope of not being technically contradictory to each other.

Hereinafter, with reference to FIGS. 1 to 37, a neural processing device according to some embodiments of the present invention will be described.

1 is a block diagram for explaining a neural processing system according to some embodiments of the present invention.

Referring to FIG. 1, a neural processing system (NPS) according to some embodiments of the present invention may include a first neural processing device 1, a second neural processing device 2, and an external interface 3. .

The first neural processing device 1 may be a device that performs calculations using an artificial neural network. For example, the first neural processing device 1 may be a device specialized for performing deep learning calculation tasks. However, this embodiment is not limited to this.

The second neural processing device 2 may be a device that has the same or similar configuration as the first neural processing device 1. The first neural processing device 1 and the second neural processing device 2 may be connected to each other through an external interface 3 and share data and control signals.

Although two neural processing devices are shown in FIG. 1, the neural processing system (NPS) according to some embodiments of the present invention is not limited thereto. That is, in the neural processing system (NPS) according to some embodiments of the present invention, three or more neural processing devices may be connected to each other through the external interface 3. Also, conversely, a neural processing system (NPS) according to some embodiments of the present invention may include only one neural processing device.

At this time, the first neural processing device 1 and the second neural processing device 2 may each be a processing device other than a neural processing device. That is, the first neural processing device 1 and the second neural processing device 2 are respectively a graphics processing unit (GPU, graphics processing unit), a central processing unit (CPU), and other types of processing devices. It may be. Hereinafter, for convenience, the first neural processing device 1 and the second neural processing device 2 will be described as neural processing devices.

FIG. 2 is a block diagram for explaining the neural processing device of FIG. 1 in detail.

Referring to FIG. 2, the first neural processing device 1 includes a neural core SoC 10, a CPU 20, an off-chip memory 30, a first non-volatile memory interface 40, and a first volatile memory interface ( 50), a second non-volatile memory interface 60, a second volatile memory interface 70, and a control interface (CIF) 80.

The Neural Core SoC 10 may be a System on Chip device. The neural core SoC (10) is an artificial intelligence calculation unit and may be an accelerator. The neural core SoC 10 may be, for example, one of a graphics processing unit (GPU), a field programmable gate array (FPGA), and an application-specific integrated circuit (ASIC). However, this embodiment is not limited to this.

The neural core SoC (10) can exchange data with other external computational units through the external interface (3). Additionally, the neural core SoC 10 may be connected to the non-volatile memory 31 and the volatile memory 32 through the first non-volatile memory interface 40 and the first volatile memory interface 50, respectively.

The CPU 20 may be a control device that controls the system of the first neural processing device 1 and executes program operations. The CPU 20 is a general-purpose calculation unit and may be inefficient in performing parallel simple calculations commonly used in deep learning. Accordingly, the neural core SoC 10 can achieve high efficiency by performing calculations on deep learning inference and learning tasks.

The CPU 20 can exchange data with other external computational units through the external interface 3. Additionally, the CPU 20 may be connected to the non-volatile memory 31 and the volatile memory 32 through the second non-volatile memory interface 60 and the second volatile memory interface 70, respectively.

The CPU 20 may also transfer a task to the neural core SoC 10 through a command. At this time, the CPU 20 may be a type of host that gives instructions to the neural core SoC 10. In other words, the neural core SoC 10 can efficiently perform parallel computing tasks such as deep learning tasks according to instructions from the CPU 20.

The off-chip memory 30 may be memory placed outside the chip of the neural core SoC 10. Off-chip memory 30 may include non-volatile memory 31 and volatile memory 32.

The non-volatile memory 31 may be a memory that continues to retain stored information even when power is not supplied. The non-volatile memory 31 includes, for example, Read-Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Alterable ROM (EAROM), Erasable Programmable Read-Only Memory (EPROM), and Electrically Erasable Programmable Memory (EEPROM). Read-Only Memory (e.g., NAND Flash memory, NOR Flash memory), UVEPROM (Ultra-Violet Erasable Programmable Read-Only Memory), FeRAM (Ferroelectric Random Access Memory), Magnetoresistive Random Access Memory (MRAM), Phase-change Random Access Memory (PRAM), silicon-oxide-nitride-oxide-silicon (SONOS), Resistive Random Access Memory (RRAM), Nanotube Random Access Memory (NRAM), magnetic computer memory It may include at least one of a device (eg, hard disk, diskette drive, magnetic tape), optical disk drive, and 3D XPoint memory. However, this embodiment is not limited to this.

Unlike the non-volatile memory 31, the volatile memory 32 may be a memory that continuously requires power to maintain stored information. The volatile memory 32 may include, for example, at least one of Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Synchronous Dynamic Random Access Memory (SDRAM), and Double Data Rate SDRAM (DDR SDRAM). there is. However, this embodiment is not limited to this.

The first non-volatile memory interface 40 and the second non-volatile memory interface 60 are, for example, Parallel Advanced Technology Attachment (PATA), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), and SATA ( It may include at least one of Serial Advanced Technology Attachment) and PCIe (PCI Express). However, this embodiment is not limited to this.

The first volatile memory interface 50 and the second volatile memory interface 70 may be configured to perform, for example, single data rate (SDR), double data rate (DDR), quad data rate (QDR), and eXtreme data rate (XDR), respectively. , Octal Data Rate). However, this embodiment is not limited to this.

The control interface 80 may be an interface for transmitting control signals between the CPU 20 and the neural core SoC 10. The control interface 80 may transmit a command from the CPU 20 and a response from the neural core SoC 10 thereto. The control interface 80 may be, for example, PCIe (PCI Express), but is not limited thereto.

FIG. 3 is a block diagram for explaining the neural core SoC of FIG. 2 in detail.

2 and 3, the neural core SoC 10 includes at least one neural processor 1000, a shared memory 2000, a direct memory access (DMA) 3000, a non-volatile memory controller 4000, and a volatile memory controller 4000. It may include a memory controller 5000, a command processor 7000, and a global interconnection 6000.

The neural processor 1000 may be a computational unit that directly performs computational tasks. When there are multiple neural processors 1000, computational tasks may be assigned to each neural processor 1000. Each neural processor 1000 may be connected to each other through a global interconnection 6000.

The shared memory 2000 may be memory shared by several neural processors 1000. The shared memory 2000 can store data of each neural processor 1000. Additionally, the shared memory 2000 can receive data from the off-chip memory 30, temporarily store it, and transmit it to each neural processor 1000. Conversely, the shared memory 2000 may receive data from the neural processor 1000, temporarily store it, and transfer it to the off-chip memory 30 of FIG. 2.

Shared memory 2000 may require relatively fast memory. Accordingly, the shared memory 2000 may include, for example, SRAM. However, this embodiment is not limited to this. That is, the shared memory 2000 may include DRAM.

The shared memory 2000 may be a memory corresponding to the SoC level, that is, level 2 (L2). Accordingly, the shared memory 2000 may be defined as L2 shared memory.

The DMA 3000 can directly control the movement of data without the need for the CPU 20 or the neural processor 1000 to control input and output of data. Accordingly, the DMA 3000 can control data movement between memories to minimize the number of interrupts of the CPU 20 or the neural processor 1000.

The DMA (3000) can control data movement between the shared memory (2000) and the off-chip memory (30). The non-volatile memory controller 4000 and volatile memory controller 5000 can move data through the authority of the DMA (3000).

The non-volatile memory controller 4000 can control read or write operations on the non-volatile memory 31. The non-volatile memory controller 4000 can control the non-volatile memory 31 through the first non-volatile memory interface 40.

The volatile memory controller 5000 can control read or write operations on the volatile memory 32. Additionally, the volatile memory controller 5000 may perform a refresh operation on the volatile memory 32. The volatile memory controller 5000 can control the volatile memory 32 through the first volatile memory interface 50.

The command processor 7000 may be connected to the control interface 80. The command processor 7000 may receive a control signal from the CPU 20 through the control interface 80. The command processor 7000 can create a task through a control signal received from the CPU 20 and transmit it to each neural processor 1000. Additionally, the command processor 7000 may receive a completion report for the task from each neural processor 1000.

The global interconnection 6000 connects at least one neural processor 1000, shared memory 2000, DMA 3000, non-volatile memory controller 4000, command processor 7000, and volatile memory controller 5000 to each other. You can. Additionally, the external interface 3 may also be connected to the global interconnection 6000. The global interconnection 6000 includes at least one neural processor 1000, a shared memory 2000, a DMA 3000, a non-volatile memory controller 4000, a volatile memory controller 5000, a command processor 7000, and an external interface. (3) It may be a path through which data moves.

The global interconnection 6000 can transmit not only data but also control signals and signals for synchronization. In the neural processing device according to some embodiments of the present invention, each neural processor 1000 can directly transmit and receive a synchronization signal. Accordingly, latency due to transmission of the synchronization signal generated by the command processor 7000 can be minimized.

That is, when there are multiple neural processors 1000, there may be a dependency of individual tasks in which the task of one neural processor 1000 must be completed before the next neural processor 1000 can start a new task. The end and start of these individual tasks can be confirmed through synchronization signals. In the existing technology, the command processor 7000 or the host, that is, the CPU 20, is in charge of both receiving these synchronization signals and instructing the start of new tasks. did.

However, as the number of neural processors 1000 increases and the dependency of the task is designed more complexly, the number of these synchronization signals increases exponentially, and the latency according to each synchronization signal can significantly reduce the efficiency of the task. .

Therefore, in the neural processing device according to some embodiments of the present invention, instead of the command processor 7000, each neural processor 1000 may directly transmit a part of the synchronization signal to another neural processor 1000 according to the dependency of the task. You can. In this case, compared to the method managed by the command processor 7000, multiple neural processors 1000 can perform synchronization tasks in parallel, thereby minimizing latency due to synchronization.

In addition, the command processor 7000 must perform task scheduling of the neural processors 1000 according to task dependency, and the overhead of such scheduling may increase significantly as the number of neural processors 1000 increases. Accordingly, in the neural processing device according to some embodiments of the present invention, the scheduling task is partially performed by the individual neural processor 1000, thereby reducing the scheduling burden, thereby improving the performance of the device.

In addition, the neural processing device according to some embodiments of the present invention may monitor task completion, event occurrence, and delay in task performance in the neural core of each neural processor 1000, and may include a command processor ( By minimizing the intervention of the command processor 7000, the burden on the command processor 7000 can be reduced, thereby improving the performance of the device.

In addition, the neural processing device according to some embodiments of the present invention can selectively generate a completion report by setting whether to monitor each task for each task, and when reporting to the command processor 7000 is necessary, it can determine whether to generate a completion report. Can be configured to modify. Accordingly, it may be possible to report on tasks requiring warnings without performing monitoring for all tasks, and stable monitoring of tasks may be possible while reducing the burden on the command processor 7000.

FIG. 4 is a structural diagram for explaining the global interconnection of FIG. 3 in detail.

Referring to FIG. 4, the global interconnection 6000 may include a data channel 6100, a control channel 6200, and an L2 sync channel 6300.

The data channel 6100 may be a dedicated channel for transmitting data. Through the data channel 6100, at least one neural processor 1000, shared memory 2000, DMA 3000, non-volatile memory controller 4000, volatile memory controller 5000, and external interface 3 exchange data with each other. can be exchanged.

The control channel 6200 may be a dedicated channel that transmits control signals. At least one neural processor 1000, shared memory 2000, DMA 3000, non-volatile memory controller 4000, volatile memory controller 5000, command processor 7000, and external interface through the control channel 6200. (3) can exchange control signals with each other. In particular, the command processor 7000 can transmit various control signals to each neural processor 1000.

The L2 sync channel 6300 may be a dedicated channel that transmits a synchronization signal. Through the L2 sync channel 6300, at least one neural processor 1000, shared memory 2000, DMA 3000, non-volatile memory controller 4000, volatile memory controller 5000, command processor 7000, and external The interface 3 can exchange synchronization signals with each other.

The L2 sync channel 6300 is set as a dedicated channel within the global interconnection 6000 and can quickly transmit synchronization signals without overlapping with other channels. Accordingly, the neural processing device according to some embodiments of the present invention does not require new wiring work and can smoothly perform synchronization work using the existing global interconnection 6000.

FIG. 5 is a block diagram for explaining the flow of control signals of the neural processing device of FIG. 1.

Referring to FIG. 5, the CPU 20 may transmit a control signal to the command processor 7000 through the control interface 80. At this time, the control signal may be a signal instructing to perform each operation, such as a computation task or a data load/store task.

The command processor 7000 may receive a control signal and transmit the control signal to at least one neural processor 1000 through the control channel 6200. Each control signal may be stored in the neural processor 1000 as each task.

FIG. 6 is a block diagram for explaining the neural processor of FIG. 3 in detail.

3 to 6, the neural processor 1000 includes at least one neural core 100, a local interconnection 200, an L1 sync path 300, an L1 shared memory 400, and a core global 500. , may include a task manager 600 and an L1 LSU 700.

At least one neural core 100 may share and perform the tasks of the neural processor 1000. For example, there may be eight neural cores 100. However, this embodiment is not limited to this. 3 and 5 show that several neural cores 100 are included in the neural processor 1000, but the present embodiment is not limited thereto. In other words, the neural processor 1000 can be configured with only one neural core 100.

The neural core 100 may receive task information from the core global 500 and perform a task according to the task information. At this time, the task may be defined by a control signal, and the task may be any one of memory operations. The memory operation may be, for example, any one of micro DMA (μDMA), low priority μDMA (LP micro DMA), store μDMA (STμDMA), and pre-processing operations.

The L1 shared memory 400 may be a memory shared by each neural core 100 within the neural processor 1000. The L1 shared memory 400 can store data of each neural core 100. Additionally, the L1 shared memory 400 can receive data from the shared memory 2000 of FIG. 4, temporarily store it, and transmit it to each neural core 100. Conversely, the L1 shared memory 400 may receive data from the neural core 100, temporarily store it, and transfer it to the shared memory 2000 of FIG. 3.

The L1 shared memory 400 may be a memory corresponding to the neural processor level, that is, level 1 (L1). L2 shared memory, that is, shared memory 2000, may be shared by the neural processor 1000, and L1 shared memory 400 may be shared by the neural core 100.

The L1 LSU 700 may receive at least one of data, control signals, and synchronization signals from the outside through the global interconnection 6000. The L1 LSU 700 may transmit at least one of the received data, control signal, and synchronization signal to the L1 shared memory 400. Similarly, the L1 LSU 700 can transmit at least one of data, control signals, and synchronization signals to the outside through the global interconnection 6000. Additionally, the L1 LSU 700 may transmit and receive at least one of data, control signals, and synchronization signals to each of the neural cores 100.

The neural core 100 may receive task information from the core global 500 and perform a task according to the task information. At this time, the task may be a computation task (operation task) or a task related to memory operation. Tasks can be defined by control signals. Task information is information about a task and may be information about the type of task, the form of the task, additional information about the task, etc.

The neural core 100 may transmit a completion signal indicating completion of the task to the core global 500.

The task manager 600 may receive a task from a control interconnection (CI). At this time, control interconnection (CI) may be a general term for a transmission interface that transmits tasks from the command processor 7000. That is, the control interconnection (CI) may include a control channel 6200 and a local interconnection 200.

The task manager 600 may receive a task, generate task information, and transmit it to the core global 500. Additionally, the task manager 600 may receive a completion signal through the core global 500, generate a completion report accordingly, and transmit it to the command processor 7000 through a control interconnection (CI).

The core global 500 may be a wire structure connected in hardware to the neural core 100. Although not shown, the core global 500 may be a structure that connects the neural core 100, L1 shared memory 400, L1 LSU 700, and task manager 600. Accordingly, the local interconnection 200 and the L1 sync path 300 may also be included in the core global 500. However, this embodiment is not limited to this.

The core global 500 may receive task information from the task manager 600, transmit it to the neural core 100, and receive a completion signal for the task from the neural core 100. Subsequently, Core Global 500 may transmit a completion signal to the task manager 600.

The local interconnection 200 may connect at least one neural core 100, L1 shared memory 400, core global 500, task manager 600, and L1 LSU 700 to each other. The local interconnection 200 may be a path through which data moves between at least one neural core 100, L1 shared memory 400, core global 500, task manager 600, and L1 LSU 700. . The local interconnection 200 is connected to the global interconnection 6000 of FIG. 3 and can transmit data.

The L1 sync path 300 may connect at least one neural core 100, L1 shared memory 400, core global 500, task manager 600, and L1 LSU 700 to each other. The L1 sync path 300 may be a path along which synchronization signals of at least one neural core 100, L1 shared memory 400, core global 500, task manager 600, and L1 LSU 700 travel. .

The L1 sync path 300 may be formed physically separately from the local interconnection 200. In the case of the local interconnection 200, unlike the global interconnection 6000, sufficient channels may not be formed internally. In this case, the L1 sync path 300 is formed separately so that transmission of the synchronization signal can be performed quickly and without delay. The L1 sync path 300 can be used for synchronization performed at a level one level lower than the L2 sync channel 6300 of the global interconnection 6000.

FIG. 7 is a diagram illustrating the hierarchical structure of a neural processing device according to some embodiments of the present invention.

Referring to FIG. 7, the neural core SoC 10 may include at least one neural processor 1000. Each neural processor 1000 can transmit data to each other through the global interconnection 6000.

Each neural processor 1000 may include at least one neural core 100. The neural core 100 may be a processing unit optimized for deep learning calculation tasks. The neural core 100 may be a processing unit corresponding to one operation of a deep learning calculation task. In other words, deep learning computational tasks can be expressed as a sequential or parallel combination of multiple operations. The neural core 100 is a processing unit that can each process one operation, and may be the minimum computational unit that can be considered for scheduling from a compiler's perspective.

The neural processing device according to this embodiment can achieve fast and efficient scheduling and performance of calculation tasks by configuring the scale of the minimum calculation unit and hardware processing unit considered from a compiler scheduling perspective to be the same.

In other words, if the processing unit that can be divided into hardware is too large compared to the computational task, inefficiency in the computational task may occur when driving the processing unit. Conversely, it is not appropriate to always schedule a processing unit smaller than the operation, which is the compiler's minimum scheduling unit, because scheduling inefficiencies may occur and hardware design costs may increase.

Therefore, in this embodiment, the scale of the compiler's scheduling unit and the hardware processing unit can be similarly adjusted to simultaneously satisfy fast computational task scheduling and efficient computational task performance without wasting hardware resources.

FIG. 8 is a block diagram for explaining the neural core of FIG. 6 in detail.

Referring to FIG. 8, the neural core 100 includes a Load/Store Unit (LSU) 110, an L0 memory 120, a weight buffer 130, an activation LSU 140, an activation buffer 150, and a processing unit ( 160) may be included.

The LSU 110 may receive at least one of data, control signals, and synchronization signals from the outside through the local interconnection 200 and the L1 sync path 300. The LSU 110 may transmit at least one of the received data, control signal, and synchronization signal to the L0 memory 120. Similarly, the LSU 110 may transmit at least one of data, a control signal, and a synchronization signal to the outside through the local interconnection 200 and the L1 sync path 300.

Specifically, the micro DMA task may be a task in which the neural core 100 loads a program or data from the shared memory 2000 or the off-chip memory 30 to the L0 memory 120. Unlike a typical micro DMA operation, the LP micro DMA operation may be a load operation for a program or data to be used later rather than the current program or data. Because these tasks have a low priority, they can be identified differently from micro DMA tasks. The ST Micro DMA operation may be a store operation that stores data from the L0 memory 120 of the neural core 100 to the shared memory 2000 or the off-chip memory 30. The preprocessing task may include preloading data, such as a large amount of lookup tables, in the CPU 20.

FIG. 9 is a block diagram for explaining the LSU of FIG. 8 in detail.

Referring to FIG. 9, the LSU 110 includes a local memory load unit 111a, a local memory store unit 111b, a neural core load unit 112a, a neural core store unit 112b, a load buffer (LB), and a store. It may include a buffer (SB), a load engine 113a, a store engine 113b, and a conversion index buffer 114.

The local memory load unit 111a may fetch a load instruction for the L0 memory 120 and issue the load instruction. When the local memory load unit 111a provides an issue load instruction to the load buffer LB, a memory access request can be sequentially transmitted to the load engine 113a according to the order in which the load buffer LB is input.

Additionally, the local memory store unit 111b may fetch a store instruction for the L0 memory 120 and issue the store instruction. When the local memory store unit 111b provides the issue store instruction to the store buffer SB, a memory access request can be sequentially transmitted to the store engine 113b according to the order in which the store buffer SB was input.

The neural core load unit 112a may fetch a load instruction for the neural core 100 and issue the load instruction. When the neural core load unit 112a provides an issue load instruction to the load buffer LB, a memory access request can be sequentially transmitted to the load engine 113a according to the order in which the load buffer LB is input.

Additionally, the neural core store unit 112b may fetch a store instruction for the neural core 100 and issue the store instruction. When the neural core store unit 112b provides the issue store instruction to the store buffer SB, a memory access request can be sequentially transmitted to the store engine 113b according to the order in which the store buffer SB was input.

The load engine 113a may receive a memory access request and load data through the local interconnection 200. At this time, the load engine 113a can quickly find data using the conversion table of recently used logical addresses and physical addresses in the conversion index buffer 114. If the logical address of the load engine 113a is not in the translation index buffer 114, address translation information can be found in another memory.

The store engine 113b may receive a memory access request and load data through the local interconnection 200. At this time, the store engine 113b can quickly find data using the conversion table of recently used logical addresses and physical addresses in the conversion index buffer 114. If the logical address of the store engine 113b is not in the translation index buffer 114, address translation information can be found in another memory.

The load engine 113a and the store engine 113b may send a synchronization signal to the L1 sync path 300. At this time, the synchronization signal may mean that the task has ended.

Referring again to FIG. 8, the L0 memory 120 is a memory located inside the neural core 100, and allows the neural core 100 to receive all input data required for work from the outside and temporarily store them. Additionally, the L0 memory 120 can temporarily store output data calculated by the neural core 100 in order to transmit it to the outside.

The L0 memory 120 may transmit input activation (Act_In) to the activation buffer 150 and receive output activation (Act_Out) by the activation LSU 140. In addition to the activation LSU 140, the L0 memory 120 can directly transmit and receive data with the processing unit 160. That is, the L0 memory 120 can exchange data with each of the PE array 163 and the vector unit 164. The L0 memory 120 may be a memory corresponding to the neural core level. At this time, the L0 memory 120 may be a private memory of the neural core.

The L0 memory 120 can transmit data such as activation or weight through a data path. The L0 memory 120 can send and receive synchronization signals through the L0 Sync Path, which is a separate dedicated path. For example, the L0 memory 120 may exchange a synchronization signal with the LSU 110, the weight buffer 130, the activation LSU 140, and the processing unit 160 through an L0 Sync Path. .

The weight buffer 130 may receive weight from the L0 memory 120. The weight buffer 130 may transmit weight to the processing unit 160. The weight buffer 130 may temporarily store the weight before transmitting the weight.

Input activation (Act_In) and output activation (Act_Out) may refer to the input and output values of the layer of the neural network network. At this time, when the neural network has multiple layers, the output value of the previous layer becomes the input value of the next layer, so the output activation (Act_Out) of the previous layer can be used as the input activation (Act_In) of the next layer.

Weight may refer to a parameter multiplied by the input activation (Act_In) input from each layer. Weight is adjusted and confirmed in the deep learning learning stage, and can be used to derive output activation (Act_Out) through a fixed value in the inference stage.

The activation LSU 140 may transfer the input activation (Act_In) from the L0 memory 120 to the activation buffer 150 and the output activation (Act_Out) from the activation buffer 150 to the on-chip buffer. That is, the activation LSU 140 can perform both activation load and store operations.

The activation buffer 150 may provide input activation (Act_In) to the processing unit 160 and receive output activation (Act_Out) from the processing unit 160. The activation buffer 150 can temporarily store input activation (Act_In) and output activation (Act_Out).

The activation buffer 150 can quickly provide activation to the processing unit 160 with a large calculation load and quickly receive activation to increase the calculation speed of the neural core 100.

The processing unit 160 may be a module that performs calculations. The processing unit 160 can perform not only one-dimensional operations but also two-dimensional matrix operations, that is, convolution operations. The processing unit 160 may receive the input activation (Act_In), multiply it by the weight, and add it to generate the output activation (Act_Out).

FIG. 10 is a block diagram for explaining the processing unit of FIG. 8 in detail.

Referring to FIGS. 8 and 10 , the processing unit 160 may include a PE array 163, a vector unit 164, a column register 161, and a row register 162.

The PE array 163 can perform multiplication by receiving input activation (Act_In) and weight (Weight). At this time, input activation (Act_In) and weight (Weight) can each be calculated through convolution in matrix form. Through this, the PE array 163 can generate output activation (Act_Out). However, this embodiment is not limited to this. The PE array 163 can generate any number of types of output other than output activation (Act_Out).

The PE array 163 may include at least one processing element 163_1. The processing elements 163_1 are aligned with each other and can perform multiplication of one input activation (Act_In) and one weight (Weight), respectively.

The PE array 163 can generate a subtotal that sums the values for each multiplication. These partial sums can be used as output activation (Act_Out). Since the PE array 163 performs two-dimensional matrix multiplication, it may also be referred to as a two-dimensional matrix compute unit.

The vector unit 164 can perform one-dimensional operations. The vector unit 164 can perform deep learning calculations together with the PE array 163. Through this, the processing unit 160 can be specialized for necessary operations. In other words, the neural core 100 has calculation modules that perform large amounts of two-dimensional matrix multiplication and one-dimensional calculations, so it can efficiently perform deep learning tasks.

The column register 161 may receive the first input (I1). The column register 161 may receive the first input (I1), divide it, and provide it to each column of the PE array 163.

Low register 162 may receive a second input (I2). The row register 162 may receive the second input I2, divide it, and provide it to each row of the PE array 163.

The first input (I1) may be input activation (Act_In) or weight (Weight). The second input (I2) may be a value other than the first input (I1) among input activation (Act_In) or weight (Weight). Alternatively, the first input (I1) and the second input (I2) may be values other than input activation (Act_In) and weight (Weight).

FIG. 11 is a block diagram for explaining the L0 memory of FIG. 8 in detail.

Referring to FIG. 11, the L0 memory 120 may include a scheduler 121 and at least one local memory bank 122.

When data is stored in the L0 memory 120, the scheduler 121 may receive the data from the load engine 113a. At this time, data may be allocated to the local memory bank 122 in a round robin manner. Accordingly, data may be stored in any one of at least one local memory bank 122.

Conversely, when data is loaded from the L0 memory 120, the scheduler 121 may receive data from the local memory bank 122 and transfer it to the store engine 113b. The store engine 113b can store data externally through the local interconnection 200.

FIG. 12 is a block diagram for explaining the local memory bank of FIG. 11 in detail.

Referring to FIG. 12, the local memory bank 122 may include a local memory bank controller 122_1 and a local memory bank cell array 122_2.

The local memory bank controller 122_1 can manage read and write operations through the address of data stored in the local memory bank 122. That is, the local memory bank controller 122_1 can manage the overall input and output of data.

The local memory bank cell array 122_2 may have a structure in which cells in which data is directly stored are aligned in rows and columns. The local memory bank cell array 122_2 may be controlled by the local memory bank controller 122_1.

FIG. 13 is a block diagram for explaining the flow of data and control signals of the neural processing device of FIG. 1, and FIG. 14 is a block diagram for explaining the relationship between the command processor and task manager of FIG. 13.

Referring to FIGS. 13 and 14 , the neural processor 1000 may include at least one neural core 100. Each neural processor 1000 may include a task manager 600 and an L1 LSU 700 therein. Task managers 600 can exchange control signals and responses with the command processor 7000 through a control interconnection (CI).

In contrast, the L1 LSU 700 can exchange data through data interconnection and memory (DIM). Data interconnection and memory (DIM) may include an interconnection for transmitting data and a memory in which the data is shared. Specifically, data interconnection and memory (DIM) may include a local interconnection 200 and a data channel 6100. Additionally, data interconnection and memory (DIM) may include L1 shared memory 400, shared memory 2000, and volatile memory 32. However, this embodiment is not limited to this.

The task manager 600 may be controlled by the command processor 7000. That is, the command processor 7000 can transmit a task to the task manager 600 through a control signal, and the task manager 600 can transmit a task completion report to the command processor 7000. At least one task manager 600 may be included in the neural processor 1000. Additionally, if there are multiple neural processors 1000, the number of task managers 600 may increase. All of these plurality of task managers 600 can be controlled by the command processor 7000.

FIG. 15 is a block diagram to explain in detail the structure of the task manager of FIG. 8.

Referring to FIGS. 8, 9, and 15, the task manager 600 may include a table passage 610, a task passage 620, and a dawn passage 630.

The table passage 610 may receive a table update request (TURQ) that updates the matching table of physical addresses and logical addresses from the control channel 6200 and transmit it to the core global 500. At this time, the table update request may be transmitted from the command processor 7000 through the control channel 6200.

The task passage 620 may receive a task from the control channel 6200, generate task information accordingly, and transmit it to the core global 500. At this time, the task may be transmitted from the command processor 7000 through the control channel 6200. Core Global 500 may transmit task information to Neural Core 100. The neural core 100 can perform a task according to the delivered task information and transmit a completion signal to the core global 500.

Core Global 500 may transmit a completion signal to Dawn Passage 630. The Dawn Passage 630 may receive a completion signal and generate a task completion report (DNrp). The Dawn Passage 630 may transmit a completion report (DNrp) to the command processor 7000 through the control channel 6200.

Additionally, the table update request (TURQ) of the table passage 610 may be transmitted to the neural core 100 through the core global 500. At this time, the table of the conversion index buffer 114 within the LSU 110 of the neural core 100 may be updated.

FIG. 16 is a block diagram for explaining the table passage of FIG. 15 in detail.

Referring to FIG. 16, the table passage 610 may include a table buffer 611 and first to mth update request queues 611a1 to 611am.

The table buffer 611 may store a table update request (TURQ) in which a physical address and a logical address are matched, transmitted from the command processor 7000. When the core global 500 fetches these table update requests (TURQ), each table update request (TURQ) may be stored in the first to mth update request queues 611a1 to 611am.

Each of the first to mth update request queues 611a1 to 611am may store different types of table update requests (TURQ). For example, different types of table update requests (TURQ) may include at least one of a neural core TLB update request, a micro DMA TLB update request, an LP micro DMA TLB update request, and an ST micro DMA TLB update request. However, this embodiment is not limited to this. In some embodiments, each of the first to mth update request queues 611a1 to 611am may include the same type of table update request (TURQ).

Additionally, the first to mth update request queues 611a1 to 611am may each be general queues, that is, queues that accommodate various types of requests. Accordingly, each of the first to mth update request queues 611a1 to 611am can accept requests regardless of type.

Each of the first to mth update request queues 611a1 to 611am may transmit a table update request (TURQ) to the core global 500 and may be transmitted to the LSU 110 through the core global 500. At this time, the table of the conversion index buffer 114 within the LSU 110 may be updated.

FIG. 17 is a block diagram for explaining the task passage of FIG. 15 in detail.

Referring to FIG. 17, the task passage 620 includes a task buffer 621, a task queue 622, and a runtime handle (RH).

The task buffer 621 may store a task according to a control signal transmitted from the command processor 7000. The task buffer 621 may store a task in the task queue 622 in the form of a task descriptor by the task fetching operation of the core global 500.

The task queue 622 is configured to sequentially store task descriptors, perform a dependency check on the stored task descriptors, and sequentially store task descriptors for which the dependency check has been completed. In an embodiment, task queue 622 may include a first queue (Q1), a dependency checker (DPc), and a second queue (Q2).

The first queue Q1 may store a task descriptor provided from the task buffer 621. The task buffer 621 may transmit the task descriptor to the first queue (Q1) and generate a transfer report (TRrp). The task buffer 621 may transmit the transfer dawn report (TRrp) to the dawn passage 630. The transfer report (TRrp) may be a report on the task transmitted to the first queue (Q1).

The first queue Q1 may store task descriptors divided according to the type of task descriptor. In Figure 17, n first queues Q1 are shown. At this time, n may be a natural number. That is, there may be at least one first queue Q1.

At this time, the first queue (Q1) may include the 1_1th to 1_nth queues (Q1_1 to Q1_n). The 1_1 queue (Q1_1) may store the first task descriptor (Tsk_d1), and the 1_2 queue (Q1_2) may store the second task descriptor (Tsk_d2). The 1_nth queue (Q1_n) can store the nth task descriptor (Tsk_dn).

The first to nth task descriptors (Tsk_d1 to Tsk_dn) may be of different types or may be of the same type. Alternatively, some of the first to nth task descriptors (Tsk_d1 to Tsk_dn) may be of the same type, and some may be of different types.

The dependency checker (DPc) can receive a dependency update request (DFURQ). A dependency update request (DFURQ) can notify changes in dependencies as completed tasks occur according to defined dependencies between specific tasks. That is, each task descriptor may include a dependency field indicating which task it has a dependency on. At this time, when the task included in the dependency field is completed, it must be updated in such a way that it is removed from the dependency field. Accordingly, the dependency update request (DFURQ) may include an update request for the dependency field of the task descriptor.

The dependency checker (DPc) may sequentially transmit the first to nth task descriptors (Tsk_d1 to Tsk_dn), descriptors for which the dependency check has been completed, to the second queue (Q2).

At this time, the second queue Q2 may include the 2_1st to 2_nth queues (Q2_1 to Q2_n). The 2_1 queue (Q2_1) may store the first task descriptor (Tsk_d1), and the 2_2 queue (Q2_2) may store the second task descriptor (Tsk_d2). The 2_nth queue (Q2_n) can store the nth task descriptor (Tsk_dn). The number of second queues Q2 may be the same as the number of first queues Q1.

The first queue (Q1) of the task queue 622 stores the first to nth task descriptors (Tsk_d1 to Tsk_dn) in the state before the dependency check, and the second queue (Q2) of the task queue 622 stores the dependency check. The first to nth task descriptors (Tsk_d1 to Tsk_dn) for which durency checks have been completed may be stored.

The runtime handle (RH) extracts the necessary information from each of the first to nth task descriptors (Tsk_d1 to Tsk_dn) stored in the second queue (Q2) to generate the first to nth task information (Tsk_d1' to Tsk_dn'). You can. The runtime handle (RH) may transmit first to nth task information (Tsk_d1' to Tsk_dn') to the core global 500. At this time, the first to nth task information (Tsk_d1' to Tsk_dn') may correspond to the first to nth task descriptors (Tsk_d1 to Tsk_dn), respectively. At this time, each of the first to nth task information (Tsk_d1' to Tsk_dn') may be the same as the first to nth task descriptors (Tsk_d1 to Tsk_dn). However, this embodiment is not limited to this.

The runtime handle (RH) can transmit check-in data (ChI) to the Dawn passage 630. Check-in data (ChI) may include first to nth task descriptors (Tsk_d1 to Tsk_dn). Check-in data (ChI) is the first to nth task information (Tsk_d1' to Tsk_dn') corresponding to the first to nth task descriptors (Tsk_d1 to Tsk_dn) leaving the task passage 620 for processing and returning to the core global (500). ) may be data indicating through the Dawn Passage 630 that it has been transmitted. Dawn passage 630 monitors whether the task descriptor is performed according to the check-in data (ChI).

The first to nth task descriptors (Tsk_d1 to Tsk_dn) may be configured to include a standby field. The waiting field may be an item pre-specified by software. The task descriptor with the wait field set is not converted into task information at the check-in timing and delivered to the core global 500, but waits in the second queue Q2. Here, check-in timing refers to the point in time when all preceding task descriptors are delivered to the core global 500, and check-in transfers task information to the core global 500 and transfers the corresponding task descriptor to the Dawn passage 630. It can mean doing.

A task descriptor with the wait field set is in a wait state. The wait field may be a means of controlling the execution timing of a task, and the task flow and execution timing may be controlled through the runtime handle (RH).

Figure 18 is a block diagram to specifically explain the function of the runtime handle.

Referring to FIG. 18, the 2_1st to 2_nth queues (Q2_1 to Q2_n) may store a plurality of task descriptors for which the dependency check has been completed. The 2_1 queue (Q2_1) may include the 1_1 task descriptor (Tsk_d11) to the 1_k task descriptor (Tsk_d1k). The 1_1st task descriptor (Tsk_d11) to the 1_kth task descriptor (Tsk_d1k) may be stored in the 2_1 queue (Q2_1) in order. Here, k is a natural number. Likewise, the 2_2 queue (Q2_2) may include the 2_1 task descriptor (Tsk_d21) to the 2_k task descriptor (Tsk_d2k), and the 2_n queue (Q2_n) may include the n_1 task descriptor (Tsk_dn1) to the n_k task descriptor ( Tsk_dnk). In an exemplary embodiment, the wait field may be set in the 1_2 task descriptor (Tsk_d12), the 2_3 task descriptor (Tsk_d23), and the n_k task descriptor (Tsk_dnk), and the wait field may not be set in the remaining task descriptors. It can be.

In the 2_1 queue (Q2_1), the 1_1 task descriptor (Tsk_d11) may be converted to task information at the check-in timing and transmitted to the core global 500 with the standby field not set, and the corresponding check-in data (ChI ) can be transmitted to the Dawn passage (630). In contrast, the runtime handle (RH) may wait in the 2_1 queue (Q2_1) without checking in the 1_2 task descriptor (Tsk_d12) even if the 1_2 task descriptor (Tsk_d12) for which the wait field is set corresponds to the check-in timing.

As the 1_2 task descriptor (Tsk_d12) waits in the 2_1 queue (Q2_1) in a waiting state, other task descriptors (Tsk_d13 to Tsk_d1k) following the 1_2 task descriptor (Tsk_d12) cannot be checked in and are stored in the 2_1 queue (Q2_1). will continue to wait.

The runtime handle (RH) can control all progress timings for the 2_1st to 2_nth queues (Q2_1 to Q2_n). The 2_1st and 2_2nd task descriptors (Tsk_d21, Tsk_d22) preceding the 2_3rd task descriptor (Tsk_d23) may be converted into task information at the check-in timing and transmitted to the core global 500, and the corresponding check-in data (ChI) It is delivered as passage 630. In contrast, the 2_3 task descriptor (Tsk_d23) cannot be checked in by the runtime handle (RH) and waits in the 2_2 queue (Q2_2).

In addition, the task descriptors preceding the n_k task descriptor (Tsk_dnk) may be converted to task information through the runtime handle (RH) and transmitted to the core global 500, and the corresponding check-in data (ChI) may be sent to the Dawn passage ( 630), but the n_k task descriptor (Tsk_dnk) including the wait field waits in the 2_n queue (Q2_n).

That is, the runtime handle (RH) can check whether the task descriptor stored in the 2_1st to 2_nth queues (Q2_1 to Q2_n) includes a wait field and determine the state of the task descriptor as a progress state or a wait state.

The runtime handle (RH) can receive a progress signal (Run) from the command processor 7000. A progress signal (Run) may be provided from the command processor 7000 through a control interconnection (CI). The command processor 7000 may transmit a progress signal (Run) in response to transmitting a task including a standby field, but the embodiment of the present invention is not limited thereto. The command processor 7000 may transmit a progress signal (Run) to the runtime handle (RH) at a certain period. The runtime handle (RH) can change the task descriptor from the standby state to the progress state in response to the progress signal (Run). The runtime handle (RH) may be configured to receive a progress signal (Run) and store the progress signal (Run) for a certain period of time. The runtime handle (RH) may include at least one of at least one register (Rs) and a counter (Rc) for receiving and storing the progress signal (Run), but the embodiment of the present invention is not limited thereto.

Hereinafter, with reference to FIGS. 19 to 21, the process in which the runtime handle (RH) performs Wait-Run control according to the progress signal (Run) will be described in more detail.

Figure 19 is an example diagram for explaining a process of processing a task descriptor included in the 2_1 queue (Q2_1) in response to a progress signal.

Referring to FIG. 19, it can be seen how the task descriptors (Tsk_d11 to Tsk_d13) included in the 2_1 queue (Q2_1) are processed according to the change in time (t0 -> t3). Here, the time (t0 to t3) is an exemplary time unit divided according to the processing state of each task descriptor, and is not limited to a specific time. In the 2_1 queue (Q2_1), the 1_2 task descriptor (Tsk_d12) includes a wait field, but the remaining task descriptors do not include a wait field.

At time t0, the 1_1 task descriptor (Tsk_d11) corresponds to the check-in timing. That is, the 1_1 task descriptor (Tsk_d11) corresponds to the leading task descriptor in the 2_1 queue (Q2_1). The runtime handle (RH) may determine that the 1_1 task descriptor (Tsk_d11), which does not include a wait field, is in progress. The runtime handle (RH) can convert the 1_1 task descriptor (Tsk_d11) into 1_1 task information (Tsk_d11') and transmit it to the core global 500, and the corresponding check-in data (ChI) can be transmitted to the dawn passage 630. You can.

At the first time (t1), the 1_2 task descriptor (Tsk_d12) corresponds to the check-in timing. That is, the 1_2 task descriptor (Tsk_d12) corresponds to the leading task descriptor in the 2_1 queue (Q2_1). However, the runtime handle (RH) may determine that the 1_2 task descriptor (Tsk_d12) including the wait field is in a waiting state, and may cause the 1_2 task descriptor (Tsk_d12) to wait in the 2_1 queue (Q2_1). Additionally, the runtime handle (RH) can check whether the progress signal (Run) is received in the register (Rs). At the first time t1, the progress signal Run has not yet been received. Accordingly, the runtime handle (RH) continues to maintain the waiting state of the 1_2 task descriptor (Tsk_d12). As the 1_2 task descriptor (Tsk_d12) waits, the following 1_3 task descriptor (Tsk_d13) also waits in the 2_1 queue (Q2_1).

At the second time t2, the progress signal Run is received, and the state of the register Rs may be changed according to the reception of the progress signal Run. In an embodiment, the state of the register (Rs) that has received the progress signal (Run) is defined as the active state, and the state of the register (Rs) that has not received the progress signal (Run) is defined as the basic state. For example, the progress signal (Run) may be a 1-bit signal, and the register (Rs) may be changed from the basic state (0) to the active state (1) in response to the progress signal (Run). The runtime handle (RH) may release the standby state of the 1_2 task descriptor (Tsk_d12) in response to the progress signal (Run) and convert it to the progress state. The runtime handle (RH) can convert the 1_2 task descriptor (Tsk_d12) into 1_2 task information (Tsk_d12') and transmit it to the core global 500, and the corresponding check-in data (ChI) can be transmitted to the dawn passage 630. You can.

At the third time t3, as the progress signal Run is used to release the standby state of the 1_2 task descriptor Tsk_d12, the state of the register Rs is restored from the active state to the default state. . The 1_3rd task descriptor (Tsk_d13) corresponds to the check-in timing. The runtime handle (RH) can convert the 1_3 task descriptor (Tsk_d13), which does not include a standby field, into 1_3 task information (Tsk_d13') and transmit it to the core global 500, and the corresponding check-in data (ChI) can be converted into 1_3 task information (Tsk_d13'). It can be delivered as a passage (630).

Figure 20 is an example diagram for explaining a process of processing a task descriptor included in the 2_1 queue (Q2_1) in response to a previously received progress signal. Here, the time (t0 to t3) is an exemplary time unit divided according to the processing state of each task descriptor, and is not limited to a specific time. In the 2_1 queue (Q2_1), the 1_2 task descriptor (Tsk_d12) includes a wait field, but the remaining task descriptors do not include a wait field.

Referring to FIG. 20, it can be seen how the task descriptors (Tsk_d11 to Tsk_d14) included in the 2_1 queue (Q2_1) are processed according to the change in time (t0 -> t3).

At time t0, the 1_1 task descriptor (Tsk_d11) corresponds to the check-in timing. That is, the 1_1 task descriptor (Tsk_d11) corresponds to the leading task descriptor in the 2_1 queue (Q2_1). The runtime handle (RH) can determine that the 1_1 task descriptor (Tsk_d11), which does not include a waiting field, is in progress, and converts the 1_1 task descriptor (Tsk_d11) into 1_1 task information (Tsk_d11') to the core global ( 500), and the corresponding check-in data (ChI) can be delivered to Dawn Passage 630.

Additionally, at time t0, it can be confirmed that the register Rs is active in response to the reception of the progress signal Run. The 1_1 task descriptor (Tsk_d11), which does not include a standby field, undergoes a check-in process regardless of the state of the register (Rs).

At the first time (t1), the 1_2 task descriptor (Tsk_d12) corresponds to the check-in timing. That is, the 1_2 task descriptor (Tsk_d12) corresponds to the leading task descriptor in the 2_1 queue (Q2_1). The runtime handle (RH) may determine that the 1_2 task descriptor (Tsk_d12) including the wait field is in a waiting state, and may cause the 1_2 task descriptor (Tsk_d12) to wait in the 2_1 queue (Q2_1). However, the runtime handle (RH) can release the standby state of the 1_2 task descriptor (Tsk_d12) through a previously received progress signal (Run). The runtime handle (RH) can convert the 1_2 task descriptor (Tsk_d12) into 1_2 task information (Tsk_d12') and transmit it to the core global 500, and the corresponding check-in data (ChI) can be transmitted to the dawn passage 630. You can.

At the second time (t2), the 1_3 task descriptor (Tsk_d13) corresponds to the check-in timing. The runtime handle (RH) can convert the 1_3 task descriptor (Tsk_d13), which does not include a standby field, into 1_3 task information (Tsk_d13') and transmit it to the core global 500, and the corresponding check-in data (ChI) can be converted into 1_3 task information (Tsk_d13'). It can be delivered as a passage (630). Additionally, at the second time t2, the progress signal Run may be received in advance and the register Rs may be converted to the active state. The active state of the register Rs can be maintained for some time, and a check-in process can be performed on a task descriptor that does not include a standby field regardless of the state of the register Rs.

It can be seen that at the third time t3, the register Rs continues to remain active. The 1_4th task descriptor (Tsk_d14) corresponds to the check-in timing. The runtime handle (RH) can convert the 1_4 task descriptor (Tsk_d14), which does not include a wait field, into 1_4 task information (Tsk_d14') and transmit it to the core global 500, and the corresponding check-in data (ChI) is It can be delivered as a passage (630).

In some embodiments, the register Rs may be configured to receive a plurality of progress signals Run. In an embodiment, the run time handle (RH) may process the progress signal (Run) received in each of the plurality of registers (Rs) individually in response to a task descriptor in a waiting state.

Figure 21 is an example diagram for explaining a process of processing a task descriptor included in the 2_1 queue (Q2_1) in response to a plurality of progress signals. Here, the time (t0 to t3) is an exemplary time unit divided according to the processing state of each task descriptor, and is not limited to a specific time. In the 2_1 queue (Q2_1), the 1_2 task descriptor (Tsk_d12) and the 1_4 task descriptor (Tsk_d14) include a wait field, but the remaining task descriptors do not include a wait field.

Referring to FIG. 21, at time t0, the 1_1 task descriptor (Tsk_d11) corresponds to the check-in timing. That is, the 1_1 task descriptor (Tsk_d11) corresponds to the leading task descriptor in the 2_1 queue (Q2_1). The runtime handle (RH) can determine that the 1_1 task descriptor (Tsk_d11), which does not include a waiting field, is in progress, and converts the 1_1 task descriptor (Tsk_d11) into 1_1 task information (Tsk_d11') to the core global ( 500), and the corresponding check-in data (ChI) can be delivered to Dawn Passage 630.

Additionally, at time t0, a plurality of progress signals (Run) may be received. For example, two progress signals (Run) may be received in the first register (Rs1) and the second register (Rs2), respectively. It can be confirmed that the first register (Rs1) and the second register (Rs2) are active according to the received progress signal (Run). The 1_1 task descriptor (Tsk_d11), which does not include a standby field, undergoes a check-in process regardless of the states of the first and second registers (Rs1 and Rs2).

At the first time (t1), the 1_2 task descriptor (Tsk_d12) corresponds to the check-in timing. That is, the 1_2 task descriptor (Tsk_d12) corresponds to the leading task descriptor in the 2_1 queue (Q2_1). The runtime handle (RH) may determine that the 1_2 task descriptor (Tsk_d12) including the wait field is in a waiting state, and may cause the 1_2 task descriptor (Tsk_d12) to wait in the 2_1 queue (Q2_1). However, the runtime handle (RH) can release the standby state of the 1_2 task descriptor (Tsk_d12) through the progress signal (Run) of the first register (Rs1) received in advance. The runtime handle (RH) can convert the 1_2 task descriptor (Tsk_d12) into 1_2 task information (Tsk_d12') and transmit it to the core global 500, and the corresponding check-in data (ChI) can be transmitted to the dawn passage 630. You can.

At the second time (t2), the 1_3 task descriptor (Tsk_d13) corresponds to the check-in timing. The runtime handle (RH) can convert the 1_3 task descriptor (Tsk_d13), which does not include a standby field, into 1_3 task information (Tsk_d13') and transmit it to the core global 500, and the corresponding check-in data (ChI) can be converted into 1_3 task information (Tsk_d13'). It can be delivered as a passage (630).

At the third time (t3), the 1_4th task descriptor (Tsk_d14) corresponds to the check-in timing. That is, the 1_4th task descriptor (Tsk_d14) corresponds to the leading task descriptor in the 2_1 queue (Q2_1). The runtime handle (RH) may determine that the 1_4th task descriptor (Tsk_d14) including the wait field is in a waiting state, and may cause the 1_4th task descriptor (Tsk_d14) to wait in the 2_1 queue (Q2_1). However, the runtime handle (RH) can release the standby state of the 1_4th task descriptor (Tsk_d14) through the progress signal (Run) of the second register (Rs2) received in advance. The runtime handle (RH) can convert the 1_4 task descriptor (Tsk_d14) into 1_4 task information (Tsk_d14') and transmit it to the core global 500, and the corresponding check-in data (ChI) can be transmitted to the dawn passage 630. You can.

In some embodiments, the runtime handle (RH) may include a counter (Rc) that can receive and process a plurality of progress signals (Run). The runtime handle (RH) can individually utilize a plurality of progress signals (Run) received from the counter (Rc) to release the waiting state of the task descriptor.

Figure 22 is an example diagram for explaining a process of processing a task descriptor included in the 2_1 queue (Q2_1) through a plurality of progress signals received by the counter. Here, the time (t0 to t3) is an exemplary time unit divided according to the processing state of each task descriptor, and is not limited to a specific time. In the 2_1 queue (Q2_1), the 1_2 task descriptor (Tsk_d12) and the 1_4 task descriptor (Tsk_d14) include a wait field, but the remaining task descriptors do not include a wait field.

Referring to FIG. 21, at time t0, the 1_1 task descriptor (Tsk_d11) corresponds to the check-in timing. That is, the 1_1 task descriptor (Tsk_d11) corresponds to the leading task descriptor in the 2_1 queue (Q2_1). The runtime handle (RH) can determine that the 1_1 task descriptor (Tsk_d11), which does not include a waiting field, is in progress, and converts the 1_1 task descriptor (Tsk_d11) into 1_1 task information (Tsk_d11') to the core global ( 500), and the corresponding check-in data (ChI) can be delivered to Dawn Passage 630.

Additionally, at time t0, a progress signal Run may be received by the counter Rc. From the received progress signal (Run), it can be seen that one progress signal (Run) has been received by the counter (Rc). The 1_1 task descriptor (Tsk_d11), which does not include a standby field, undergoes a check-in process regardless of the state of the counter (Rc).

At the first time t1, one progress signal Run can be received by the counter Rc, and it can be seen that the state of the counter Rc has changed from 1 to 2.

At the first time (t1), the 1_2 task descriptor (Tsk_d12) corresponds to the check-in timing. That is, the 1_2 task descriptor (Tsk_d12) corresponds to the leading task descriptor in the 2_1 queue (Q2_1). The runtime handle (RH) may determine that the 1_2 task descriptor (Tsk_d12) including the wait field is in a waiting state, and may cause the 1_2 task descriptor (Tsk_d12) to wait in the 2_1 queue (Q2_1). However, the runtime handle (RH) can release the standby state of the 1_2 task descriptor (Tsk_d12) through the progress signal (Run) of the counter (Rc) received in advance. The runtime handle (RH) can convert the 1_2 task descriptor (Tsk_d12) into 1_2 task information (Tsk_d12') and transmit it to the core global 500, and the corresponding check-in data (ChI) can be transmitted to the dawn passage 630. You can.

At the second time (t2), the 1_3 task descriptor (Tsk_d13) corresponds to the check-in timing. The runtime handle (RH) can convert the 1_3 task descriptor (Tsk_d13), which does not include a standby field, into 1_3 task information (Tsk_d13') and transmit it to the core global 500, and the corresponding check-in data (ChI) can be converted into 1_3 task information (Tsk_d13'). It can be delivered as a passage (630).

At the third time (t3), the 1_4th task descriptor (Tsk_d14) corresponds to the check-in timing. That is, the 1_4th task descriptor (Tsk_d14) corresponds to the leading task descriptor in the 2_1 queue (Q2_1). The runtime handle (RH) may determine that the 1_4th task descriptor (Tsk_d14) including the wait field is in a waiting state, and may cause the 1_4th task descriptor (Tsk_d14) to wait in the 2_1 queue (Q2_1). However, the runtime handle (RH) can release the standby state of the 1_4th task descriptor (Tsk_d14) through the progress signal (Run) of the counter (Rc) received in advance. The runtime handle (RH) can convert the 1_4 task descriptor (Tsk_d14) into 1_4 task information (Tsk_d14') and transmit it to the core global 500, and the corresponding check-in data (ChI) can be transmitted to the dawn passage 630. You can.

In addition, the runtime handle (RH) not only controls the wait-run control of individual task descriptors, but also provides a pause function to temporarily pause and resume the operation of at least one second queue. -Resume control can also be performed.

In some embodiments, the runtime handle (RH) may temporarily stop checking in a task descriptor in at least one second queue when an abnormality or overload is expected in the operation of the neural core 100.

In some embodiments, the runtime handle (RH) may perform stop-restart control based on a danger signal provided in the dark passage 630. Here, the danger signal may be an event according to at least one of a hardware or software error, a log-related event, and a task performed without a descriptor, and such event may be provided from the event monitor (EM) of the Dawn passage 630, which will be described later. However, the embodiments of the present invention are not limited thereto.

Additionally, the runtime handle (RH) may perform stop-restart control in response to an overload of the task queue 622 or an overload of the report queue of the reporting manager (RM), which will be described later.

Depending on the pause control of the runtime handle (RH), the processing of task information corresponding to the task descriptor being transmitted to the core global 500 may be temporarily stopped. When the overload is resolved, the runtime handle (RH) can release the stopped state and restart processing of the waiting task descriptor.

FIG. 23 is a block diagram for explaining the Dawn passage of FIG. 15 in detail.

Referring to FIG. 23, the dawn passage 630 may include a check-in buffer (Cib), dependency setters (DPs), timeout monitor (ToM), event monitor (EM), and report management module 631. there is.

The check-in buffer (Cib) can receive check-in data (ChI). The check-in buffer (Cib) may include first to n-th check-in buffers (Cib_1 to Cib_n). The check-in buffer (Cib) may store the first to n-th task descriptors (Tsk_d1 to Tsk_dn) stored in the check-in data (ChI). The first to nth check-in buffers (Cib_1 to Cib_n) may store the first to nth task descriptors (Tsk_d1 to Tsk_dn), respectively. The check-in buffer (Cib) can perform check-in of the first to n-th task descriptors (Tsk_d1 to Tsk_dn) through this.

That is, the first check-in buffer (Cib_1) can store the first task descriptor (Tsk_d1), and the second check-in buffer (Cib_2) can store the second task descriptor (Tsk_d2). The nth check-in buffer (Cib_n) may store the nth task descriptor (Tsk_dn). The number of check-in buffers (Cib) may be equal to the number of first queues (Q1) and the number of second queues (Q2).

The check-in buffer (Cib) may receive a completion signal from the core global 500. At this time, the completion signal may include the first to nth completion signals (Tsk_d1d to Tsk_dnd). The first to nth completion signals (Tsk_d1d to Tsk_dnd) may be completion signals for the first to nth task descriptors (Tsk_d1 to Tsk_dn), respectively. The first to nth completion signals (Tsk_d1d to Tsk_dnd) may be received into the first to nth check-in buffers (Cib_1 to Cib_n), respectively. That is, the first check-in buffer (Cib_1) may receive the first completion signal (Tsk_d1d), and the second check-in buffer (Cib_2) may receive the second completion signal (Tsk_d2d). The nth check-in buffer (Cib_n) may receive the nth completion signal (Tsk_dnd).

Dependency setters (DPs) may receive a completion signal from the check-in buffer (Cib) and generate a dependency update request (DFURQ). That is, dependency setters (DPs) can generate a dependency update request (DFURQ) depending on which task corresponding to the task descriptor has been completed. Dependency setters (DPs) may transmit a dependency update request (DFURQ) to the task passage 620.

Dependency setters (DPs) may check out each of the first to nth task descriptors (Tsk_d1 to Tsk_dn) according to the completion signal. Accordingly, dependency setters (DPs) can generate a checkout report (COrp) about which tasks have been completed and checked out. Dependency setters (DPs) can transmit a checkout report (COrp) to the reporting management module 631.

In other words, check-in is a procedure in which a task descriptor is registered before it is processed, and check-out can be defined as a procedure in which registration is deregistered after the task descriptor has been processed.

As the dependency setters (DPs) transmit a dependency update request (DFURQ) to the task passage 620, the dependency checker (DPc) of the task passage 620 updates the task descriptor according to the dependency of the task descriptor. can be transmitted sequentially.

In this embodiment, the command processor 7000 does not take full charge of processing according to dependencies, but allows the task manager 600 to directly perform dependency checking and setting, thereby improving communication with the command processor 7000. Overhead can be minimized. Accordingly, the performance and speed of the neural processing device 1 according to this embodiment can be dramatically improved.

The timeout monitor (ToM) may receive a timeout detection signal (TOdec) from the check-in buffer (Cib). The timeout detection signal (TOdec) may be a signal indicating whether the time from check-in to check-out exceeds a preset threshold time. Here, the checkout time may mean the time when the task is completed. The check-in buffer (Cib) can monitor the execution time of the task corresponding to the checked-in task descriptor. The check-in buffer (Cib) can determine whether to generate a timeout detection signal (TOdec) by comparing the task execution time and the threshold time. The check-in buffer (Cib) may generate a timeout detection signal (TOdec) when the execution time calculated from the check-in time exceeds the threshold time. That is, if the task is not completed by the critical time, a timeout detection signal (TOdec) is generated. The first to nth check-in buffers (Cib_1 to Cib_n) check whether the checked-in task descriptor is performed, and if the execution time exceeds the threshold time, a timeout detection signal (TOdec) is generated.

In embodiments, the threshold time may be set individually depending on the task. In some embodiments, the threshold time may be set differently depending on the type of task. A task corresponding to a memory operation may be set to have a shorter threshold time than a task corresponding to a computation. However, the embodiments of the present invention are not limited thereto.

Additionally, in an embodiment, whether or not to generate a timeout report may be individually set depending on the task. That is, the command processor 7000 can be configured not to receive timeout reports for at least some of the tasks delivered to the task manager 600. Since timeout monitoring can be set not to be performed for all tasks, the burden of timeout monitoring on the task manager 600 can be reduced. As an example, a timeout report may be generated for a task corresponding to a computation, but a timeout report may be set not to be generated for a task corresponding to a memory operation. However, the embodiments of the present invention are not limited thereto.

The timeout monitor (ToM) can generate a timeout report (TOrp) according to the timeout detection signal (TOdec). The timeout monitor (ToM) can transmit the generated timeout report (TOrp) to the reporting management module 631.

In an embodiment, the event monitor (EM) may detect whether an event occurs and may generate an event report (Erp) according to the event detection signal. The generated event report (Erp) may be provided to the reporting management module 631.

The reporting management module 631 may generate a completion report (DNrp) by receiving at least one of a transfer report (TRrp), an event report (Erp), a checkout report (COrp), and a timeout report (TOrp). .

In the embodiment, the checkout report (COrp) corresponds to a report that allows the command processor 7000 to confirm that the task delivered to the neural core 100 has been processed normally and checked out.

The transfer report (TRrp) corresponds to a report that allows the command processor 7000 to confirm that the task has been normally provided as a task passage 620 and a task descriptor has been created.

The event report (Erp) corresponds to a report that allows the command processor 7000 to confirm that an event according to at least one of hardware or software errors, log-related events, and tasks performed without a descriptor has occurred.

The timeout report (TOrp) corresponds to a report that allows the command processor 7000 to confirm that processing for a specific task is delayed beyond a set threshold time.

In an embodiment, a checkout report (COrp), a transfer report (TRrp), an event report (Erp), and a timeout report (TOrp) may each be generated independently. For example, even if a timeout report (TOrp) is generated due to a delay in the performance of a task related to a specific task descriptor, the checkout report (COrp) generates a timeout report (TOrp) when the execution of the task is completed. Can occur independently.

Here, the completion report (DNrp) may be generated based on the checkout report (COrp). Since the completion report (DNrp) includes at least a checkout report, whether the task is normally performed can be communicated to the command processor 7000. Through the creation and delivery of this completion report (DNrp), it is confirmed whether the task is performed normally, and the prolonged performance delay of a specific task depending on the dependency can be prevented.

In addition, the completion report (DNrp) may be configured to further include at least one of a transfer report (TRrp), an event report (Erp), and a timeout report (TOrp), and whether the task is performed, whether it times out, and whether the transfer Completion, whether an event has occurred, etc. can be comprehensively reported to the command processor 7000.

FIG. 24 is a block diagram for explaining the report management module of FIG. 23 in detail.

Referring to FIG. 24, the report management module 631 includes a transfer report queue (TQ), an event report queue (EQ), a checkout report queue (CQ), a timeout report queue (TOQ), and a reporting manager (RM). may include.

The Transfer Dawn Report Queue (TQ) can receive the Transfer Dawn Report (TRrp) and deliver it to the Reporting Manager (RM). Transfer Dawn Reports (TRrp) can be received sequentially in the Transfer Dawn Report Queue (TQ), and accumulated Transfer Dawn Reports (TRrp) can be delivered to the Reporting Manager (RM) according to first-in-first-out (FIFO).

The event report queue (EQ) can receive the event report (Erp) and deliver it to the reporting manager (RM). Event reports (Erp) can be sequentially received in the event report queue (EQ), and accumulated event reports (Erp) can be delivered to the reporting manager (RM) according to first-in-first-out (FIFO). The checkout report queue (CQ) can receive the checkout report (COrp) and deliver it to the reporting manager (RM). Checkout reports (COrp) can be sequentially received in the checkout report queue (CQ), and the accumulated checkout reports (COrp) can be delivered to the reporting manager (RM) according to first-in-first-out (FIFO). Additionally, the timeout report queue (TOQ) can receive the timeout report (TOrp) and deliver it to the reporting manager (RM). Timeout reports (TOrp) can be sequentially received in the timeout report queue (TOQ), and accumulated timeout reports (TOrp) can be delivered to the reporting manager (RM) according to first-in-first-out (FIFO).

The reporting manager (RM) can receive at least one of the transfer report (TRrp), event report (Erp), checkout report (COrp), and timeout report (TOrp), and generate a completion report (DNrp) through this. there is. The reporting manager (RM) may transmit the completion report (DNrp) to the command processor 7000.

Additionally, the reporting manager (RM) may monitor the status of at least one of an event report queue (EQ), a checkout report queue (CQ), and a timeout report queue (TOQ). The reporting manager (RM) monitors at least one of the event report acceptance status of the event report queue (EQ), the checkout report acceptance status of the checkout report queue (CQ), and the timeout report acceptance status of the timeout report queue (TOQ). can do. If at least one of the event report queue (EQ), checkout report queue (CQ), and timeout report queue (TOQ) is confirmed to be saturated, the reporting manager (RM) generates a task passage (620) through the runtime handle (RH). ) operation can be paused.

FIG. 25 is a diagram illustrating data exchanged between the core global and neural core of FIG. 15.

Referring to FIG. 25, Core Global 500 may receive a table update request (TURQ) and transmit it to LSU 110. Additionally, the core global 500 may receive task information (Tsk_d') and transmit it to the neural core 100.

The neural core 100 may perform a task and generate a completion signal (Tsk_dd). The LSU 110 or the processing unit 160 may transmit a completion signal (Tsk_dd) to the core global 500. Core global 500 may include a signal scheduler (sgn_sch). The signal scheduler (sgn_sch) may receive a completion signal, schedule transmission of the completion signal, and transmit it to the Dawn passage 630.

Figure 26 is a diagram for explaining the types of task descriptors stored in the first queue, second queue, and check-in buffer.

Referring to FIG. 26, the 1_1st to 1_4th queues (Q1_1 to Q1_4) of the first queue (Q1), the 2_1st to 2_4th queues (Q2_1 to Q2_4) of the second queue (Q2), and the check-in buffer (Cib) The first to fourth check-in buffers (Cib_1 to Cib_4) may each store a specific type of task descriptor. The 1_1st to 1_4th queues (Q1_1 to Q1_4), the 2_1st to 2_4th queues (Q2_1 to Q2_4), and the 1st to 4th check-in buffers (Cib_1 to Cib_4) may each store different types of task descriptors.

For example, the 1_1 queue (Q1_1), the 2_1 queue (Q2_1), and the first check-in buffer (Cib_1) store the task descriptor for computation, and the 1_2 queue (Q1_2), the 2_2 queue (Q2_2), and The second check-in buffer (Cib_2) may store a task descriptor for micro DMA. In addition, the 1_3 queue (Q1_3), the 2_3 queue (Q2_3), and the third check-in buffer (Cib_3) store the task descriptor for LP micro DMA, and the 1_4 queue (Q1_4), the 2_4 queue (Q2_4), and the 4 Check-in buffer (Cib_4) can store a task descriptor for ST micro DMA. However, this embodiment is not limited to this.

FIG. 27 is a diagram illustrating a first queue, a second queue, and a check-in buffer of a neural processing device according to some embodiments of the present invention.

Referring to FIG. 27, the 1_1st to 1_4th queues (Q1_1 to Q1_4), the 2_1st to 2_4th queues (Q2_1 to Q2_4), and the 1st to 4th check-in buffers (Cib_1 to Cib_4) each have a specific type of task descriptor. You can save it. The 1_1st to 1_4th queues (Q1_1 to Q1_4), the 2_1st to 2_4th queues (Q2_1 to Q2_4), and the 1st to 4th check-in buffers (Cib_1 to Cib_4) may store task descriptors of the same type.

For example, the 1_1 queue (Q1_1), the 2_1 queue (Q2_1), and the 1st check-in buffer (Cib_1) store the task descriptor for the first computation, and the 1_2 queue (Q1_2) and the 2_2 queue (Q2_2) ) and the second check-in buffer (Cib_2) may store a task descriptor for the second computation. In addition, the 1_3 queue (Q1_3), the 2_3 queue (Q2_3), and the third check-in buffer (Cib_3) store the task descriptor for the third computation, and the 1_4 queue (Q1_4), the 2_4 queue (Q2_4), and The fourth check-in buffer (Cib_4) may store a task descriptor for the fourth computation. However, this embodiment is not limited to this.

At this time, the first to fourth computations may be completely the same computation, or may be computations of the same type but different in detail.

FIG. 28 is a diagram illustrating a first queue, a second queue, and a check-in buffer of a neural processing device according to some embodiments of the present invention.

Referring to FIG. 28, the 1_1st to 1_4th queues (Q1_1 to Q1_4), the 2_1st to 2_4th queues (Q2_1 to Q2_4), and the 1st to 4th check-in buffers (Cib_1 to Cib_4) each contain several types of task descriptors. You can save it. The 1_1st to 1_4th queues (Q1_1 to Q1_4), the 2_1st to 2_4th queues (Q2_1 to Q2_4), and the 1st to 4th check-in buffers (Cib_1 to Cib_4) may store different types of task descriptors, and may store the same task descriptors. You can also store the type's task descriptor.

Figure 29 is a block diagram to explain in detail the structure of a neural processing device according to some embodiments of the present invention.

Referring to FIG. 29, the neural core 101, unlike the neural core 100, may have a CGRA structure. The neural core 101 may include an instruction memory 111_1, a CGRA L0 memory 111_2, a PE array 111_3, and a Load/Store Unit (LSU) 111_4.

The instruction memory 111_1 can receive and store instructions. The instruction memory 111_1 may sequentially store instructions internally and provide the stored instructions to the PE array 111_3. At this time, the instruction may direct the operation of the processing element 111_3a included in each PE array 111_3.

The CGRA L0 memory 111_2 is a memory located inside the neural core 101, and allows the neural core 101 to receive all input data required for work from the outside and temporarily store them. Additionally, the CGRA L0 memory 111_2 can temporarily store output data calculated by the neural core 101 in order to transmit it to the outside. The CGRA L0 memory 111_2 may serve as a cache memory for the neural core 101.

The CGRA L0 memory 111_2 can transmit and receive data with the PE array 111_3. The CGRA L0 memory 111_2 may be a memory corresponding to L0 (level 0), which is lower than L1. At this time, the L0 memory may be a private memory of the neural core 101 that is not shared. The CGRA L0 memory (111_2) can transmit data such as activation or weight and programs to the PE array (111_3).

The PE array 111_3 may be a module that performs calculations. The PE array 111_3 can perform not only one-dimensional operations but also two-dimensional or more matrix/tensor operations. The PE array 111_3 may include a plurality of processing elements 111_3a and a specific processing element 111_3b therein.

The processing element 111_3a and the specific processing element 111_3b may be arranged in rows and columns. The processing element 111_3a and the specific processing element 111_3b may be arranged in m columns. Additionally, the processing element 111_3a may be arranged in n rows, and the specific processing element 111_3b may be arranged in l rows. Accordingly, the processing element 111_3a and the specific processing element 111_3b may be arranged in (n+l) rows and m columns.

The LSU 111_4 may receive at least one of data, control signals, and synchronization signals from the outside through the local interconnection 200. The LSU 111_4 may transmit at least one of the received data, control signal, and synchronization signal to the CGRA L0 memory 111_2. Similarly, the LSU 111_4 may transmit at least one of data, a control signal, and a synchronization signal to the outside through the local interconnection 200.

The neural core 101 may have a Coarse Grained Reconfigurable Architecture (CGRA) structure. Accordingly, the neural core 101 configures each processing element 111_3a and the specific processing element 111_3b of the PE array 111_3 at least one of the CGRA L0 memory 111_2, the instruction memory 111_1, and the LSU 111_4. It can be connected to one. That is, the processing element 111_3a and the specific processing element 111_3b do not have to be connected to all of the CGRA L0 memory 111_2, the instruction memory 111_1, and the LSU 111_4, but may be connected to some of them.

Additionally, the processing element 111_3a and the specific processing element 111_3b may be different types of processing elements. Accordingly, among the CGRA L0 memory 111_2, the instruction memory 111_1, and the LSU 111_4, the element connected to the processing element 111_3a and the element connected to the specific processing element 111_3b may be different from each other.

The neural core 101 of the present invention with a CGRA structure is capable of high-level parallel operations and direct data exchange between the processing element 111_3a and the specific processing element 111_3b, so power consumption can be low. Additionally, optimization according to various computational tasks may be possible by including two or more types of processing elements 111_3a.

For example, if the processing element 111_3a is a processing element that performs a two-dimensional operation, the specific processing element 111_3b may be a processing element that performs a one-dimensional operation. However, this embodiment is not limited to this.

FIG. 30 is a diagram illustrating the hierarchical structure of a command processor and a task manager of a neural processing device according to some embodiments of the present invention, and FIG. 31 is a diagram illustrating a command processor and a task manager of a neural processing device according to some embodiments of the present invention. This is a diagram to explain the hierarchy of managers.

Referring to FIGS. 30 and 31 , if the number of task managers 600 increases, it may be difficult for the command processor 7000 to manage all task managers 600. Accordingly, in the neural processing device 1 according to some embodiments of the present invention, the master task manager 600M manages a plurality of task managers 600, and the command processor 7000 manages the master task manager 600M. You can have a hi-key structure to manage.

Additionally, referring to FIG. 31, levels below the master task manager 600M may also be subdivided into various ways. For example, the first sub-task manager 600s1 and the second sub-task manager 600s2 may form separate layers. That is, one first sub-task manager 600s1 manages at least one second sub-task manager 600s2, and one master task manager 600M manages at least one first sub-task manager 600s1. can do. Additionally, multiple layers may be added below the second sub-task manager 600s2.

That is, although three levels of the task manager 600, the master task manager 600M, and the command processor 7000 are shown in FIGS. 30 and 31, the number of levels may be four or more. In other words, the depth of the hi-key structure may vary depending on the number of task managers 600.

Figure 32 is a block diagram for explaining memory reorganization of a neural processing system according to some embodiments of the present invention.

Referring to FIG. 32, the neural core SoC 10 may include first to eighth processing units 160a to 160h and an on-chip memory (OCM). Eight processing units are shown as an example, but this is only an example and the number of processing units may vary.

The on-chip memory (OCM) may include first to eighth L0 memories 120a to 120h and a shared memory 2000.

The first to eighth L0 memories 120a to 120h may be used as dedicated memories for the first to eighth processing units 160a to 160h, respectively. That is, the first to eighth processing units 160a to 160h and the first to eighth L0 memories 120a to 120h may correspond to each other 1:1.

The shared memory 2000 may include first to eighth memory units 2100a to 2100h. The first to eighth memory units 2100a to 2100h may correspond to the first to eighth processing units 160a to 160h and the first to eighth L0 memories 120a to 120h, respectively. That is, the number of memory units may be 8, which is the same as the number of processing units and L0 memories.

Shared memory 2000 may operate in either of two types of on-chip memory formats. That is, the shared memory 2000 may operate in either an L0 memory format or a global memory format. In other words, the shared memory 2000 can implement two logical memories with one hardware.

When the shared memory 2000 is implemented in an L0 memory format, the shared memory 2000 is a dedicated memory for each of the first to eighth processing units 160a to 160h, such as the first to eighth L0 memories 120a to 120h. It can operate with (private memory). The L0 memory can operate at a relatively high clock speed compared to the global memory, and the shared memory 2000 can also use a relatively faster clock when operating in the L0 memory format.

When the shared memory 2000 is implemented in a global memory format, the shared memory 2000 can operate as a common memory that the first processing unit 100a and the second processing unit 100b use together. there is. At this time, the shared memory 2000 may be shared not only by the first to eighth processing units 160a to 160h but also to the first to eighth L0 memories 120a to 120h.

Global memory can generally use a lower clock than L0 memory, but is not limited to this. When the shared memory 2000 operates in a global memory format, the first to eighth processing units 160a to 160h may share the shared memory 2000. At this time, the shared memory 2000 is connected to the volatile memory 32 of FIG. 2 through the global interconnection 6000, and may operate as a buffer of the volatile memory 32.

At least part of the shared memory 2000 may operate in an L0 memory format, and the remainder may operate in a global memory format. That is, the entire shared memory 2000 may operate in an L0 memory format, or the entire shared memory 2000 may operate in a global memory format. Alternatively, part of the shared memory 2000 may operate in the L0 memory format, and the remaining part may operate in the global memory format.

Figure 33 is a block diagram showing an example of memory reorganization of a neural processing system according to some embodiments of the present invention.

32 and 33, the first, third, fifth and seventh dedicated areas (AE1, AE3) of each of the first, third, fifth and seventh processing units (100a, 100c, 100e, 100g) , AE5, and AE7) may include only the first, third, fifth, and seventh L0 memories 120a, 120c, 120e, and 120g, respectively. In addition, the second, fourth, sixth, and eighth dedicated areas (AE2, AE4, AE6, and AE8) of the second, fourth, sixth, and eighth processing units (100b, 100d, 100f, and 100h) are respectively It may include second, fourth, sixth, and eighth L0 memories (120b, 120d, 120f, 120h). Additionally, the second, fourth, sixth, and eighth dedicated areas (AE2, AE4, AE6, and AE8) will include the second, fourth, sixth, and eighth memory units (2100b, 2100d, 2100f, 2100h). You can. The first, third, fifth, and seventh memory units 2100a, 2100c, 2100e, and 2100g of the shared memory 2000 may be used as a common area (AC).

The common area AC may be a memory shared by the first to eighth processing units 160a to 160h. The second dedicated area AE2 may include a second L0 memory 120b and a second memory unit 2100b. The second dedicated area AE2 may be an area in which the hardware-separated second L0 memory 120b and the second memory unit 210b operate in the same manner and logically operate as one L0 memory. The fourth, sixth, and eighth dedicated areas (AE4, AE6, and AE8) may also operate in the same manner as the second dedicated area (AE2).

The shared memory 2000 according to this embodiment can be used by converting the area corresponding to each neural core into logical L0 memory and logical global memory at an optimized ratio. The shared memory 2000 can adjust this ratio at run time.

In other words, each neural core may perform the same tasks, but may also perform different tasks. In this case, the capacity of L0 memory and the capacity of global memory required for the work performed by each neural core are bound to be different each time. Accordingly, if the composition ratio of L0 memory and shared memory is set fixedly, as in the existing on-chip memory, inefficiencies may occur due to the computational tasks assigned to each neural core.

Accordingly, the shared memory 2000 of the neural processing device according to this embodiment can set the optimal ratio of L0 memory and global memory according to the computational task during run time and improve computational efficiency and speed.

Figure 34 is an enlarged block diagram of part A of Figure 32.

32 and 34, the shared memory 2000 includes a first L0 memory controller 122_1a, a second L0 memory controller 122_1b, a fifth L0 memory controller 122_1e, and a sixth L0 memory controller 122_1f. , may include first to eighth memory units 2100a to 2100h and a global controller 2200. Other L0 memory controllers not shown may also be included in this embodiment, but descriptions are omitted for convenience.

The first L0 memory controller 122_1a can control the first L0 memory 120a. Additionally, the first L0 memory controller 122_1a may control the first memory unit 2100a. Specifically, when the first memory unit 2100a is implemented in a logical L0 memory format, control by the first L0 memory controller 122_1a may be performed on the first memory unit 2100a.

The second L0 memory controller 122_1b can control the second L0 memory 120b. Additionally, the second L0 memory controller 122_1b may control the second memory unit 2100b. That is, when the second memory unit 2100b is implemented in a logical L0 memory format, control by the first L0 memory controller 122_1a can be performed on the second memory unit 2100b.

The fifth L0 memory controller 122_1e can control the fifth L0 memory 120e. Additionally, the fifth L0 memory controller 122_1e can control the fifth memory unit 2100e. That is, when the fifth memory unit 2100e is implemented in a logical L0 memory format, control by the fifth L0 memory controller 122_1e can be performed on the fifth memory unit 2100e.

The sixth L0 memory controller 122_1f can control the sixth L0 memory 120f. Additionally, the sixth L0 memory controller 122_1f can control the sixth memory unit 2100f. That is, when the sixth memory unit 2100f is implemented in a logical L0 memory format, control by the sixth L0 memory controller 122_1f can be performed on the sixth memory unit 2100f.

The global controller 2200 can control all of the first to eighth memory units 2100a to 2100h. Specifically, when the first to eighth memory units 2100a to 2100h each logically operate in the global memory format (i.e., do not logically operate in the L0 memory format), the global controller 2200 operates the first memory The units 2100a to 8th memory units 2100h can be controlled.

That is, the first to eighth memory units 2100a to 2100h are controlled by the first to eighth L0 memory controllers 122_1a to 122_1h, respectively, or by the global controller 2200, depending on what type of memory they are logically implemented as. It can be controlled by

When L0 memory controllers including the first, second, fifth, and sixth L0 memory controllers 122_1a, 122_1b, 122_1e, and 122_1f control the first to eighth memory units 2100a to 2100h, respectively, the first Since the first to eighth L0 memory controllers 122_1a to 141h control the first to eighth memory units 2100a to 2100h in the same manner as the first to eighth L0 memories 120a to 120h, the first to eighth processing units It can be controlled with a dedicated memory of (160a~160h). Accordingly, the first to eighth memory units 2100a to 2100h may operate at a clock frequency corresponding to the clock frequency of the first to eighth processing units 160a to 160h.

The L0 memory controllers including the first L0 memory controller 122_1a, the second L0 memory controller 122_1b, the fifth L0 memory controller 122_1e, and the sixth L0 memory controller 122_1f are respectively the LSU 110 of FIG. 8. may include.

When the global controller 2200 controls at least one of the first to eighth memory units 2100a to 2100h, the global controller 2200 controls the first to eighth memory units 2100a to 2100h, respectively. It can be controlled by the global memory of the 8th processing unit (160a ~ 160h). Accordingly, at least one of the first to eighth memory units 2100a to 2100h may operate at a clock frequency that is unrelated to the clock frequency of the first to eighth processing units 160a to 160h. However, this embodiment is not limited to this.

The global controller 2200 may connect the first to eighth memory units 2100a to 2100h with the global interconnection 6000 of FIG. 3. The first to eighth memory units 2100a to 2100h exchange data with the off-chip memory 30 of FIG. 1 by the global controller 2200, or exchange data with the first to eighth L0 memories 120a to 120h, respectively. can be exchanged.

The first to eighth memory units 2100a to 2100h may each include at least one memory bank. The first memory unit 2100a may include at least one first memory bank 2110a. The first memory bank 2110a may be an area divided by dividing the first memory unit 2100a into a specific size. Each first memory bank 2110a may be a memory element of the same size. However, this embodiment is not limited to this. In Figure 29, four memory banks are shown as being included in one memory unit.

Similarly, the second, fifth, and sixth memory units 2100b, 2100e, and 2100f may each include at least one second, fifth, and sixth memory bank 2110b, 2110e, and 2110f.

Hereinafter, the description will be made based on the first memory bank 2110a and the fifth memory bank 2110e, which may be the same as other memory banks including the second and sixth memory banks 2110b and 2110f.

The first memory bank 2110a may logically operate in an L0 memory format or logically in a global memory format. At this time, the first memory bank 2110a may operate independently from other memory banks in the first memory unit 2100a. However, this embodiment is not limited to this.

When operating independently for each memory bank, the first memory unit 2100a has a first area that operates in the same manner as the first L0 memory 120a and a second area that operates in a different manner from the first L0 memory 120a. Can include 2 areas. At this time, the first area and the second area do not necessarily coexist, and one area may occupy the entire first memory unit 2100a.

Likewise, the second memory unit 2100b may include a third area that operates in the same manner as the second L0 memory 120b and a fourth area that operates in a different manner from the second L0 memory 120b. At this time, the third area and the fourth area do not necessarily coexist, and one area may occupy the entire first memory unit 2100a.

At this time, the ratio of the first area to the second area may be different from the ratio of the third area to the fourth area. However, this embodiment is not limited to this. Accordingly, the ratio of the first area to the second area may be the same as the ratio of the third area to the fourth area. That is, the memory configuration ratio in each memory unit can vary as much as desired.

In general, in the case of existing system-on-chip, the on-chip memory, excluding high-speed L0 memory, is often composed of high-density, low-power SRAM. This is because SRAM has high efficiency in terms of chip area and power usage compared to the required capacity. However, the processing speed of the existing on-chip memory inevitably slowed down significantly in the case of tasks that required more data quickly than the predetermined capacity of the L0 memory, and even when the need for global memory was not large, there was no way to utilize the remaining global memory. There was no use at all, resulting in inefficiency.

In contrast, the shared memory 2000 according to some embodiments of the present invention may be selectively controlled by one of two controllers, depending on the case. At this time, the shared memory 2000 is not controlled as a whole by only one of the two controllers, but can be independently controlled on a memory unit basis or a memory bank basis.

Through this, the shared memory 2000 according to this embodiment can obtain the optimal memory configuration ratio according to the computational task during run time and perform faster and more efficient computational tasks. In the case of processing units specialized in artificial intelligence, the required sizes of L0 memory and global memory may vary for each specific application. Furthermore, even for the same application, when using a deep learning network, the required sizes of L0 memory and global memory for each layer may vary. The shared memory 2000 according to this embodiment can enable fast and efficient deep learning work because the memory composition ratio can be changed during run time despite changes in the calculation steps for each layer.

FIG. 35 is a diagram for explaining the first memory bank of FIG. 34 in detail. Although FIG. 35 illustrates the first memory bank 2110a, other memory banks may also have the same structure as the first memory bank 2110a.

Referring to FIG. 35, the first memory bank 2110a may include a cell array (Ca), a bank controller (Bc), a first path unit (P1), and a second path unit (P2).

The cell array (Ca) may include a plurality of memory elements (Cells) therein. The cell array Ca may have a plurality of memory elements arranged in a lattice structure. The cell array (Ca) may be, for example, a Static Random Access Memory (SRAM) cell array.

The bank controller (Bc) can control the cell array (Ca). The bank controller Bc may determine whether the cell array Ca will operate in an L0 memory format or a global memory format and control the cell array Ca accordingly.

Specifically, the bank controller (Bc) can determine whether to transmit and receive data in the first path unit (P1) direction or the second path unit (P2) direction during run time. The bank controller (Bc) can determine the direction of data transmission and reception according to the path control signal (Spc).

The path control signal (Spc) can be generated by a pre-designed device driver or compiler. A path control signal (Spc) can be generated according to the characteristics of the computational task. Alternatively, the path control signal (Spc) may be generated by input received from the user. In other words, the user can directly apply the input to the path control signal (Spc) in order to select the most optimal memory configuration ratio.

The bank controller (Bc) can determine a path for transmitting and receiving data stored in the cell array (Ca) through the path control signal (Spc). The data exchange interface may vary depending on how the bank controller (Bc) determines the path through which data is transmitted and received. That is, the bank controller Bc can use the first interface when exchanging data with the first path unit P1, and can use the second interface when exchanging data with the second path unit P2. At this time, the first interface and the second interface may be different from each other.

Additionally, the address system in which data is stored may also vary. That is, when a specific interface is selected, read and write operations can be performed using the corresponding address system.

The bank controller (Bc) can operate at a specific clock frequency. For example, when the cell array Ca is an SRAM cell array, the bank controller Bc can operate at a typical SRAM operating clock frequency.

The first path unit (P1) may be connected to the bank controller (Bc). The first path unit P1 may directly exchange data of the cell array Ca with the first processing unit 100a. At this time, “directly” may mean that they are exchanged without going through the global interconnection (6000). That is, the first processing unit 100a can directly exchange data with the first L0 memory 120a, and the first processing unit 100a can first process the first processing unit 100a when the shared memory 2000 is logically implemented in the L0 memory format. 1 Data can be exchanged through the path unit (P1). The first path unit P1 may include an L0 memory controller including the first L0 memory controller 122_1a and the second L0 memory controller 122_1b of FIG. 32 .

The first path unit P1 may configure a multi-cycle sync path. That is, the operating clock frequency of the first path unit P1 may be the same as the operating clock frequency of the first processing unit 100a. The first L0 memory 120a can quickly exchange data at the same clock frequency as the operating clock frequency of the first processing unit 100a in order to quickly exchange data at the same speed as the operation of the first processing unit 100a. . The first path unit P1 may also operate at the same clock frequency as the operating clock frequency of the first processing unit 100a.

At this time, the operating clock frequency of the first path unit (P1) may be a multiple of the operating clock frequency of the bank controller (Bc). In this case, a separate CDC (Clock Domain Crossing) operation for clock synchronization between the bank controller (Bc) and the first path unit (P1) is not required, and accordingly, a delay in data transmission may not occur. there is. Accordingly, faster and more efficient data exchange may be possible.

In FIG. 35 , as an example, the operating clock frequency of the first path unit P1 may be 1.5 GHz. This may be twice the frequency of 750 MHz of the bank controller (Bc). However, this embodiment is not limited to this, and it may be possible as long as the first path unit (P1) operates at an integer multiple of the clock frequency of the bank controller (Bc).

The second path unit (P2) may be connected to the bank controller (Bc). The second path unit P2 may exchange data of the cell array Ca through the global interconnection 6000 instead of directly exchanging it with the first processing unit 100a. That is, the first processing unit 100a can exchange data with the cell array Ca through the global interconnection 6000 and the second path unit P2. At this time, the cell array Ca can exchange data not only with the first processing unit 100a but also with other neural cores.

That is, the second path unit P2 may be a data exchange path between the cell array Ca and all neural cores when the first memory bank 2110a is logically implemented in a global memory format. The second path unit (P2) may include the global controller 2200 of FIG. 23.

The second path unit (P2) may configure an Async-Path. The operating clock frequency of the second path unit P2 may be the same as the operating clock frequency of the global interconnection 6000. The second path unit P2 may also operate at the same clock frequency as the operating clock frequency of the global interconnection 6000.

At this time, the operating clock frequency of the second path unit (P2) may not be synchronized with the operating clock frequency of the bank controller (Bc). In this case, a Clock Domain Crossing (CDC) operation may be required to synchronize clocks between the bank controller (Bc) and the second path unit (P2). If the operating clock frequency of the bank controller (Bc) and the operating clock frequency of the second path unit (P2) are not synchronized with each other, the degree of freedom in designing the clock domain may increase. Accordingly, the difficulty of hardware design is lowered and hardware operations can be derived more easily.

The bank controller Bc may use different address systems when exchanging data through the first path unit P1 and when exchanging data through the second path unit P2. That is, the bank controller Bc can use the first address system through the first path unit P1 and the second address system through the second path unit P2. At this time, the first address system and the second address system may be different from each other.

The bank controller (Bc) does not necessarily need to exist for each memory bank. In other words, the bank controller (Bc) is not a part for scheduling but serves to transmit signals, so it is not an essential part for each memory bank with two ports. Therefore, one bank controller (Bc) can control multiple memory banks. Multiple memory banks can operate independently although controlled by the bank controller (Bc). However, this embodiment is not limited to this.

Of course, a bank controller (Bc) may exist for each memory bank. In this case, the bank controller Bc can individually control each memory bank.

34 and 35, when the first memory unit 210a exchanges data through the first path unit (P1), it uses the first address system and exchanges data through the second path unit (P2). In case of exchange, a second address system can be used. Similarly, when the second memory unit 210b exchanges data through the first path unit P1, a third address system is used, and when data is exchanged through the second path unit P2, the second address system is used. You can use the system. At this time, the first address system and the third address system may be the same. However, this embodiment is not limited to this.

The first address system and the third address system may be used exclusively for the first processing unit 100a and the second processing unit 100b, respectively. The second address system may be commonly applied to the first processing unit 100a and the second processing unit 100b.

In FIG. 35 , as an example, the operating clock frequency of the second path unit P2 may operate at 1 GHz. This may be a frequency that is not synchronized with the 750 MHz operating clock frequency of the bank controller (Bc). That is, the operating clock frequency of the second path unit (P2) can be freely set without being at all dependent on the operating clock frequency of the bank controller (Bc).

Typical global memory uses slow SRAM (e.g., 750 MHz) and faster global interconnection (e.g., 1 GHz), which inevitably causes delays due to CDC operations. In contrast, the shared memory 2000 according to some embodiments of the present invention has room to use the first path unit (P1) in addition to the second path unit (P2), thereby avoiding delays due to the CDC task.

In addition, since a typical global memory uses a single global interconnection 6000 for multiple neural cores, a decrease in overall processing speed can easily occur when data transmission occurs simultaneously. On the other hand, the shared memory 2000 according to some embodiments of the present invention has room to use the first path unit (P1) in addition to the second path unit (P2), thereby appropriately reducing the data processing load on the global controller 2200. A dispersing effect can also be achieved.

Figure 36 is a block diagram illustrating the software hierarchy of a neural processing device according to some embodiments of the present invention.

Referring to FIG. 36, the software layer structure of a neural processing device according to some embodiments of the present invention may include a DL framework 10000, a compiler stack 20000, and a backend module 30000.

The DL framework (10000) may refer to a framework for a deep learning model network used by users. For example, a fully trained neural network can be created using programs such as TensorFlow or PyTorch.

The compiler stack 20000 may include an adaptation layer 21000, a compute library 22000, a front-end compiler 23000, a back-end compiler 24000, and a runtime driver 25000.

The adaptation layer (21000) may be a layer in contact with the DL framework (10000). The adaptation layer (21000) can quantize the user's neural network model created in the DL framework (10000) and modify the graph. Additionally, the adaptation layer 21000 can convert the model type into a required type.

The front-end compiler (23000) can convert various neural network models and graphs received from the adaptation layer (21000) into a certain intermediate representation (IR). The converted IR may be a preset expression that is easy to handle later in the backend compiler 24000.

The IR of the front-end compiler 23000 can be optimized in advance at the graph level. Additionally, the front-end compiler 23000 can ultimately generate the IR by converting it into a hardware-optimized layout.

The backend compiler (24000) optimizes the IR converted from the frontend compiler (23000) and converts it into a binary file so that the runtime driver can use it. The back-end compiler (24000) can generate optimized code by dividing the job at a scale that matches the details of the hardware.

The compute library 22000 can store template operations designed in a form suitable for hardware among various operations. The compute library 22000 provides several template operations that require hardware to the backend compiler 24000, allowing optimized code to be generated.

The runtime driver 25000 may continuously perform monitoring while driving to drive the neural network device according to some embodiments of the present invention. Specifically, it may be responsible for executing the interface of the neural network device.

The backend module 30000 may include an application specific integrated circuit (ASIC) 31000, a field programmable gate array (FPGA) 32000, and a C-model (33000). ASIC (31000) may refer to a hardware chip determined according to a predetermined design method. FPGA 32000 may be a programmable hardware chip. C-model (33000) may refer to a model implemented by simulating hardware in software.

The backend module 30000 can perform various tasks and derive results using binary code generated through the compiler stack 20000.

Figure 37 is a conceptual diagram to explain a deep learning operation performed by a neural processing device according to some embodiments of the present invention.

Referring to FIG. 37, the artificial neural network model 40000 is an example of a machine learning model, and in machine learning technology and cognitive science, a statistical learning algorithm implemented based on the structure of a biological neural network or an algorithm thereof. It is a structure that executes .

In the artificial neural network model (40000), as in a biological neural network, nodes, which are artificial neurons that form a network through the combination of synapses, repeatedly adjust the weight of the synapse, creating a gap between the correct output corresponding to a specific input and the inferred output. By learning to reduce the error of , a machine learning model with problem-solving capabilities can be expressed. For example, the artificial neural network model 40000 may include random probability models, neural network models, etc. used in artificial intelligence learning methods such as machine learning and deep learning.

A neural processing device according to some embodiments of the present invention may perform calculations by implementing this type of artificial neural network model (40000). For example, the artificial neural network model 40000 may receive an input image and output information about at least a portion of the object included in the input image.

The artificial neural network model (40000) is implemented as a multilayer perceptron (MLP) consisting of multiple layers of nodes and connections between them. The artificial neural network model 40000 according to this embodiment can be implemented using one of various artificial neural network model structures including MLP. As shown in FIG. 36, the artificial neural network model 40000 includes an input layer 41000 that receives an input signal or data 40100 from the outside, and an output layer that outputs an output signal or data 40200 corresponding to the input data. (44000), located between the input layer 41000 and the output layer 44000, receives n signals from the input layer 41000, extracts the characteristics, and transmits them to the output layer 44000 (where n is a positive integer). It consists of a hidden layer (42000 to 43000). Here, the output layer 44000 receives signals from the hidden layers 42000 to 43000 and outputs them to the outside.

The learning methods of the artificial neural network model (40000) include supervised learning, which learns to optimize problem solving by inputting teacher signals (correct answers), and unsupervised learning, which does not require teacher signals. ) There is a way.

The neural processing device can directly generate learning data for training the artificial neural network model (40000) through simulation. In this way, a plurality of input variables and a plurality of output variables corresponding to the input layer 41000 and the output layer 44000 of the artificial neural network model 40000 are matched, respectively, and the input layer 41000, hidden layers 42000 to 43000, and By adjusting the synapse values between nodes included in the output layer 44000, learning can be done so that the correct output corresponding to a specific input can be extracted. Through this learning process, the characteristics hidden in the input variables of the artificial neural network model (40000) can be identified, and the nodes of the artificial neural network model (40000) can be used to reduce the error between the output variables calculated based on the input variables and the target output. You can adjust the synapse value (or weight) between them.

FIG. 38 is a conceptual diagram illustrating learning and inference operations of a neural network of a neural processing device according to some embodiments of the present invention.

Referring to FIG. 38, in the training phase, a number of learning data (TD) may be forwarded to the artificial neural network model (NN) and then forwarded back again. Through this, the weights and biases of each node of the artificial neural network model (NN) are adjusted, and through this, learning can be performed to produce increasingly accurate results. Through this learning process (Training Phase), the artificial neural network model (NN) can be converted into a learned neural network model (NN_T).

In the inference phase, new data (ND) can be input back into the learned neural network model (NN_T). The learned neural network model (NN_T) can take new data (ND) as input and derive result data (RD) through already learned weights and biases. This result data (RD) may be important in terms of which learning materials (TD) were used in the training process (Training Phase) and how much learning materials (TD) were used.

Hereinafter, with reference to FIGS. 39 and 40, a task management method of a neural processing device according to some embodiments of the present invention will be described. The task management method according to the embodiment is a method performed in the neural processing device according to the above-described embodiment, and parts that overlap with the above-described embodiment are omitted or simplified. Additionally, FIGS. 1 to 38 and related descriptions may be referred to for description of the present embodiment.

Figure 39 is a flow chart to explain a task management method of a neural processing device according to some embodiments of the present invention.

Referring to FIG. 39, a task management method according to an embodiment includes receiving a task descriptor in a task queue (S100); Checking whether the task descriptor includes a waiting field (S200); and, when the task descriptor includes a waiting field, queuing the task descriptor in the task queue (S300).

Additionally, referring to FIG. 39, the task management method according to some embodiments may further include a step (S400) of releasing the standby state of the task descriptor in response to a progress signal provided from the command processor.

In step S400, the progress signal may be a signal provided after the waiting state of the task descriptor.

Additionally, in step S400, the progress signal may be a signal provided before the task descriptor waiting state.

Additionally, referring to FIG. 39, the task management method according to some embodiments includes generating task information corresponding to a task descriptor that has been released from the waiting state or a task descriptor that does not include a waiting field and transmitting it to the core global (S500). ; And it may further include providing a task descriptor corresponding to the task information transmitted to the core global as check-in data as a dawn passage (S600).

FIG. 40 is a flowchart illustrating in detail the step of receiving a task descriptor from the task queue of FIG. 39.

Referring to FIG. 40, in some embodiments, receiving a task descriptor in a task queue (S100) includes receiving a task from a command processor and generating a task descriptor for the task (S110), sending the task descriptor to the first It includes a step of storing in a queue (S120), a step of checking the dependency of the task descriptor (S130), and a step of storing the task descriptor for which the dependency check has been completed in a second queue (S140).

The above description is merely an illustrative explanation of the technical idea of the present embodiment, and those skilled in the art will be able to make various modifications and variations without departing from the essential characteristics of the present embodiment. Accordingly, the present embodiments are not intended to limit the technical idea of the present embodiment, but rather to explain it, and the scope of the technical idea of the present embodiment is not limited by these examples. The scope of protection of this embodiment should be interpreted in accordance with the claims below, and all technical ideas within the equivalent scope should be interpreted as being included in the scope of rights of this embodiment.

Claims (20)

a task buffer that receives a task from a command processor and creates a task descriptor for the task;
a task queue in which the task descriptor received from the task buffer waits; and
A runtime handle that generates task information corresponding to the task descriptor delivered from the task queue and transmits it to the core global,
The runtime handle causes the task descriptor to wait in the task queue when the task descriptor includes a wait field.
Task manager.
According to claim 1,
The runtime handle releases the waiting state of the task descriptor in response to a progress signal provided from the command processor,
Task manager.
According to clause 2,
The runtime handle includes a progress signal counter at which the progress signal is received,
Task manager.
According to clause 3,
The runtime handle releases the waiting state of the task descriptor through the progress signal previously received by the progress signal counter.
Task manager.
According to clause 3,
The progress signal counter is configured to receive at least two progress signals,
Task manager.
According to clause 2,
The runtime handle generates task information corresponding to the task descriptor from which the waiting state has been released or a task descriptor that does not include the waiting field and transmits it to the core global, and provides a task descriptor corresponding to the task information transmitted to the core global. Provided by Dawn Passage as check-in data,
Task manager.
According to clause 6,
The Dawn Passage receives a completion signal for the task information provided through the core global, and checks out the checked-in task descriptor in response to the completion signal to generate a completion report.
Task manager.
According to clause 6,
The runtime handle stops transmitting task information to the core global according to a danger signal provided from the dawn passage,
Task manager.
According to claim 1,
The task queue is,
a first queue that receives the task descriptor from the task buffer;
a dependency checker that receives a task descriptor from the first queue and performs a dependency check of the received task descriptor; and
Comprising a second queue that receives a task descriptor for which the dependency check has been completed from the dependency checker,
Task manager.
According to clause 9,
The second queue includes a first task descriptor and a second task descriptor stored sequentially,
As the first task descriptor is waiting in the second queue by the runtime handle, the second task descriptor is also waiting in the second queue.
Task manager.
a task manager that generates task information corresponding to the task descriptor depending on whether the task descriptor includes a waiting field;
a neural core that performs a task according to the task information and generates a completion signal for the task; and
Comprising a core global that receives task information about the task, transmits the task information to the neural core, and receives the completion signal of the task from the neural core,
Neural processing device.
According to claim 11,
The task manager is,
A task passage that generates the task descriptor, selectively generates the task information according to the task descriptor, and transmits it to the core global;
Comprising a Dawn passage that checks in the task descriptor from the task passage, receives the completion signal, checks out the task descriptor, and generates the completion report,
Neural processing device.
According to claim 12,
The task passage is,
a task buffer that receives a task from a command processor and creates a task descriptor for the task;
a task queue in which the task descriptor received from the task buffer waits; and
A runtime handle that generates task information corresponding to the task descriptor delivered from the task queue and transmits it to the core global,
The runtime handle causes the task descriptor to wait in the task queue if the task descriptor includes a wait field,
The runtime handle releases the waiting state of the task descriptor in response to a progress signal provided from the command processor,
Neural processing device.
According to claim 13,
The runtime handle generates task information corresponding to the task descriptor from which the waiting state has been released or a task descriptor that does not include the waiting field and transmits it to the core global, and provides a task descriptor corresponding to the task information transmitted to the core global. Provided by the Dawn Passage as check-in data,
Neural processing device.
Receiving a task descriptor in a task queue;
Checking whether the task descriptor includes a waiting field; and
When the task descriptor includes the waiting field, queuing the task descriptor in the task queue.
According to claim 15,
Further comprising releasing the waiting state of the task descriptor in response to a progress signal provided from a command processor,
Task management method for neural processing devices.
According to claim 16,
The progress signal is a signal provided after the waiting state of the task descriptor,
Task management method for neural processing devices.
According to claim 16,
The progress signal is a signal provided before the task descriptor waiting state,
Task management method for neural processing devices.
According to claim 16,
generating task information corresponding to a task descriptor from which the waiting state has been released or a task descriptor not including the waiting field and transmitting it to the core global; and
Further comprising providing a task descriptor corresponding to the task information transmitted to the core global as check-in data in a Dawn passage,
Task management method for neural processing devices.
According to claim 15,
The step of receiving the task descriptor in the task queue is,
Receiving a task from a command processor and generating a task descriptor for the task;
storing the task descriptor in a first queue;
Checking dependency of the task descriptor; and
Comprising the step of storing the task descriptor for which the dependency check has been completed in a second queue,
Task management method for neural processing devices.

Images