Microcode efficient emulation method for a network processor

Abstract

The present application relates to a microcode efficient simulation method of network processor, and belongs to the field of network processor. The present application develops a network processor simulation model; the user can see the running condition of each instruction and each variable through the simulation waveform, including the instruction delay and the change process of the variable; the user can pause the simulation at any time during the simulation process, which is convenient for upgrading the instruction (hereinafter collectively referred to as microcode) of the network processor and editing the content of the received and transmitted data packet (these data packets are the messages received from the Ethernet port and sent to the processor for processing, and the messages sent to the Ethernet port for transmission after being processed by the processor), greatly improving the simulation and code iteration efficiency.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of network processors, and particularly relates to a microcode efficient simulation method of a network processor. BACKGROUND

[0002] Networks develop rapidly, network bandwidth is higher and higher, network protocols are more and more complex, and network protocol processing needs programmable processing, that is, messages need to be processed by programmable processor cores. Semiconductor technology enters the post-Moore era, chip technology improves at a slower pace, and the frequency of the processor increases less and less. Due to power consumption constraints, the frequency of the processor cannot be run too high, so it is more and more difficult to improve performance by single-core. Multi-core architecture and multi-launch architecture emerge as the times require.

[0003] Under the multi-core architecture and multi-launch architecture, network processors are almost awakened by data packets, timer events and Doorbell events to process events. Parallel processing and in-order processing of various events need to be considered between processors. The delay of each instruction needs to be accurately calculated to maximize the IPC of the processor, which belongs to parallel programming mode. The parallel programming of network processors is much more difficult than the serial programming of general-purpose processors.

[0004] Therefore, the current situation is:

[0005] 1. The high difficulty of parallel programming of network processors greatly increases the technical support cost of network processor suppliers.

[0006] 2. The cost of learning and familiarizing with parallel programming based on the flexible architecture of network processors is high. SUMMARY

[0007] (I) Technical problems to be solved

[0008] The technical problem to be solved by the present application is how to provide a microcode efficient simulation method of a network processor to solve the problem that the high difficulty of parallel programming of network processors greatly increases the technical support cost of network processor suppliers and the cost of learning and familiarizing with parallel programming based on the flexible architecture of network processors is high.

[0009] (II) Technical solutions

[0010] In order to solve the above technical problems, the present application provides a microcode efficient simulation method of a network processor, which comprises the following steps:

[0011] S1: Simulation personnel compiles a verification environment including verification platform code TB and design code rtl to generate a compiled library;

[0012] S2: The simulation personnel starts the simulator to execute the simulation process; the TB loads the register configuration command to the logic dut to be tested to complete the initialization of the rtl;

[0013] S3: The TB automatically reads the data message to be sent to the network processor for processing from the file, adds it to the sending queue of the TB, and waits for the Ethernet message receiving module of the dut to receive the Ethernet message from the Ethernet port;

[0014] S4: The TB loads the microcode to be run to the network processor NP of the multi-core through the register configuration command;

[0015] S5: The TB sends the message to be sent in S3 from the Ethernet port to the Ethernet message receiving module of the dut;

[0016] S6: The TB sends all the data messages to be processed to the dut;

[0017] S7: The Ethernet message receiving module of the dut sends all the messages to be processed to the network processor for processing, and completes the simulation round after the processing is completed, and the simulation personnel suspends the simulation process;

[0018] S80: The simulation personnel checks the log file and waveform file generated by the simulation to determine whether the simulation result meets the design requirements, and decides whether to modify the microcode of the network processor or the data message sent to the dut;

[0019] S81: The simulation personnel temporarily interrupts the simulation process of the simulator, but does not exit, and decides to modify the microcode of the NP core or multiple NP cores of the multi-core network processor according to the result of S80;

[0020] S82: The simulation personnel checks the simulation result and decides to modify the data message sent to the dut;

[0021] S83: The simulation personnel modifies the microcode of the NP core or multiple NP cores of the multi-core network processor in the debugging environment of the microcode, generates the hex file that can be loaded by the TB after the compilation is completed, and places the microcode in the specified path;

[0022] S84: The simulation personnel reconstructs the new data message in the message generation environment, and places it in the position that can be read by the TB, and waits for the TB to read the new message into the sending queue of the TB;

[0023] S85: The simulation personnel starts the simulation process of the simulator, and starts the task of sending the message to the dut in the TB in the command line, and temporarily stops the simulation after the simulator executes all the contents of the task, and continues to wait for the new simulation command input by the command line;

[0024] S86: judging whether the microcode needs to be reloaded, if yes, the emulator invokes the function of TB to load the microcode of the corresponding network processor into the network processor in the command line, the emulator temporarily stops the simulation after running the task, and continues to wait for the new simulation command input by the command line;

[0025] S9: after repeating the iterations of S5-S86 for multiple rounds, the emulator checks the simulation results and determines whether the design requirements are met, and if yes, the emulator prepares to end the simulation;

[0026] S10: the emulator inputs exit in the command line to exit the simulation.

[0027] Further, the design code is encrypted in step S1.

[0028] Further, the dut is a logic including a series of rtl code modules in step S2.

[0029] Further, the dut is a logic including a series of rtl code modules in step S2.

[0030] Further, the emulator inputs CTRL+C in the simulation interface to temporarily interrupt the simulation process of the emulator in step S81.

[0031] Further, if no, the new packet is directly started in step S5 to start the sending and processing of the data packet after being added to the sending queue in step S86.

[0032] Further, the key signals of the internal module of the network processor are extracted, the signals are processed by a certain logic in the TB, and the new signals are put into the interface, and the simulation personnel checks the simulation results by viewing the signals of the interface in step S80.

[0033] Further, the simulation environment of the emulator includes the sv function written by systemverilog and the tcl call in the command line in step S85.

[0034] Further, the function sv_task written by systemverilog is always suspended after the simulation is run, waits for the parameter transmitted from the command line to trigger the function to execute, the sv_task does not exit, but always stays in the state of waiting for the trigger condition, and executes when the condition is met, and returns to the state of waiting for the new trigger after the execution is completed.

[0035] Further, the tcl call of the command line in the simulation process is: a function written by sv, which is registered to tcl through certain processing to obtain the sv_task_register_in_tcl function, and after the simulation runs, the function will not run automatically, but needs to be called in the command line in the form of function call after the simulation is paused, and after the function is run, the simulation is temporarily exited, and the command line displays the input of a new command.

[0036] (III) Beneficial Effects

[0037] The microcode efficient simulation method of the network processor is proposed, compared with the prior art, the technical scheme proposed by the application can realize dynamic loading of the network processor microcode. In the state of continuous simulation, the microcode of the corresponding network processor is modified and dynamically loaded according to the running result each time, the packet is retransmitted after loading, the new microcode is used to process the data packet and the result is checked, and the microcode is modified, loaded and debugged multiple times according to the need. The development efficiency of the microcode is greatly improved, and rapid iteration is realized. BRIEF DESCRIPTION OF DRAWINGS

[0038] Figure 1 The simulation processing flowchart of the application is shown in the figure;

[0039] Figure 2 The SV task and command line TCL interaction schematic diagram is shown in the figure;

[0040] Figure 3 The waveform check schematic diagram is shown in the figure;

[0041] Figure 4 The interface schematic diagram of extracting the key signal in the rtl is shown in the figure. DETAILED DESCRIPTION

[0042] In order to make the purpose, content and advantages of the application more clear, the specific embodiments of the application are further described in detail below in combination with the drawings and examples.

[0043] The purpose of the application is to reduce the difficulty of parallel programming of the network processor.

[0044] The application mainly solves the following four difficult problems:

[0045] 1. Develop a network processor simulation model;

[0046] 2. Users can see the running situation of each instruction and each variable through the simulation waveform, including the instruction delay and the change process of the variable;

[0047] 3. User can pause simulation at any time during simulation, facilitating upgrading instruction of network processor (hereinafter collectively referred to as microcode) and editing content of transceiving data packet (these data packets are messages received from Ethernet interface and sent to processor for processing, and messages sent to Ethernet interface after being processed by processor), greatly improving simulation and code iteration efficiency;

[0048] Figure 1 is the main flowchart of the technical scheme of the present application. As shown in Figure 1 the microcode high-efficiency simulation method of network processor proposed by the present application comprises the following steps:

[0049] S1: simulation personnel compiles verification environment, including verification platform code TB and design code rtl, to generate compilation library;

[0050] S2: simulation personnel starts simulator to execute simulation process. TB performs register configuration on to-be-tested logic dut (commonly referred to as dut, i.e. logic code containing a series of rtl code modules, in this text, it mainly refers to a series of logic codes containing multi-core network processor, hereinafter referred to as NP, and other cooperating processors) by issuing register configuration command, to complete initialization of rtl;

[0051] S3: TB automatically reads data messages to be sent to processor for processing from file, adds them to the sending queue of TB, and waits for Ethernet messages received by Ethernet message receiving module of dut;

[0052] S4: TB loads microcode to be run into multi-core network processor NP by issuing register configuration command;

[0053] S5: TB sends the messages to be sent in S3 from Ethernet interface to Ethernet message receiving module of dut;

[0054] S6: TB sends all data messages to be processed this time to dut;

[0055] S7: Ethernet message receiving module of dut sends all messages to be processed this time to network processor for processing, and waits for completion of this round of simulation after processing, and simulation personnel pauses simulation process;

[0056] S80: simulation personnel checks log file and waveform file generated by simulation running, judges whether simulation result meets design requirement, and decides whether to modify microcode of network processor and whether to modify data messages sent to dut;

[0057] S81: The simulation personnel input CTRL+C in the simulation interface to temporarily interrupt the simulation process of the simulator, but do not exit, and then decide to modify the microcode of the NP core or NPs of the corresponding multi-core network processor according to the result of S80;

[0058] S82: The simulation personnel check the simulation result and decide to modify the data packet sent to the dut again;

[0059] S83: The simulation personnel modify the microcode of the NP core or NPs of the corresponding multi-core network processor in the debugging environment of the microcode, generate a hex file that can be loaded by the TB after completing the compilation, and place the microcode in the specified path;

[0060] S84: The simulation personnel reconstruct a new data packet in the packet generation environment and place it in a position that can be read by the TB, and wait for the TB to read the new packet into the sending queue of the TB;

[0061] S85: The simulation personnel start the simulation process of the simulator, and start the task of sending the packet to the dut in the command line of the TB, and the simulator temporarily stops the simulation after executing all the contents of the task, and continues to wait for the new simulation command input by the command line;

[0062] S86: Determine whether the microcode needs to be reloaded, if so, the simulation personnel call the function of the TB to load the microcode in the command line, load the microcode of the corresponding network processor into the processor, and the simulator temporarily stops the simulation after running the task, and continues to wait for the new simulation command input by the command line.

[0063] Note: It is not necessary to reload the microcode when adding a new packet to the dut. If the microcode does not need to be reloaded, the S5 step is started directly after the new packet is added to the sending queue to start the sending and processing of the data packet; if the microcode needs to be reloaded, the microcode of the corresponding network processor is reloaded after the sending packet is added to the sending queue, and then the S5 step is started to start the sending and processing of the data packet.

[0064] S9: After repeating S5-S8 for multiple iterations, the simulation personnel check the simulation result to meet the design requirements, and then prepare to end the simulation;

[0065] S10: The simulation personnel input exit in the command line to exit the simulation.

[0066] Figure 2 It is the principle diagram for realizing the dynamic loading of the network processor microcode and the dynamic sending of the packet in the technical scheme of the application.

[0067] The simulation environment of the simulator in the application mainly consists of two parts, an sv function written by systemverilog (abbreviation sv) and a tcl call of a command line in a simulation process.

[0068] The first kind of function written by sv (sv_task in the left upper half part) is hung up after the simulation is run, and waits for a parameter transmitted in the command line in the simulation process to trigger the function to execute. Figure 2 The task of this kind will not exit, but will be in the state of waiting for a trigger condition, and will execute when the condition is met, and will return to the state of waiting for a new trigger after the execution.

[0069] The second kind of function written by sv is registered in tcl through certain processing, and obtains a function such as sv_task_register_in_tcl in the right half part. Figure 2 After the simulation is run, the function of this kind will not run automatically, but needs to pause the simulation in the simulation process, and then the function is called in the command line in the form of a function call, such as sv_task0_register_in_tcl in the command to run the task. After the function is run, the simulation is temporarily exited, and the command line displays a new command to be input;

[0070] Figure 3 , Figure 4 is one of the ways for the simulation personnel to check the simulation result in the technical scheme of the application, and is a further description of how S80 in the main flow checks whether the design conforms to the expectation through a waveform.

[0071] Because the rtl is relatively complex, the simulation personnel does not need to pay attention to how the dut or the rtl runs internally, but only needs to pay attention to whether the microcode instruction runs normally. At the same time, the original design code can be encrypted to protect the intellectual property right. Therefore, the key signals of the internal module of the network processor are extracted, and the signals are processed through certain logic in the TB to generate new signals and put the new signals into the interface interface. The microcode simulation personnel can check the simulation result by checking the signals of the interface through a waveform.

[0072] Compared with the prior art, the technical scheme provided by the application can realize dynamic loading of the microcode of the network processor. In the state of the simulation, the microcode of the corresponding network processor is modified and dynamically loaded according to the result of each execution, the packet is retransmitted after the loading, the new microcode is used to process the data packet, and the result is checked. According to the need, the microcode is modified, loaded and debugged many times. The development efficiency of the microcode is greatly improved, and the rapid iteration is realized.

[0073] The above merely describes the preferred embodiments of the present application, and it should be pointed out that, for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present application, and these improvements and modifications should also be considered as the protection scope of the present application.

Claims

1. A method for efficient microcode emulation of a network processor, characterized in that, The method includes the following steps: S1: The simulation personnel compile and verify the environment, including the verification platform code TB and the design code rtl, and generate the compiled library; S2: The simulation operator starts the simulator to execute the simulation process; TB configures the registers of the logic under test (DUT) by issuing register configuration commands, thus completing the initialization of the RTL. S3: TB automatically reads the data packets to be sent to the network processor from the file and adds them to the TB's sending queue, waiting for the Ethernet packet receiving module of DUT to be sent from the Ethernet port; S4: TB loads the microcode to be run to the multi-core network processor NP by issuing register configuration commands; S5: TB sends the message to be sent by S3 from the Ethernet port to the Ethernet message receiving module of DUT. S6: TB sends all data packets to be processed to DUT; S7: The Ethernet packet receiving module of DUT sends all the packets to be processed to the network processor for processing. After processing is completed, the simulation is finished and the simulation personnel pause the simulation process. S80: Simulation personnel check the log files and waveform files generated during the simulation run to determine whether the simulation results meet the design requirements, and decide whether to modify the network processor's microcode and the data packets sent to the DUT. S81: The simulator operator temporarily interrupts the simulator's simulation process but does not exit. Based on the results of S80, the operator decides to modify the microcode of one or more NP cores of the corresponding multi-core network processor. S82: The simulation personnel review the simulation results and decide to modify the data packets sent to DUT. S83: Simulation personnel modify the microcode of one or more NPs of the corresponding multi-core network processor in the microcode debugging environment, and after compilation, generate a hex file that TB can load and put the microcode into the specified path. S84: The simulator reconstructs a new data packet in the packet generation environment and places it in a location that TB can read, waiting for TB to read the new packet into TB's sending queue; S85: The simulation operator starts the simulation process of the simulator and sends a message to the task in TB via the command line. After the simulator finishes executing all the contents of the task, it temporarily stops the simulation and continues to wait for the command line to input new simulation commands. S86: Determine whether microcode needs to be reloaded. If so, the simulator operator calls the TB microcode loading function in the command line to load the corresponding network processor's microcode into the network processor. After the simulator runs this task, it temporarily stops the simulation and continues to wait for new simulation commands to be entered in the command line. S9: After repeating S5 to S86 multiple iterations, if the simulation personnel find that the simulation results meet the design requirements, then they are ready to end the simulation. S10: The simulation user enters "exit" in the command line to exit the simulation.

2. The efficient microcode emulation method for network processors as described in claim 1, characterized in that, In step S1, the design code is encrypted.

3. The efficient microcode emulation method for network processors as described in claim 1, characterized in that, In step S2, dut is logic that contains a series of RTL code modules.

4. The efficient microcode emulation method for network processors as described in claim 1, characterized in that, In step S2, dut is a series of logic codes that include the multi-core network processor NP and other cooperating processors.

5. The efficient microcode emulation method for network processors as described in claim 1, characterized in that, In step S81, the simulation operator enters CTRL+C in the simulation interface to temporarily interrupt the simulation process of the simulator.

6. The efficient microcode emulation method for network processors as described in claim 1, characterized in that, In step S86, if not required, step S5 is started directly after the new message is added to the sending queue to begin sending and processing the data message.

7. The efficient microcode emulation method for network processors as described in any one of claims 1-6, characterized in that, In step S80, key signals from the internal modules of the network processor are extracted, and these signals are processed in TB to generate new signals which are then placed into the interface. Microcode simulation personnel check the simulation results by viewing the waveforms of the interface signals.

8. The efficient microcode emulation method for network processors as described in claim 7, characterized in that, In step S85, the simulator's simulation environment includes sv functions written in SystemVerilog and tcl calls to the command line during the simulation process.

9. The efficient microcode emulation method for network processors as described in claim 8, characterized in that, The function sv_task, written in SystemVerilog, is suspended after the simulation starts running, waiting for parameters passed from the command line during the simulation to trigger the function to continue execution. The sv_task will not exit, but will remain in the state of waiting for the trigger condition. If the condition is met, it will continue to execute, and after execution, it will return to the state of waiting for a new trigger.

10. The efficient microcode emulation method for network processors as described in claim 8, characterized in that, During the simulation, the command line TCL calls are as follows: functions written in SV are registered in TCL through certain processing to obtain the sv_task_register_in_tcl function. After the simulation starts, these functions will not run automatically. Instead, the simulation needs to be paused first, and then the function is called explicitly in the command line. After these functions complete, the simulation temporarily exits, and the command line displays a message waiting for new commands to be entered.

Images