Pattern file compiling method, compiler and electronic equipment

Abstract

The invention relates to the technical field of compiling, in particular to a pattern file compiling method, a compiler and electronic equipment, and the compiling method comprises the following steps: decomposing a huge whole pattern file into a plurality of processing blocks according to a preset rule, and converting a single and huge compiling task into a large number of sub-tasks which can be independently processed. On the basis, the processing blocks are compiled in parallel by utilizing a multi-thread technology, so that a plurality of CPU cores can work simultaneously, and the original lengthy sequential execution time is greatly compressed. Finally, the multi-thread technology is adopted again in the link stage, all the intermediate files are organized into the final executable file in parallel, and the situation that the final synthesis stage becomes a new performance bottleneck is avoided. The whole-course parallel assembly line from compiling to linking is particularly suitable for processing large-scale Pattern files of ten millions of rows, the compiling time can be remarkably shortened, and the compiling efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of compiling, in particular to a pattern file compiling method, a compiler and an electronic device. BACKGROUND

[0002] In the field of integrated circuit (IC) testing, automatic test equipment (ATE) needs to verify the functionality, performance and reliability of chips by executing specific test programs. The core of these test programs is a file called "Pattern" (test pattern), which is essentially a sequence of logical truth tables that describe what signals should be applied to the pins of the chip at a specific point in time, and what signals are expected to be captured from the pins of the chip. Pattern files are usually written by engineers in high-level languages or specific formats, and are represented as text files containing a large amount of test vectors, control instructions (microinstructions), labels and other information.

[0003] However, the text format of the Pattern file cannot be directly executed by the ATE tester, and must be translated and linked into binary machine code that can be recognized and executed by the ATE tester through a special tool - the Pattern compiler. This process usually includes: parsing the syntax and structure of the Pattern file, extracting microinstructions, test data and labels; compiling microinstructions into corresponding machine code; converting test data into binary format; finally, linking all compiled modules to generate a complete and executable test program image.

[0004] Existing Pattern compilers usually use a serial processing method, and the compilation process can be summarized as follows: 1. Sequential parsing: the compiler reads the text format of the Pattern file line by line, performs lexical analysis and syntax analysis, and stores the parsed elements in memory. 2. Sequential compilation: after parsing, the compiler converts microinstructions into machine code and test data into binary format in the order of instructions and data in the file. 3. Final linking: all code segments and data segments obtained by compilation are integrated in order to generate the final output file.

[0005] With the exponential growth of chip design complexity, the size of Pattern file required for testing is increasingly large, often reaching the level of ten million lines or even one hundred million lines. The inherent defects of the above-mentioned serial processing mode become particularly prominent when dealing with large-scale Pattern files, and the most core technical problem is that the compilation efficiency is extremely low. Since the entire process is single-threaded and sequentially executed, only one line of data can be processed at a time, resulting in the compilation process consuming several hours or even tens of hours when dealing with massive Pattern data, which seriously slows down the process of chip testing and product listing. In addition, in the serial compilation process, the entire file needs to be completely loaded into the compilation process, which not only puts a huge pressure on the memory resources, but also makes the compilation process difficult to be interrupted or optimized in stages.

[0006] Therefore, how to break through the bottleneck of the existing serial compilation technology and significantly improve the compilation speed of large-scale Pattern files has become a key technical problem to be solved in the field. SUMMARY

[0007] The present application provides a pattern file compilation method, a compiler and an electronic device, which is used to solve the technical problem of low compilation efficiency of pattern files in the prior art.

[0008] The first aspect of the present application provides a pattern file compilation method, comprising: S1: parsing the input pin definition file and the pattern file, extracting the pin information, test vector data, label information and micro instruction information therein, and converting them into data structures in memory; S2: decomposing the parsed pattern file into a plurality of processing blocks according to a predetermined rule; S3: using multi-threading technology to compile the plurality of processing blocks in parallel, generating a plurality of intermediate files corresponding to each processing block, the intermediate files at least including a pattern data intermediate file, a label intermediate file and a micro instruction intermediate file; S4: linking the plurality of intermediate files using multi-threading technology, organizing and generating a final executable pattern file.

[0009] In the first possible implementation of the first aspect of the pattern file compilation method, S2 comprises: S21: calculating and determining the number of processing blocks according to the total size of the pattern file and the predetermined block size threshold; S22: decomposing the content of the pattern file into a plurality of corresponding processing blocks according to the determined number of processing blocks.

[0010] In conjunction with the pattern file compilation method provided in the first aspect or the first possible implementation of the pattern file compilation method in the first aspect, in the second possible implementation of the pattern file compilation method in the first aspect, the process of generating intermediate files in S3 includes: S31: Process the content of the processing block line by line, and store it into the corresponding data list according to the content type; S32: When the amount of data in any of the data lists reaches the preset row count threshold, write the data in the data list to the corresponding intermediate file and clear the data list. S33: After processing all the contents of a processing block, write the remaining data in each data list to the corresponding intermediate file.

[0011] In the third possible implementation of the pattern file compilation method in the first aspect, S4 includes: Multi-threaded parallel execution is adopted, with each linking thread responsible for linking multiple intermediate files corresponding to a processing block and jointly organizing them to generate the final executable pattern file.

[0012] In the fourth possible implementation of the pattern file compilation method in the first aspect, S1 is preceded by: S01: Calculate the hash value of the pin definition file and / or the pattern file; S02: Compare the calculated hash value with the previously saved hash value; S03: If the hash values ​​match, skip the compilation and directly use the compiled final executable pattern file. If the hash values ​​do not match, execute S1 to S4.

[0013] In conjunction with the fourth possible implementation of the pattern file compilation method in the first aspect, the fifth possible implementation of the pattern file compilation method in the first aspect, after S02 and before S1, also includes: S04: If the hash values ​​are inconsistent, delete the existing intermediate file before S1; if the hash values ​​are consistent, use the existing intermediate file directly in S4.

[0014] In the sixth possible implementation of the pattern file compilation method in the first aspect, S4 is followed by: S5: Compress the final executable pattern file.

[0015] In the seventh possible implementation of the pattern file compilation method in the first aspect, the intermediate file in S3 is managed using memory-mapped file technology.

[0016] The second aspect of the present application provides a pattern file compiler, comprising: a file parsing module, configured to parse an input pin definition file and a pattern file, extract pin information, test vector data, label information and microinstruction information therefrom, and convert the information into a data structure in memory; a block splitting module, configured to split the parsed pattern file into a plurality of processing blocks according to a preset rule; a parallel compiling module, configured to utilize a multithreading technique to compile the plurality of processing blocks in parallel, and generate a plurality of intermediate files corresponding to each processing block, the intermediate files including at least a pattern data intermediate file, a label intermediate file and a microinstruction intermediate file; a linking module, configured to utilize a multithreading technique to link the plurality of intermediate files, organize and generate a final executable pattern file.

[0017] The third aspect of the present application provides an electronic device, comprising a memory, a processor and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of any possible implementation of the pattern file compiling method provided by the first aspect.

[0018] As can be seen from the above technical solutions, the present application has the following advantages: ①The present application greatly improves the compiling efficiency by introducing a cooperative mechanism of "block splitting" and "parallelism". Firstly, step S2 splits the huge overall pattern file into a plurality of processing blocks according to a preset rule, converting a single and huge compiling task into a large number of independent subtasks. On this basis, step S3 utilizes a multithreading technique to compile these processing blocks in parallel, so that multiple CPU cores can work simultaneously, thereby greatly compressing the originally lengthy sequential execution time. Finally, step S4 again utilizes a multithreading technique in the linking stage to organize the intermediate files into a final executable file in parallel, avoiding the final synthesis stage from becoming a new performance bottleneck. This whole parallel pipeline from compiling to linking is particularly suitable for processing large-scale pattern files of the order of ten million lines, and can significantly shorten the compiling time and improve the compiling efficiency.

[0019] 2. The present application brings excellent error isolation ability naturally through its block processing architecture. After the file is decomposed into multiple independent processing blocks in step S2, the parallel compilation process in step S3 makes the compilation of each block logically isolated from each other. Therefore, when there is a syntax or data format error in a certain processing block, its impact will be strictly limited within the block, and the compiler can immediately locate the error information to the specific file block. This design completely changes the situation in the traditional process that a small error causes the entire compilation process to be interrupted and difficult to troubleshoot, so that the developer can concentrate on quickly fixing a single problem block, greatly simplifying the debugging process and improving the maintainability of the entire compilation process.

[0020] 3. While improving speed, the present application also optimizes system resource utilization and the manageability of output results. The block processing mechanism in step S2 allows the system to process the blocks one by one or in parallel without loading the entire large Pattern file into memory at once, thereby significantly reducing the peak demand for memory and avoiding compilation failures due to insufficient memory. At the same time, the parallel processing in steps S3 and S4 fully taps the computing potential of multi-core CPUs, improving overall resource utilization. Finally, the final executable Pattern file generated in step S4 has a clear internal structure that reflects the block division of the source file, forming a modular and logically clear data organization method. This structured output not only facilitates version comparison and differential upgrading, but also lays a solid foundation for subsequent test program maintenance and iterative development. BRIEF DESCRIPTION OF DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor.

[0022] Figure 1 A flowchart of a pattern file compilation method provided by an embodiment of the present application. DETAILED DESCRIPTION

[0023] The embodiments of the present application provide a pattern file compilation method, a compiler and an electronic device, which are used to solve the technical problem of low pattern file compilation efficiency in the prior art.

[0024] In order to make the objectives, characteristics and advantages of the present application more obvious and easy to understand, the technical solutions in the embodiments of the present application will be clearly and completely described below in combination with the drawings in the embodiments of the present application. Obviously, the following described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0025] In the description of the embodiments of the present application, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer" and the like indicate the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the embodiments of the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation on the embodiments of the present application. In addition, the terms "first", "second", "third" are only for the purpose of description, and cannot be understood as indicating or implying relative importance.

[0026] In the description of the embodiments of the present application, it should be noted that unless otherwise explicitly specified and limited, the terms "mounting", "connecting", "connecting" should be understood in a broad sense, for example, it can be fixedly connected, or it can be replaceably connected, or it can be integrally connected, it can be mechanically connected, or it can be electrically connected, it can be directly connected, or it can be indirectly connected through an intermediate medium, it can be the communication inside two elements. For those skilled in the art, the specific meaning of the above terms in the embodiments of the present application can be understood according to the specific circumstances.

[0027] In the prior art, the entire process is single-threaded and sequentially executed, and only one row of data can be processed each time, resulting in a compilation process consuming several hours or even tens of hours when processing massive Pattern data, and the compilation efficiency is extremely low. Embodiments

[0028] Please refer to Figure 1 The pattern file compilation method provided by the embodiments of the present application comprises: S1: parsing the input pin definition file and pattern file, extracting pin information, test vector data, label information and microinstruction information therein, and converting them into data structures in memory; The step is the data preparation stage of the compilation process, and the core purpose is to convert human-readable text format source files into structured memory data objects that can be efficiently processed and operated by computer programs. It provides a unified and standardized data foundation for all subsequent automated processing processes. Specifically, the process of parsing the pin definition file is to read and interpret the file that defines the mapping relationship between the chip pins (Pin) and the test machine channels. The output is a data structure containing all pin attributes (such as name, type, number) and their grouping (PinGroup) information, which is the basis for mapping logical test vectors to physical channels. The process of parsing the Pattern file is to analyze the Pattern source file line by line, identify and extract three core elements: test vector data: the specific value sequence of drive (Drive) and compare (Compare), which is the core data of testing chip function. Label: used to mark a specific position in the Pattern, to realize the jump and loop control of the test process. Microinstruction: used to control the advanced commands of the test machine hardware, such as setting timing, trigger condition, etc. Through a series of parsers, loose text information is converted into accurate, semantic structured data models, laying a data foundation for subsequent automation and parallel processing. For example: the parser encounters a line of text "PIN A1, B2;", which identifies that it is defining a pin group and creates the corresponding PinGroup object. When it encounters "Label: START_LOOP;", it creates a Label object to record its name and line number. For a line of test vector "W 1 0 H L;", the parser will decompose it into microinstructions "W" and corresponding data bits "1", "0", "H", "L" according to the pre-defined format, and store them respectively.

[0029] S2: decompose the parsed pattern file into multiple processing blocks according to a preset rule; The step aims to "divide the whole into parts" for large-scale data processing tasks, which is the key prerequisite for efficient parallel computing. By dividing the complete Pattern file into multiple smaller, independent processing units, the speed bottleneck of single-thread sequential processing can be effectively overcome, and conditions for fully utilizing multi-core CPU computing resources are created. Specifically, the preset rules followed by the division are the core to ensure the effectiveness of the division. A typical preset rule is based on a fixed number of lines, that is, each processing block contains the same number of Pattern lines. Another optional preset rule is based on a fixed data size, that is, according to the estimated data size to divide, to ensure that the load of each block is relatively balanced. Each processing block is a logically self-contained data segment, containing a continuous segment of Pattern lines and their related labels and micro-instructions. The division of processing blocks should ensure the independence of blocks as much as possible to reduce the communication and synchronization overhead in subsequent parallel execution. By breaking the traditional single-thread processing mode of large files, the problem is converted from the serial field to the parallel field, which provides structural possibilities for significantly improving the compilation speed. For example: assuming that a Pattern file has 1 million rows of data, and each processing block is set to 100,000 rows. Then, step S2 will divide this large file into 10 processing blocks (Block 1 to Block 10). Each block contains all Pattern data from the starting line number to the ending line number, labels within this range, and micro-instructions.

[0030] The specific implementation of the block operation has uncertainty and randomness, which may lead to different parallel effects in different implementations. For example, if the block size is out of control, it may produce too many fragmented tasks to increase thread scheduling overhead, or too few large tasks to fully utilize multi-core resources, ultimately resulting in low parallel speedup ratio and failing to achieve the purpose of improving compilation efficiency. In order to avoid this problem, S2 is optimized as: S21: According to the total size of the pattern file and the preset block size threshold, the number of processing blocks is calculated and determined; The core of this sub-step is to materialize the "preset rule" of chunking into an executable algorithm. It takes two input parameters, the objective "total file size" and the subjective "chunk size threshold", and outputs a definite number of processing chunks through a determined mathematical calculation. Specifically, the total size preferably refers to the total number of rows in the Pattern file, as rows are the basic unit of work for compilation processing. The chunk size threshold is an adjustable system parameter that defines the upper limit of the amount of data contained in a single processing chunk. Its setting needs to strike a balance between parallel efficiency (the chunk is small enough to generate enough parallel tasks) and thread management overhead (the chunk cannot be too small to avoid excessive overhead). A typical calculation method is chunk number = ceil(total file size / chunk size threshold). This calculation ensures that all data is covered, and the size of each chunk (except the last one) is effectively constrained within the threshold. S21 solves the problem of "how many chunks" by parameterized configuration, making the chunking strategy adaptable to different sizes of files and processing environments.

[0031] S22: According to the determined number of processing chunks, the content of the pattern file is divided into a corresponding plurality of processing chunks.

[0032] This sub-step is the physical implementation of the chunking strategy, which guides the cutting of the complete file data stream into discrete processing units according to the number calculated by S21. Specifically, according to the determined number of processing chunks, the decomposition operation is strictly controlled by the calculation result of the previous step, ensuring the consistency of the strategy. Decomposition refers to the sequential and non-overlapping division of the continuous data sequence of the source file into multiple logical containers, each container being a processing chunk. S22 solves the problem of "how to divide" and ensures the accurate physical implementation of the calculation result.

[0033] Implementation: Method one: fixed row number chunking. In this way, "total file size" is the total number of rows, and "chunk size threshold" is the maximum number of rows allowed per chunk. After S21 calculates the number of chunks N, S22 executes and allocates the first N-1 chunks to the maximum number of rows specified by the threshold, and the last chunk contains all the remaining rows. This method is simple and efficient in calculation, and is the preferred solution to ensure high load balancing. Method two: fixed data volume chunking. In this way, "total file size" is the number of bytes of the file, and "chunk size threshold" is the maximum number of bytes allowed per chunk. S21 calculates the number of chunks based on these two byte parameters. S22 executes the file cutting by byte offset. This method is suitable for scenarios where the row length of the file varies greatly, and can more accurately control the volume of each chunk at the storage level. It should be noted that since the cutting point may fall in the middle of a row, a row boundary correction mechanism needs to be implemented to ensure that each processing chunk starts from the beginning of a row and ends at the end of a row, maintaining the integrity of the data.

[0034] For example, a Pattern file named memory_test.pat has a total of 1,050,000 lines. The system preset block size threshold is 100,000 lines. The calculation process is: block number = ceil(1,050,000 / 100,000) = ceil(10.5) = 11. S21 is executed: the system will create 11 processing blocks. Among them, Block 1 to Block 10 each contain exactly 100,000 lines of data. Block 11 contains the remaining 50,000 lines of data.

[0035] By introducing the two specific and cooperative sub-steps of "calculating the number" and "performing decomposition", an explicit and optimal implementation path is provided for the block processing, the key technical problem of how to scientifically and effectively divide the tasks before parallel compilation is solved, load balancing is ensured, resource idling or contention is avoided, the block operation has predictability and configurability, thereby the granularity of parallel processing is accurately controlled, and then the parallel compilation method can be reliably and efficiently implemented.

[0036] S3: using multi-threading technology, the plurality of processing blocks are compiled in parallel to generate a plurality of intermediate files corresponding to each processing block, the intermediate files at least including a pattern data intermediate file, a label intermediate file and a micro-instruction intermediate file; This step is the core execution phase to improve the efficiency of compilation. It converts the computing power of multi-core processors into actual compilation speed improvement by compiling multiple processing blocks generated in S2 into target intermediate files simultaneously through concurrent execution. Specifically, the thread of the operating system or runtime environment is the basic unit of scheduling. Here, an independent compilation thread is created for each processing block or for several processing blocks, and these threads can be scheduled by the operating system to different CPU cores to run truly simultaneously. "Compiling" here refers to converting the high-level information in each processing block (such as test vectors, labels, microinstructions) into a lower-level, more machine-executable binary or specific encoding format. For example, converting microinstruction mnemonics into machine code and converting test data into a compact binary stream. The intermediate file is the direct output of parallel processing, generating a set of intermediate files (such as data files, label files, instruction files) for each processing block, achieving physical separation of the compilation results and enabling flexible organization of the subsequent linking step. This design also facilitates caching and incremental compilation. For example, based on the example in S2, the system creates 10 compilation threads (Thread 1 to Thread 10). Thread 1 is responsible for compiling Block 1, converting the Pattern data, labels, and microinstructions in it into block1_data.bin, block1_label.idx, and block1_instruction.cmd, respectively. Other threads perform similar compilation work on their respective blocks simultaneously.

[0037] Generating intermediate files may use a simple strategy of "processing one line and writing one line", which can result in extremely frequent disk I / O operations, becoming a major performance bottleneck for the system; or it may use a strategy of "assembling all data in memory and then writing it all at once", which can occupy a large amount of memory when processing large blocks of data, posing a risk of overflow. To avoid this risk, the process of generating intermediate files is optimized as follows: S31: Process the content of the processing block line by line, and store it in the corresponding data list according to the content type; This step is the core of data shunting. The compiler needs to identify the type of each line of content (such as Pattern data, Label, Instruction) and temporarily store it in the corresponding memory data list. This classified storage lays the foundation for generating different types of intermediate files. The data list is a buffer area opened in memory for temporarily gathering data lines of the same type. Its role is to integrate fragmented write requests and prepare for subsequent batch writing.

[0038] S32: When the amount of data in any of the data lists reaches a preset row threshold, write the data in the data list to the corresponding intermediate file and clear the data list; This step is the key of performance optimization. It sets a condition (row threshold) to trigger batched write, thus avoiding performing disk I / O operation for each row. Specifically, the row threshold is a configurable parameter (e.g. 1000 rows), whose value needs to be set by balancing memory occupation and I / O frequency: too small threshold, the buffer effect is not good; too large threshold, the memory occupation is too high. When any data list reaches the threshold, a batched append write operation to the intermediate file of this type is triggered. After the write is completed, the list in memory is emptied immediately to receive new data, thus recycling memory space.

[0039] S33: After processing all the contents of a processing block, write the remaining data in each data list to the corresponding intermediate file.

[0040] This step is the finishing operation to ensure data integrity. After all the contents of a processing block are processed, there may still be data in each data list that does not reach the threshold. This step is responsible for writing these "residual" data to disk, ensuring that all information of the processing block is completely persisted to the intermediate file.

[0041] This optimization optimizes the generation process of intermediate files from a simple "row-by-row direct write" to a controlled, batched pipeline. S31 is responsible for data classification and buffering, S32 implements efficient batched I / O through threshold mechanism, and S33 ensures data integrity. These three sub-steps together constitute an efficient and reliable memory-disk data exchange strategy, which greatly reduces I / O overhead and improves compilation speed through buffering and batched write mechanism; at the same time, by setting the write threshold, it effectively controls the memory occupation peak, avoids memory overflow, effectively balances memory consumption and I / O efficiency, and guarantees the stability and reliability of the system under large data processing.

[0042] Implementations can include: Mode 1: Parallel list management based on data type, in which the system maintains three core data lists for each processing block independently: patternDataList, labelList, instructionList. In S31, each line of data parsed is appended to the corresponding list according to its type. In S32, the three lists independently check their own length, and any list reaching the row threshold (e.g. 1000 rows) will independently trigger the write and empty operation of its own data. This mode has clear logic, and the types of data do not affect each other. Mode 2: Unified queue and distributor-based working mode, in which a unified producer-consumer model is used in S31. A parsing thread acts as a producer, placing data rows with type markers into a unified blocking queue. Multiple consumer threads (or background write services) take data from the queue and distribute it to different memory lists according to the type marker, while also being responsible for checking and triggering the write condition of S32. This mode can decouple parsing and writing when I / O is the bottleneck, further improving throughput.

[0043] Example: Suppose a processing block has 5,850 rows of content, of which 5,000 rows are Pattern data, 500 rows are Label, and 350 rows are Instruction. The preset row threshold is 1000 rows. Execute S31 and S32: Pattern data: when the 1000th row of Pattern data is processed, patternDataList reaches the threshold, triggering a batch write to the blockX_data.bin file, and then the list is emptied. This process will be repeated at the 2000th, 3000th, 4000th rows. When the 5000th row is processed, there are 1000 rows of data in the list, triggering a write again. Label: when the 1000th row of total data is processed, labelList may have accumulated 200 Label, which does not reach the threshold, and does not trigger a write. Until all the contents of the block are processed, there are 500 Label in labelList. Instruction: During processing, instructionList always does not reach the 1000 row threshold. Execute S33: After processing all 5850 rows of the block, the system checks the lists. It is found that patternDataList has been emptied; labelList has 500 rows of data, which are all written to blockX_label.idx; instructionList has 350 rows of data, which are all written to blockX_instruction.cmd.

[0044] Under the traditional file management mode, the frequent writing and reading of mass intermediate files will generate huge I / O pressure, resulting in a large amount of CPU time in an idle state waiting for I / O completion, which makes the computing efficiency improved by parallel compilation be offset by the delay of disk I / O. Especially in the scene of processing ten million level Pattern files, the I / O bottleneck effect is particularly significant. In order to solve this problem, the file technology of the optimization scheme is used to manage the intermediate files. Specifically, the memory mapping file technology is a high-level I / O mechanism provided by the operating system. It allows the application to directly map a file or part of a file to the virtual address space of the process. Thereafter, the application can read and write file content by accessing memory pointers without calling traditional read or write I / O functions. The management covers the whole life cycle operations of the intermediate files, including creation, writing, reading and deletion. Using the memory mapping file technology means that these operations will be completed through memory addressing and operation. By introducing the memory mapping file technology, the disk read and write operations on the intermediate files are converted into direct memory access operations, so that the data exchange between the parallel compilation threads and the intermediate files is transferred from the low-speed disk I / O subsystem to the high-speed memory bus, greatly alleviating the I / O bottleneck, making the performance of generating and reading a large number of intermediate files close to the speed of directly operating memory, ensuring that the parallel computing resources will not be dragged down by low-speed I / O, and making the generation and consumption speed of the intermediate files match the speed of multi-thread parallel computing.

[0045] The implementation modes are as follows: mode one: hybrid management based on read-only and read-write mapping, under this mode, for the generated intermediate files (such as written by the compiler thread in S3), the memory mapping in read-write mode is adopted. The compiler thread directly writes data into the mapped memory area, and the operating system is responsible for writing these dirty pages back to the disk asynchronously in the background. For the intermediate files that need to be read (such as read by the linking thread in S4), the memory mapping in read-only mode is adopted. Multiple linking threads can safely share the read-only mapping of the same file, efficiently reading data without loading file data into the user space buffer. Mode two: dynamic management based on segmented mapping, when a single intermediate file is very large, it may not be realistic to map it all to memory. Under this mode, the system only maps the part of the file that needs to be accessed (for example, the segment that a data list is about to write or the data block that a linking thread needs to read) to memory. After processing the paragraph, the current mapping is released and the next required paragraph is mapped. This way realizes the "on-demand" memory mapping of super large files, effectively controlling the peak of memory occupation while maintaining high performance.

[0046] Example: In S3 stage, a compiling thread needs to write a compiled block of 500,000 lines of Pattern data into the intermediate file block5_data.bin. Traditional way: the thread needs to repeatedly call functions like fwrite, each call potentially involving context switch between user mode and kernel mode, and multiple copies of data from user buffer to system page cache and then to disk. Our way: the system creates a read-write memory mapping of a specified size for the file block5_data.bin, and returns a pointer ptr pointing to the memory region. The compiling thread directly copies the compiled binary data into the memory region pointed by ptr in order, and moves the pointer offset. This process is no different from manipulating a normal memory array, and is extremely efficient. The OS transparently writes the content in the memory mapping to the disk file block5_data.bin at appropriate time (e.g. when a memory page is full or the system flushes). In S4 stage, a linking thread can create a read-only memory mapping of block5_data.bin, and then directly traverse all the data in the file through memory pointers, and perform linking operation, again avoiding explicit file read calls.

[0047] S4: Use multi-threading technique to link the multiple intermediate files, organize and generate the final executable pattern file.

[0048] This step is the final stage of the compilation process, responsible for integrating the scattered intermediate results into a unified, ordered, and executable whole. It also employs parallel techniques to ensure that the synthesis of the final file does not become a performance bottleneck for the system. Specifically, the linking operation includes address resolution and data merging. Address resolution refers to determining the absolute address of each label (Label) in the final file. Data merging is to splice the contents of each intermediate file in the correct logical order. Organization and generation refer to building the format and structure of the final file. The final file usually contains a file header (describing the overall layout, the starting address of each block, etc.) and subsequent continuous data blocks. The linker needs to be responsible for building this complete file image. In this phase, multi-threading can be used to perform multiple "write" operations on blocks in parallel. For example, one thread can write a linked data block to the specified offset position of the final file, while another thread can prepare and write the next data block at the same time. For example: the linker first allocates the global address space, for example, determines the starting address of Block 1 as 0, the starting address of Block 2 as the size of Block 1, and so on. Then, multiple linking threads start working: Thread A is responsible for writing the contents of block1_data.bin to the final file at address 0 offset, and correcting all the labels in Block 1; at the same time, Thread B is responsible for writing block2_data.bin to the next address offset, and correcting the labels in Block 2. After all threads are completed, the linker writes the file header, and finally generates a complete final_pattern.exe file.

[0049] In the absence of specific limitation on the linking step, there is a risk of using single-thread for linking. For a large-scale compilation task consisting of tens or even hundreds of processing blocks, single-thread linking requires sequential processing of all data, which can completely offset or even exceed the time saved by parallel compilation, thus becoming the performance bottleneck of the entire system, greatly reducing the parallel advantage. Therefore, S4 is optimized as follows: multi-thread parallel execution is adopted, and each linking thread is responsible for linking multiple intermediate files corresponding to one of the processing blocks, and jointly organizing the generation of the final executable pattern file. By distributing the linking task to multiple threads for parallel execution, it is ensured that in large-scale pattern file compilation, the entire process from parsing, compilation to linking can obtain significant acceleration effect, avoiding the efficiency bottleneck of "parallel compilation and serial linking". Specifically, the use of multi-thread parallel execution of this feature indicates the execution architecture of the linking operation. It means that the system will create multiple worker threads in the linking phase, which can be scheduled by the operating system to different CPU cores to run simultaneously, thus converting the serial processing of linking tasks in time into parallel processing in space. Each linking thread is responsible for a processing block, and this feature defines the task allocation strategy. The linking task is divided according to the processing block generated by S2 step, and each thread is assigned one or more complete processing blocks, responsible for the linking of all related intermediate files of the block. This "block-level" task division is consistent with the compilation phase, achieving the unity of data processing granularity and simplifying system design. For a single thread, linking includes reading all intermediate files (data, labels, instructions) corresponding to the processing block it is responsible for, compiling micro-instructions into final machine code, and resolving the global address of labels in the final file. Jointly organizing the generation: refers to the cooperation of multiple linking threads to build the same final executable pattern file. This requires the system to predefine the global layout of the final file (for example, the starting offset address of each processing block in the file), and each thread writes the linking result to the predetermined position of the final file after completing the linking of its own block. After all threads are completed, the complete executable file is assembled. In this way, a "task decomposition-parallel linking-collaborative writing" executable solution is formed. It ensures that the performance of the linking phase can match the compilation phase, making the parallelization of the entire compilation process complete and complete. Through fine task division and global address space management, multiple threads can efficiently and conflict-freely complete the synthesis of a complex file together.

[0050] Implementations include: Mode 1: Parallel write with pre-allocated address space, in which the master thread first calculates the exact start address and length of each block in the final executable file according to the sizes of the compiled intermediate files of the blocks, and creates a file header to record this information. Subsequently, each linking thread independently writes the linking result of the processing block it is responsible for directly to the specified offset position in the final file according to the global address mapping table. This mode is efficient and does not require frequent communication between threads, but requires accurate address planning in advance. Mode 2: Dynamic write management based on a queue, in which the system maintains a queue of tasks to be written. After each linking thread completes the linking of a processing block, it puts the linking result data packet (containing data and its target address) of the block into the queue. One or more dedicated write threads take data packets from the queue and write them in order to the final file. This mode further decouples linking calculation from file I / O, can effectively smooth the I / O jitter caused by differences in linking speeds of different blocks, is particularly effective when I / O is the bottleneck, and reduces the management complexity of parallel write files.

[0051] Example: Assume that there are 3 processing blocks (Block1, Block2, Block3) to be linked, and 3 linking threads (Thread1, Thread2, Thread3) are enabled. Execution process (using Mode 1): The master thread calculates the global layout: the start address of Block1 is 0, the start address of Block2 is the size of Block1, and the start address of Block3 is the size of Block1+Block2. Thread1 is responsible for Block1: it reads block1_data.bin, block1_label.idx, block1_instruction.cmd, performs linking calculation, and then writes the final data to the area starting at address 0 in the final file. Thread2 is responsible for Block2: similarly, it links the intermediate files of Block2, and then writes the data to the address area allocated in advance for Block2 in the final file. Thread3 is responsible for Block3: performs similar operations. After all threads are completed, the master thread writes the file header containing the address information of each block to the start position of the file, and finally generates a complete executable file.

[0052] The beneficial effects of the embodiment include: ① The present application greatly improves the compiling efficiency by introducing the cooperative mechanism of "block" and "parallel". Firstly, the huge whole Pattern file is decomposed into multiple processing blocks according to preset rules in step S2, and a single and huge compiling task is converted into a large number of independent subtasks. On this basis, the multiple thread technology is used to compile the processing blocks in parallel in step S3, so that multiple CPU cores can work at the same time, thereby greatly compressing the originally long sequential execution time. Finally, the multi-thread technology is used again in step S4 to organize the intermediate files into the final executable file in parallel, avoiding the final synthesis stage from becoming a new performance bottleneck. This whole parallel pipeline from compiling to linking is particularly suitable for processing large-scale Pattern files of tens of millions of lines, and can significantly shorten the compiling time and improve the compiling efficiency.

[0053] ② The present application naturally brings excellent error isolation capability through the block processing architecture. After the file is decomposed into multiple independent processing blocks in step S2, the parallel compiling process in step S3 makes the compilation of each block logically isolated from each other. Therefore, when there is a syntax or data format error in a processing block, its influence will be strictly limited within the block, and the compiler can immediately locate the error information to the specific file block. This design completely changes the situation in the traditional process that a small error causes the entire compiling process to be interrupted and difficult to troubleshoot, so that the developer can concentrate on quickly repairing a single problem block, greatly simplifying the debugging process and improving the maintainability of the entire compiling process.

[0054] ③ The present application not only improves the speed, but also optimizes the system resource utilization and the management of output results. The block processing mechanism in step S2 makes the system not need to load the entire huge Pattern file into the memory at one time, but can process it in blocks in sequence or in parallel, thereby significantly reducing the peak demand for memory and avoiding the compiling failure caused by insufficient memory. At the same time, the parallel processing in steps S3 and S4 fully taps the computing potential of multi-core CPU and improves the overall resource utilization. Finally, the final executable Pattern file generated in step S4 has a clear internal structure reflecting the block division of the source file, forming a modular and logically clear data organization method. This structured output not only facilitates version comparison and differential upgrading, but also lays a solid foundation for subsequent test program maintenance and iterative development.

[0055] In the chip test development, engineers may only modify one of the many test items, or repeatedly fine-tune the Pattern during debugging. In the solution provided above, any minor modification will trigger the full recompilation of the entire test item. When the size of the Pattern file is huge, waiting for the compilation each time will consume a lot of valuable time and seriously slow down the development and debugging efficiency. To solve this problem, the following steps are added before S1: S01: Calculate the hash value of the pin definition file and / or the pattern file; This step is the data basis for incremental judgment. Its core is to use a hash function to generate a unique high number summary (hash value) for the input file. The calculation object can be the pin definition file, the Pattern file, or both. The preferred solution is to calculate the hash value of both, and any change in either file will trigger recompilation, ensuring the correctness of the output. Hash algorithm: MD5, SHA-1, or SHA-256 encryption hash function can be selected. These algorithms can reflect any minor changes in the file as a significant difference in the hash value, so that changes can be reliably detected.

[0056] S02: Compare the calculated hash value with the previously saved hash value; This step is the core of the decision logic. It compares the new hash value calculated with the historical record (such as the hash value saved at the last successful compilation). The previously saved hash value: a persistent storage mechanism is needed to record the value, for example, store it in a local configuration file, database, or metadata file associated with the final executable pattern file.

[0057] S03: If the hash values are consistent, skip the compilation and directly use the compiled final executable pattern file. If the hash values are not consistent, perform S1 to S4.

[0058] This step directs the direction of the entire compilation process according to the comparison result. If consistent: it indicates that the source file has not been modified since the last compilation, so there is no need to perform the time-consuming and laborious S1 to S4 complete compilation process, and the existing executable pattern file is directly reused as the output of this operation. If inconsistent: it indicates that the source file has been modified and the complete compilation process from S1 to S4 must be performed to generate a new executable file that matches the current source file.

[0059] The idea of version control is integrated into the compilation process, and an efficient "compilation cache" system is built through the three steps S01 to S03. It replaces the potential heavy compilation process with a lightweight hash calculation and comparison, optimizing the compilation behavior from "must be performed every time" to "only when necessary". That is, by adding a pre-decision step before the core compilation process, an intelligent incremental compilation mechanism is introduced, which identifies content changes by checking the digital fingerprint of the input file, intelligently identifies the real target that needs to be compiled, concentrates computing resources on processing the part that has actually changed, and avoids repeated compilation of unmodified files. This greatly saves computing resources, improves development efficiency, shortens the overall engineering processing time, and improves the response speed of the development and test process. For chip test development links that need frequent iteration and debugging, it can bring significant efficiency improvement.

[0060] Implementation methods include: Method 1: Implementation based on local hash record file. In this method, after a successful compilation, the system writes the hash value of the input file this time into a specific file (such as.build_checksum) under the project directory. At the next compilation start (S01), the system reads the source file and calculates the new hash value, and reads the old hash value from the record file (S02) for comparison. This method is simple to implement and does not depend on version control systems (such as Git), making it suitable for single-machine development environments. Method 2: Implementation integrated with version control system. In this method, the system binds the hash value with the commit (Commit) information of the version control system. For example, the Git commit ID (Commit Hash) corresponding to the last successful compilation of the source code is used as the "previously saved hash value". In S02, the system compares the commit ID of the current working area with the recorded commit ID. If they are consistent, skip the compilation. This method is particularly effective in team development environments, ensuring that all developers use the correct compiled files based on the same code version.

[0061] For example, a test item named cpu_core_test is being debugged, which contains two source files pin.def and test.pat. The first compilation: the system performs a complete compilation (S1-S4). After successful compilation, the MD5 value of pin.def is "a1b2c3", and the MD5 value of test.pat is "d4e5f6", and these two values are recorded in the cpu_core_test.checksum file. The second compilation (without modifying the source file): after the system starts, S01 is executed first, and the MD5 values of the current pin.def and test.pat are calculated, which are still "a1b2c3" and "d4e5f6". S02 is executed to compare with the record in cpu_core_test.checksum, and the result is consistent. S03 is executed to skip S1-S4 and directly output the executable file generated last time. The whole process can be completed within seconds. The third compilation (test.pat is modified): S01 calculates the new MD5 value of test.pat as "x7y8z9". S02 finds that it is inconsistent with the recorded value "d4e5f6". S03 triggers the complete compilation process (S1-S4). After successful compilation, the cpu_core_test.checksum file is updated with the new hash value.

[0062] The introduction of S01-S03 solves the problem of whether to recompile, but does not involve the state management of intermediate files. Therefore, when the source file is changed, the residual old intermediate file may be accidentally mixed into the new linking process, resulting in the generation of an error executable file, and the error is hidden and difficult to find. Conversely, if there is no reuse mechanism, even if the source file is not changed, S3 still needs to regenerate all intermediate files, which cannot maximize efficiency improvement. To avoid this problem, after S02 and before S1, step S04 is added: if the hash values are inconsistent, delete the existing intermediate files before S1; if the hash values are consistent, directly use the existing intermediate files in S4. Specifically, when the hash values are inconsistent, the existing intermediate files are deleted, because when the source file is detected to be changed, it means that the old intermediate file is outdated and does not match the new source file. This operation is to clean the workspace and provide a clean environment for the new compilation process. The deletion object refers to deleting all intermediate files (such as *.bin, *.idx, *.cmd, etc.) generated by the last or historical compilation related to the current processing. It is executed before S1 (file parsing) starts, to ensure that the subsequent process will not misread the wrong cache file. When the hash values are consistent, the existing intermediate files are directly used in S4, because when it is confirmed that the source file has not been changed, not only the compilation is skipped, but also the intermediate file generation step of the linking stage is skipped, and all existing intermediate files are directly reused for linking. Direct use: means that the input of the linking module (S4) is no longer the real-time output of the parallel compilation module (S3), but directly reads the intermediate files generated and retained previously from the disk. This saves the calculation and I / O overhead of the entire S3 step. By extending "skipping compilation" from only reusing the final output file to reusing all intermediate outputs, the consistency of the compilation environment is ensured, and the linking error or data pollution caused by the residual of old intermediate files is prevented, while maximizing the advantages of incremental compilation, skipping the compilation and linking stages when the file is not changed, further improving the efficiency. This not only improves the efficiency by avoiding repeated calculation, but also ensures the absolute correctness of the compilation process by actively cleaning. It makes the entire incremental compilation system more efficient.

[0063] The implementation modes include: Mode 1: cleaning and reuse based on fixed directory, in which all intermediate files are stored in a specific working directory (for example,. / transfer / ) at the time of compilation. When it is necessary to delete (the hash values are inconsistent), all files in the directory or files meeting a specific naming pattern are directly deleted. When it is necessary to reuse (the hash values are consistent), the linking module (S4) directly searches for the required intermediate files from the directory. Mode 2: intermediate file management based on version marking, in which the system takes the "previously saved hash value" as the version label, and the intermediate file is renamed or stored in a subdirectory named according to the version label (for example,. / transfer / a1b2c3_d4e5f6 / ) after being generated. When the hash values are inconsistent, the system only needs to delete the entire directory corresponding to the old version label. When the hash values are consistent, the linker directly points to the directory of the specific version to obtain the intermediate file. This mode can retain multiple historical versions of intermediate files and has more refined management, but requires more disk space.

[0064] For example: the project projX has a source file hash value record of "old_hash", and the corresponding intermediate file exists in the. / transfer / old_hash / directory. Scenario 1 (the source file is modified): S01 / S02: calculate the current hash value as "new_hash", which is inconsistent with "old_hash".

[0065] S04: the system performs a deletion operation to empty the. / transfer / old_hash / directory. S03: trigger complete compilation S1-S4. The new intermediate file is written to the. / transfer / new_hash / directory. Scenario 2 (the source file is not modified): S01 / S02: calculate the current hash value as "old_hash", which is consistent with the record.

[0066] S04: the system does not perform any deletion operation, and records that the intermediate file in the. / transfer / old_hash / directory will be used at the S4 stage. S03: skip S1 to S3. S4: the linking module directly reads the intermediate file from the. / transfer / old_hash / directory to organize and generate the final executable pattern file.

[0067] With the increasing complexity of chip testing, the corresponding executable Pattern file volume can reach several GB or even tens of GB. Such a huge file will quickly fill the hard disk space of the test machine control computer, and when transmitted between the engineer station and the test machine through the local area network, it will consume a lot of time and network bandwidth, becoming an efficiency bottleneck in the test process. In order to solve this problem, step S5 is added after step S4: the final executable pattern file is data compressed. Specifically, the operation object of this step is the final executable Pattern file generated after the S4 linking process. This file usually contains all test vectors, microinstruction machine code and label address information, has a regular structure, low redundancy, and is very suitable for data compression. Compression: refers to applying one or more data compression algorithms to encode the input file to generate an output file with smaller volume. This process is lossless, ensuring that the decompressed data is exactly the same as the original file to ensure the accuracy of the test. Most compression algorithms allow trade-offs between compression speed and compression rate. Fast compression (short time-consuming, lower compression rate) or maximum compression (long time-consuming, higher compression rate) can be selected according to actual needs. Adding a data compression step at the end of the compilation process seamlessly integrates data compression into the automated compilation process, continuously producing volume-optimized test program files without human intervention, ensuring that the final output is in the optimal storage state when generated. This step extends the compiler's function from simply "code generation" to "resource optimization", improving the completeness of the entire tool chain, not directly reducing hardware storage costs, and speeding up the deployment and update cycle of the test program.

[0068] Implementation methods include: Method one: overall compression using ZIP format, using a standard ZIP compression library to compress the finally generated executable Pattern file (such as final_pattern.bin) into a ZIP file (such as final_pattern.zip) as a single entry. This method is highly versatile, and the generated compressed file can be opened by various decompression tools, making it easy to exchange and use. In addition, as mentioned, a password can be set for the ZIP file to increase data security. Method two: using a special compression algorithm optimized for test data, which aims to achieve higher compression efficiency. Since the data in the Pattern file (such as continuous 0 / 1 sequences, repeated microinstruction operation codes) has a specific pattern, faster algorithms such as LZ4, Zstandard, or custom compressors based on dictionary encoding can be used. These algorithms may have better performance in compression speed and rate for binary test data, especially suitable for scenarios that require fast compression / decompression.

[0069] Example: A large Pattern file for memory test, the final executable file mem test final.bin generated after S4 linking is 2.1 GB in size. Perform S5 (using method 1): system call ZIP compression module, compress mem test final.bin. Compression level is set to "standard". After the compression process is completed, the mem test final.zip file is generated. Result: After compression, the size of the mem test final.zip file is reduced to 650 MB. The storage space is saved by about 70%. When the test program needs to be distributed to multiple test workshops or archived, the efficiency of transmission and storage is significantly improved.

[0070] Without automatic verification, the compiler may only generate a general "compilation failed" signal, or worse, generate an executable file containing implicit errors, which may cause expensive misjudgments in chip testing. Engineers need to rely on subsequent simulation or measurement to find functional abnormalities, and then go back to manually check the code, which is extremely inefficient. To solve this problem, the present scheme adds an automatic verification step in S3: while compiling the processing block, automatically check for syntax errors and data type errors, and provide error prompt information. Specifically, this step is synchronized with the compilation process of S3 and is an embedded quality inspection link in the compilation pipeline. It does not interrupt the main process, but checks the data being processed in parallel. Syntax error: check if the structure of the Pattern source code conforms to the predefined syntax specification. For example, check if the microinstruction format is correct, the number of operands is matched, the label definition is unique, etc. Data type error: check the legality and context matching of data values. For example, check if the operand of an instruction that requires a number is a non-numeric character; check if the signal value (such as H, L, Z) is allowed to be used in the current context. When an error is detected, the system generates a structured error report, which at least includes: error type, source file name, exact line number, error code snippet, and readable error description. This provides clear repair guidance for users. The automatic verification mechanism is integrated in the parallel compilation step, and when each compilation thread processes its own processing block, it completes the verification in real time and on site, advancing the error detection time from "manual inspection after compilation" to "real-time discovery during compilation", automating and real-time the originally time-consuming and laborious manual quality inspection, verifying immediately while generating data, and since the error is limited to a specific processing block, it can quickly locate and report defects in the source code, preventing error propagation to subsequent processes, thereby greatly improving the efficiency of development and debugging and the reliability of the compilation result.

[0071] The implementation modes include: mode one: instant checking based on a rule engine, in which mode, a rule base is built in the system, in which various syntax and data type constraint conditions are defined. After parsing each line (or each syntax unit), the compiling thread immediately sends the data of the unit to the rule engine for matching and checking. Once any violation rule is triggered, the error is immediately recorded. This mode is flexible and configurable, and is convenient for extending new checking rules. Mode two: stream checking based on a finite state machine, which is particularly suitable for checking syntax structures with strong sequential dependence. In the process of generating intermediate code for each line, the internal parser of the compiler itself is a state machine. Checking logic can be embedded in the key nodes of the state machine, and an error is thrown when the state transition fails or illegal input is encountered. This mode is closely combined with the compiling process, and the checking efficiency is high.

[0072] For example, a compiling thread is compiling a certain processing block, and the current processing line content is: MOVR R1, 1.5.3 (the intention is to move the value 1.5 to the register R1, but the number format is incorrect). The execution process is as follows: the thread parses the line and identifies the micro-instruction MOVR and the operand R1, 1.5.3. The automatic checking step is triggered: syntax checking: passed (the number of instructions and operands is correct). Data type checking: the number format of the second operand 1.5.3 is checked, and it is found that it does not conform to the format specification of an integer or a floating-point number. Error prompt information is generated: the thread immediately generates an error object, and the content is as follows: error type: data type error; file: function_test.pat; line number: 10527; code segment: MOVR R1, 1.5.3; description: the format of the operand '1.5.3' is incorrect, and an effective number is expected.

[0073] The error information is output to the error list or log of the compiler, and generally causes the compiling process to terminate (for a serious error) or be marked as failed. Embodiment

[0074] The pattern file compiler provided by the embodiment of the application comprises: The file analysis module is configured to analyze the input pin definition file and the pattern file, extract pin information, test vector data, label information and micro instruction information therefrom, and convert the information into a data structure in memory; the block module is configured to divide the analyzed pattern file into a plurality of processing blocks according to a preset rule; the parallel compiling module is configured to utilize a multithreading technique to compile the plurality of processing blocks in parallel, and generate a plurality of intermediate files corresponding to each processing block, the intermediate files including at least a pattern data intermediate file, a label intermediate file and a micro instruction intermediate file; and the linking module is configured to utilize a multithreading technique to link the plurality of intermediate files, organize and generate a final executable pattern file.

[0075] Specifically, the pattern file compiler constitutes an efficient data processing pipeline through the cooperation of four functional modules. The file parsing module serves as the starting point of the process, and its input is the original, text format pin definition file (such as a.dec file) and the pattern source file (such as a.pat file). Through lexical analysis and syntax analysis, the module interprets these files line by line, accurately extracts pin attributes (name, type, channel mapping), pin grouping information, test vectors (Drive / Compare data), label (Label) definitions, and microinstruction (Instruction) sequences, and uniformly converts these elements into structured data structures (such as lists, dictionaries, or specific object models) existing in memory, providing a structured data foundation for all subsequent automated processing. The chunking module then operates on the parsed pattern data, taking the structured pattern data output by the file parsing module as input and dividing the complete, large-scale data sequence into multiple appropriately sized processing blocks according to pre-set rules (such as based on fixed line numbers or fixed data volume). The output of this module is a set of processing block descriptors, each defining its starting position and range in the source data, thereby breaking down the large compilation task into smaller parts and creating prerequisites for parallel processing. The parallel compilation module is the core of performance improvement, receiving processing block descriptors from the chunking module as a task list. The module dynamically creates multiple compilation threads, each independently taking a processing block and compiling the high-level semantic information (such as test vectors, labels, and microinstruction mnemonics) into lower-level, machine-executable binary or specific encoding formats. Finally, the linking module is responsible for the final integration, taking the set of intermediate files generated by the parallel compilation module as input. Using multi-threading technology, each linking thread reads one or more intermediate files corresponding to a processing block in parallel, performs global address resolution and relocation, and organizes and writes all data blocks and instruction blocks according to the pre-defined global file layout into a single, final executable pattern file. The output file contains all the necessary information for the tester to load and execute directly, completing the entire compilation process from the source file to the final test program. The modules are strictly linearly dependent, with the output of the previous module constituting the input of the next module. The data flow sequentially passes through parsing, chunking, parallel compilation, and parallel linking, finally generating the target file and forming an efficient and automated complete compilation link. Embodiments

[0076] This invention also provides an electronic device, including a memory and a processor, i.e., a computer program stored in the memory; The processor executes a computer program to implement the pattern file compilation method in Example 1.

[0077] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, other working processes of the method described above can be referred to the corresponding processes in the foregoing embodiments, and will not be repeated here.

[0078] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, and of course, it can also be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods of the various embodiments of this application.

[0079] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0080] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the flow or function according to the embodiments of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions can be transmitted from one website, computer, training device or data center to another website, computer, training device or data center through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that the computer can store or be integrated into a data storage device such as a training device, a data center, etc. containing one or more available media sets. The available media can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (SSD)), etc.

[0081] The above embodiments are only used to illustrate the technical solutions of the present application, not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can be modified, or some technical features can be replaced by equivalent ones; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for compiling a pattern file, characterized in that, include: S1: Parse the input pin definition file and pattern file, extract the pin information, test vector data, label information and microinstruction information, and convert them into data structures in memory; S2: Decompose the parsed pattern file into multiple processing blocks according to preset rules; S3: Using multi-threading technology, the multiple processing blocks are compiled in parallel to generate multiple intermediate files corresponding to each processing block. The intermediate files include at least a pattern data intermediate file, a tag intermediate file, and a micro-instruction intermediate file. S4: Use multi-threading technology to link the multiple intermediate files, organize them, and generate the final executable pattern file.

2. The method for compiling a pattern file according to claim 1, characterized in that, S2 include: S21: Calculate and determine the number of processing blocks based on the total size of the pattern file and a preset block size threshold; S22: Based on the determined number of processing blocks, decompose the content of the pattern file into multiple corresponding processing blocks.

3. A method for compiling a pattern file according to claim 1 or 2, characterized in that, The process of generating intermediate files in S3 includes: S31: Process the content of the processing block line by line, and store it into the corresponding data list according to the content type; S32: When the amount of data in any of the data lists reaches a preset row count threshold, the data in the data list is written to the corresponding intermediate file and the data list is cleared. S33: After processing all the contents of a processing block, write the remaining data in each data list into the corresponding intermediate file.

4. The method for compiling a pattern file according to claim 1, characterized in that, S4 includes: Multi-threaded parallel execution is employed, with each linking thread responsible for linking multiple intermediate files corresponding to a processing block and jointly organizing them to generate the final executable pattern file.

5. The method for compiling a pattern file according to claim 1, characterized in that, S1 was preceded by: S01: Calculate the hash value of the pin definition file and / or the pattern file; S02: Compare the calculated hash value with the previously saved hash value; S03: If the hash values ​​match, skip the compilation and directly use the compiled final executable pattern file. If the hash values ​​do not match, execute S1 to S4.

6. The method for compiling a pattern file according to claim 5, characterized in that, After S02 and before S1, it also includes: S04: If the hash values ​​are inconsistent, delete the existing intermediate file before S1; if the hash values ​​are consistent, use the existing intermediate file directly in S4.

7. The method for compiling a pattern file according to claim 1, characterized in that, S4 is followed by: S5: Compress the final executable pattern file.

8. The method for compiling a pattern file according to claim 1, characterized in that: The intermediate files in S3 are managed using memory-mapped file technology.

9. A pattern file compiler, characterized in that, include: The file parsing module is used to parse the input pin definition file and pattern file, extract the pin information, test vector data, label information and microinstruction information, and convert them into data structures in memory. The block segmentation module is used to decompose the parsed pattern file into multiple processing blocks according to preset rules; The parallel compilation module is used to compile the multiple processing blocks in parallel using multi-threading technology, generating multiple intermediate files corresponding to each processing block. The intermediate files include at least a pattern data intermediate file, a tag intermediate file, and a micro-instruction intermediate file. The linking module is used to link the multiple intermediate files using multi-threading technology, organize them, and generate the final executable pattern file.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the steps of the pattern file compilation method according to any one of claims 1 to 8.

Images