WO2017202083A1

WO2017202083A1 - Microcode debugging method and single board

Info

Publication number: WO2017202083A1
Application number: PCT/CN2017/074452
Authority: WO
Inventors: 姜海明
Original assignee: 中兴通讯股份有限公司
Priority date: 2016-05-25
Filing date: 2017-02-22
Publication date: 2017-11-30
Also published as: CN107436842A

Abstract

Provided are a microcode debugging method and a single board. In the microcode debugging method, when a breakpoint instruction is executed, a microcode on a single board is debugged by invoking a debugging program stored in advance on the single board. In the microcode debugging method provided in the present invention, since a debugging program is stored in advance on a single board, in a subsequent debugging process, there is no need to issue the debugging program to the single board again via an IDE.

Description

Microcode debugging method and board

Technical field

The present invention relates to the field of communications technologies, and in particular, to a microcode debugging method, a single board, and a computer storage medium.

Background technique

Today's network development is amazing, network traffic growth and the emergence of new services require network equipment to have wire-speed and flexible processing capabilities. With its high-speed processing advantages and flexible programmability, network processors have become an effective tool for data processing in today's networks.

The core unit of the NP (Network Processor) is the micro-engine, and the micro-engine resides in the micro-code for processing the message data. When the message enters the microengine, the microcode execution is triggered. If you need to debug the microcode, you usually set the hardware breakpoint in the microcode, and then let the microcode instruction step by step. Then, the context content of the message after the single-step execution is read, and the context content of the message is modified, and the context content of the message includes the register resource information of the context of the message and the content of the message.

In order to debug the microcode, at present, the general scheme is as shown in FIG. 1. The network port of the computer 1 is directly connected to the network port of the board 2, and the IDE (Integrated Development Environment) program is run on the computer 1. The IDE is an application provided to the user for the program development environment, which typically includes a code editor, compiler, debugger, and graphical user interface tools. At present, debugging of many programs requires the use of an IDE environment.

However, it has been found in the specific application that the debugging of the microcode in the prior art is very complicated.

Summary of the invention

The embodiment of the present invention is intended to provide a microcode debugging method for solving the technical problem of an IDE environment supporting the microcode on a computer when debugging the microcode in the prior art.

An embodiment of the present invention provides a microcode debugging method, including:

When the breakpoint instruction is executed, the pre-stored debugger on the board is called;

Debugging the microcode on the board according to the debugging program.

The present invention provides a board, including a network processor and a memory, the network processor including a micro engine;

The micro engine is configured to, when executing a breakpoint instruction, control the microcode to enter a debugging state, and invoke a pre-stored debugging program on the board;

The micro engine is further configured to debug the microcode on the board according to the debugging program.

The microcode debugging method and the board provided by the embodiment of the invention, when executing the breakpoint instruction, enable the microcode to enter the debugging state, and call the pre-stored debugging program on the board to debug the microcode on the board. In the microcode debugging method provided by the present invention, since the debugging program is stored on the board in advance, in the subsequent debugging process, the debugging program is not required to be sent to the board through the IDE, so it is not required to be on the computer. Running the IDE program simplifies the debugging process of the microcode, and since the computer is no longer required to support the operation of the IDE program, the requirements for the device to be debugged are also reduced, thereby improving the user experience.

DRAWINGS

1 is a schematic diagram of debugging a single board microcode in the prior art;

2 is a schematic flowchart of a microcode debugging method according to Embodiment 1 of the present invention;

3 is a schematic structural diagram of a microcode debugging apparatus according to Embodiment 2 of the present invention;

4 is a schematic diagram of a first structure of an instruction debugging module according to Embodiment 2 of the present invention;

FIG. 5 is a schematic diagram of a second structure of an instruction debugging module according to Embodiment 2 of the present invention; FIG.

6 is a schematic diagram of a third structure of an instruction debugging module according to Embodiment 2 of the present invention;

FIG. 7 is another schematic structural diagram of a microcode debugging apparatus according to Embodiment 2 of the present invention; FIG.

FIG. 8 is a schematic structural diagram of a single board according to Embodiment 3 of the present invention; FIG.

FIG. 9 is a schematic flowchart of a method for debugging a micro-board of a third board according to an embodiment of the present invention.

detailed description

The study found that the single board 2 shown in Figure 1 has two core chips, NP and CPU, and the micro-engine in the NP stores microcode. The driver software can be run on the CPU, and the CPU is provided with a debug network port for receiving the debugger. The driver software running on the CPU will host an agent client that connects to the IDE of the computer through a Socket (socket) and receives messages sent by the IDE. The IDE encapsulates the control commands to be sent to the microcode into messages, which are sent to the agent via the Socket. The Agent program parses the message sent by the IDE and performs corresponding operations on the micro engine through the CPU interface of the NP. This method requires the micro-engine to have a dedicated DEBUG (debug) module, the DEBUG module is used to access the micro-engine internal registers and header storage space and other resources.

In the above-mentioned existing debugging scheme, since the debugging program for debugging the microcode must be sent to the board by the IDE, it is necessary to use the computer to run the IDE program when the microcode debugging work is performed, so that the debugging of the microcode debugging is caused. The path sent by the program is long, and there are many intermediate nodes passing through, which makes the debugging process complicated and inefficient. After the technical problem is discovered, the embodiment of the present invention provides a microcode debugging method, in which a debugging program stored on a calling board is called in advance, and when debugging is required, a debugging program pre-stored on the board is called for debugging, thereby It is not necessary to be debugged by the IDE, which simplifies the debugging of the debugging program and direct debugging processing, and improves the debugging efficiency. The present invention will be further described in detail with reference to the accompanying drawings, in which: FIG.

Embodiment 1:

This embodiment provides a microcode debugging method. Referring to FIG. 2, the method includes:

S201. When executing the breakpoint instruction, the debugger stored in advance on the board is called.

In this embodiment, in addition to the microcode, the microengine has a section of code dedicated to debugging, which is the debugger. The debugger is called when the microengine in the network processor executes a breakpoint instruction.

S202. Debug the microcode on the board according to the debugging program.

The debugger includes a variety of code that can implement a certain function, including setting a breakpoint (Set Breakpoint), reading registers (Registers) or message content (Packet memory), modifying registers or message content, and stepping through (Single Step), Run (Continue), etc. The debugger can execute the corresponding code according to the debug instructions input by the user and then implement the corresponding functions.

In this embodiment, it is necessary to receive a debugging instruction input by the user before debugging the microcode on the board according to the debugging program. The debugging instructions are sent to the CPU through the computer and then stored in the first storage space. The first storage space can be set to a SRAM (Static Random Access Memory) on the network processor and set outside the network processor. SRAM or DRAM (Dynamic Random-Access Memory) set outside the network processor.

The user can input various debugging commands through the CLI (command-line interface). The CLI refers to an interface that can input executable instructions at the user prompt. It usually does not support the mouse. The user inputs commands through the keyboard and receives the CPU. The CLI instruction is stored after the instruction.

It can be understood that, in some specific scenarios, when debugging the microcode on the board, the user may not need to input an instruction, for example, when executing the instruction to the breakpoint, the code in the debugger is automatically run. Code for debugging.

When the CPU stores the debug instructions to the first storage space, the micro engine goes from the first storage space The debug command is read, and the debugger is controlled to implement the function desired by the user according to the debug command.

In this embodiment, the manner of debugging the microcode on the board according to the read debugging instruction includes the following:

The first type, when reading the information storage instruction, stores the debugging information into the second storage space, and the debugging information includes the register resource of the message context and the content of the message. The debug information here includes the register resource information of the message context, for example, the register identifier of the register of the message context.

Like the first storage space, the second storage space may be an SRAM disposed on a network processor, an SRAM disposed outside the network processor, or a DRAM disposed outside the network processor. The first storage space and the second storage space may be different storage addresses belonging to the same memory, or may belong to different memories. After the debugging information is stored in the second storage space, the CPU may be notified by the interrupt, so that the CPU can read the debugging information in the second storage space in a first time and further display it to the user.

Second, when the information modification instruction is read, the debugging information is modified.

Since the function of the microcode itself is to process the message, in order to test the correctness of the microcode program, the debugging information needs to be modified, that is, the register resource of the message context and the content of the message need to be modified, and the result of the modification is modified. If it does not match the user's expectations, it indicates that there is a problem with the microcode instruction. If it matches the user's expectations, it can be determined that the microcode instruction has no problem.

Third, when reading the breakpoint end instruction, the debugging of the original microcode instruction corresponding to the current breakpoint instruction is exited.

The debugging of the original microcode instruction corresponding to the current breakpoint instruction is exited, that is, the original microcode instruction corresponding to the current breakpoint instruction is exited from the debugging state. In this embodiment, the breakpoint end instruction includes two types, one is Used to control the direct exit of the debug state, for example, the user enters Continue as a debug command in the CLI interface. The other is a single-step execution instruction, which is used to write the previously stored original microcode instruction back to the previous current breakpoint instruction, and the next sentence of the line The original microcode instruction is replaced with a breakpoint instruction and the original microcode instruction is stored, and then the debug instruction is issued to notify the debug state, trigger a new breakpoint, and re-enter the debug state from the new breakpoint. If the user is currently debugging the microcode instruction on line 37 and then wants to perform a single step, the user can enter "Single Step" via the CLI. The microengine can first replace the 37-line breakpoint instruction with the stored original microcode instruction, then replace the 38-line original microcode instruction with a breakpoint instruction, and save the 38-line original microcode instruction at 38th. After the instruction of the line is debugged, the original microcode instruction is written back.

It is worth noting that before the debug program pre-stored on the board is called, the breakpoint command is set in the preset position according to the breakpoint setting instruction. Before debugging a piece of microcode, you must first set at least one breakpoint instruction. At the same time, since the debugging process is triggered by a breakpoint instruction, you must ensure that at least the debugged code exists before entering the debug state each time. A breakpoint instruction. Therefore, from the body, setting the breakpoint command must be before debugging. In fact, in this embodiment, a breakpoint instruction can also be set during the debugging process, but the breakpoint instruction set at this time is used for the next debugging, and the microengine is executed again when it is executed to other positions of the microcode. status. The other location mentioned here is the location reserved by the user, and the user can determine the location of the breakpoint instruction by specifying the line number. In this embodiment, a method for setting a breakpoint instruction is provided: replacing the original microcode instruction at the breakpoint to a breakpoint instruction. Since the breakpoint instruction needs to be restored to the original microcode instruction after the debugging at the breakpoint instruction ends, the original microcode instruction needs to be saved while replacing the original microcode instruction with the breakpoint instruction.

A partial code of a debugger is provided below for reference by those skilled in the art, as follows:

Loop{

Cmd=Read(SRAM.cmd);

Switch(cmd)

{

Case 1: Store (SRAM.rsp, info), the read debugging information is stored in the RSP space;

Case 2: Modify the debugging information;

Case 3: continue execution, exit;

}

As can be seen from the above code segment, the debugger is mainly used to read the debug instruction from the cmd space in the SRAM, and then execute the corresponding program according to the read debug instruction, for example, when the instruction is read from the cmd space. When it is "1", the program of Case 1 is executed, and the read debug information is stored in the RSP space of the SRAM, and the debug information includes the register resource of the message context and the content of the message. When the read command is "2", the debug information is modified. Similarly, when the debug command is "3", the debug is exited, and the microengine continues to execute the microcode normally.

Although the above example stores the debug instructions in the cmd space of the SRAM and stores the debug information in the RSP space of the SRAM, it can be understood that in the actual application process, the debug instructions are not required to be stored in the cmd space. Similarly, it is not required to store debug information in the RSP space of the SRAM.

During the actual debugging process, the debugging information is read by the CPU and displayed to the user through the display device, and the debugging instruction is used to indicate which code the debugger in the network processor should execute. Therefore, the reason why the debug instructions and debug information are stored separately is to allow the CPU and the micro engine to determine which information to read. However, those skilled in the art should understand that as long as the CPU can read the debugging information instead of the debugging instruction and let the micro engine read the correct debugging instruction instead of the debugging information, even if the debugging instruction and the debugging information are not stored separately. It doesn't matter. For example, all debug information is prefixed to distinguish it from debug instructions without a prefix. In this case, the CPU reads the information with the specific prefix as a debug when reading the information. Information, and the micro engine only reads information without the prefix as a debug command.

In the microcode debugging method provided by the present invention, since the debugging program is stored on the board in advance, in the subsequent debugging process, the debugging program is not required to be sent to the board through the IDE. The need to run the IDE program on the computer simplifies the debugging process of the microcode, and since the computer is no longer required to support the operation of the IDE program, the requirements for the device to be debugged are also reduced, thereby improving the user experience.

Embodiment 2:

The embodiment provides a microcode debugging device. The microcode debugging method provided in the first embodiment can be run on the microcode debugging device. Please refer to FIG. 3:

The microcode debugging device 30 includes a program invocation module 301 and an instruction debugging module 302.

The program invocation module 301 is configured to call a pre-stored debugger on the board when the breakpoint instruction is executed.

In this embodiment, in addition to the microcode, the microengine has a section of code dedicated to debugging, which is the debugger. When the microengine in the network processor executes the breakpoint instruction, the program call module 301 will call the debugger.

The instruction debugging module 302 is configured to debug the microcode on the board according to the debugging program.

The debugger includes a variety of code that can implement a function, including setting breakpoints, reading registers or message contents, modifying registers or message contents, stepping through, running, and so on. The debugger can execute the corresponding code according to the debug instructions input by the user and then implement the corresponding functions.

In this embodiment, the instruction debugging module 302 is further configured to receive a debugging instruction input by the user before debugging the microcode on the board according to the debugging program. The debugging instructions are sent to the CPU through the computer and then stored in the first storage space. The first storage space may be an SRAM disposed on the network processor, an SRAM disposed outside the network processor, or a DRAM disposed outside the network processor. .

The user can input various debugging instructions through the CLI. The CLI refers to an interface that can input executable instructions at the user prompt. It usually does not support the mouse. The user inputs commands through the keyboard, and the CPU stores the CLI instructions after receiving the instructions.

It can be understood that, in some specific scenarios, when debugging the microcode on the board, the user does not need to input an instruction, for example, when the breakpoint instruction is executed, the microcode is automatically entered into the debugging state, automatically. Run the code in the debugger to debug the microcode.

After the CPU stores the debug instruction to the first storage space, the micro engine reads the debug instruction from the first storage space, and the instruction debug module 302 controls the debug program to implement the function desired by the user according to the debug instruction.

As shown in FIG. 4, the instruction debug module 302 includes a first debug module 3021. The first debugging module 3021 is configured to store the debugging information to the second storage space when the information storage instruction is read, where the debugging information includes a register resource of the message context and a message content.

As shown in FIG. 5, the instruction debug module 302 includes a second debug module 3022. The second debugging module 3022 is configured to modify the debugging information when the information modification instruction is read.

The instruction debugging module 302 shown in FIG. 6 includes a third debugging module 3023 for controlling the current breakpoint instruction to exit the debugging state when reading the breakpoint end instruction.

In this embodiment, the breakpoint end instruction includes two types, one is for controlling to directly exit the debug state, for example, the user inputs Continue as a debug command in the CLI interface. Another one The single-step execution instruction is used to write the previously stored original microcode instruction back to the previous current breakpoint instruction, replace the original microcode instruction of the next sentence of the line with a breakpoint instruction and store the original micro Code instruction. Then issue a debug command to notify the debug state, trigger a new breakpoint, and re-enter the debug state from the new breakpoint. If the user is currently debugging the microcode instruction on line 37 and then wants to perform a single step, the user can enter "Single Step" via the CLI. The microengine can first replace the 37-line breakpoint instruction with the stored original microcode instruction, then replace the 38-line original microcode instruction with a breakpoint instruction, and save the 38-line original microcode instruction at 38th. After the instruction of the line is debugged, the original microcode instruction is written back.

It should be understood by those skilled in the art that the instruction debug module can include the first, second, third, and fourth debug modules described above.

In an example provided in this embodiment, as shown in FIG. 7, the microcode debugging apparatus 30 further includes a breakpoint setting module 300 configured to be configured to be pre-stored in the instruction debugging module 302. Before the program, set a breakpoint command at the preset position according to the breakpoint setting command. Before debugging a piece of microcode, the breakpoint setting module 300 must first set at least one breakpoint instruction. At the same time, since the debugging process is triggered by the breakpoint instruction, it must be guaranteed before each entry into the debug state. There is at least one breakpoint instruction in the debug code. Therefore, in the body, the breakpoint setting module 300 sets the breakpoint instruction must be before debugging. However, in the embodiment, in the debugging process interruption point setting module 300, it is configured to also set a breakpoint instruction, but only the breakpoint instruction set by the breakpoint setting module 300 is used for the next debugging, which is The microengine enters the debug state again when it executes to other locations in the microcode. The other location mentioned here is the location reserved by the user, and the user can determine the location of the breakpoint instruction by specifying the line number. In this embodiment, the breakpoint setting module 300 is provided with a setting method of a breakpoint instruction: the original microcode instruction at the breakpoint needs to be replaced with a breakpoint instruction. Since the breakpoint instruction needs to be restored to the original microcode instruction after the debugging at the breakpoint instruction ends, the original microcode instruction needs to be saved while replacing the original microcode instruction with the breakpoint instruction.

Loop{

Cmd=Read(SRAM.cmd);

Switch(cmd)

{

Case 2: Modify the debugging information;

Case 3: continue execution, exit;

}

Although the above example stores the debug instructions in the cmd space of the SRAM and stores the debug information in the RSP space of the SRAM, it can be understood that in the actual application process, the debug instructions are not required to be stored in the cmd space. Internally, the same is not required to store debug information in the RSP space of the SRAM.

During the actual debugging process, the debugging information is read by the CPU and displayed to the user through the display device, and the debugging instruction is used to indicate which code the debugger in the network processor should execute. Therefore, the reason why the debug instructions and debug information are stored separately is to allow the CPU and the micro engine to determine which information to read. However, those skilled in the art should understand that as long as it is ensured that the CPU can read the debug information instead of the debug command, the micro engine reads the correct tone. Trying instructions instead of debugging information, it doesn't matter if the debug instructions are not stored separately from the debug information. For example, all debug information is prefixed to distinguish it from debug instructions without a prefix. In this case, the CPU reads the information with the specific prefix as a debug when reading the information. Information, and the micro engine only reads information without the prefix as a debug command.

Embodiment 3:

This embodiment provides a board that includes a network processor and a memory. There is a micro-engine in the network processor. The micro-engine stores the micro-code. If a breakpoint is set in the micro-code, when the micro-engine is configured to execute the breakpoint instruction, it will enter the debug state. The stored debugger debugs the microcode in the microengine. The debugger can also reside in the microengine like the microcode. After reading the debug command, the debugger is used to debug the microcode in the microengine according to the debug command.

As shown in FIG. 8, in an example of the embodiment, the board 80 includes a network processor 801 and a memory 802. The memory 802 may be disposed on the network processor 801, or may be configured with a network processor 801 on the board 80. In addition to the location, preferably, the board 80 further includes a central processing unit 803. The central processing unit 803 is connected to the network processor 801 via PCI-E.

After entering the debugging state, the user can send a debugging instruction from the computer to the central processing unit 803 through the CLI interface, and the central processing unit 803 can store the debugging instruction in the first storage space of the memory 802, and the micro engine 8011 can be from the first The debug instructions are read in the storage space and debugged according to the debug instructions by the debugger.

If the debug command read by the microengine 8011 is an information store command, the micro engine 8011 may store the debug information to the second storage space of the memory 802 and notify the central processor 803 to enable the central processor 803 to access the second storage space. The debug information is read and displayed to the user through the display device. In this embodiment, the debug information includes a register resource of the message context and a message content.

The microcode debugging process on the board in this embodiment is described below with reference to FIG. 9:

When the micro-engine 8011 in the network processor 801 executes the breakpoint instruction, it enters the debug state.

S901. The micro engine stores the debugging information into the RSP space of the memory.

The debug information includes the contents of the register and the packet header.

S902: The micro engine triggers an interrupt to notify the central processing unit;

S903. The central processor reads the debugging information from the RSP space of the memory.

The information read by the central processing unit can be displayed to the user through a computer connected to the board, allowing the user to obtain debugging information, and then issuing debugging instructions from the CLI interface according to the debugging information.

S904. The central processor stores the debugging instruction in a cmd space of the memory.

There are several kinds of debugging instructions, which can be used to set breakpoints, read registers or message contents, modify registers or message contents, single-step execution, and run.

Although the breakpoint instruction is set in the above scheme during the debugging process, that is, after entering the debug state, those skilled in the art should understand that the debug process is triggered by the breakpoint instruction, so each time the debug state is entered. It must also be ensured that at least one breakpoint instruction exists in the debugged code. So, in general, setting breakpoint instructions must be before debugging. In the above scheme, the breakpoint instruction set during the debugging process is used for the next debugging, and the microengine enters the debugging state again when it executes to other positions of the microcode. The other location mentioned here is the location reserved by the user, and the user can determine the location of the breakpoint instruction by specifying the line number. The way to set the breakpoint instruction in this embodiment is to replace the original microcode instruction at the breakpoint to be a breakpoint instruction. Since the breakpoint instruction needs to be restored to the original microcode instruction after the debugging at the breakpoint instruction ends, the original microcode instruction needs to be saved while replacing the original microcode instruction with the breakpoint instruction.

S905. The microengine reads the debugging instruction from the cmd space of the memory.

After the micro engine reads the debug instruction, it can control the debugger to execute the corresponding code. Now the user wants the function. For example, setting a breakpoint, reading a register or message content, or modifying a register or message content.

The debugger that pre-stores the microcode on the board provided in this embodiment enters the debug state when the microengine executes the breakpoint instruction, and invokes the debugger to debug the microcode on the board. When debugging the microcode on the board provided by the present invention, since the board itself has a debugging program, there is no need to send a debugging program through the IDE, so there is no need to run the IDE program on the computer, which simplifies the debugging of the microcode. The process, and because the computer is no longer required to support the operation of the IDE program, it also reduces the requirements for the device to be debugged, thereby improving the user experience.

Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device such that they may be stored in a storage medium (ROM/RAM, diskette, optical disk) by a computing device, and in some cases The steps shown or described may be performed in an order different than that herein, or they may be separately fabricated into individual integrated circuit modules, or a plurality of the modules or steps may be implemented as a single integrated circuit module. Therefore, the invention is not limited to any particular combination of hardware and software.

The above is a further detailed description of the present invention in connection with the specific embodiments, and the specific embodiments of the present invention are not limited to the description. Modifications made in accordance with the principles of the invention are understood to fall within the scope of the invention.

Claims

A microcode debugging method, including:

When the breakpoint instruction is executed, the pre-stored debugger on the board is called;

Debugging the microcode on the board according to the debugging program.
The microcode debugging method according to claim 1, further comprising:

Receiving a debugging instruction input by a user and storing it in the first storage space;

The debugging the microcode on the board according to the debugging program includes:

Reading the debug instruction from the first storage space, and performing debugging according to the debug instruction by using the debug program.
The microcode debugging method according to claim 1, wherein the calling the pre-stored debugging program on the board further comprises: setting a breakpoint instruction at the preset position according to the breakpoint setting instruction.
The microcode debugging method according to claim 3, wherein the setting of the breakpoint instruction at the preset position according to the breakpoint setting instruction comprises: replacing the original microcode instruction at the breakpoint to be set as a breakpoint instruction and saving the The original microcode instruction.
The microcode debugging method according to any one of claims 1 to 4, wherein the manner of debugging the microcode on the board according to the debugging program comprises:

When the information storage instruction is read, the debugging information is stored in the second storage space, where the debugging information includes the register resource information of the message context and the content of the message;

or,

Modifying the debugging information when the information modification instruction is read;

or,

When the breakpoint end instruction is read, the debugging of the original microcode instruction corresponding to the current breakpoint instruction is exited.
The microcode debugging method according to claim 5, wherein said debugging information is stored After being stored in the second storage space, the method further includes: notifying the central processor to read the debugging information.
The microcode debugging method according to claim 5, wherein the debugging of the original microcode instruction corresponding to the current breakpoint instruction comprises: replacing the current breakpoint instruction with the original microcode instruction corresponding to the breakpoint instruction .
A single board includes a network processor and a memory, and the network processor includes a micro engine;

The micro engine is configured to invoke a pre-stored debugging program on the board when executing the breakpoint instruction;

The micro engine is further configured to debug the microcode on the board according to the debugging program.
The board of claim 8, further comprising a central processing unit, the central processor configured to, after receiving the debug instruction input by the user, store the debug instruction into the first storage space of the memory The microengine is further configured to read the debug instruction from the first storage space, and perform debugging according to the debug instruction by using the debugger.
The board of claim 9, wherein after the micro engine reads the information storage instruction, the debugging information is stored to the second storage space and the central processor is notified, the debugging information including the message context Register resource information and message content.
The board according to any one of claims 7 to 10, wherein the memory is a static random access memory provided on the network processor, a static random access memory disposed outside the network processor, or disposed in the Any of the dynamic random access memories other than the network processor.