Neural mimicry hardware simulation method and system based on crossbar

Abstract

The invention provides a neural mimicry hardware simulation method and system based on crossbar, and the neural mimicry hardware comprises a simulator; the method comprises the steps that S1, a configuration file and a network file are loaded, and initialization parameters are obtained; s2, initializing a chip module and a neuron set module of the simulator according to the initialization parameters; s3, starting simulation, enabling the neuron set module to receive a pulse signal, and executing operation according to the pulse signal to obtain an operation result; s4, judging whether the simulation is finished or not according to the pulse count of the operation result, if so, executing the step S5, and if not, executing the step S5; if not, not processing; and S5, enabling the chip module to integrate all the operation results, and generating a report file. According to the invention, the problem of limitation of the current simulator in the aspects of precision, performance and flexibility is solved, and more stable and efficient simulation support is provided.

Description

Technical Field

[0001] The present invention belongs to the field of neuromorphic chip technology, and specifically, relates to a crossbar-based neuromorphic hardware simulation method and system, and more specifically, to the design and implementation of a crossbar-based neuromorphic hardware simulator. Background Art

[0002] Neuromorphic computing, or neuromorphic computing, as a computing method that imitates the operating mechanism of the human brain neural network, has been widely used in the fields of deep learning, artificial intelligence, and large-scale parallel computing in recent years. Neuromorphic computing can efficiently handle complex computing tasks by simulating the pulse transmission and synaptic weight adjustment between neurons. However, as the scale of neuromorphic computing continues to expand, traditional computing architectures, especially GPU-based parallel computing, have gradually exposed their limitations in processing neuromorphic computing. The high parallelism of GPUs mainly relies on synchronous computing units, while neuromorphic computing needs to process a large number of asynchronous neuronal activities.

[0003] This characteristic of neuromorphic computing means that GPUs often fail to fully utilize their hardware resources when performing these tasks, resulting in performance bottlenecks, especially poor performance in terms of energy consumption and latency. Neuromorphic chips based on the crossbar architecture provide new possibilities for solving this problem. The crossbar architecture achieves true large-scale parallel computing by directly mapping neurons and synapses to physical hardware.

[0004] In a typical crossbar array, thousands of neurons and synapses can perform computing operations simultaneously in the same time step, greatly improving computing efficiency. For example, the Memristor-based crossbar architecture can perform matrix multiplication and accumulation operations directly in the circuit, completing the calculation of the neural network by converting the input voltage into the output current. This direct hardware computing method not only reduces the data transmission requirements, but also significantly reduces energy consumption. In contrast, traditional GPUs need to frequently transfer data between memory and computing units, resulting in higher energy loss.

[0005] With the rapid development of neuromorphic computing, the demand for simulators is growing to cope with complex neural network structures and large-scale computing tasks. At present, some solutions for neuromorphic chip simulators have been proposed. Existing mature solutions can be divided into two categories: the first category is to simplify the creation of neuron models through domain-specific languages, such as the NESTML language introduced by NEST. NESTML provides a comprehensive and concise language to help researchers accurately describe complex biological neural system models and use them in the NEST simulator. However, the drawback of this approach is that researchers need to first learn the NESTML language, which increases the learning cost of development and model description, and hinders its popularity among researchers with non-programming backgrounds.

[0006] The second category is to improve simulation performance through hardware acceleration, such as the NeuroFlow platform. NeuroFlow uses customized hardware processors such as programmable gate arrays, or FPGAs, to achieve high-performance computing, and flexibly adjusts the degree of parallelism to adapt to different simulation needs. However, the disadvantage of using this solution is that developers need to have in-depth knowledge of hardware programming to effectively redesign and configure the processor architecture. In addition, reliance on customized hardware also brings compatibility and flexibility issues, making this solution difficult to be widely used on a variety of hardware platforms.

[0007] In addition, simulators such as Brian 2 and PIMCOMP also have their own limitations.

[0008] Brian 2 simplifies the description and simulation process of neural network models through runtime code generation, but the generated code may still not achieve the expected efficiency when processing tasks with high performance requirements; PIMCOMP focuses on the acceleration of deep neural networks. Although its crossbar structure is suitable for processing sparse matrix operations, it still needs to be optimized to cope with the unique computing requirements and architectural characteristics of a wider range of pulse neural network applications.

[0009] Patent document CN114968186A discloses a unified programming method for a general neural network tensor processor, which includes: a development step based on development software, a verification step based on development software, a verification step based on hardware virtual software, and a hardware-based deployment; wherein the development software refers to software used to complete neural network algorithm training, the hardware virtual software refers to software used to simulate the behavior of hardware running on the neural network algorithm, and the hardware refers to hardware used to execute the neural network algorithm. This solution improves the ease of use of embedded deployment of neural networks, but does not solve the limitations of current simulators in terms of accuracy, performance, and flexibility. This problem needs to be solved urgently. Summary of the invention

[0010] In view of the defects in the prior art, the object of the present invention is to provide a crossbar-based neuromorphic hardware simulation method and system.

[0011] According to a crossbar-based neuromorphic hardware simulation method provided by the present invention, the neuromorphic hardware includes: a simulator; the simulator includes a chip module and a neuron assembly module; the chip module is used to manage and coordinate the management of all cores, memory and on-chip network communications of the simulator; the neuron assembly module is used to perform simulation tasks;

[0012] The crossbar-based neuromorphic hardware simulation method is implemented based on the neuromorphic hardware, and includes:

[0013] Step S1: Load configuration files and network files to obtain initialization parameters;

[0014] Step S2: Initializing the chip module and neuron assembly module of the simulator according to the initialization parameters;

[0015] Step S3: starting the simulation, allowing the neuron assembly module to receive the pulse signal, and performing calculations according to the pulse signal to obtain calculation results;

[0016] Step S4: judging whether the simulation is finished according to the pulse count of the operation result, if the result is yes, executing step S5; if the result is no, no processing;

[0017] Step S5: instructing the chip module to integrate all the calculation results and generate a report file.

[0018] Preferably, the simulator of the neuromorphic hardware further comprises a core module; the core module is used to manage the computing and storage tasks of the chip; when the core of the core module is instantiated, a crossbar module is created; the crossbar module is used to process and transmit pulse signals between neurons;

[0019] In step S1, the initialization parameters include: the number of neurons, neuron ID, synapse information, neuron connection matrix and simulation parameters; the simulation parameters include simulation duration; the synapse information includes the number of synapses;

[0020] In the step S1, a global routing table is generated based on the neuron ID and synapse information of the initialization parameters;

[0021] In the step S2, the crossbar module of the simulator is initialized and a monitor is created; the monitor is used to check the status of the core of the core module;

[0022] In the step S2, the membrane potential of the neurons of the neuron assembly module is initialized.

[0023] Preferably, the step S3 includes:

[0024] Step S3.1: Instruct the crossbar module to send the pulse signal to the target neuron according to the global routing table;

[0025] Step S3.2: Instruct the neuron assembly module to update the neuron potential according to the pulse signal, and then accumulate the pulse value to obtain the calculation result;

[0026] Step S3.3: Instruct the core module to integrate all the calculation results to obtain a calculation result.

[0027] Preferably, in step S4, an inspection cycle is set, and according to the inspection cycle, the core module is allowed to check and determine through the monitor whether the pulse count of the previous cycle is equal to the pulse count of the current cycle. If the result is yes, the simulation result is recorded and output; if the result is no, the test is performed again.

[0028] Preferably, in step S5, the report file includes: the path of the configuration file, the number of cores, the number of neurons, simulation information, energy consumption statistics and operation data of each core; the energy consumption statistics are simulated and counted by the crossbar module according to the global routing table;

[0029] In step S3, a pulse accumulation threshold is set to determine whether the current pulse value is greater than the pulse accumulation threshold. If the result is yes, a pulse is emitted to clear the membrane potential of the neuron; if the result is no, no processing is performed.

[0030] According to a crossbar-based neuromorphic hardware simulation system provided by the present invention, the neuromorphic hardware includes: a simulator; the simulator includes a chip module and a neuron assembly module; the chip module is used to manage and coordinate the management of all cores, memory and on-chip network communications of the simulator; the neuron assembly module is used to perform simulation tasks;

[0031] The crossbar-based neuromorphic hardware simulation system includes:

[0032] Module M1: load configuration files and network files, and obtain initialization parameters;

[0033] Module M2: Initialize the chip module, core module and neuron assembly module of the simulator according to the initialization parameters;

[0034] Module M3: Start the simulation, so that the neuron module receives the pulse signal, and performs calculation according to the pulse signal to obtain the calculation result;

[0035] Module M4: judging whether the simulation is finished according to the count of the pulse signal, if the result is yes, executing step S5; if the result is no, no processing;

[0036] Module M5: instructs the chip module to integrate all the calculation results and generate a report file.

[0037] Preferably, the simulator of the neuromorphic hardware further comprises a core module; the core module is used to manage the computing and storage tasks of the chip; when the core of the core module is instantiated, a crossbar module is created; the crossbar module is used to process and transmit pulse signals between neurons;

[0038] In the module M1, the initialization parameters include: the number of neurons, neuron ID, synapse information, neuron connection matrix and simulation parameters; the simulation parameters include simulation duration; the synapse information includes the number of synapses;

[0039] In the module M1, a global routing table is generated based on the neuron ID and synapse information of the initialization parameters;

[0040] In the module M2, the crossbar module of the simulator is initialized and a monitor is created; the monitor is used to check the status of the core of the core module;

[0041] In the module M2, the membrane potential of the neurons of the neuron assembly module is initialized.

[0042] Preferably, the module M3 includes:

[0043] Module M3.1: instruct the crossbar module to send the pulse signal to the target neuron according to the global routing table;

[0044] Module M3.2: instructing the neuron assembly module to update the modulus potential of the neuron according to the pulse signal, and then accumulate the pulse value to obtain the calculation result;

[0045] Module M3.3: Instruct the core module to integrate all the calculation results to obtain the calculation result.

[0046] Preferably, in the module M4, an inspection cycle is set, and according to the inspection cycle, the core module is allowed to check and determine through the monitor whether the pulse count of the previous cycle is equal to the pulse count of the current cycle. If the result is yes, the simulation result is recorded and output; if the result is no, the test is performed again.

[0047] Preferably, in the module M5, the report file includes: the path of the configuration file, the number of cores, the number of neurons, simulation information, energy consumption statistics and operation data of each core; the energy consumption statistics are simulated and counted by the crossbar module according to the global routing table;

[0048] In the module M3, a pulse accumulation threshold is set to determine whether the current pulse value is greater than the pulse accumulation threshold. If the result is yes, a pulse is emitted to clear the membrane potential of the neuron; if the result is no, no processing is performed.

[0049] Compared with the prior art, the present invention has the following beneficial effects:

[0050] 1. The present invention simulates the parallel processing mechanism of the crossbar architecture, can simulate the delay of pulse neuron chips with microsecond accuracy, accurately output the results and energy consumption of network operation, and support efficient simulation of large neural networks with millions of neurons; and the present invention optimizes the communication and computing load distribution between neurons by adopting a multi-level graph partitioning method based on parallel graph calculation, reducing cross-thread communication between neurons by 57% and increasing the average running speed of the simulator by 63%.

[0051] 2. The present invention ensures the accurate transmission of pulse signals under complex neural network structures by introducing an efficient neuron routing table. Compared with using a global routing table, the average running speed of the simulator is increased by 25%, thereby enhancing the flexibility and scalability of the simulator.

[0052] 3. The present invention solves the problems of limitations of current simulators in terms of accuracy, performance and flexibility, and provides more stable and efficient simulation support. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0054] Figure 1 A schematic diagram of the system framework of a crossbar-based neuromorphic hardware simulator provided by the present invention;

[0055] Figure 2 A schematic diagram of the mechanism of the parallel computing simulation method on the crossbar provided by the present invention;

[0056] Figure 3 A schematic diagram of the neuron routing addressing strategy block provided by the present invention. DETAILED DESCRIPTION

[0057] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0058] The present invention provides a design and implementation of a crossbar-based neuromorphic hardware simulator, including: 1. The architecture of the existing neuromorphic chip is abstracted and implemented, and the key parts such as the core, crossbar, and neuron nodes in the chip are simulated using SystemC; 2. By simulating the crossbar parallel computing process, the pulse neurons are abstracted as nodes, and their computing process is abstracted as parallel graph computing to balance the computing delay and memory consumption brought about by the software simulation process; 3. Comprehensive and fine-grained configurable items are provided to support developers to simulate the latency, memory usage, energy consumption and other data of neuromorphic hardware; 4. By adopting a time step adaptive mechanism, the computing delay of the simulator is further optimized. In addition, the present invention performs a fine-grained simulation of the crossbar-based neuromorphic hardware, optimizes the performance on the basis of ensuring the accuracy of the simulator, improves its configurability and ease of use, and fills the gap in the field of general neuromorphic hardware simulators.

[0059] Step S1: Load and parse the configuration file and network description file; In this step, the simulator first loads the configuration file and network description file, parses key information such as network scale, number of neurons, synaptic connections, and provides the required configuration and parameters for the initialization of subsequent modules. Step S2: Initialize all key modules on the simulator; This step initializes the key modules in the simulator, including the chip module, the core module, the Crossbar module on each core, and the neuron collection module in the core. The initialization configuration of each module comes from the file information parsed in step S1. Step S3: Start the simulation and perform network operations; After the simulation starts, the chip module is responsible for the overall scheduling, and the core module coordinates the communication between the Crossbar module on it and other cores. The Crossbar module is responsible for scheduling the neuron collection module on it and performing specific computing task processing. Step S4: Stability monitoring and simulation end judgment; During the simulation process, the system continuously monitors the stability of the network, and determines whether the neural network has converged by observing the changes in the pulse counter, and then determines whether the simulation is completed. Step S5: Output the network operation results and performance statistics; After the simulation is completed, the chip module summarizes the execution results of each neuron collection module and generates an operation result file. At the same time, the chip module will also summarize the energy consumption statistics of each module, combined with the global simulation time of SystemC, to generate a performance report file to provide detailed simulation analysis.

[0060] In step S1, the initialization information includes simulator performance simulation parameters, namely, average latency of each calculation step, average memory read and write latency, average energy consumption of each calculation step and neural network operation information, including:

[0061] Step S1.1, load configuration file: load the pre-prepared neural network configuration information file. The file contains the network scale and simulation settings, including: the network scale includes: the total number of neurons, i.e., num_neurons, the total number of synapses, i.e., num_synapses, the number of input layer neurons, i.e., num_input_neurons, and the number of output layer neurons, i.e., num_output_neurons.

[0062] Core configuration information: including the number of neurons in each core, the task allocation of each neuron set, the communication delay between cores, etc. Simulation parameters: simulation mode, i.e. sim_mode, simulation duration, i.e. sim_time, and report detail level, i.e. report_verbose_level, determine the calculation accuracy and performance statistics during the simulation process. Other hardware parameters: such as the matrix configuration of each core and the configuration of local memory and global memory; the configuration of the global memory includes read and write delays and data width. The matrix configuration includes: crossbar size and delay.

[0063] The parsing of the configuration file is performed through the parser module in the system to ensure that the scale of the neural network, core configuration information and hardware configuration are obtained.

[0064] In step S1.2, load the network file: load three binary files related to the neural network, which contain the specific structure and status information of the neural network: SNN_Core_mapping.bin: records the mapping relationship between each core and the neuron, including the list of neuron IDs that each core is responsible for. These mapping information helps the simulator to assign tasks to different cores at startup, so as to perform parallel computing efficiently.

[0065] SNN_neurons.bin: records the initial state of neurons and the connection relationship between neurons. Specific information includes: neuron ID, that is, the unique identifier of each neuron. Membrane potential and other initial states, that is, the initial membrane potential value of each neuron, may also include other state information of neurons, including: number of firings, thresholds. Synaptic connections, including the successor neuron ID and synaptic weight of each neuron, that is, the connection strength between neurons. These synaptic weights determine the intensity of the pulse signal transmitted between neurons. SNN_activate.bin: records the initial neuron ID that needs to be activated and its corresponding activation value. The activation value usually indicates the impact of the input signal on the neuron, which determines whether the neuron triggers the pulse firing.

[0066] In step S1.3, the configuration file is parsed and key information is extracted from the loaded configuration file, including: the number of neurons, i.e., num_neurons, which indicates the total number of neurons in the neural network. The simulator needs to assign corresponding computing tasks to each neuron based on this value. The number of synapses, i.e., num_synapses: indicates the total number of synapses in the neural network. The simulator will use this information to build connections between neurons. The number of input layer neurons, i.e., num_input_neurons, and the number of output layer neurons, i.e., num_output_neurons: these values ​​determine the hierarchical structure of the neural network. The neurons in the input layer and the output layer will receive external input and generate output signals respectively during the simulation process. Neuron connection matrix: parses the connection information between neurons, i.e., synaptic weights and connection structures, and sets appropriate paths for communication between neurons.

[0067] In step S1.4, a global routing table is generated; a global routing table is generated based on the parsed neuron ID and synaptic connection information. The purpose of this routing table is to record how each neuron communicates with other neurons through a crossbar. The specific implementation is as follows: Construct a mapping between neuron ID and routing path: the pulse signal of each neuron needs to be passed to the target neuron according to the routing table. The routing table defines for each neuron how to pass the signal to other target nodes across cores and neurons. Crossbar configuration: The generated global routing table will route the signal to the target neuron based on the connection status of each neuron. This table not only considers the direct connection between neurons, but also ensures that the signal can be correctly routed through the on-chip network when communicating across cores. Dynamic optimization of the routing table: Depending on the network scale and the density of neuron connections, the routing table may need to be optimized to make cross-core signal transmission more efficient and avoid communication bottlenecks.

[0068] Specifically, in step S2, the simulator will initialize all necessary modules according to the configuration information loaded and parsed in step S1. Specifically, it includes chip module, core module and neuron assembly module. Each module is configured according to the configuration file and the parsed information, and is ready for subsequent simulation. The following is the detailed implementation process:

[0069] In step S2.1, the chip module is initialized; the chip module is the top module of the simulator, responsible for overall resource management and simulation scheduling. The initialization process includes: loading and initializing configuration: obtaining configuration information about the chip module, global memory, on-chip network, etc. from the configuration file.

[0070] Create global memory and network objects: Instantiate the global_memory and network modules according to the configuration. global_memory manages the global memory of the simulator, and network manages data transfer between different cores. Create core instances: By looping each core information in snn_info.cores, multiple Core modules, namely core modules, are instantiated, and local memory, crossbar modules, neuron sets, etc. are configured for each core. Specifically, the Core module uses the SNNInfoPerCore configuration information and allocates neuron tasks across cores through callback functions. When each core is instantiated, it is also bound to the on-chip network for cross-core communication. Start stability monitoring: Create and start the stabilityCheckProcess thread to regularly monitor whether the entire network has reached a stable state.

[0071] In step S2.2, the core module is initialized; the core module is the unit that manages computing and storage in each chip, and is responsible for processing local memory, crossbar module, computing unit, network communication and other resources. Each core is initialized through the Core class, and the following operations are performed during initialization: Create a core instance: When each Core module is instantiated, local memory, i.e., local_memory, crossbar module, and neuron set, will be created according to the core configuration information in the configuration file.

[0072] Initialize the local memory module: Each core has local memory, which is responsible for efficient data storage and access. Simulate memory latency according to the write_latency_cycle and read_latency_cycle in the configuration file.

[0073] Initialize the Crossbar module: A Crossbar module is created when each core is instantiated. Crossbar is responsible for the transmission and processing of pulse signals between neurons and supports parallel computing. Here, the Crossbar module will be configured to support the scheduling of input pulse queues and output pulse queues to ensure efficient connections between neurons.

[0074] Initialize network stability monitor: Inside each core module, create a stability monitor to check whether the core has reached a stable state and determine whether the network can stop simulation.

[0075] Step S2: Initialize all key modules on the simulator, including chip modules, core modules, crossbar modules on the core, and all neuron assembly modules. In step S2, the simulator will initialize all key modules according to the content specified in the configuration file. Specifically, the initialization process includes chip modules, core modules, crossbar modules in the core, and neuron assembly modules.

[0076] The following is the specific execution process: In step S2.1, the chip module is initialized. The chip module is the top-level module of the simulator, which is responsible for the overall management of all cores, global memory, on-chip network communication, i.e., NoC and other resources, to ensure that all sub-modules work in coordination. Its initialization process includes: Loading and initializing chip configuration: Loading detailed information about the chip structure from the configuration file; the detailed information includes: core_cnt, i.e., the number of cores, global_memory_config, on-chip network configuration. Instantiating global memory and network: Creating global_memory, i.e., global memory module and network, i.e., on-chip network module, and connecting them to the chip module. These modules are responsible for handling data transmission between global memory and cores. Core module initialization: Instantiating each core module according to the parsed configuration information of each core. Each core contains resources such as crossbar module, local_memory module, neuron set, etc. In specific implementation, the Core object initializes itself according to the information extracted from the configuration file, including neuron ID and connection information.

[0077] In step S2.2, the core module, i.e., Core, is initialized. The core module is the unit for managing computing and storage in each chip, and is responsible for processing resources such as local memory, crossbar module, computing unit, and network communication. Each core is initialized through the Core class, and the following operations are performed during initialization: Create a core instance: When each Core module is instantiated, local memory (local_memory), crossbar module, neuron set, etc. are created according to the core configuration information in the configuration file. Initialize the local memory module: Each core has local memory, which is responsible for efficient data storage and access. Simulate memory latency according to write_latency_cycle and read_latency_cycle in the configuration file. Initialize the Crossbar module: A Crossbar module is created when each core is instantiated. Crossbar is responsible for the transmission and processing of pulse signals between neurons, and supports parallel computing. Here, the Crossbar module will be configured to support the scheduling of input pulse queues and output pulse queues to ensure efficient connections between neurons. Initialize the network stability monitor: Inside each core module, a stability monitor is created to check whether the core has reached a stable state and determine whether the network can stop emulation.

[0078] In step S2.3, the Crossbar module is initialized; the Crossbar module is located inside the core and is responsible for processing the pulse transmission between neurons. Its initialization process includes: Crossbar configuration: The Crossbar module uses SNNRouter and SNNFSM, that is, the state machine to manage the transmission of pulse signals. SNNRouter is responsible for transmitting the signal between neurons to the correct target neuron, and SNNFSM is responsible for controlling the processing of pulse signals during the simulation process.

[0079] Create and bind input / output queues: The Crossbar module in each core binds the input and output pulse queues to ensure efficient reception and issuance of pulse signals. Crossbar polls the input queue and puts the calculation results into the output queue.

[0080] In step S2.4, the neuron set module is initialized; the neuron set module (i.e., LIFNeuronSet) is responsible for managing and simulating multiple neurons as a computing unit. During the initialization process: Create LIFNeuronSet: Each neuron set module consists of multiple neurons. When the module is initialized, the state of each neuron will be initialized according to the given neuron ID list. Initialize the state of the neuron: The membrane potential, firing times, threshold and other information of the neuron will be initialized according to the default values ​​in the configuration file. Start the pulse receiving thread: Each neuron set will start a thread, continuously listen to the input pulses and calculate based on the membrane potential to decide whether to trigger the pulse firing.

[0081] Specifically, in step S3, the simulation starts to perform the actual operation of the network. In this stage, each core module coordinates execution through its internal Crossbar module, and uses the global routing table to transmit pulse signals, and the neuron set is responsible for performing specific operations. The specific operation process includes: in step S3.1, the operation of the neuron set module is started; the neuron set module, such as LIFNeuronSet, is responsible for receiving and processing pulse signals, calculating the membrane potential of neurons, and triggering pulse emission. Whenever a pulse signal is received, the neuron module will perform calculations according to the following steps: receiving pulse signals: through the spike_receive method, the neuron set module continuously monitors the pulse signal in the input queue, that is, input_spike. When the pulse signal is received, it calculates the membrane potential change of the neuron. Specifically, membrane potential update: the membrane potential of each neuron is updated, and the received pulse value is accumulated. If the membrane potential exceeds the threshold, the pulse emission is triggered. Pulse emission: when the neuron membrane potential exceeds its threshold, the pulse emission is triggered by the fire_spike method, the neuron emission count is updated and the membrane potential is cleared. Pulse routing: Through the fire_spike method, the pulses emitted by the neuron will crossbar and be routed to the target neuron according to the global routing table, i.e. global_routing_table.

[0082] In step S3.2, the operation of the Crossbar module is started; inside each core, the Crossbar module is responsible for managing the transmission of pulse signals between neurons. The Crossbar module forwards pulse signals based on the global routing table. It will decide whether to send the pulse signal to the core where the target neuron is located, or to send it to other cores through the on-chip network based on the local routing information and the target neuron of the pulse signal.

[0083] Receive pulse signals: Through the processSpike method, the Crossbar module continuously polls the pulse queue. If the queue is empty, it waits until a new pulse signal arrives. Routing pulse signals: Based on the ID of the target neuron of the pulse and the global routing table, Crossbar determines whether the pulse signal belongs to the current core. If it belongs to the current core, the pulse is passed to the target neuron through local processing; otherwise, it sends the pulse signal to the target core through the on-chip network. Calculate delay and energy consumption: During the routing process, the Crossbar module simulates the delay and power consumption of reading the routing table. Through the configured MemoryConfig, the time required to read the routing table is simulated and the corresponding energy consumption is increased.

[0084] In step S3.3, the communication and coordination between cores; each core module communicates and coordinates through the on-chip network. The Crossbar module in each core is responsible for transmitting the pulse signal to other cores according to the global routing table. The specific process is as follows:

[0085] Cross-core communication: During the computation of the neuron assembly module, if the target neuron of a pulse is located in another core, the Crossbar module will forward the pulse signal to the target core through the NoC. Collaborative computing: Multiple cores can perform neuron computations in parallel, and by sharing data and routing tables, each core can access the required computing resources. Communication delays, energy consumption, and computational latency between cores are simulated and included in the simulation.

[0086] Specifically, in step S4, the simulation system performs stability monitoring and determines whether the simulation is completed. The core of this step is to monitor the pulse counter of each core and check whether the neural network has reached a stable state. The specific implementation steps are as follows: In step S4.1, the pulse counter is updated when the neuron pulses; whenever the neuron pulses, SNRouter::spikeHandler will be triggered to record the pulse of the current neuron and increase the pulse counter in the core, namely spike_neuron_sum. If this is the first pulse of the neuron, it will trigger the start signal of the simulation and notify the system to start monitoring.

[0087] In step S4.2, the stability is monitored and the simulation is judged to be finished; specifically, in the core module, the stabilityCheckProcess thread periodically checks the changes of the spike counter to judge whether the network is stable. The stability standard is: if the spike_neuron_sum, that is, the sum of the spike counters, does not change over a period of time, it means that the neuron activity of all cores has stabilized. The system will judge whether the simulation is finished based on this information.

[0088] Monitor pulse counter changes: Check whether there is a change by comparing the current pulse counter value with the value of the previous cycle. If they are the same, continue to wait; if they are the same twice, it means that the simulation network has stabilized. Calculate simulation end delay: If stable, calculate the delay of the current simulation run and record the simulation end timestamp. It also outputs the current energy consumption and delay information.

[0089] In step S4.3, determine whether the network is stable; the core of stability monitoring is to compare whether the total spike counters of two consecutive times are equal. If there is no change within two cycles, the system will consider the network to be stable, and the simulation end flag end is set to true. When stable, calculate the total delay and energy consumption of the network, and output and record the simulation results. When the pulse counter changes, the system will restart monitoring to ensure that no pulse activity is missed. Specifically, in step S5, the simulation system generates the network's operating results and performance statistics files by summarizing the operating results of each core module and combining the energy consumption statistics of each module. The purpose of this step is to collect all key data in the simulation process, generate a final simulation report, and output the results to a specified file for analysis and evaluation.

[0090] In step S5.1, the network operation results are summarized: During the simulation process, the pulse emission of each neuron will be recorded. After the simulation is completed, the chip module will traverse all cores and collect the output information of each neuron set, namely LIFNeuronSet. Whenever a neuron emits a pulse, an output information, namely NetIOSerial, will be generated according to its ID and membrane potential or threshold. All output data will be collected and finally written into a binary file.

[0091] Output data structure: Each output data contains a neuron ID and a corresponding value, i.e., membrane potential or threshold. These data are saved in the NetIOSerial array in sequence. Output file: The output results of all neurons will eventually be written to the file / tmp / npsim / data.bin, and the size of the output data and the specific output content will be saved in the file.

[0092] In step S5.2, the performance statistics are summarized. During the simulation process, the energy consumption of each module, that is, the dynamic power consumption and the static power consumption, will be recorded in real time. Through the Simulator::getSimulationReport function, the simulation system will generate a detailed report containing basic information during the simulation, simulation time, the number of pulse neurons for each core, simulation mode, etc. This report helps developers evaluate the operating efficiency and energy consumption of the simulation system.

[0093] The report content includes: basic information such as the number of cores in the configuration file path, the number of spike neurons, the simulation mode, simulation time and energy consumption statistics, and a summary of the network operation results; the summary of the network operation results is to call the getSimulationReport function to summarize the operation data of each core. Generate a report: After the simulation is completed, the system will generate the final simulation report based on the information in sim_config and chip_config, combined with spike_neuron_sum, that is, the total number of spike neurons, and write it into a file and return it to the user.

[0094] In other words, according to a crossbar-based neuromorphic hardware simulation system provided by the present invention, the execution steps between its modules include: the chip management module performs parsing configuration, core module instantiation and global memory binding to obtain the core initialization state; the core initialization state is handed over to the core module; after the core module receives the core initialization state, it initializes the core and parses to obtain the crossbar initialization state; the crossbar initialization state is handed over to the crossbar module; the Crossbar module allocates the corresponding computing tasks, performs pulse signal parsing, obtains the neuron state, the global routing table and the pulse signal; the neuron state is handed over to the neuron management module; finally, the neuron management module is initialized according to the neuron state, performs parallel computing, and obtains the output result, thereby realizing the precise simulation and performance optimization of large-scale neuromorphic chips.

[0095] Specific mechanism description; Chip management module mechanism: Specifically, the initialization and resource scheduling mechanism of the chip management module includes: Multi-core instantiation: Parse the configuration file and generate the initialization configuration for each core. Global routing table binding: Set the on-chip network routing table and bind the global memory to the core network node. Performance monitoring thread: Real-time monitoring of the neural network stability through stabilityCheckProcess.

[0096] Specifically, the stability monitoring mechanism of the chip management module includes: state variable monitoring: setting the chip_stability variable to mark the stability state of each core. Monitoring cycle and completion judgment: checking chip_stability at fixed intervals to determine whether all core networks are stable. Simulation completion record: recording the stability moment and calling the performance statistics module to output the results.

[0097] Specifically, the performance statistics mechanism of the chip management module includes: Energy consumption statistics: accumulating module energy consumption data through the getEnergyCounter method of the core, on-chip network and global memory. Delay analysis: simulating hardware delay based on the wait function of SystemC and calculating the total delay of task operation. Result summary: outputting energy consumption and delay information as a simulation report.

[0098] Mechanism of the core module: Specifically, the instruction pipeline management mechanism of the core module includes: Instruction acquisition: The instruction fetch module reads the core task instructions and passes them to the instruction decoder module. Instruction decoding: The instruction decoder module parses the instructions and distributes them to the execution units, including scalar, matrix and pulse neuron computing units. Control coordination: The control module ensures smooth operation of instructions and avoids data conflicts through the if_stall and id_stall signals.

[0099] Specifically, the local memory management mechanism of the core module includes: Data read and write binding: Bind local memory to each execution unit through the memory_socket interface. Efficient data access: Simulate the memory read and write process of actual hardware to improve data storage efficiency. Energy consumption tracking: Call the getEnergyCounter function to record memory energy consumption in real time.

[0100] Specifically, the network node monitoring mechanism of the core module specifically includes: Neuron activity monitoring: Use the spike_num variable to record the activation status of neurons in each core. Stability check: Use the stability_check thread to regularly check whether spike_num changes to determine the core network status. State synchronization: If the network is stable, the core notifies the chip module through the global variable chip_stability.

[0101] Mechanism of the Crossbar module: Specifically, the pulse management mechanism of the crossbar module includes: Input queue processing: Poll the pulse signal from the input_spike_queue through the SystemC thread and distribute it to the synaptic matrix. Output queue processing: Route the pulse signal according to the global_routing_table and write it to the output_spike_queue. Thread optimization: When the queue is empty, save resources through the SystemC wait mechanism.

[0102] Specifically, the neuron and synapse management mechanism of the crossbar module includes: Synaptic weight storage: Synaptic weights are stored in a two-dimensional matrix to dynamically manage connections between neurons. Membrane potential calculation: Update neuron membrane potential based on input pulses to decide whether to emit pulses. Synaptic connection update: Dynamically adjust synaptic weights to support the flexibility of network structure.

[0103] Mechanism of neuron module: Specifically, the state maintenance mechanism of neuron module includes: State storage: The neuron membrane potential and firing times are stored in a hash table. Thread safety: The mutex std::mutex is used to protect state updates and avoid concurrent conflicts. Data consistency: Ensure state consistency in a high-concurrency environment.

[0104] Specifically, the pulse receiving and processing mechanism of the neuron module includes: Pulse accumulation: receiving external input pulses and accumulating them to the membrane potential. Pulse emission: if the membrane potential exceeds the threshold, the fire_spike function is triggered to generate a new output pulse. Energy consumption recording: after each pulse processing, the energy consumption is recorded for accurate simulation.

[0105] Specifically, the routing maintenance mechanism of the neuron module includes: routing table design: managing the connection relationship of neurons in the sub-network through local_routing_table. Pulse transmission: transmitting the pulse to the target neuron through the routing table. Connection optimization: dynamically updating the routing table to improve transmission efficiency.

[0106] According to a crossbar-based neuromorphic hardware simulation method provided by the present invention, the process of its software system includes: Step S1: system initialization; parsing the network configuration file, instantiating the core module and the global memory. Step S2: Instruction pipeline startup; the core module performs the pulse signal parsing task. Step S3: crossbar parallel calculation; processing the input pulse queue to complete the synaptic weight update. Step S4: Neuron state update; update the membrane potential to determine whether to trigger a pulse. Step S5: Output simulation results; summarize performance data, generate a simulation report, and realize the neuromorphic hardware simulation task.

[0107] In the step S1: step S1.1: parse the network configuration file and extract the core parameters of the neural network; step S1.2: instantiate the core module and allocate memory resources; step S1.3: initialize the on-chip network and the global routing table.

[0108] In the step S2: step S2.1: start the instruction fetch module, read and parse the simulation instruction; step S2.2: distribute the decoded task to the execution unit; step S2.3: coordinate the control module to avoid resource conflict.

[0109] In step S3: step S3.1: read the signal from the input pulse queue and map it to the synaptic matrix; step S3.2: update the synaptic weight according to the target neuron; step S3.3: write the result to the output pulse queue.

[0110] In the step S4: step S4.1: accumulate the membrane potential and determine whether it exceeds the threshold; step S4.2: trigger pulse emission and reset the membrane potential; step S4.3: update energy consumption statistics and generate the next cycle pulse.

[0111] In step S5: step S5.1: call the performance statistics module to record the core energy consumption and delay data; step S5.2: output the neural network simulation report, including the statistical results of delay and energy consumption

[0112] The multi-core chip simulator based on the crossbar pulse neural network, the core module, includes: instruction pipeline management: instruction pipeline management covers the acquisition, decoding, execution and control of instructions. Through four sub-modules: instruction fetch, de-instruction, execution and control modules, they work together to achieve smooth operation of the pipeline. Each sub-module is responsible for a specific stage of the instruction pipeline, and uses the sc_signal of systemc to synchronize through the port binding mechanism to achieve the transmission of data and control signals. After completing the instruction reading, the instruction fetch module directly passes the output to the de-instruction module, and the de-instruction module distributes the decoded signal to the corresponding execution unit. After the execution unit completes the calculation, it returns the result to the register file or other modules. To ensure the smooth operation of the pipeline, the control module coordinates the start and stop signals of each sub-module to prevent data conflicts and resource competition.

[0113] For example, when the instruction fetch module is still processing the previous instruction, the control module can temporarily prevent the decompression module from starting, thereby avoiding pipeline stall.

[0114] Local memory management module: responsible for handling data storage and access within the core. By binding local memory to the memory interface of each execution unit, data within the core can be read and written more quickly. This module simulates the common design of pulse neural network chips.

[0115] Network node monitoring module: monitors the sub-network nodes on the core, i.e., spiking neurons, and counts whether all spiking neurons have reached a stable state. The core class maintains an unsigned integer called spike_num, which increments every time a neuron is activated. A systemc thread named stability_check is used to periodically check whether spike_num has changed compared to the previous cycle at a time interval of t_core. If it has not changed, it means that the sub-network on the core has remained stable during this period. The core transmits information about the network stability to the chip module by writing global variables to synchronize the network status.

[0116] Crossbar management module: The core needs to provide management for the resources required for crossbar calculations. The core needs to pass the input pulse information obtained by the on-chip network to the input pulse queue of the crossbar, and process the output pulse queue of the crossbar: if the target neuron of the output pulse is in the current core, it will be processed and put into the input pulse queue of the crossbar. Otherwise, it will be packaged and sent to the target core through the on-chip network.

[0117] The multi-core chip simulator based on the crossbar spiking neural network, the crossbar module comprises:

[0118] Pulse management module: Maintains the input pulse queue entering the crossbar, as well as the output pulse queue generated by calculations on the crossbar, to ensure the correct transmission of pulse signals within the crossbar. The pulse input queue and pulse output queue interact and synchronize with the core in a producer-consumer mode, and consume in a first-in-first-out mode. Among them, the input queue is produced by the core where the crossbar is located, and crossbar, as a consumer, polls to obtain pulses from the input queue for consumption. To prevent performance loss caused by the while loop, when the input queue is empty, crossbar uses systemc's wait, that is, sc_event to wait for new input pulses to appear in the queue. The output queue implementation method is basically the same as the input queue. Crossbar acts as a producer to produce output pulses obtained by neuron calculations on the crossbar, and the core acts as a consumer to process the output pulses.

[0119] Neuron and synapse management module: There are several target neurons on each crossbar, connected to the bit line of the crossbar. In order to provide parallel computing while ensuring simulation performance, the neuron management module binds multiple spiking neurons to a LIFNeuronSet to centrally manage neurons. The LIFNeuronSet module implements the management and calculation of pulse integration and firing in spiking neural networks, namely Leaky Integrate-and-Fire, or LIF neurons for short. Its core functions include receiving pulse signals, integrating potentials, triggering pulse firing, and managing the state of neurons. Neurons continuously listen to input pulses through the spike_receive thread. When an input pulse arrives, the system increases the membrane potential of the corresponding neuron. If the membrane potential exceeds the threshold, the fire_spike function is triggered to fire the pulse. After the pulse is fired, the membrane potential of the neuron is reset to zero, and the number of pulse firings is counted. LIFNeuronSet also includes a local routing table for routing pulses to target neurons based on neuron IDs. Through the pushSpike function, LIFNeuronSet can add pulses to the input queue and trigger processing. The getSpike function takes pulses out of the queue for processing. The synaptic weights are stored in a two-dimensional matrix and are designed as a static variable. LIFNeuronSet can freely access the weights.

[0120] A multi-core chip simulator of a pulse neural network based on crossbar, the neuron module includes: Neuron state maintenance module: The LIFNeuronSet module is responsible for maintaining the state information of each neuron, including key data such as the membrane potential and the number of firings of the neuron. The module stores the information of all neurons through an internal hash table, so that state access and update can be carried out efficiently. To ensure security in a multi-threaded environment, the module introduces a concurrency and synchronization management mechanism. Specifically, the module protects shared resources, such as the input pulse queue, by using a mutex, namely std::mutex, to prevent data conflicts caused by simultaneous access by multiple threads. This design ensures that the update of neuron states can remain consistent and accurate under high concurrency conditions.

[0121] Pulse receiving and calculation processing module: The LIFNeuronSet module receives external pulse signals and performs corresponding calculation processing. When the input pulse arrives, the spike_receive thread is responsible for accumulating the pulse signal to the membrane potential of the corresponding neuron. If the membrane potential exceeds the preset threshold, the module triggers the pulse emission and resets the membrane potential to zero. When emitting pulses, the module will monitor the energy consumption to ensure that the energy consumption of each pulse processing can be tracked in the simulation, supporting accurate simulation of pulse neural networks.

[0122] The crossbar-based neuromorphic hardware simulator provided by the present invention includes:

[0123] Chip management module: simulates multi-core pulse neuron chips, manages chips, monitors the network operation status on the chip, and summarizes the performance data of network operation.

[0124] In other words, this module is responsible for the overall management of the simulated multi-core pulse neuron chip, including the core, global memory, and on-chip network communication, that is, the management and scheduling of NoC. During the simulation initialization phase, each core is instantiated as a core class object according to the configuration file and added to the core list of the chip module. The chip module manages the global memory and network through the global memory class and the network class to ensure smooth data communication between cores, and ensures the reliability of the simulation process by regularly monitoring the network status of the chip.

[0125] Core management module: manages the core and correctly promotes the operation of the instruction pipeline inside the core; monitors the operation of the network on the core in real time, and reports the operation status and operation results to the chip to which it belongs. In other words, the core module is responsible for managing all resources of each core in the chip, including local memory, crossbar and computing unit. The instruction pipeline management module coordinates the instruction acquisition, decoding, execution and control in the core, and ensures the synchronization of data and signal transmission between each submodule through the port binding mechanism of SystemC. This part also includes real-time monitoring of network nodes in the core to ensure that all pulse neurons reach a stable state within the specified time, and report the operation results of the core to the chip module; crossbar management module: manages the input pulse queue and output pulse queue passing through the crossbar; manages the neurons and their synapses connected to the crossbar, and provides support for the parallel computing process of neuron computing and pulse transmission. Manage the axon routing table of the neuron, correctly address the target neuron of the activation signal, and flexibly select different routing strategies to adapt to diverse computing needs.

[0126] In other words, the crossbar module is responsible for managing input and output pulse queues and supporting large-scale parallel computing. Through two independent SystemC threads, the crossbar module processes the input and output pulse queues respectively to achieve efficient parallel computing. This module also includes the management of neurons and synapses connected to the crossbar, supports the correct transmission of pulse signals, and ensures the flexibility and accuracy of pulse transmission through routing tables; neuron management part: abstract and manage pulse neurons, parallelly calculate the membrane potential update of pulse neurons, and process the output pulses they emit. In other words, the neuron module abstracts and manages pulse neurons. The LIFNeuronSet subnetwork combines multiple neurons into a computing unit and uses SystemC modules to implement its parallel computing. The neuron module receives external input pulse signals, updates the membrane potential, and triggers pulse emission when the threshold is reached. This module also manages the connection between neurons through an internal routing table to ensure the efficiency and accuracy of signal transmission.

[0127] Specifically, the chip module includes: a multi-core management module, a stability monitoring module and a performance statistics module;

[0128] The multi-core management module is responsible for managing multiple cores on the chip, including on-chip network communication between cores and scheduling of global memory. At the beginning of the simulation, each core on the chip is instantiated as a core class object according to the configuration information and added to the core list of the chip module. The chip module implements the management of global memory and network through the global memory class and the network class. Among them, the global memory class is responsible for providing unified storage resources for multiple cores in the simulator, and interacting with the on-chip network through the encapsulator and the switch. It supports efficient memory read and write operations and integrates energy consumption statistics. The network class manages network communication in the chip and supports data transmission operations by storing and calculating the delay and energy consumption information between nodes. It implements the registration and search functions of the switch, and dynamically sets the delay and energy consumption between nodes by reading the configuration file to optimize the efficiency and accuracy of data transmission during the simulation process. The core will be bound to the network during initialization to ensure smooth communication between cores. At the same time, the global memory class is also bound to the network during initialization to ensure that each core can access the global memory through the network, realizing communication management between cores.

[0129] The stability monitoring module is responsible for real-time monitoring of the running state of the pulse neural network and determining whether the network has reached a stable state at a certain moment. This function is implemented through a systemc thread named stabilityCheckProcess: the chip object reserves an n-bit global memory chip_stability to mark whether each core has reached a stable state. n is the number of cores on the chip, 0 is stable, and 1 is unstable. The stabilityCheckProcess thread will periodically determine whether the sub-networks on all cores have reached a stable state at a time interval of t; if chip_stability is 0 for m consecutive time periods, the network is considered to have reached stability, and the current simulation completion time finish_time_stamp is recorded, and the simulation results are output. The simulation results include statistical information such as network delay and energy consumption provided by the performance statistics module and file information containing the calculation results of the network.

[0130] The performance statistics module needs to count and summarize the energy consumption and delay generated by running the network after the simulation is completed, so as to evaluate the network performance. Energy consumption statistics: In order to facilitate energy consumption statistics, the core class, on-chip network class, and global memory class have their own energy consumption counters and getEnergyCounter methods. After the network operation reaches stability, the energy consumption data of each core is accumulated into the total energy consumption counter by traversing the core list and calling the core's getEnergyCounter. In addition, it is also necessary to perform energy consumption statistics on the on-chip network and global memory, and accumulate energy consumption by calling network.getEnergyCounter and global memory.getEnergyCounter. Delay analysis: In delay statistics, we directly use the simulation time provided by systemc. According to the configuration items, the wait library function of systemc is called in each operation that will generate delay to simulate the generation of delay in real hardware. After the network reaches stability, you only need to obtain the simulation end time at the end time to get the total delay of the network operation.

[0131] Core instantiation and management: During the simulation initialization process, the chip module parses the configuration file to obtain the configuration information of each core and instantiates them into Core class objects in turn.

[0132] In the specific implementation, the Chip class constructor first parses the spiking neural network, or SNN information, and converts it into the configuration object SNNInfoPerCore for each core. Then, multiple Core instances are created through the constructor in a loop, giving each core an independent computing task. These instances are stored in the core_array list for subsequent simulation process calls and management;

[0133] Global memory management: Global memory is managed uniformly by the global memory object. Global memory is instantiated during the initialization phase of the chip module and is bound to the on-chip network, or NoC, through MemoryWrapper and Switch. In implementation, global memory is responsible for coordinating the access of multiple cores to unified storage resources, and converts memory read and write requests into data packets that can be processed by the on-chip network through the wrapper to ensure the validity and integrity of data transmission. In addition, the global memory class also contains an energy consumption counter, which records the energy consumption information of memory operations in real time by calling the energy consumption statistics method in each memory operation;

[0134] Network communication management: The network object is responsible for communication management between chip cores. By calling the registerSwitch method of the network in the constructor of the Chip class, each core is bound to the switch of the on-chip network to configure the communication path between the cores. During the simulation, the network class calculates the data transmission delay and energy consumption between different cores through the transfer method. This method simulates the delay and accumulates the energy consumption of the transmitted data packets based on the delay and energy consumption parameters in the configuration file. After the simulation is completed, the total energy consumption of network communication during the entire simulation process is summarized through the getEnergyCounter method;

[0135] Core and network binding: When the chip is initialized, each Core instance binds itself to the on-chip network by calling the switchBind method. This binding process is implemented in the constructor of the Chip class. By traversing the core_array, the switch interface of each core is connected to the on-chip network in turn to achieve interconnection between cores. In this way, data can be transmitted between cores through the on-chip network, supporting data sharing and collaborative computing across cores;

[0136] Stability monitoring and simulation end judgment: The stabilityCheckProcess thread is initialized in the Chip class constructor to monitor the stability of the network in real time during the simulation. In the specific implementation, the thread will periodically check the changes in the global variable spike_neuron_sum. If the variable remains unchanged for a certain period of time, it means that the activities of all neurons have reached a stable state. At this time, the thread will record the current simulation time as finish_time_stamp and call the getOutput method to output the simulation results, including the pulse output of the neuron and the delay of the network.

[0137] Preferably, the core module includes: instruction pipeline management: the instruction pipeline management of the core module covers the acquisition of instructions, i.e. inst_fetch, decoding, i.e. inst_decode, execution, i.e. scalar_unit, matrix_unit, vector_unit, snn_unit and control, i.e. controller. In the Core class, these functions are completed by multiple sub-modules in collaboration. Each sub-module transmits data and control signals through the sc_signal and port binding mechanism of SystemC, such as fetch_decode, decode_matrix, decode_vector, etc., to ensure the smooth operation of the pipeline. In the specific implementation, after reading the instruction, the instruction fetch module passes the instruction to the de-instruction module through if_id_port, and the de-instruction module distributes the decoded instruction to the corresponding execution unit through ports such as id_matrix_port and id_vector_port. The control module, i.e., the controller, coordinates the start and stop of the pipeline through signals such as if_stall and id_stall to prevent the pipeline from stalling due to data conflicts or resource competition; local memory management module: the local_memory object is responsible for the local memory management in the core module. In the Core class, the local memory is bound to the memory interface memory_socket of each execution unit to achieve fast data reading and writing. In the specific implementation, local_memory is bound to the memory_socket of each execution unit through target_socket, simulating the data access process in the actual hardware. This binding mechanism enables the data in the core to be stored and read efficiently, further improving the performance of the simulator. The local_memory module also contains energy consumption statistics. Through the getEnergyCounter method, the energy consumption data of the local memory can be obtained at the end of the simulation and added to the total energy consumption of the core; network node monitoring: the core module needs to monitor the activity state of the pulse neurons in the core to determine whether it has reached a stable state. In the Core class, this function is implemented by a SystemC thread named stability_check. Each core maintains an unsigned integer named spike_num. When a neuron is activated, spike_num will increment. The stability_check thread periodically checks whether spike_num has changed compared to the previous cycle at a time interval of t_core. If spike_num remains unchanged for several consecutive cycles, it is considered that the neuron network in the core has reached a stable state. At this time, the core will report this state to the chip module by writing the global variable chip_stability to achieve synchronization of multi-core network states.

[0138] Crossbar management: crossbar is a key component of the pulse neuron chip, responsible for managing pulse transmission and parallel computing between neurons. In the Core class, crossbar management includes processing input pulse queues and output pulse queues. In the specific implementation, the core passes the input pulse information obtained by the on-chip network, that is, NoC, to the input pulse queue input_spike of the crossbar through switch_socket. Crossbar processes these input pulses through a polling mechanism and outputs the calculation results to the output pulse queue output_spike. If the target neuron of the output pulse is in the current core, it is passed to local_memory, otherwise, it is packaged and sent to the target core through the on-chip network, that is, NoC.

[0139] Preferably, the crossbar module includes: input pulse queue processing: the input pulse queue processing thread is responsible for reading the pulse signal from the input_spike_queue and distributing it to the corresponding neurons for processing. Each pulse signal is addressed inside the crossbar according to its target neuron ID and activates the corresponding synaptic connection. In order to simulate the computational delay in real hardware, the thread introduces an appropriate delay when processing each pulse; specifically, the delay is through the wait mechanism of SystemC. In this way, the crossbar module can accurately simulate the timing behavior in the pulse neural network and ensure high efficiency when processing a large number of parallel pulses;

[0140] Output pulse queue processing: The output pulse queue processing thread is responsible for placing the calculated pulse signal into the output_spike_queue and determining the transmission path of these pulses based on the global routing table, i.e., global_routing_table. If the target neuron of the pulse signal is located on the crossbar of the current core, the thread will directly pass it to the input queue of the target neuron; otherwise, the pulse signal will be forwarded to the target core through the on-chip network, i.e., NoC. This design enables the crossbar module to not only achieve efficient inter-neuron communication within a single core, but also support cross-core pulse transmission in multi-core scenarios;

[0141] Neuron and synapse management: The crossbar module manages the neurons and synapses connected to it in detail. Each neuron is mapped to a specific row or column of the crossbar, such as a word line and a bit line, and the weight information of the synapse is stored at the intersection of the crossbar. By managing these synaptic connections, the module ensures that after receiving a pulse signal, it can correctly calculate the membrane potential change of the target neuron and decide whether to trigger a new pulse. In order to support complex network structures, the crossbar module allows flexible configuration of the synaptic weight matrix and ensures the correct transmission of pulse signals in the network by updating the routing table, namely global_routing_table.

[0142] Preferably, the neuron management module includes: Neuron state maintenance: The LIFNeuronSet module is responsible for maintaining the state information of each neuron, including key data such as the neuron's membrane potential and firing times. The module stores information of all neurons through an internal hash table neurons to ensure efficient state access and update. To adapt to multi-threaded environments, the module uses the std::mutex mutual exclusion lock mechanism to protect shared resources, such as the input pulse queue input_spike, to prevent data conflicts when multiple threads access it at the same time. This design ensures that the update of neuron states can remain consistent and accurate under high concurrency conditions;

[0143] Pulse reception and computational processing: The LIFNeuronSet module processes external incoming pulse signals through the spike_receive thread. Whenever a pulse arrives, the spike_receive thread adds the pulse signal to the membrane potential of the corresponding neuron. If the membrane potential exceeds the preset threshold, the module calls a function to trigger the pulse and reset the membrane potential to zero. While processing the pulse, the module records energy consumption information to ensure that the energy consumption of each pulse processing can be accurately tracked in the simulation;

[0144] Maintaining internal routing: The LIFNeuronSet module manages the connection relationship between neurons by maintaining an internal routing table local_routing_table, which is equivalent to establishing an independent sub-network in the core sub-network. When the target neuron of a pulse emitted by a neuron is also in the current module, the module will directly pass the pulse to the target neuron according to the information in local_routing_table. The routing table stores the connection information between neurons, including the ID of the target neuron and the weight of the connection dendrite_weight, which makes it possible to implement complex neural network structures within the set and effectively supports efficient pulse transmission and calculation.

[0145] The parallel computing simulation method on the crossbar based on parallel graph computing provided by the present invention includes:

[0146] LIFNeuronSet sub-network abstraction step: abstract multiple neuron nodes into a LIFNeuronSet sub-network and implement this abstraction through SystemC module.

[0147] Crossbar parallel processing step: Introduce two independent SystemC threads to process the input pulse queue and the output pulse queue respectively, supporting parallel computing on the crossbar architecture.

[0148] Steps for building a parallel graph computing model: abstract neuron nodes into nodes in graph computing, and synaptic connections between neurons into edges in the graph. Based on the existing parallel graph computing partitioning method, multi-level graph partitioning is performed on the large graph.

[0149] Dynamic optimization steps for neuron routing table design: According to the graph structure and configuration items, dynamically build a global routing table that is efficient in search and meets memory requirements to improve simulator performance.

[0150] Preferably, the LIFNeuronSet subnetwork abstraction step includes:

[0151] Modular abstraction of neuron state management: In the design of LIFNeuronSet subnetwork, each neuron is modularly abstracted as an independent computing unit, and its state information, such as membrane potential, firing times, etc., is stored and updated through centralized management. LIFNeuronSet maintains an efficient hash table to store the state information of all neurons, so that during the simulation process, the state reading and writing operations can be completed in constant time.

[0152] Parallel processing mechanism of pulse signals: The neurons in the LIFNeuronSet subnetwork receive, process and emit pulse signals through a parallel processing mechanism. This mechanism creates multiple SystemC threads, allowing each thread to independently process the input pulse signals of a specific neuron. These threads can quickly calculate the changes in membrane potential and decide whether to emit pulses without interfering with other threads.

[0153] Dynamic mapping of internal routing and synaptic connections: In the LIFNeuronSet subnetwork, the synaptic connection relationship between neurons is managed through a dynamic routing table. The routing table determines the transmission path of the pulse signal based on the neuron ID and connection weight, and ensures that the signal can be efficiently transmitted between multiple neurons. If the target neuron is in the same LIFNeuronSet, the pulse signal will be transmitted directly; if the target neuron is in another LIFNeuronSet, the routing table will guide the signal to be transmitted through the crossbar or on-chip network.

[0154] Preferably, the crossbar parallel processing step includes: threaded management of the input pulse queue: the crossbar module uses a dedicated SystemC thread to process the input pulse queue. The thread continuously polls the input queue to ensure that all incoming pulse signals can be captured in time. When a new input pulse is detected, the thread will quickly take the pulse signal out of the input queue and send it to the corresponding LIFNeuronSet module according to the predefined routing rules. This process greatly improves the processing speed of the input pulse through the multi-threading mechanism implemented at the software level, ensuring that each LIFNeuronSet can receive and process the pulse signal in parallel.

[0155] Threaded transmission of output pulse queue: The crossbar module also uses an independent SystemC thread to process output pulses. The output pulse thread also continuously polls the output queue. When LIFNeuronSet completes the pulse calculation, the generated pulse signal will be sent to the output queue. This thread is responsible for taking out these pulse signals and determining the crossbar where its target neuron is located based on the routing table. If the target neuron is in the current core, the pulse will be directly passed to the input queue of the core; if the target neuron is in another core, the pulse signal will be directly routed to the target core through the on-chip network.

[0156] Preferably, the parallel graph computing model construction step includes: graph structure mapping of neurons and synapses: abstracting neurons and synapses in the pulse neural network into nodes and edges in the graph. Each neuron is represented as a node in the graph, and the synaptic connections between neurons correspond to directed edges in the graph, thereby constructing a graph computing model.

[0157] Multi-level graph partitioning and optimization: Perform multi-level graph partitioning on the entire neural network. Use a configured multi-level graph algorithm, such as Metis's multi-level partitioning technology, to compress the graph into a smaller version for preliminary partitioning, and then gradually decompress and optimize the partitioning results. Each subgraph corresponds to a LIFNeuronSet, in which the nodes, i.e., neurons, are closely connected, and the border connections across subgraphs are minimized. This partitioning strategy aims to reduce the communication overhead between different LIFNeuronSets, improve the parallelism of calculations within each subnetwork, and enable the system to efficiently utilize hardware resources for parallel processing.

[0158] Dynamic adjustment based on system resources: After completing the initial graph partitioning, the system will dynamically adjust the graph computing model based on the hardware resources of the target machine, such as memory capacity and parallel computing capabilities. This process involves optimizing the number of neurons contained in LIFNeuronSet so that the computing load of each LIFNeuronSet is balanced while maximizing the use of the system's parallel processing capabilities. The strategy module dynamically adjusts the partitioning results of LIFNeuronSet by analyzing the graph structure data to adapt to different hardware configurations and neural network sizes. This dynamic adjustment mechanism ensures that the graph computing model can run efficiently and provide optimal computing performance in different computing environments.

[0159] Preferably, the dynamic optimization step of the neuron routing table includes: L1 routing table entry size determination: according to the configured memory requirements and the average density of the neural network, the size of each row of the L1 routing table is determined, that is, the number of synapses stored, balancing time performance and memory requirements.

[0160] L1 routing table management: In the global routing table, each neuron ID corresponds to the serial number of the routing table. The L1 routing table is organized in the form of an array. The number of synaptic entries contained in each routing table row is fixed, and the user can configure the number according to needs. The L1 routing table provides an efficient routing lookup mechanism for most neurons with fewer connections.

[0161] L2 routing table management: For neurons with a large number of connections, if the L1 routing table cannot fully accommodate all of its synapses, a pointer to the L2 routing table will be stored in the L1 routing table. The L2 routing table exists in the form of a linked list, and all synaptic information of the neuron can be obtained through the linked list. The design of the L2 routing table ensures that the system can still efficiently perform routing lookup and signal transmission even when there are many connections.

[0162] A parallel computing simulation method on a crossbar based on parallel graph computing provided by the present invention includes:

[0163] Abstract multiple neuron nodes into a LIFNeuronSet subnetwork and implement it as a systemc module. Multiple LIFNeuronSets can perform calculations in parallel and update neuron states.

[0164] Crossbar uses two systemc threads to process the input pulse queue and output pulse queue respectively to better support parallel computing. The input pulse queue processing thread loops to take out the input pulses and sends them to the corresponding LIFNeuronSet input queue, which performs specific calculations. The output pulse queue processing thread loops to take out the output pulses and routes them to the crossbar where the target neuron is located, that is, the core where it is located, and is forwarded to the corresponding core by the on-chip router.

[0165] Neuron nodes can be abstracted into graph nodes, and the division of LIFNeuronSet can correspond to the division of processing units in parallel graph computing. Users dynamically configure the number of neurons contained in LIFNeuronSet based on the size of the network and the support for parallelism and memory size of the target machine where the simulator is located. The strategy module analyzes the graph structure data to obtain the final division result of LIFNeuronSet.

[0166] A method for routing neuron pulses, including: abstracting multiple neuron nodes into a LIFNeuronSet subnetwork, LIFNeuronSet maintaining a routing table within the subnetwork, recording the synapses of the source neuron and the target neuron in the current LIFNeuronSet. Maintaining a global routing table on the chip, all target neurons with the neuron as the source neuron can be addressed through the neuron id number. The routing item will record the core where the target neuron is located, LIFNeuronSet and the target neuron id. The global routing table is divided into an L1 routing table and an L2 routing table. The L1 routing table is organized in an array form, each neuron id number corresponds to the serial number of the routing table one by one, and the number of synaptic entries contained in each routing table row is fixed and configured by the user. The L2 routing table exists in the form of a linked list. If the L1 routing table cannot completely accommodate all the dendrites corresponding to the neuron id, the row will store a pointer to an L2 routing table, and all axons of the neuron can be obtained through the linked list.

[0167] Methods for optimizing simulator performance include: Adaptive time step mechanism: SystemC simulation is usually based on discrete event driven models, in which the choice of time step directly affects the simulation efficiency. During the simulation process, a time step that is too small will lead to frequent event scheduling, increase scheduling overhead, and thus reduce the simulation speed. To this end, an adaptive time step mechanism is introduced to dynamically adjust the time step according to the frequency and density of events during the simulation process to improve efficiency while ensuring simulation accuracy. By monitoring the density of events, the system can increase the time step when events are sparse and reduce the number of scheduling times; and shorten the time step when events are dense to ensure simulation accuracy.

[0168] Neuron partitioning based on parallel graph computing: abstract the neurons in the neural network into nodes of the graph, and abstract the synaptic connections between neurons into edges in the graph.

[0169] Application of parallel graph computing algorithm: Use the Metis algorithm to perform multi-level partitioning on the constructed graph, compress the graph into smaller versions for preliminary partitioning, and then gradually decompress and optimize the partitioning results. Divide the neuron nodes into multiple LIFNeuronSets, so that the neurons in each LIFNeuronSet are more closely connected, and the border connections across LIFNeuronSets are reduced as much as possible.

[0170] Embodiment 1, the present invention provides a crossbar structure-based neuromorphic hardware simulator, including: a chip architecture management part: software simulation of the core part of the crossbar structure neuromorphic chip, on-chip network routing, i.e., NoC routing, and key hardware components such as memory. Each hardware component is designed as an independent SystemC module, i.e., systemc module, and its working process is simulated through multiple SystemC threads, i.e., sc_thread.

[0171] Parallel computing simulation part: simulates the parallel computing process between the crossbar structure and the spiking neurons connected to it, accurately reproduces the data transmission and computing process in the neuromorphic chip, and ensures the high accuracy of the simulation results.

[0172] Design method of neuron pulse routing: The LIFNeuronSet subnetwork maintains an internal routing table to record the synaptic connections between source and target neurons. The chip global routing table addresses the target neuron through the neuron ID. The L1 routing table stores fixed entries, and the L2 routing table is extended in the form of a linked list to ensure connection integrity.

[0173] Simulator performance optimization method: Adaptive time step mechanism dynamically adjusts the time step to improve simulation efficiency, increases the step size when events are sparse, and shortens the step size to ensure accuracy when events are dense. Neuron partitioning based on Metis algorithm optimizes LIFNeuronSet internal connections and reduces cross-boundary communication.

[0174] The chip architecture management part includes: modular design of the core part: each hardware component, such as crossbar, neuron node, synaptic connection, etc., is independently implemented as a SystemC module, i.e., systemc module, to ensure the independence and scalability of the module. Each core module can be simulated independently and can be integrated into a more complex system architecture.

[0175] Multithreaded parallel simulation: Use multiple SystemC threads in SystemC, namely sc_thread, to simulate the working process of hardware components, such as parallel computing of crossbar, pulse emission of neuron nodes, and communication of on-chip network, etc. Through the thread synchronization mechanism, the orderliness of data transmission and signal transmission between modules is ensured, simulating the parallel computing behavior in real hardware.

[0176] On-chip network routing, namely NoC routing and global memory management: The NoC module is responsible for data transmission between different cores, simulating the pulse transmission process across cores. The global memory provides memory access rights for each core through a unified storage interface, supporting efficient data read and write operations. The binding of NoC and global memory supports the simulation of system memory access latency, and provides a dynamic routing mechanism for the selection of transmission paths to adapt to different network loads.

[0177] Simulation monitoring and data aggregation: By integrating a performance monitoring unit into the SystemC module, the system can record the computational latency and energy consumption data of each module in real time, ensuring that a detailed performance evaluation report can be provided at the end of the simulation, including neuron activity status, crossbar latency, and NoC energy consumption statistics.

[0178] The parallel computing simulation part includes: parallel processing of the crossbar structure: the crossbar structure is designed as a core component to support large-scale parallel computing. In the simulation, the crossbar processes the input pulse signal through the SystemC thread and transmits it to the target neuron through the crossbar node. The input pulse queue is responsible for processing the input signal from the on-chip network or internal, and the output queue transmits the calculation result to the target neuron or other crossbar nodes.

[0179] Parallel computing of spiking neurons: Each crossbar node is connected to a different spiking neuron. Using the parallel computing mechanism, multiple neurons can process pulses simultaneously. By abstracting the computing process into a parallel graph computing model, multiple LIFNeuronSet modules can update membrane potential and trigger pulses simultaneously, ensuring that the system can efficiently simulate the large-scale parallel computing behavior of neuromorphic chips.

[0180] Synchronous processing of data transmission and pulse emission: Through multi-threaded management of input pulses and output pulse queues, the simulation can accurately simulate the transmission delay and routing selection of pulse signals. Each thread is responsible for a specific pulse queue, ensuring parallel processing across multiple neuron nodes. At the same time, the operation of pulse emission and synaptic weight update is also accurately controlled by the scheduling mechanism of SystemC, simulating the characteristics of parallel computing and communication in real hardware.

[0181] Optimization of parallel computing: The crossbar module reduces bottlenecks in computing and data transmission through efficient routing algorithms and storage structures of synaptic weight matrices. In large-scale simulations, crossbar can dynamically adjust the order of pulse processing to optimize overall computing performance.

[0182] The design method of neuron pulse emission routing includes: LIFNeuronSet internal routing table: Each LIFNeuronSet subnetwork is responsible for maintaining the connection information of internal neurons, including the synaptic weights of source neurons and target neurons. The routing table uses the neuron ID as an index to record all connections in the current subnetwork. In this way, the propagation of pulses within LIFNeuronSet does not need to cross other subnetworks, ensuring the efficiency of local computing.

[0183] Design of global routing table: At the chip level, the system maintains a global routing table to handle cross-core neuron connections. Through the neuron ID, the routing table can accurately locate the core and LIFNeuronSet where the target neuron is located. The global routing table is designed as a two-level structure: the L1 routing table stores a fixed number of synaptic connections in the form of an array, and the L2 routing table is used as an extended linked list to store neuron connection information that exceeds the L1 capacity limit.

[0184] Expansion mechanism of the routing table: For neurons with a large number of connections, if the L1 routing table cannot fully accommodate all connections, the system will automatically store its connection information in the L2 routing table. The L2 routing table exists in the form of a linked list, which supports fast retrieval and dynamic expansion, ensuring the connection integrity and communication efficiency under the complex neural network structure. Positioning of pulse emission and target neurons: When a neuron triggers pulse emission, the routing table will find the connection information of the target neuron according to the neuron ID, and route the pulse signal to the core or LIFNeuronSet where the target neuron is located. Through hierarchical routing design, the system can maintain an efficient pulse transmission mechanism in large-scale neural networks. The method for optimizing the performance of the simulator: Improve the simulation efficiency and accuracy through an adaptive time step mechanism and a neuron partitioning strategy based on the Metis algorithm.

[0185] Adaptive time step mechanism: SystemC simulation usually uses discrete event driven models, and the scheduling time step between different events will affect the simulation efficiency. To improve efficiency, the system introduces an adaptive time step mechanism to dynamically adjust the size of the time step. When the events in the simulation are sparse, the system automatically increases the time step to reduce unnecessary scheduling operations; when the events are dense, the system shortens the time step to ensure the accuracy of event scheduling. This adaptive mechanism ensures that the simulation can still maintain high efficiency and accuracy under high load.

[0186] Neuron partitioning based on Metis algorithm: In order to optimize parallel computing in simulation, the system uses Metis algorithm to perform multi-level partitioning of neuron nodes in the neural network. First, the Metis algorithm abstracts neurons and synaptic connections into a graph structure, and compresses the neural network into smaller sub-networks through multi-level graph partitioning technology. Then, the system decompresses and optimizes these sub-networks, and finally divides them into multiple LIFNeuronSets, making the connection within each sub-network closer and reducing the communication requirements across sub-networks.

[0187] Optimization of communication load: By reducing cross-LIFNeuronSet boundary communication, the simulation can significantly reduce the latency and energy consumption of cross-core data transmission. In large-scale networks, the partitioning strategy between LIFNeuronSets directly affects the computational efficiency and communication load. Based on the partitioning results of the Metis algorithm, the system can flexibly adjust the distribution of neuron nodes to maximize parallel computing performance.

[0188] Improved scheduling and computing efficiency: By dividing the computational process of neurons into multiple parallel tasks, combined with adaptive step size and optimized graph partitioning strategy, the simulator can significantly improve computing efficiency while ensuring accuracy.

[0189] Embodiment 2 is a preferred example of embodiment 1. Figure 1 , which is the overall framework of the crossbar-based neuromorphic hardware simulator proposed in the proposal of the present invention. The upper part mainly shows the design of the chip module, including the layout of multiple cores and their connection with the global memory. The cores communicate with each other through the on-chip network, namely NoC. The global memory provides unified storage resources for each core through the Memory Wrapper. The network monitoring module is used to monitor the operating status of the entire chip in real time to ensure the reliability and efficiency of data transmission. The middle part shows the internal structure and workflow of the core module. The core module realizes the acquisition, decoding, execution and control of instructions through multiple functional units. The instruction fetch module is responsible for reading instructions from the instruction cache, the instruction decoder module performs instruction decoding processing, and the execution module performs calculation processing through crossbar. The local memory provides data storage support for the core, the control module coordinates the working order of each functional unit, and the interactive machine is responsible for the data interaction between the core and external components such as other cores and global memory. The lower part shows the design of the pulse neuron module. The signals in the input pulse queue are distributed to different neuron nodes through hashing, and the neurons decide whether to issue pulses based on the membrane potential update and calculation rules. After the pulse is issued, it is stored in the output pulse queue and transmitted to the target neuron through the routing mechanism. The design supports parallel computing and signal transmission of complex neural networks by managing neurons and pulses.

[0190] The design process of neuron pulse routing is described as follows. Figure 2 As shown in the figure, the routing mechanism is mainly composed of L1 axon table, i.e. L1 Axon Table, L2 axon table, i.e. L2 Axon Table and L3 axon table in DRAM. In a neural network, when a neuron sends a pulse, it will first query the L1 axon table of the local core. If the L1 axon table can directly find the target neuron, the pulse will be immediately transmitted to the neuron. If the corresponding routing entry is not found in the L1 axon table, the L2 axon table will be entered. The L2 axon table is responsible for storing neuron connection information in a larger range. Generally, unlike the L1 table, the L2 table contains more neuron connection information. If the corresponding routing information is still not found in the L2 table, the router will query through the L3 axon table. The L3 table is usually stored in global memory, such as DRAM, and is responsible for managing neuron connection information in a larger range and across cores. The L1 and L2 tables exist in a hierarchical form. The L2 table has a large number of entries and can support neuron connections across cores. The L2 table expands the storage capacity of the L1 table through a linked list structure. When the system performs routing, it first searches for the nearest neuron target in L1. If it misses in L1, it gradually performs a more extensive search in L2 and L3 to ensure that signal transmission across cores and modules can be completed smoothly.

[0191] The design process of the neuron pulse processing mechanism is described as follows. Figure 3 As shown in the figure, the processing of pulses is divided into multiple steps: ① Determine the neuron group: The input pulse first enters the input pulse queue, and the system uses a hash mechanism to determine the neuron group to which the pulse should be transmitted. Each neuron group contains several neurons, and the input pulse needs to accurately find the target neuron group to which it belongs and further process it; ② Update the neuron membrane potential: After finding the target neuron, the system will update the membrane potential of the neuron through the neuron state list. The neuron state list records the membrane potential, impulse information and threshold of each neuron. As the input pulses accumulate, the membrane potential of the neuron will continue to increase until it reaches its threshold. ③ Determine whether the membrane potential reaches the threshold: The system detects the membrane potential of the neuron to determine whether it exceeds the set threshold. If the membrane potential exceeds the threshold, the system will search for the target neuron through the neuron routing table to determine the next signal transmission path. ④ Process the output pulse queue: If the neuron triggers a pulse, the pulse is placed in the output pulse queue. According to the routing mechanism, the system will determine whether the output pulse is processed in the current crossbar or needs to be sent to other cores. If the pulse is in the current crossbar, it will be directly placed in the input queue for further processing; if it is not in the current crossbar, it will be sent to the target core through on-chip routing.

[0192] The present invention also provides a crossbar-based neuromorphic hardware simulation system, which can be implemented by executing the process steps of the crossbar-based neuromorphic hardware simulation method, that is, those skilled in the art can understand the crossbar-based neuromorphic hardware simulation method as a preferred implementation of the crossbar-based neuromorphic hardware simulation system.

[0193] The crossbar-based neuromorphic hardware simulation system includes: module M1: loading configuration files and network files to obtain initialization parameters; module M2: initializing the chip module, core module and neuron assembly module of the simulator according to the initialization parameters; module M3: starting the simulation, allowing the neuron module to receive a pulse signal, and performing operations according to the pulse signal to obtain operation results; module M4: judging whether the simulation is completed according to the count of the pulse signal, if the result is yes, executing step S5; if the result is no, no processing; module M5: allowing the chip module to integrate all the operation results to generate a report file.

[0194] Those skilled in the art know that, in addition to realizing the system and its various devices, modules, and units provided by the present invention in a purely computer-readable program code, it is entirely possible to realize the same functions in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a hardware component, and the devices, modules, and units included therein for realizing various functions can also be regarded as structures within the hardware component; the devices, modules, and units for realizing various functions can also be regarded as both software modules for realizing the method and structures within the hardware component.

[0195] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A crossbar-based neuromorphic hardware simulation method, characterized in that: The neuromorphic hardware includes: a simulator; the simulator includes a chip module and a neuron assembly module; the chip module is used to manage and coordinate the management of all cores, memory and on-chip network communications of the simulator; the neuron assembly module is used to perform simulation tasks; The crossbar-based neuromorphic hardware simulation method is implemented based on the neuromorphic hardware, and includes: Step S1: Load configuration files and network files to obtain initialization parameters; Step S2: Initializing the chip module and neuron assembly module of the simulator according to the initialization parameters; Step S3: starting the simulation, allowing the neuron assembly module to receive the pulse signal, and performing calculations according to the pulse signal to obtain calculation results; Step S4: judging whether the simulation is finished according to the pulse count of the operation result, if the result is yes, executing step S5; if the result is no, no processing; Step S5: instructing the chip module to integrate all the calculation results and generate a report file.

2. The crossbar-based neuromorphic hardware simulation method according to claim 1, characterized in that: The simulator of the neuromorphic hardware further includes a core module; the core module is used to manage the computing and storage tasks of the chip; when the core of the core module is instantiated, a crossbar module is created; The crossbar module is used to process and transmit pulse signals between neurons; In the step S1, the initialization parameters include: the number of neurons, neuron ID, synapse information, neuron connection matrix and simulation parameters; the simulation parameters include simulation duration; the synapse information includes the number of synapses; In the step S1, a global routing table is generated based on the neuron ID and synapse information of the initialization parameters; In the step S2, the crossbar module of the simulator is initialized and a monitor is created; the monitor is used to check the status of the core of the core module; In the step S2, the membrane potential of the neurons of the neuron assembly module is initialized.

3. The crossbar-based neuromorphic hardware simulation method according to claim 2, characterized in that: In the step S3, it includes: Step S3.1: Instruct the crossbar module to send the pulse signal to the target neuron according to the global routing table; Step S3.2: Instructing the neuron assembly module to update the neuron potential according to the pulse signal, and then accumulate the pulse value to obtain the calculation result; Step S3.3: Instruct the core module to integrate all the calculation results to obtain the calculation result.

4. The crossbar-based neuromorphic hardware simulation method according to claim 2, characterized in that: In the step S4, a check cycle is set, and according to the check cycle, the core module is made to check and determine whether the pulse count of the previous cycle is equal to the pulse count of the current cycle through the monitor, and if the result is yes, the simulation result is recorded and output; If the result is no, retest.

5. The crossbar-based neuromorphic hardware simulation method according to claim 3, characterized in that: In step S5, the report file includes: the path of the configuration file, the number of cores, the number of neurons, simulation information, energy consumption statistics and operation data of each core; the energy consumption statistics are simulated and counted by the crossbar module according to the global routing table; In step S3, a pulse accumulation threshold is set to determine whether the current pulse value is greater than the pulse accumulation threshold. If the result is yes, a pulse is emitted to clear the membrane potential of the neuron; if the result is no, no processing is performed.

6. A crossbar-based neuromorphic hardware simulation system, characterized in that: The neuromorphic hardware includes: a simulator; the simulator includes a chip module and a neuron assembly module; the chip module is used to manage and coordinate the management of all cores, memory and on-chip network communications of the simulator; the neuron assembly module is used to perform simulation tasks; The crossbar-based neuromorphic hardware simulation system includes: Module M1: load configuration files and network files, and obtain initialization parameters; Module M2: Initialize the chip module, core module and neuron assembly module of the simulator according to the initialization parameters; Module M3: Start the simulation, so that the neuron module receives the pulse signal, and performs calculation according to the pulse signal to obtain the calculation result; Module M4: judging whether the simulation is finished according to the count of the pulse signal, if the result is yes, executing step S5; if the result is no, no processing; Module M5: instructs the chip module to integrate all the calculation results and generate a report file.

7. The crossbar-based neuromorphic hardware simulation system according to claim 6, characterized in that: The simulator of the neuromorphic hardware further includes a core module; the core module is used to manage the computing and storage tasks of the chip; when the core of the core module is instantiated, a crossbar module is created; The crossbar module is used to process and transmit pulse signals between neurons; In the module M1, the initialization parameters include: the number of neurons, neuron ID, synapse information, neuron connection matrix and simulation parameters; the simulation parameters include simulation duration; the synapse information includes the number of synapses; In the module M1, a global routing table is generated based on the neuron ID and synapse information of the initialization parameters; In the module M2, the crossbar module of the simulator is initialized and a monitor is created; the monitor is used to check the status of the core of the core module; In the module M2, the membrane potential of the neurons of the neuron assembly module is initialized.

8. The crossbar-based neuromorphic hardware simulation system according to claim 7, characterized in that: The module M3 includes: Module M3.1: instruct the crossbar module to send the pulse signal to the target neuron according to the global routing table; Module M3.2: instructing the neuron assembly module to update the modulus potential of the neuron according to the pulse signal, and then accumulate the pulse value to obtain the calculation result; Module M3.3: Instruct the core module to integrate all the calculation results to obtain the calculation result.

9. The crossbar-based neuromorphic hardware simulation system according to claim 7, characterized in that: In the module M4, a check cycle is set, and according to the check cycle, the core module is made to check and determine whether the pulse count of the previous cycle is equal to the pulse count of the current cycle through the monitor, and if the result is yes, the simulation result is recorded and output; If the result is no, retest.

10. The crossbar-based neuromorphic hardware simulation system according to claim 8, characterized in that: In the module M5, the report file includes: the path of the configuration file, the number of cores, the number of neurons, simulation information, energy consumption statistics and operation data of each core; the energy consumption statistics are simulated and counted by the crossbar module according to the global routing table; In the module M3, a pulse accumulation threshold is set to determine whether the current pulse value is greater than the pulse accumulation threshold. If the result is yes, a pulse is emitted to clear the membrane potential of the neuron; if the result is no, no processing is performed.

Images