目录

CPU Twin Debugging

Function Description

  • CPU debugging for operators can be preferred if you want to quickly debug code logic. Common printing and GDB debugging methods can be used to quickly locate code problems.

  • CPU debugging can be used before operator running on the NPU board, to preliminarily locate operator accuracy issues and improve the success rate of NPU board running.

CPU twin debugging generates the required binary .bin file based on your input, and then automatically compiles and runs operators. Table 1 lists the debugging items supported in this phase.

Table 1 CPU debugging functions

Function Name Function Description
Automatic accuracy comparison If golden data is configured, the tool automatically compares the accuracy of the actual debugging result with that of the golden data.
printf/PRINTF Displays scalar data, such as constants and character strings. For details, see printf/PRINTF Function.
DumpTensor Dumps tensor data. The function and artifacts are similar to those of the dump function on the NPU board. For details, see DumpTensor Function.
DumpAccChkPoint Dumps tensor data at the offset position. For details, see DumpAccChkPoint Function.
Assert Displays assertions on the screen. For details, see Assert Function.
CCE instruction stream printing This function is enabled by default. For details about the CCE instruction stream file, see Artifact Description.
GDB debugging You can use GDB to debug the operator computation precision step by step. For details, see GDB Debugging.

Procedure (CLI-based)

The key steps for performing CPU debugging using the CLI are as follows:

  1. Set up the environment and prepare the input/golden data file.

  2. Run the following command to perform CPU debugging. Only key parameters are provided. For details about other parameters, see CPU Debugging Parameters.

    ascendebug kernel --backend cpu --chip-version ${chip_version} --repo-type customize --json-file ${op_config_json_file} --core-type ${core_type} --work-dir ${work_dir}... { Other parameters}

    To view all parameters involved in CPU debugging, you can use ascendebug kernel -h or ascendebug kernel --help.

  3. View the result file. For details, see Artifact Description.

Artifact Description

The CPU debugging result is stored in the ${root}/${work_dir}/cpu directory. ${root} indicates the current operation path, ${work_dir} indicates the debugging workspace which defaults to the /debug_workspace/${op_type} directory, and ${op_type} indicates the operator name. The directory structure is as follows:

├ ${op_type} // Operator name
├── cpu
│   ├── build // Directory for storing the intermediate files generated after CPU compilation
│   │   ├── cceprint // Directory for storing the output files of the CCE instruction stream
│   │   │   └── auto_gen_add_custom_kernel_0_0_mix.cce // CCE instruction stream file
│       ├── xxx_cpu // Executable program of the operator generated after CPU compilation
│   ├── output // Directory for storing the output file and accuracy comparison result file after CPU compilation and running
│       ├── y.bin // Original data output by running
│       ├── y.txt // Accuracy comparison result file
│   ├── src // Directory for storing the temporary code files generated after CPU compilation
│       ├── CMakeLists.txt
│       ├── data_definition.txt
│       ├── add_custom_main.cpp
│       ├── add_custom_tiling.h
│       ├── _gen_kernel_${op_type}.cpp
│   ├── dump // Directory for storing dump files
│       ├── PARSER_${timestamp}
│           ├── dump_data
│               ├──0 // Core ID
│                   ├──index_1 // index is the unique identifier of the dump API description.
│                       ├──core_0_index_1_loop_0.bin
│                       ├──core_0_index_1_loop_0.txt