A host model for front-end verification of hard disk controllers

Abstract

The present application discloses a host model for front-end verification of a hard disk controller, and relates to the field of storage technology. In the host model of the present application, on the one hand, by constructing a submission model, a completion model, and a management model, and the submission model includes a submission queue, the completion model includes a completion queue, and the management model includes a pending command array, therefore, based on the submission queue, the completion queue, and the pending command array, the communication between the host and the hard disk controller can be simulated to achieve front-end verification of the hard disk controller. On the other hand, the submission model, the completion model, and the management model provide methods that can be called, so that the front-end verification personnel can complete the front-end verification of the hard disk controller by calling these methods without directly operating the storage space of the host, thereby solving the problem that the front-end verification of the hard disk controller in some technologies is difficult to implement.

Description

Technical Field

[0001] The present application relates to the field of storage technology, and in particular to a host model for performing front-end verification on a hard disk controller. Background Art

[0002] In the field of storage technology, hard drive controllers serve as the key node connecting the host computer and the hard drive. They are primarily responsible for transmitting data instructions, managing data transfer processes, and processing read and write requests from the hard drive. As hard drive controllers continue to become more complex and integrated, front-end verification of these controllers is becoming increasingly necessary.

[0003] Currently, hard drive controllers and hosts primarily communicate based on the NVMe (Non-Volatile Memory Express) protocol. Front-end verification of hard drive controllers based on NVMe requires reading or writing commands to the host's storage space. However, due to the mismatch between the bit width of the storage space and the bit width of the commands, front-end verification of hard drive controllers is difficult to implement. Summary of the Invention

[0004] The present application provides a host model for performing front-end verification on a hard disk controller, so as to at least solve the problem in the related art that the front-end verification of a hard disk controller is difficult to implement.

[0005] This application provides a host model for front-end verification of a hard disk controller, the host model comprising:

[0006] A submission model, including a submission queue and a command issuing method, wherein the submission queue is a queue of commands to be executed by the hard disk controller, and in response to the command issuing method being called, the submission model adds a new command to the submission queue;

[0007] A completion model, comprising a completion queue and a retrieval method, wherein the completion queue is a queue of commands that have been executed by the hard disk controller, and in response to the retrieval method being called, the completion model retrieves commands from the completion queue;

[0008] The management model includes a pending command array, which is used to store commands that have not been completed by the hard disk controller. The management model calls the retrieval method, retrieves the commands in the pending command array in the completion queue, and deletes the retrieved commands from the pending command array.

[0009] In the technical solutions of some embodiments of the present application, on the one hand, by constructing a submission model, a completion model, and a management model, and the submission model includes a submission queue, the completion model includes a completion queue, and the management model includes a pending command array, it is possible to simulate the communication between the host and the hard disk controller based on the submission queue, the completion queue, and the pending command array, and track the unexecuted commands to achieve front-end verification of the hard disk controller. On the other hand, the submission model, the completion model, and the management model provide methods that can be called, so that the front-end verification personnel can complete the front-end verification of the hard disk controller by calling these methods without directly operating the host's storage space, that is, without considering the problem of the inconsistency between the bit width of the storage space and the bit width of the command, thereby solving the problem of difficult implementation of front-end verification of the hard disk controller in some technologies. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0011] Figure 1 A schematic diagram of the structure of a host model provided for some embodiments of the present application;

[0012] Figure 2 A schematic diagram of the structure of a target model provided for other embodiments of the present application;

[0013] Figure 3 The class structure of the submission model provided for some embodiments of the present application;

[0014] Figure 4 The class structure of the completion model provided for some embodiments of the present application;

[0015] Figure 5 A schematic diagram of a hard disk controller writing a command in a completion queue provided in some embodiments of the present application;

[0016] Figure 6 The class structure of the management model provided in some embodiments of the present application;

[0017] Figure 7 A schematic structural diagram of a host model provided for other embodiments of the present application. DETAILED DESCRIPTION

[0018] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0019] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0020] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0021] A host is a device used to perform various computing tasks, such as a personal computer or server. A host typically includes hardware components such as a processor and memory, as well as software components such as an operating system. During interaction between the host and the hard disk controller, the host primarily sends data operation commands to the hard disk controller and receives responses from the controller. These commands may include, but are not limited to, data read and write commands, delete commands, and modify commands. These commands specify the storage location and size of the target data, as well as the type of operation (e.g., read, write, delete, modify, etc.) to be performed by the host. Based on these commands, the hard disk controller performs the data operation on a storage medium such as a solid-state drive (SSD) and returns a data operation response to the host. This response may include, but is not limited to, the target data read from the storage medium and a response indicating whether the operation was successful.

[0022] Currently, some technologies require that the host and hard drive controller interact using the NVMe protocol. In the NVMe protocol, the host's storage space maintains a submission queue and a completion queue. The submission queue stores commands that the host needs to send to the hard drive controller, while the completion queue stores commands that the hard drive controller has already executed. Because both the submission queue and the completion queue are stored in the host's storage space, the hard drive controller needs to read commands from the host's storage space or write completed commands to the host's storage space via the bus between the host and hard drive controller.

[0023] Front-end verification of a hard disk controller simulates the process of the host writing commands to the submission queue, the hard disk controller reading commands from the submission queue, executing the commands, and writing the completed commands to the completion queue. As can be seen from the above description, both writing and reading commands require operations on the host's storage space. However, due to the mismatch between the bit width of the storage space and the bit width of the commands, front-end verification of the hard disk controller cannot simply read and write commands to the host's storage space through storage space operations, making front-end verification of hard disk controllers difficult to implement.

[0024] In view of this, the present application provides a host model for performing front-end verification of a hard disk controller, which can reduce the difficulty of front-end verification of the hard disk controller.

[0025] In this embodiment, the host model can be constructed based on the object-oriented programming syntax of SystemVerilog. SystemVerilog is a high-level language used for hardware description and verification. It allows front-end verification personnel to construct a host model by defining classes, objects, and inheritance. The constructed host model can be run on a target device. The target device may include, but is not limited to, electronic devices such as tablets, laptops, desktop computers, and servers.

[0026] See also Figure 1 , which is a structural diagram of the host model provided in some embodiments of the present application. Figure 1 In , host models include submit models, complete models, and manage models.

[0027] The submission model may include a submission queue and a command issuing method. The submission queue is a command queue to be executed by the hard disk controller. In response to the command issuing method being called, the submission model can add a new command to the submission queue. Specifically, in the process of constructing the submission model, the first capacity of the submission queue can be specified. The first capacity refers to the maximum number of commands that the submission queue can accommodate. Based on the first capacity, a first storage space can be opened up in the target device running the host model. The first storage space can be used to save the submission queue in the submission model. The input parameter of the command issuing method can be the target command that the host needs to send to the submission queue during the front-end verification process. For example, the target command can be a 64B NVMe command. During the operation of the command issuing method, the target storage location of the target command in the submission queue can be calculated, and the target command can be saved to the target storage location. In this way, adding a new command to the submission queue is achieved.

[0028] The completion model includes a completion queue and a retrieval method. The completion queue is a queue of commands that have been executed by the hard disk controller. In response to the retrieval method being called, the completion model can retrieve commands from the completion queue. Specifically, similar to the submission model, the second capacity of the completion queue can be specified during the construction of the completion model. The second capacity refers to the maximum number of commands that the completion queue can accommodate. Based on the second capacity, a second storage space can be opened up in the target device running the host model. The second storage space can be used to save the completion queue in the completion model. During the operation of the retrieval method, at least part of the commands written by the hard disk controller can be retrieved from the completion queue. For any command in the submission queue, if the command is retrieved in the completion queue, it means that the command has been executed.

[0029] The management model includes a pending command array, which is used to store commands that have not been completed by the hard disk controller. Specifically, the pending command array can store commands in the submission queue that have not yet been read by the hard disk controller, as well as commands in the submission queue that have been read by the hard disk controller but have not yet been completed. When a command is saved to the submission queue, it can also be saved to the pending command array. The management model calls a retrieval method to retrieve commands in the pending command array from the completion queue. For any command in the pending command array, if the command is retrieved from the completion queue, it means that the command has been completed. Therefore, the retrieved command can be deleted from the pending command array.

[0030] Specifically, the management model can call a retrieval method at preset intervals to retrieve commands from the pending command array in the completion queue in real time and remove the retrieved commands from the pending command array. Based on the pending command array, the hard disk controller can effectively track incomplete and completed commands.

[0031] In summary, in the technical solutions of some embodiments of the present application, on the one hand, by constructing a submission model, a completion model, and a management model, and the submission model includes a submission queue, the completion model includes a completion queue, and the management model includes an array of pending commands, it is possible to simulate the communication between the host and the hard disk controller based on the submission queue, the completion queue, and the array of pending commands, and track the unexecuted commands to achieve front-end verification of the hard disk controller. On the other hand, the submission model, the completion model, and the management model provide methods that can be called, so that the front-end verification personnel can complete the front-end verification of the hard disk controller by calling these methods without directly operating the storage space of the host, that is, without considering the problem of the inconsistency between the bit width of the storage space and the bit width of the command, thereby solving the problem that the front-end verification of the hard disk controller in some technologies is difficult to implement.

[0032] Continue reading Figure 1In this embodiment, when constructing a host model based on the object-oriented programming syntax of the SystemVerilog language, the submission model, completion model, and pending command array can be packaged into a management model class. By creating an object (i.e., an instance) of the management model class, the host model can be obtained.

[0033] See also Figure 2 , which is a structural diagram of the target model provided in some other embodiments of the present application. Figure 2 In the case where there are multiple submission queues and multiple completion queues, the host model includes multiple submission models and multiple completion models, each submission model includes one of the submission queues, and each completion model includes one of the completion queues, each submission model adds commands to the submission queue included in each, and each completion model retrieves commands from the completion queue included in each.

[0034] For example, assuming that there are submission queues 1, 2, ..., n and completion queues 1, 2, ..., n, the host model may include submission models 1, 2, ..., n and completion models 1, 2, ..., n. Submission model 1 may include submission queue 1, submission model 2 may include submission queue 2, ..., submission model n may include submission queue n, and completion model 1 may include completion queue 1, completion model 2 may include completion queue 2, ..., completion model n may include completion queue n.

[0035] In response to a call to the command publish method in submission model 1, submission model 1 can add a command to submission queue 1. In response to a call to the command publish method in submission model 2, submission model 2 can add a command to submission queue 2. And so on. Similarly, in response to a call to the retrieval method in completion model 1, completion model 1 can retrieve a command from completion queue 1. In response to a call to the retrieval method in completion model 2, completion model 2 can retrieve a command from completion queue 2. And so on.

[0036] The submission queues in each submission model may have their own corresponding first capacity, that is, the maximum number of commands that the submission queues in different submission models can accommodate may be the same or different. For example, submission queue 1 in submission model 1 can accommodate 30 commands, and submission queue 2 in submission model 2 and submission queue n in submission model n can accommodate 25 commands. Similarly, the completion queues in each completion model may have their own corresponding second capacity, that is, the maximum number of commands that the completion queues in different completion models can accommodate may be the same or different. In this way, in the front-end verification of the hard disk controller, multiple submission queues and completion queues of different capacities can be set for the hard disk controller simulation according to actual needs, thereby meeting a variety of different verification requirements.

[0037] Furthermore, in the case where the host model includes multiple submission models and multiple completion models, the number of submission models and the number of completion models can be the same, and the submission models and the completion models can correspond and be associated one-to-one. For any submission model, the hard disk controller reads the command from the submission queue of the submission model, and after the command execution is completed, puts the executed command into the completion queue of the completion model associated with the submission model. For example, suppose that submission model 1 is associated with completion model 1, and submission model 2 is associated with completion model 2. Then, the hard disk controller reads command A from submission queue 1 included in submission model 1, and after executing command A, puts the executed command A into completion queue 1 included in completion model 1. Similarly, the hard disk controller reads command B from submission queue 2 included in submission model 2, and after executing command B, puts the executed command B into completion queue 2 included in completion model 2.

[0038] Furthermore, if the host model includes multiple submission models and multiple completion models, the multiple submission models, multiple completion models, and a pending command array can be packaged into a management model class. The host model can be obtained by creating an object (i.e., an instance) of the management model class.

[0039] In the above embodiment, after creating a submission model corresponding one-to-one to the submission queue and a completion model corresponding one-to-one to the completion queue in the host model, different submission queues can be managed differently based on different submission models, and different completion queues can be managed differently based on different completion models. The solution is highly flexible and can meet a variety of different verification requirements.

[0040] For easier understanding, please refer to Figure 3 , which is the class structure of the submission model provided in some embodiments of this application. Figure 3 As shown in the example, in the class structure of the submission model, the model identifier, submission queue capacity, submission queue base address, command issuing method, model identifier of the associated completion model, storage address of the next command to be saved, storage address of the next command to be read, and register update interface are defined. Figure 1 The relevant description is not repeated here.

[0041] Figure 3 In the example, model ID refers to the model ID of the submitted model.

[0042] The submission queue capacity refers to the number of commands that the submission queue included in the submission model can accommodate.

[0043] The submission queue base address refers to the starting address of the first storage space allocated for the submission queue in the submission model. Commands to be saved to the submission queue are sequentially saved in the first storage space, starting from this base address. The first storage space can be used cyclically. For example, commands can be saved sequentially from the base address of the first storage space until the end address of the first storage space is reached. Then, the end address can be returned to the base address and commands can be saved again starting from the base address.

[0044] The model ID of the associated completed model refers to the model ID of the completed model associated with the submitted model.

[0045] The storage address of the next command to be saved, also known as the storage address next_index1, refers to the storage address of the newly added command when the command issuing method is called for the next time. After each time one or more commands are added to the submission queue, the storage address next_index1 will change accordingly. For example, assuming that a newly added command is saved at the storage address address1 when the command issuing method is called for the first time, then after the command issuing method is called for the first time, the storage address next_index1 can be updated to the next storage address address2 of the storage address address1. In this way, when the command issuing method is called for the second time, the newly added command can be saved at the storage address address2. Similarly, after the command issuing method is called for the second time, the storage address next_index1 can be updated to the next storage address address3 of the storage address address2. In this way, when the command issuing method is called for the third time, the newly added command can be saved at the storage address address3. And so on.

[0046] The target device running the host model may include a register corresponding to the submission model. This register may be used to store the storage address next_index1 of the submission model. When the hard disk controller detects a change in the value in the register, it may determine that a new command has appeared in the submission queue and may read the new command from the submission queue.

[0047] The storage address of the next command to be read, also known as the storage address head_ptr, is the storage address of the command that the hard disk controller needs to read the next time it reads a command from the submission queue. The storage address head_ptr changes each time the hard disk controller reads a command from the submission queue. The relevant principles are similar to those for the storage address next_index1 and are not further explained here.

[0048] In the above-mentioned storage address next_index1 and storage address head_ptr, the value of the storage address next_index1 can be maintained by the submission model. For example, during the execution of the command issuing method, the latest storage address next_index1 can be written into the register corresponding to the submission model, and the storage address head_ptr value can be maintained by the hard disk controller. For example, after the hard disk controller completes each command reading operation, the storage address head_ptr can be updated based on the storage address of the last read command.

[0049] The register update interface is used to update the value in the register corresponding to the submitted model. For example, during the execution of the command issuance method, the register update interface can be called to update the value of the storage address next_index1 in the register corresponding to the submitted model.

[0050] right Figure 3 Different submission models can be obtained by instantiating the class shown. For example, by setting the model identifier to 001, the model identifier of the completion model associated with the submission model to 002, the submission queue capacity to 20, the submission queue base address to address1, the command issuance method to method F1, and the register update interface to interface M, submission model A1 can be obtained. For another example, by setting the model identifier to 003, the model identifier of the completion model associated with the submission model to 004, the submission queue capacity to 25, the submission queue base address to address2, the command issuance method to method F1, and the register update interface to interface M, submission model A2 can be obtained.

[0051] In the case where multiple submission models are instantiated, the target device where the host model runs may include registers corresponding to the submission models, each register being used to store the storage address next_index1 of the corresponding submission model.

[0052] In this embodiment, in the class definition of the submission model, the register update interface can be a virtual interface. After the submission model is instantiated, a real interface can be connected to the instantiated submission model, so that the submission model updates the storage address next_index1 in the register through the real interface.

[0053] See also Figure 4 , which is the class structure of the completed model provided in some embodiments of this application. Figure 4As shown, in the class structure of the completion model, the model identifier, completion queue capacity, completion queue base address, whether to use interrupts, interrupt number, first search method, second search method, register update interface, interrupt count value, first state flag and search start position are defined. Among them, the model identifier, completion queue capacity, completion queue base address and Figure 3 Similar, I will not go into details here. Figure 4 The other parameters in are described below.

[0054] Figure 4 In the retrieval start position, which can also be called the storage address next_index2, refers to the starting address when the completion model retrieves the command in the completion queue. After the completion model performs each command retrieval operation in the completion queue, the storage address next_index2 will change. The relevant principle is similar to the above-mentioned storage address next_index1 and will not be repeated here. The target device running the host model may include a register corresponding to the completion model. The register can be used to save the storage address next_index2 of the corresponding completion model. When the hard disk controller writes the completed command to the completion queue of the completion model, it can determine the command write position based on the storage address next_index2 in the register. In this way, it avoids overwriting the command that has not been retrieved by the completion model.

[0055] The register update interface is an interface used to update the value in the register corresponding to the completed model. For example, during the execution of the first search method, the register update interface can be called to update the storage address next_index2 in the register corresponding to the completed model.

[0056] Further, such as Figure 4 As shown, in some embodiments, each completed model may have its own corresponding interrupt number. Different completed models may have different interrupt numbers. The interrupt number may be the model identifier of the completed model. For example, assuming that the model identifier of completed model A1 is 001 and the model identifier of completed model A2 is 002, the interrupt number corresponding to completed model A1 is 001, and the interrupt number corresponding to completed model A2 is 002.

[0057] The target device in the host model is connected to the hard disk controller via a bus. After the hardware controller executes a command, it can send an interrupt message to the target device via the bus when writing the completed command to the completion queue of any completion model. The interrupt message is used to identify the interrupt number corresponding to the completion model in which the completion command is currently written. Specifically, interrupt messages may include but are not limited to MSI (Message Signaled Interrupts) and MSI-X (Extended Message Signaled Interrupts). Between the target device and the hard disk controller, the hard disk controller transmits interrupt messages corresponding to different completion models by writing specific values to specific addresses in the host model via the bus. For example, writing the value 0 to address 1 indicates the transmission of the interrupt message for completion model A1, and writing the value 1 to address 2 indicates the transmission of the interrupt message for completion model A2.

[0058] The host model may include a monitoring component and a counter corresponding to the completion model. The monitoring component monitors the interrupt message by monitoring whether there is a write transfer of a specific value at a specific address. When an interrupt message is monitored, the monitoring component can determine the completion model to which the completion command is currently written based on the interrupt message, and update the counter corresponding to the corresponding completion model (for example, add 1 to the value in the counter). For example, if the interrupt message represents the interrupt number of the completion model A1, the counter corresponding to the completion model A1 is updated; if the interrupt message represents the interrupt number of the completion model A2, the counter corresponding to the completion model A2 is updated. In this way, the value in the counter can represent the current interrupt count value of the completion model. Accordingly, the interrupt count value in the completion model can represent the value in the corresponding counter when the completion model last retrieved the included completion queue.

[0059] For the above-mentioned solution based on interrupt number, whether to use the solution based on interrupt number can be configured in the completion model. Specifically, by configuring the parameter "Whether to use interrupt" in the completion model, whether to use the solution based on interrupt number can be configured in the completion model.

[0060] Furthermore, the retrieval method in the completion model may include a first retrieval method and a second retrieval method. In response to the first retrieval method being called, the completion model may compare the locally stored interrupt count value with the value in the counter. If the locally stored interrupt count value is different from the value in the counter, it means that the command in the completion queue included in the completion model has been updated. At this time, the second retrieval method can be run. During the operation of the second retrieval method, the storage address next_index2 can be obtained, and starting from the storage address next_index2, the completion queue can be searched to see if there are any new commands written by the hard disk controller. If there are new commands written by the hard disk controller in the completion queue, all the new commands written by the hard disk controller are retrieved.

[0061] Furthermore, since the commands in the completion queue reuse the storage space, it is necessary to distinguish the new and old commands written by the hard disk controller in the completion queue. Figure 5 , is a schematic diagram of a hard disk controller writing commands in a completion queue provided in some embodiments of the present application. Figure 5 In the figure, along the arrow direction, it is assumed that during the first phase of command writing, the hard disk controller writes a command marked as 1 to each command position in the completion queue. After completing the first phase of writing and reaching the end position of the completion queue, the hard disk controller continues to return to the beginning position of the completion queue and writes a command marked as 0. Figure 5 It can be seen that although the command marked 1 is located after the command marked 0, the command marked 1 is an old command written by the hard disk controller, while the command marked 0 is a new command written by the hard disk controller. Based on this, assuming that during the execution of the second retrieval method, the storage address next_index2 points to the starting position of the completion queue, then the first three commands marked 0 are the new commands written by the hard disk controller and need to be retrieved, while the subsequent commands marked 1 are old commands written by the hard disk controller and do not need to be retrieved.

[0062] In summary, in this embodiment, the completion model can locally maintain a first state flag, and the value of the first state flag can be 0 or 1. The completion model performs a flip on the value of the first state flag each time it traverses the completion queue (i.e., after traversing from the starting position to the end position of the completion queue) based on the capacity of the included completion queue. The so-called flip is to modify the value of the first state flag to another value between 0 and 1. For example, when the value of the first state flag is 0, after the flip is executed, the value of the first state flag becomes 1. Conversely, when the value of the first state flag is 1, after the flip is executed, the value of the first state flag becomes 0.

[0063] In the command written to the completion queue, the hard disk controller maintains a second status flag (i.e., the second status flag is used to identify the command written to the completion queue). The value of the second status flag can also be 0 or 1. According to a principle similar to the completion model, the hard disk controller will also periodically flip the value of the second status flag. In this way, during the operation of the second retrieval method, for any command in the completion queue, the completion model will compare the locally stored first status flag with the second status flag of the command. If the first status flag is the same as the second status flag, it means that the command is an old command written to the completion queue by the hard disk controller and has not been overwritten by a new command. In this case, the command can be ignored and the command retrieval can be stopped. On the contrary, if the first status flag is different from the second status flag, it means that the command is a new command written to the completion queue by the hard disk controller. In this case, the command can be regarded as a new command written to the completion queue by the hard disk controller.

[0064] and Figure 3 Similar, yes Figure 4 By instantiating the classes shown, different completion models can be obtained.

[0065] In the case where multiple completed models are instantiated, the target device where the host model runs may include registers corresponding to the completed models, each register being used to store the storage address next_index2 of the corresponding completed model.

[0066] See also Figure 6 , is the class structure of the management model provided in some embodiments of this application. Figure 6 As shown, in the class that manages the model, the object collection all_sq[] of the submitted model, the object collection all_cq[] of the completed model, the command receiving method, the polling method, the post-processing method and the pending command array are defined. For the pending command array, please refer to Figure 1 For related descriptions, as well as command receiving methods, polling methods, and post-processing methods, please refer to the subsequent related descriptions and will not be repeated here.

[0067] In the object-oriented programming syntax of SystemVerilog language, the object collections all_sq[] and all_cq[] can be SV language associative arrays. In the object collection all_sq[], one or more submission models can be included. The index type is the model identifier of the submission model. The data type is Figure 3 The class object of the submitted model. In the object collection all_cq[], one or more completed models can be included. The index type is the model identifier of the completed model. The data type is Figure 4The class object of the completed model in the object set all_sq[] can be associated with the completed models in the object set all_cq[]. For example, if the object set all_sq[] includes submitted models A1 and A2, and the object set all_cq[] includes completed models B1 and B2, then submitted model A1 can be associated with completed model B1, and submitted model A2 can be associated with completed model B2. Figure 6 The meaning is: by packaging the submission model in the object collection all_sq[], the completion model in the object collection all_cq[], and an array of pending commands, a management model class can be obtained.

[0068] By instantiating the management model class, you can create multiple different management models. For example, by filling the object collection all_sq[] with submission models A1 and A2, and the object collection all_cq[] with completion models B1 and B2, you can create management model M1. For another example, in the management model class, by filling the object collection all_sq[] with submission models C1 and C2, and the object collection all_cq[] with completion models D1 and D2, you can create management model M2.

[0069] In this embodiment, the management model can also be used to manage the deletion or addition of submission models and completion models. For example, during the execution of the post-processing method, submission models and completion models can be added to the management model's object sets all_sq[] and all_cq[]. Alternatively, during the execution of the post-processing method, submission models and completion models can be deleted from the management model's object sets all_sq[] and all_cq[]. In this way, dynamic modification of submission models and completion models is achieved.

[0070] Further, see Figure 7 , which is a structural diagram of the host model provided in some embodiments of the present application. Figure 7 In the case of multiple hard disk controllers, each hard disk controller has its own corresponding management model, submission model and completion model, and the management models, submission models and completion models corresponding to different hard disk controllers are different. In simple terms, if Figure 7 As shown, each hard disk controller can correspond to a management model class instance, namely Figure 7Different hard disk controllers have different corresponding management models. For example, in the management model corresponding to hard disk controller T1, the object set all_sq[] includes submission models A1 and A2, and the object set all_cq[] includes completion models B1 and B2. In the management model corresponding to hard disk controller T2, the object set all_sq[] includes submission models C1 and C2, and the object set all_cq[] includes completion models D1 and D2. This allows for simultaneous front-end verification of different hard disk controllers, which is quite practical.

[0071] The following is combined with the above Figures 2 to 6 , explaining how to perform front-end verification of the hard disk controller based on the host model of this application.

[0072] 1) In response to the command receiving method being called, the management model receives the target command and the target model identifier, determines the target submission model based on the target model identifier, and performs the following operations:

[0073] Write the target command to the pending command array and identify the target command using a combined index that includes the position identifier of the target command in the target submission queue and the model identifier of the target submission model.

[0074] The command publishing method of the target submission model is called to enable the target submission model to add the target command to the target submission queue included in the target submission model.

[0075] 2) After the target submission model adds a new target command to the target submission queue, it writes the storage address of the next command to be saved in the target submission queue into the first register corresponding to the target submission model; in response to the change in the value in the first register, the hard disk controller reads the target command from the target submission queue and writes the executed target command into the completion queue of the target completion model associated with the target submission model.

[0076] Specifically, the command receiving method in the management model is a method provided for front-end verification personnel to call. The command receiving method's input parameters include the target command to be submitted to the storage controller and the model identifier of the target submission model in which the target command should be placed. By calling the command receiving method, front-end verification personnel can simulate the scenario of issuing commands to the hard disk controller without having to manipulate the host storage space.

[0077] Based on the above description of the submission model, the target submission model includes: the model identifier of the target submission model, and the model identifier of the target completion model associated with the target submission model; the queue base address and capacity size of the target submission queue; the storage address next_index1 of the next command to be saved in the target submission queue; the storage address head_ptr of the next command read by the hard disk controller from the target submission queue; and an interface for updating the first register.

[0078] Based on the information in the target submission model, during the execution of the command issuing method, the target storage address of the target command can be calculated based on the queue base address and storage address next_index1 of the target submission queue, and then the system function $deposit can be called to write the target command into the target submission queue, and then the storage address next_index1 is updated, and the updated storage address next_index1 is written to the first register through the interface for updating the first register.

[0079] 3) After writing the target command to the pending command array, the management model traverses the target command in the pending command array and, based on the combined index of the target command, determines the target submission model and the target completion model associated with the target submission model. Furthermore, the management model searches the target completion queue included in the target completion model for the presence of the target command. If the target command is found in the target completion queue, the management model deletes the target command from the pending command array. Specifically, after determining the target completion model, the management model calls a retrieval method in the target completion model. In response to the retrieval method being called, the target completion model searches the included target completion queue for the presence of the target command.

[0080] Specifically, such as Figure 6 The management model may include a polling method and a post-processing method. The management model may run the polling method at a preset interval. During the execution of the polling method, the target commands in the pending command array are traversed, and based on the combined index of the target commands, a target submission model and a target completion model associated with the target submission model are determined;

[0081] The polling method passes the model identifier of the target completion model to the post-processing method. During the execution of the post-processing method, the target completion queue included in the target completion model is searched for the existence of the target command. If the target command is found in the target completion queue, the target command is deleted from the pending command array. During the execution of the post-processing method, the retrieval method in the target completion model can be called to search for the existence of the target command in the target completion queue included in the target completion model.

[0082] 4) In response to the retrieval method being called, the target completion model compares the locally stored interrupt count value with the value in the target counter. If the interrupt count value and the value in the target counter are equal, the target completion model searches the target completion queue for the target command. Before searching for the target command, the target completion model also obtains the first search starting position. When searching for the target command, the target completion model starts at the first search starting position in the target completion queue and searches for the target command.

[0083] Specifically, during the execution of the post-processing method, a first retrieval method in the target completion model may be called. In response to the first retrieval method being called, the target completion model compares the locally stored interrupt count value with the value in the target counter, and if the interrupt count value is different from the value in the target counter, runs a second retrieval method to obtain the first retrieval starting position, and searches for the presence of the target command starting from the first retrieval starting position in the target completion queue.

[0084] Specifically, such as Figure 4 The relevant description of the target completion model may include the model identifier of the target completion model, the target completion queue capacity, the target completion queue base address, whether to use interrupts, the interrupt number, the first retrieval method, the second retrieval method, the register update interface, the interrupt count value, the first status flag, and the storage address next_index2 of the next command to be retrieved. Based on the information in the target completion model, all new commands newly written to the target completion queue by the hard disk controller can be retrieved during the operation of the second retrieval method. The second retrieval method can return all retrieved new commands to the post-processing method of the management model. The post-processing method searches for the target command in the command returned by the second retrieval method based on the combined index in the command. If so, the target command is deleted from the pending command array of the management model. If not, the target command continues to be retained in the pending command array of the management model.

[0085] 5) After completing the retrieval in the target completion queue, the target completion model also determines the second retrieval starting position for the next retrieval in the target completion queue, and writes the second retrieval starting position into the second register corresponding to the target completion model. The next time the hard disk controller writes the executed command into the target completion queue, it determines the command write position based on the second retrieval starting position in the second register.

[0086] In summary, in the technical solutions of some embodiments of the present application, on the one hand, by constructing a submission model, a completion model, and a management model, and the submission model includes a submission queue, the completion model includes a completion queue, and the management model includes an array of pending commands, it is possible to simulate the communication between the host and the hard disk controller based on the submission queue, the completion queue, and the array of pending commands, and track the unexecuted commands to achieve front-end verification of the hard disk controller. On the other hand, the submission model, the completion model, and the management model provide methods that can be called, so that the front-end verification personnel can complete the front-end verification of the hard disk controller by calling these methods without directly operating the storage space of the host, that is, without considering the problem of the inconsistency between the bit width of the storage space and the bit width of the command, thereby solving the problem that the front-end verification of the hard disk controller in some technologies is difficult to implement.

[0087] The above describes in detail the host model provided by this application for front-end verification of a hard disk controller. This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above examples is only intended to help understand the method and core concept of this application. It should be noted that for ordinary technicians in this technical field, without departing from the principles of this application, various improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A host model for front-end verification of a hard disk controller, characterized in that: The host model includes: A submission model, including a submission queue and a command issuing method, wherein the submission queue is a queue of commands to be executed by the hard disk controller, and in response to the command issuing method being called, the submission model adds a new command to the submission queue; A completion model, comprising a completion queue and a retrieval method, wherein the completion queue is a queue of commands that have been executed by the hard disk controller, and in response to the retrieval method being called, the completion model retrieves commands from the completion queue; A management model includes a pending command array, wherein the pending command array is used to store commands that have not been completed by the hard disk controller, and the management model calls the retrieval method to retrieve the commands in the pending command array from the completion queue and delete the retrieved commands from the pending command array; Wherein, in the case where there are multiple submission queues and multiple completion queues, the host model includes multiple submission models and multiple completion models, each of the submission models includes one of the submission queues, and each of the completion models includes one of the completion queues, each of the submission models adds commands to the submission queue included therein, and each of the completion models retrieves commands from the completion queue included therein; Furthermore, the management model includes a command receiving method, in response to the command receiving method being called, the management model receives a target command and a target model identifier, determines a target submission model based on the target model identifier, and calls a command issuing method of the target submission model; In response to the command issuing method being called, the target submission model adds the target command to the target submission queue included in the target submission model.

2. The host model according to claim 1, characterized in that The host model runs in a target device, the target device includes registers corresponding one-to-one to the submitted models, and the submitted models correspond one-to-one to and are associated with the completed models; After the target submission model adds the target command to the target submission queue, the target submission model writes the storage address of the next command to be saved in the target submission queue into the first register corresponding to the target submission model; In response to a change in the value in the first register, the hard disk controller reads the target command from the target submission queue and writes the target command that has been executed into a completion queue of a target completion model associated with the target submission model.

3. The host model according to claim 2, characterized in that The target submission model also includes at least one of the following information: The model identifier of the target submission model, and the model identifier of the target completion model associated with the target submission model; The queue base address and capacity of the target submission queue; The storage address of the next command to be saved in the target submission queue; The storage address of the next command read by the hard disk controller from the target submission queue; An interface for updating the first register.

4. The host model according to claim 2, characterized in that In response to the command receiving method being called, the management model is also used to write the target command into the pending command array and identify the target command using a combined index, wherein the combined index includes a position identifier of the target command in the target submission queue and a model identifier of the target submission model.

5. The host model according to claim 4, characterized in that: After writing the target command into the pending command array, the management model also traverses the target command in the pending command array, and based on the combined index of the target command, determines the target submission model and the target completion model associated with the target submission model, and retrieves whether the target command exists in the target completion queue included in the target completion model, wherein if the target command is retrieved in the target completion queue, the target command is deleted from the pending command array.

6. The host model according to claim 5, characterized in that: The management model also includes a polling method and a post-processing method; During the execution of the polling method, traversing the target commands in the pending command array and determining the target submission model and the target completion model associated with the target submission model based on the combined index of the target command; The polling method passes the model identifier of the target completion model to the post-processing method. During the running of the post-processing method, it searches the target completion queue included in the target completion model to see whether the target command exists. If the target command is retrieved from the target completion queue, the target command is deleted from the pending command array.

7. The host model according to claim 5, characterized in that: After determining the target completion model, the management model calls a retrieval method in the target completion model; In response to the retrieval method being called, the goal completion model searches the included goal completion queue to see if the goal command exists.

8. The host model according to claim 7, characterized in that: Each completion model has its own corresponding interrupt number. The host model also includes a monitoring component and a counter corresponding to each completion model. When the hard disk controller executes the target command, it also sends a target interrupt message. The target interrupt message is used to identify the interrupt number corresponding to the target completion model. When the monitoring component monitors the target interrupt message, it updates the value in the target counter corresponding to the target completion model. In response to the retrieval method being called, the target completion model compares the locally stored interrupt count value with the value in the target counter. If the interrupt count value is equal to the value in the target counter, the target completion queue is searched to see whether the target command exists.

9. The host model according to claim 8, characterized in that: The target completion model further obtains a first search starting position before retrieving the target command; When searching for the target command, the target completion model starts from the first search start position of the target completion queue to search whether the target command exists.

10. The host model according to claim 9, characterized in that: The target device includes registers corresponding one-to-one to the completed models; After completing the retrieval in the target completion queue, the target completion model also determines the second retrieval starting position for the next retrieval in the target completion queue, and writes the second retrieval starting position into the second register corresponding to the target completion model. The next time the hard disk controller writes the executed command into the target completion queue, it determines the command write position based on the second retrieval starting position in the second register.

11. The host model according to claim 10, characterized in that: The retrieval method in the goal completion model includes a first retrieval method and a second retrieval method; In response to the first retrieval method being called, the target completion model compares the locally stored interrupt count value with the value in the target counter, and if the interrupt count value is different from the value in the target counter, runs the second retrieval method to obtain the first retrieval starting position, and starts from the first retrieval starting position of the target completion queue to retrieve whether the target command exists.

12. The host model according to claim 1, characterized in that: In the case where there are multiple hard disk controllers, each hard disk controller has its own corresponding management model, submission model and completion model, and the management models, submission models and completion models corresponding to different hard disk controllers are different.

13. The host model according to claim 12, characterized in that: The management model is also used to manage the deletion or addition of the submitted model and the completed model.

Images