Host model for performing front-end verification on hard disk controller
By building a submission queue, completion queue and pending command array in the host model, the communication between the host and the hard disk controller is simulated, which solves the problem of difficult front-end verification of the hard disk controller and realizes verification without considering the inconsistency between the storage space bit width and the command bit width.
Patent Information
- Application Number
- CN202510704312.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-29
- Publication Date
- 2025-07-04
- Estimated Expiration
- 2045-05-29
AI Technical Summary
In the prior art, the front-end verification of the hard disk controller is difficult to implement because the storage space bit width between the host and the hard disk controller is inconsistent with the command bit width.
Building a host model, including submitting the model, completing the model, and managing the model, simulates the communication between the host and the hard disk controller by submitting the queue, completing the queue and pending command array, providing callable methods for front-end verification.
There is no need to directly operate the host storage space, which solves the problem of inconsistent bit width in front-end verification and realizes effective verification of the hard disk controller.
Smart Images

Figure CN120255820A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of storage technologies, and in particular, to a host model for front-end verification of a hard disk controller. Background Art
[0002] In the field of storage technologies, as a key node connecting a host and a hard disk, a hard disk controller is mainly used for transmitting data instructions, managing data transfer processes, and processing read and write requests of the hard disk. With the continuous improvement of the complexity and integration level of hard disk controllers, front-end verification of hard disk controllers has become increasingly necessary.
[0003] Currently, the hard disk controller and the host mainly communicate based on the NVMe (Non-Volatile Memory Express) protocol. When performing front-end verification of the hard disk controller based on the NVMe protocol, it is necessary to read or write commands from / to the storage space of the host. However, due to the inconsistent bit widths of the storage space and the commands, it is difficult to implement front-end verification of the hard disk controller. Summary of the Invention
[0004] This application provides a host model for front-end verification of a hard disk controller to at least solve the problem in the related art that it is difficult to implement front-end verification of a hard disk controller.
[0005] This application provides a host model for front-end verification of a hard disk controller, and the host model includes: A submission model, including a submission queue and a command issuing method. The submission queue is a queue of commands to be executed by the hard disk controller. In response to the call of the command issuing method, the submission model adds a new command to the submission queue; A completion model, including a completion queue and a retrieval method. The completion queue is a queue of commands that have been executed and completed by the hard disk controller. In response to the call of the retrieval method, the completion model retrieves commands from the completion queue; A management model, including an outstanding command array for saving commands that have not been executed and completed by the hard disk controller. The management model calls the retrieval method to retrieve commands in the outstanding command array from the completion queue and deletes the retrieved commands from the outstanding command array.
[0006] 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, where the submission model includes a submission queue, the completion model includes a completion queue, and the management model includes an array of outstanding commands. Therefore, based on the submission queue, the completion queue, and the array of outstanding commands, the communication between the host and the hard disk controller can be simulated, and the commands that have not been completed can be tracked to achieve the front-end verification of the hard disk controller. On the other hand, the submission model, the completion model, and the management model provide callable methods. In this way, 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 inconsistent bit widths between the storage space and the commands, thus solving the problem that the front-end verification of the hard disk controller in some technologies is difficult to implement. BRIEF DESCRIPTION OF THE DRAWINGS
[0007] To more clearly illustrate the embodiments of the present application, the following will briefly introduce the drawings required in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.
[0008] Figure 1 Structural schematic diagram of the host model provided by some embodiments of the present application; Figure 2 Structural schematic diagram of the target model provided by some other embodiments of the present application; Figure 3 Class structure of the submission model provided by some embodiments of the present application; Figure 4 Class structure of the completion model provided by some embodiments of the present application; Figure 5 Schematic diagram of the hard disk controller writing commands in the completion queue provided by some embodiments of the present application; Figure 6 Class structure of the management model provided by some embodiments of the present application; Figure 7 Structural schematic diagram of the host model provided by some other embodiments of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0009] The following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, not all embodiments. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present application.
[0010] It should be noted that in the description of this application, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements but also includes other elements not expressly listed, or also includes 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 specific order or sequence.
[0011] To enable those skilled in the art of this technology to better understand the solution of this application, the following further detailed description of this application will be given in conjunction with the accompanying drawings and specific embodiments.
[0012] The host refers to a device used to perform various computing tasks, such as a personal computer, a server, etc. The host generally includes hardware components such as a processor and memory, and also includes software components such as an operating system. During the interaction between the host and the hard disk controller, the host is mainly used to send data operation commands to the hard disk controller and receive responses from the hard disk controller. Among them, the data operation commands can include but are not limited to read and write commands, delete commands, modify commands, etc. In the data operation commands, the storage location, size of the target data required to be operated by the host and the operation type for the target data (such as read, write, delete, modify, etc.) can be specified. Based on the data operation commands, the hard disk controller performs data operations in a storage medium such as a Solid State Drive (SSD) and returns a data operation response to the host. The data operation response can include but is not limited to the target data read from the storage medium, a response indicating whether the operation is successful, etc.
[0013] Currently, in some technologies, when the host and the hard disk controller interact, they need to follow the NVMe protocol. In the NVMe protocol, submission queues and completion queues are maintained in the storage space of the host. Among them, the submission queue is used to store commands that the host needs to send to the hard disk controller, and the completion queue is used to store commands that the hard disk controller has executed and completed. Since both the submission queue and the completion queue are stored in the storage space of the host, the hard disk controller needs to read commands from the storage space of the host or write the executed and completed commands into the storage space of the host through the bus between the host and the hard disk controller.
[0014] Front - end verification of a hard disk controller is to simulate processes such as the host writing commands into the submission queue, the hard disk controller reading commands from the submission queue, executing the commands, and writing the executed - completed commands into the completion queue. From the above - related descriptions, it can be seen that whether writing commands or reading commands, operations need to be performed in the storage space of the host. However, due to the inconsistent bit widths of the storage space and the commands, during the front - end verification process of the hard disk controller, front - end verification personnel cannot read and write commands in the storage space of the host through simple storage - space operation methods, that is, the front - end verification of the hard disk controller is difficult to implement.
[0015] In view of this, the present application provides a host model for front - end verification of a hard disk controller, which can reduce the difficulty of front - end verification of the hard disk controller.
[0016] In this embodiment, the host model can be constructed based on the object - oriented programming syntax in the SystemVerilog language. SystemVerilog is a high - level language for hardware description and verification, which supports front - end verification personnel to construct the host model by defining classes, objects, and inheritance. The constructed host model can run in the target device. The target device can include, but is not limited to, electronic devices such as tablet computers, laptop computers, desktop computers, and servers.
[0017] Refer to Figure 1 , which is a schematic structural diagram of the host model provided in some embodiments of the present application. Figure 1 In, the host model includes a submission model, a completion model, and a management model.
[0018] The submission model can include a submission queue and a command - publishing method. Among them, the submission queue is a command queue to be executed by the hard disk controller. In response to the call of the command - publishing method, the submission model can add a new command to the submission queue. Specifically, during 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 - publishing method can be the target command that the host needs to issue to the submission queue during the front - end verification process. For example, the target command can be a 64B NVMe command. During the running process of the command - publishing 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 realized.
[0019] The completion model includes a completion queue and a retrieval method. Among them, the completion queue is a command queue that the hard disk controller has executed and completed. In response to the retrieval method being called, the completion model can retrieve commands in the completion queue. Specifically, similar to the submission model, during the process of constructing the completion model, the second capacity of the completion queue can be specified. 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 allocated in the target device running the host model. The second storage space can be used to store the completion queue in the completion model. During the operation of the retrieval method, at least some 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 from the completion queue, it means that the command has been executed and completed.
[0020] The management model includes an outstanding command array, which is used to store the commands that the hard disk controller has not executed and completed. Specifically, the outstanding command array can store the commands in the submission queue that have not been read by the hard disk controller, as well as the commands in the submission queue that have been read by the hard disk controller but have not been executed and completed. When a command is saved to the submission queue, the command can be saved to the outstanding command array at the same time. When the management model calls the retrieval method, it can retrieve the commands in the outstanding command array from the completion queue. For any command in the outstanding command array, if the command is retrieved from the completion queue, it means that the command has been executed and completed. Therefore, the retrieved command can be deleted from the outstanding command array.
[0021] Specifically, the management model can call the retrieval method at preset time intervals to retrieve the commands in the outstanding command array from the completion queue in real time and delete the retrieved commands from the outstanding command array. Based on the outstanding command array, the commands that the hard disk controller has not executed and completed and the commands that have been executed and completed can be effectively tracked.
[0022] 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 outstanding command array. Therefore, based on the submission queue, the completion queue, and the outstanding command array, the communication between the host and the hard disk controller can be simulated, and the commands that have not been executed and completed can be tracked to achieve the 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. In this way, 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 inconsistent bit widths of the storage space and the commands, thus solving the problem that the front-end verification of the hard disk controller in some technologies is difficult to implement.
[0023] Continue to refer to Figure 1。In this embodiment, when constructing the host model based on the object-oriented programming syntax in SystemVerilog language, the submission model, the completion model, and the 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.
[0024] Refer to Figure 2 , which is a schematic structural diagram of the target model provided by some other embodiments of the present application. Figure 2 In, in the case of 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 a command to the submission queue it includes, and each completion model retrieves a command from the completion queue it includes.
[0025] For example, assume there are submission queues 1, 2,..., n and completion queues 1, 2,..., n. Then the host model can include submission models 1, 2,..., n and completion models 1, 2,..., n. Among them, submission model 1 can include submission queue 1, submission model 2 can include submission queue 2,..., submission model n can include submission queue n, and completion model 1 can include completion queue 1, completion model 2 can include completion queue 2,..., completion model n can include completion queue n.
[0026] In response to the call of the command publishing method in submission model 1, submission model 1 can add a command to submission queue 1. In response to the call of the command publishing method in submission model 2, submission model 2 can add a command to submission queue 2. And so on. Similarly, in response to the call of the retrieval method in completion model 1, completion model 1 can retrieve a command from completion queue 1. In response to the call of the retrieval method in completion model 2, completion model 2 can retrieve a command from completion queue 2. And so on.
[0027] Each submission queue in each submission model can have its corresponding first capacity, that is, the maximum number of commands that can be accommodated in the submission queues of different submission models can 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, each completion queue in each completion model can have its corresponding second capacity, that is, the maximum number of commands that can be accommodated in the completion queues of different completion models can be the same or different. In this way, in the front-end verification of the hard disk controller, multiple submission queues and completion queues with different capacities can be simulated and set for the hard disk controller according to actual needs, so as to meet various different verification requirements.
[0028] Further, 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 be in one-to-one correspondence and association. For any submission model, the hard disk controller reads commands from the submission queue of the submission model, and after the commands are executed, puts the executed commands into the completion queue of the completion model associated with the submission model. For example, assume 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.
[0029] Further, in the case where the host model includes multiple submission models and multiple completion models, multiple submission models, multiple completion models, and an outstanding 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.
[0030] In the above embodiments, 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 management can be performed on different submission queues based on different submission models, and different management can be performed on different completion queues based on different completion models. The flexibility of the solution is high, and various different verification requirements can be met.
[0031] For ease of understanding, with reference to Figure 3 , the class structure of the submission model provided by some embodiments of this application is shown. As Figure 3 shown, in the class structure of the submission model, the model identifier, submission queue capacity, submission queue base address, command issuance 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. The command issuance method can refer to the relevant description in Figure 1 , which will not be elaborated here.
[0032] Figure 3 In
[0033] , the model identifier refers to the model identifier of the submission model.
[0034] The base address of the submission queue refers to the starting address of the first storage space allocated for the submission queue in the submission model. The commands to be saved to the submission queue start from this base address and are sequentially saved in the first storage space. The first storage space can be reused cyclically. For example, commands are sequentially saved starting from the base address of the first storage space until the end address of the first storage space is reached. Then, it can return from the end address to the base address and start saving commands again from the base address.
[0035] The model identifier of the associated completion model refers to the model identifier of the completion model associated with the submission model.
[0036] 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 new command when the command issuance method is called next time. After adding one or more commands to the submission queue each time, the storage address next_index1 will change accordingly. For example, assume that when the command issuance method is called for the first time, a new command is saved at the storage address address1. Then, after the command issuance 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 issuance method is called for the second time, the new command can be saved at the storage address address2. Similarly, after the command issuance 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 issuance method is called for the third time, the new command can be saved at the storage address address3. And so on.
[0037] In the target device where the host model runs, it can include registers corresponding to the submission model. This register can be used to store the storage address next_index1 of the submission model. When the hard disk controller monitors a change in the value in the register, it can determine that a new command has appeared in the submission queue, and then it can read the new command from the submission queue.
[0038] The storage address of the next command to be read, also known as the storage address head_ptr, refers to the storage address of the command that needs to be read when the hard disk controller reads a command from the submission queue next time. After the hard disk controller executes a read command operation from the submission queue each time, the storage address head_ptr will change accordingly. The relevant principle is similar to that of the storage address next_index1 and will not be elaborated here.
[0039] In the above storage addresses next_index1 and head_ptr, the value of the storage address next_index1 can be maintained by the submission model. For example, during the running of the command issuing method, the latest storage address next_index1 can be written into the register corresponding to the submission model. And the value of the storage address head_ptr can be maintained by the hard disk controller. For example, after the hard disk controller finishes each command reading operation, the storage address head_ptr can be updated based on the storage address of the last read command.
[0040] The register update interface refers to the interface used to update the value in the register corresponding to the submission model. For example, during the running of the command issuing method, the register update interface can be called to update the value of the storage address next_index1 in the register corresponding to the submission model.
[0041] For Figure 3 Instantiating the class shown can obtain different submission models. For example, setting the model identifier to 001, setting the model identifier of the completion model associated with the submission model to 002, setting the submission queue capacity to 20, setting the submission queue base address to address1, setting the command issuing method to method F1, and setting the register update interface to interface M, submission model A1 can be obtained. Another example is setting the model identifier to 003, setting the model identifier of the completion model associated with the submission model to 004, setting the submission queue capacity to 25, setting the submission queue base address to address2, setting the command issuing method to method F1, and setting the register update interface to interface M, submission model A2 can be obtained.
[0042] In the case of obtaining multiple submission models by instantiation, in the target device where the host model runs, there can be registers corresponding one-to-one to the submission models. Each register is used to save the storage address next_index1 of the corresponding submission model.
[0043] In this embodiment, in the class definition of the submission model, the register update interface can be a virtual interface. After obtaining the submission model by instantiation, a real interface can be connected to the instantiated submission model, so that the submission model can update the storage address next_index1 in the register through this real interface.
[0044] Refer to Figure 4 , for the class structure of the completion model provided by some embodiments of this application. As 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 retrieval method, second retrieval method, register update interface, interrupt count value, first status flag, and retrieval start position are defined. Among them, the model identifier, completion queue capacity, and completion queue base address are similar to Figure 3 and will not be elaborated here. The following will explain the other parameters in Figure 4 .
[0045] Figure 4 In ,
[0045] , Figure 4 , the retrieval start position, also known as the storage address next_index2, refers to the start address when the completion model retrieves commands in the completion queue. After each command retrieval operation is performed by the completion model 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 elaborated here. The target device running the host model may include registers corresponding to the completion model. This register can be used to save the storage address next_index2 of the corresponding completion model. When the hard disk controller writes the executed command into 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 can avoid overwriting the commands that the completion model has not yet retrieved.
[0046] The register update interface refers to the interface used to update values in the register corresponding to the completion model. For example, during the operation of the first retrieval method, the register update interface can be called to update the storage address next_index2 in the register corresponding to the completion model.
[0047] Furthermore, as Figure 4 shown, in some embodiments, each completion model may have its own corresponding interrupt number. The interrupt numbers of different completion models are different. This interrupt number can be the model identifier of the completion model. For example, assume that the model identifier of completion model A1 is 001 and the model identifier of completion model A2 is 002. Then the interrupt number corresponding to completion model A1 is 001, and the interrupt number corresponding to completion model A2 is 002.
[0048] The target device where the host model is located is connected to the hard disk controller via a bus. After the hardware controller finishes executing a command, when writing the executed and completed command to the completion queue in any of the completion models, it can send an interrupt message to the target device via the bus. The interrupt message is used to identify the interrupt number corresponding to the completion model where the completion command is currently being written. Specifically, the interrupt message can include, but is 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 the interrupt messages corresponding to different completion models by writing specific values to a specific address of the host model via the bus. For example, writing the value 0 to address 1 indicates transmitting the interrupt message of completion model A1, and writing the value 1 to address 2 indicates transmitting the interrupt message of completion model A2.
[0049] The host model can include a monitoring component and a counter corresponding to each completion model one by one. The monitoring component monitors the interrupt message by monitoring whether there is a write transfer of a specific value at a specific address. When the interrupt message is monitored, the monitoring component can determine the completion model where the completion command is currently being written based on the interrupt message, and update the counter corresponding to the corresponding completion model (such as incrementing the value in the counter by 1). For example, if the interrupt message represents the interrupt number of completion model A1, then update the counter corresponding to completion model A1; if the interrupt message represents the interrupt number of completion model A2, then update the counter corresponding to completion model A2. In this way, the value in the counter can represent the current interrupt count value of the completion model. Correspondingly, the interrupt count value in the completion model can represent the value in the counter corresponding to the last retrieval of the completion queue included in the completion model.
[0050] For the above solution based on the interrupt number, it can be configured in the completion model whether to use the solution based on the interrupt number. Specifically, by configuring the parameter "whether to use interrupt" in the completion model, it can be configured whether the completion model uses the solution based on the interrupt number.
[0051] Further, 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 saved interruption count value with the value in the counter. If the locally saved interruption count value is different from the value in the counter, it indicates that the commands in the completion queue included in the completion model have been updated. At this time, the second retrieval method may be run. During the running process of the second retrieval method, the storage address next_index2 may be obtained, and starting from the storage address next_index2, it may be retrieved whether there are commands newly written by the hard disk controller in the completion queue. If there are commands newly written by the hard disk controller in the completion queue, all the commands newly written by the hard disk controller may be retrieved.
[0052] Further, since the commands in the completion queue recycle the storage space repeatedly, it is necessary to distinguish the new and old commands written by the hard disk controller in the completion queue. For ease of understanding, refer to Figure 5 for a schematic diagram of the hard disk controller writing commands in the completion queue provided by some embodiments of the present application. Figure 5 In [the figure], along the arrow direction, assume that during the command writing process in the first stage by the hard disk controller, commands marked as 1 are written at each command position in the completion queue. After completing the writing in the first stage and reaching the end position of the completion queue, the hard disk controller continues to return to the starting position of the completion queue and writes commands marked as 0. From Figure 5 it can be seen that although the commands marked as 1 are located after the commands marked as 0, the commands marked as 1 are the old commands written by the hard disk controller, while the commands marked as 0 are the new commands written by the hard disk controller. Based on this, assume that during the running process of the second retrieval method, the storage address next_index2 points to the starting position of the completion queue. Then, the first 3 commands marked as 0 should be the new commands written by the hard disk controller and need to be retrieved, while the subsequent commands marked as 1 are the old commands written by the hard disk controller and do not need to be retrieved.
[0053] In summary, in this embodiment, the completion model may locally maintain a first status flag, and the value of the first status flag may be 0 or 1. According to the capacity of the completion queue included in the completion model, after traversing the completion queue once (i.e., after traversing from the starting position to the end position of the completion queue), the value of the first status flag is flipped once. By flipping, it means modifying the value of the first status flag to the other value among 0 and 1. For example, when the value of the first status flag is 0, after flipping, the value of the first status flag becomes 1. Conversely, when the value of the first status flag is 1, after flipping, the value of the first status flag becomes 0.
[0054] In the commands written to the completion queue, the hard disk controller maintains a second status flag (i.e., uses the second status flag to identify the commands in 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 compares the first status flag saved locally 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 in the completion queue written by the hard disk controller that has not been overwritten by a new command. At this time, this 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 in the completion queue written by the hard disk controller. At this time, this command can be used as a new command in the completion queue written by the hard disk controller.
[0055] Similar to Figure 3 , instantiating the class shown Figure 4 can obtain different completion models.
[0056] In the case of obtaining multiple completion models by instantiation, in the target device where the host model runs, it can include registers corresponding one-to-one to the completion models. Each register is used to save the storage address next_index2 of the corresponding completion model.
[0057] Referring to Figure 6 , it is the class structure of the management model provided by some embodiments of this application. As Figure 6 shown, in the class of the management model, an object set all_sq[] of the submission model, an object set all_cq[] of the completion model, a command receiving method, a polling method, a post-processing method, and an outstanding command array are defined. Among them, regarding the outstanding command array, reference can be made to Figure 1 the relevant description, and for the command receiving method, the polling method, and the post-processing method, reference can be made to the subsequent relevant description, which will not be elaborated here.
[0058] In the syntax of object-oriented programming in the SystemVerilog language, the object sets all_sq[] and all_cq[] can be SV language associative arrays. In the object set all_sq[], one or more submission models can be included. The index type is the model identifier of the submission model, and the data type is Figure 3 the class object of the submission model in Figure 4The class object of the completion model. The submission models in the object set all_sq[] and the completion models in the object set all_cq[] can be corresponding and associated one by one. For example, assume that the object set all_sq[] includes submission models A1 and A2, and the object set all_cq[] includes completion models B1 and B2. Then, the submission model A1 can be associated with the completion model B1, and the submission model A2 can be associated with the completion model B2. Figure 6 The meaning is: By packing the submission models in the object set all_sq[], the completion models in the object set all_cq[], and an array of pending commands, a management model class can be obtained.
[0059] By instantiating the management model class, multiple different management models can be obtained. For example, by filling the submission models A1 and A2 in the object set all_sq[] and the completion models B1 and B2 in the object set all_cq[], the management model M1 can be obtained. Another example, in the management model class, by filling the submission models C1 and C2 in the object set all_sq[] and the completion models D1 and D2 in the object set all_cq[], the management model M2 can be obtained.
[0060] 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 running process of the post-processing method, submission models and completion models can be added to the object sets all_sq[] and all_cq[] of the management model. Or, during the running process of the post-processing method, submission models and completion models can be deleted from the object sets all_sq[] and all_cq[] of the management model. In this way, the dynamic modification of submission models and completion models is realized.
[0061] Further, with reference to Figure 7 , which is the structural schematic diagram of the host model provided by some embodiments of the present application. Figure 7 In, 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. Briefly speaking, as Figure 7 shown, each hard disk controller can respectively correspond to an instance of the management model class, that is Figure 7The management models in it. The management models corresponding to different hard disk controllers are different. For example, in the management model corresponding to the 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 the 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. In this way, front-end verification can be performed on different hard disk controllers simultaneously, which is quite applicable.
[0062] The following combines the above Figures 2 to 6 to illustrate how to perform front-end verification of the hard disk controller based on the host model of this application.
[0063] 1) In response to the call of the command receiving method, 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: Write the target command into the pending command array, and use the combined index to identify the target command. The combined index includes the position identifier of the target command in the target submission queue and the model identifier of the target submission model.
[0064] Call the command publishing method of the target submission model to enable the target submission model to add the target command to the target submission queue included in the target submission model.
[0065] 2) After the target submission model adds the target command to the target submission queue, write the storage address of the next command to be saved to the target submission queue into the first register corresponding to the target submission model; in response to the change of 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.
[0066] Specifically, the command receiving method in the management model is a method provided for front-end verification personnel to call. The input parameters of the command receiving method can include the target command to be submitted to the storage controller and the model identifier of the target submission model to which the target command needs to 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 operating the host storage space.
[0067] Based on the above descriptions related to 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 to 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.
[0068] Based on the information in the target submission model, during the running process of the command publishing method, the target storage address of the target command can be calculated first based on the queue base address of the target submission queue and the storage address next_index1, and then the system function $deposit can be called to write the target command into the target submission queue. Then, the storage address next_index1 is updated, and the updated storage address next_index1 is written into the first register through the interface for updating the first register.
[0069] 3) After writing the target command into the pending command array, the management model also traverses the target commands in the pending command array, and determines the target submission model and the target completion model associated with the target submission model based on the combined index of the target commands, and retrieves whether there is a target command in the target completion queue included in the target completion model. Specifically, if a target command is retrieved in the target completion queue, the target command is deleted from the pending command array. Specifically, after determining the target completion model, the management model calls the retrieval method in the target completion model. In response to the call of the retrieval method, the target completion model retrieves whether there is a target command in the target completion queue included.
[0070] Specifically, as Figure 6 described, the management model can include a polling method and a post-processing method. The management model can run the polling method every preset time period. During the running process of the polling method, it traverses the target commands in the pending command array and determines the target submission model and the target completion model associated with the target submission model based on the combined index of the target commands; The polling method passes the model identifier of the target completion model to the post-processing method. During the running process of the post-processing method, it retrieves whether there is a target command in the target completion queue included in the target completion model, and deletes the target command from the pending command array if a target command is retrieved in the target completion queue. Among them, during the running process of the post-processing method, the retrieval method in the target completion model can be called to retrieve whether there is a target command in the target completion queue included.
[0071] 4) In response to the retrieval method being called, the target completion model compares the locally saved interrupt count value with the value in the target counter. If the interrupt count value is equal to the value in the target counter, it retrieves whether there is a target command in the target completion queue. Before retrieving the target command, the target completion model also obtains the first retrieval start position. When retrieving the target command, the target completion model starts from the first retrieval start position of the target completion queue to retrieve whether there is a target command.
[0072] Specifically, during the operation of the post-processing method, the first retrieval method in the target completion model can be called. In response to the first retrieval method being called, the target completion model compares the locally saved interrupt count value with the value in the target counter. When the interrupt count value is different from the value in the target counter, it runs the second retrieval method to obtain the first retrieval start position and starts from the first retrieval start position of the target completion queue to retrieve whether there is a target command.
[0073] Specifically, as Figure 4 As described relatedly, in the target completion model, it can 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, during the operation of the second retrieval method, all new commands newly written by the hard disk controller to the target completion queue can be retrieved. The second retrieval method can return all the retrieved new commands to the post-processing method of the management model. The post-processing method looks for whether there is a target command among the commands returned by the second retrieval method based on the combined index in the command. If it exists, the target command is deleted from the outstanding command array of the management model. If it does not exist, the target command continues to be retained in the outstanding command array of the management model.
[0074] 5) After completing the retrieval in the target completion queue, the target completion model also determines the second retrieval start position for the next retrieval in the target completion queue and writes the second retrieval start position into the second register corresponding to the target completion model. When the hard disk controller writes the executed and completed commands into the target completion queue next time, it determines the command write position based on the second retrieval start position in the second register.
[0075] 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, where the submission model includes a submission queue, the completion model includes a completion queue, and the management model includes an array of outstanding commands. Therefore, based on the submission queue, the completion queue, and the array of outstanding commands, the communication between the host and the hard disk controller can be simulated, and the commands that have not been completed can be tracked to achieve the front-end verification of the hard disk controller. On the other hand, the submission model, the completion model, and the management model provide callable methods. In this way, 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 inconsistent bit widths of the storage space and the commands, thus solving the problem that it is difficult to implement the front-end verification of the hard disk controller in some technologies.
[0076] The above has introduced in detail a host model for front-end verification of a hard disk controller provided by the present application. Specific examples are used in this article to elaborate on the principle and implementation manner of the present application. The description of the above embodiments is only used to help understand the method and its core idea of the present application. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present 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. The submission queue is a queue of commands to be executed by the hard disk controller. In response to the invocation of the command issuing method, the submission model adds a command to the submission queue. A completion model, including a completion queue and a retrieval method. The completion queue is a queue of commands that have been executed and completed by the hard disk controller. In response to the invocation of the retrieval method, the completion model retrieves a command from the completion queue. A management model, including an array of outstanding commands, which is used to save the commands that have not been executed and completed by the hard disk controller. The management model invokes the retrieval method to retrieve the commands in the array of outstanding commands from the completion queue, and deletes the retrieved commands from the array of outstanding commands.
2. The host model according to claim 1, characterized in that In the case of 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 a command to its respective submission queue, and each completion model retrieves a command from its respective completion queue.
3. The host model according to claim 2, wherein The management model includes a command receiving method. In response to the invocation of the command receiving method, the management model receives a target command and a target model identifier, determines a target submission model based on the target model identifier, and invokes the command issuing method of the target submission model. In response to the invocation of the command issuing method, the target submission model adds the target command to the target submission queue included in the target submission model.
4. The host model according to claim 3, wherein The host model runs in a target device, which includes registers corresponding one-to-one to the submission models, and the submission models and the completion models correspond one-to-one and are associated with each other. After adding the target command to the target submission queue, the target submission model writes the storage address of the next command to be saved to 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 executed and completed target command into the completion queue of the target completion model associated with the target submission model.
5. The host model according to claim 4, wherein The target submission model further includes at least one of the following pieces of 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 to 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.
6. The host model according to claim 4, characterized in that, In response to the invocation of the command receiving method, the management model is further configured to write the target command into the array of outstanding commands and identify the target command using a combined index, where the combined index includes the position identifier of the target command in the target submission queue and the model identifier of the target submission model.
7. The host model according to claim 6, 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.
8. The host model according to claim 7, wherein The management model also includes a polling method and a post-processing method; During the operation of the polling method, the target command in the pending command array is traversed, and based on the combined index of the target command, the target submission model and the target completion model associated with the target submission model are determined; The polling method passes the model identifier of the target completion model to the post-processing method. During the operation of the post-processing method, it is retrieved whether the target command exists in the target completion queue included in the target completion model, and in the case where the target command is retrieved in the target completion queue, the target command is deleted from the pending command array.
9. The host model according to claim 7, characterized in that, After determining the target completion model, the management model calls the retrieval method in the target completion model; In response to the retrieval method being called, the target completion model retrieves whether the target command exists in the target completion queue included therein.
10. The host model according to claim 9, characterized in that, Each completion model has its own corresponding interrupt number. The host model also includes a monitoring component and a counter corresponding one-to-one to the completion model. When the hard disk controller finishes executing the target command, it also sends a target interrupt message, which 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 saved interrupt count value with the value in the target counter. If the interrupt count value is equal to the value in the target counter, it retrieves whether the target command exists in the target completion queue.
11. The host model according to claim 10, characterized in that, Before retrieving the target command, the target completion model also obtains a first retrieval start position; When retrieving the target command, the target completion model starts from the first retrieval start position of the target completion queue and retrieves whether the target command exists.
12. The host model according to claim 11, characterized in that, The target device includes registers corresponding one-to-one to the completion models; After completing the retrieval in the target completion queue, the target completion model also determines a second retrieval start position for the next retrieval in the target completion queue, and writes the second retrieval start position into the second register corresponding to the target completion model. When the hard disk controller writes the executed and completed command into the target completion queue next time, it determines the command writing position according to the second retrieval start position in the second register.
13. The host model according to claim 12, characterized in that, The retrieval methods in the target completion model include a first retrieval method and a second retrieval method; In response to the call of the first retrieval method, the target completion model compares the locally saved interruption count value with the value in the target counter, and if the interruption count value is different from the value in the target counter, runs the second retrieval method to obtain the first retrieval start position, and starts retrieving from the first retrieval start position of the target completion queue to check if there is the target command.
14. The host model according to claim 1, characterized in that, 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.
15. The host model according to claim 14, characterized in that, The management model is also used to manage the deletion or addition of the submission model and the completion model.
Citation Information
Patent Citations
Realization method for NVMe extension and solid state disk
CN108549610A
Storage devices configured to support multiple hosts and operation methods thereof
CN113342256A
Storage virtualization device, operating method thereof, and operating method of system having same
CN114443209A
NVMe storage acceleration system with complete hardware unloading
CN115826872A
Memory device and operating method thereof
CN116028390A