Electronic device
Patent Information
- Application Number
- CN202511263385.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2025-03-10
- Filing Date
- 2025-09-05
- Publication Date
- 2026-09-11
AI Technical Summary
[0006] According to one embodiment, the electronic device includes random access memory and interface circuitry. The interface circuitry performs communication between the electronic device and an external electronic device. The interface circuitry stores data received from the external electronic device in the random access memory. The interface circuitry manages multiple credit values, each corresponding to a multiple category, and each representing the amount of data of the corresponding category that can currently be received from the external electronic device. The interface circuitry sends a first packet, including credit information representing at least one of the multiple credit values, to the external electronic device.
Smart Images

Figure CN122733769A_ABST
Abstract
Description
Technical Field
[0001] Embodiments of the present invention relate to techniques for controlling data transmission between electronic devices. Background Technology
[0002] PCI Express is one of the known interface standards for connecting two electronic devices. TM (PCIe TM The PCIe standard allows two electronic devices to be connected via a transmission path called a link, using an interface that conforms to the PCIe standard. Data is transmitted using packets on the link.
[0003] Two electronic devices, such as a host and a storage system, can be used. In this case, the data transmitted using packets includes, for example, requests from the host to the storage system, responses from the storage system to the host, or user data.
[0004] In PCIe Gen6 (PCIe 6.0 standard), a new Flit (flow control unit) mode was defined. Flit mode transmits data in units called Flit packets. In Flit mode, data received from the upper layer is broken down into Flit packets, which are stored in 256-byte units, and then transmitted in Flit units. Summary of the Invention
[0005] One implementation provides an electronic device capable of efficiently transmitting information related to data transmission between electronic devices.
[0006] According to one embodiment, the electronic device includes random access memory and interface circuitry. The interface circuitry performs communication between the electronic device and an external electronic device. The interface circuitry stores data received from the external electronic device in the random access memory. The interface circuitry manages multiple credit values, each corresponding to a multiple category, and each representing the amount of data of the corresponding category that can currently be received from the external electronic device. The interface circuitry sends a first packet, including credit information representing at least one of the multiple credit values, to the external electronic device. Attached Figure Description
[0007] Figure 1 This is a block diagram illustrating an example configuration of an information processing system including the electronic device of the first embodiment.
[0008] Figure 2 This is a block diagram illustrating a configuration example of the electronic device according to the first embodiment.
[0009] Figure 3This is a diagram illustrating an example of the configuration of a credit management table used in the electronic device of the first embodiment.
[0010] Figure 4 This is a diagram illustrating an example of the configuration of a credit management form used in the electronic device of the first embodiment.
[0011] Figure 5 This is a diagram illustrating an example of credit information being sent from an electronic device of the first embodiment to an external electronic device.
[0012] Figure 6 This is a diagram illustrating an example of the data layout of Flit used in the electronic device of the first embodiment.
[0013] Figure 7 This is a diagram illustrating an example of the format of a data link layer packet (DLLP) payload used in the electronic device of the first embodiment.
[0014] Figure 8 This is a diagram illustrating an example of credit information stored in the DLLP payload in the electronic device of the first embodiment.
[0015] Figure 9 This is a diagram illustrating another example of credit information stored in the DLLP payload in the electronic device of the first embodiment.
[0016] Figure 10 This is a diagram illustrating an example of the Flit transmission operation in the electronic device of the first embodiment.
[0017] Figure 11 This is a flowchart illustrating an example of the steps of the transmission control process performed in the electronic device of the first embodiment.
[0018] Figure 12 This is a diagram illustrating an example of Flit receiving operation in an electronic device according to the first embodiment.
[0019] Figure 13 This is a flowchart illustrating an example of the steps of the receiving control process performed in the electronic device of the first embodiment.
[0020] Figure 14 This is a diagram illustrating an example of a combination of category identifier and credit information stored in the DLLP payload in an electronic device according to the second embodiment.
[0021] Figure 15 This is a diagram illustrating an example of N combinations and the number of categories of category information and credit information stored in the DLLP payload in the electronic device of the second embodiment.
[0022] Figure 16 This is a flowchart illustrating an example of the steps of the transmission control process performed in the electronic device of the second embodiment.
[0023] Explanation of reference numerals in the attached figures
[0024] 1…Information processing system, 1T…Electronic device (transmitter), 1R…Electronic device (receiver), 2…Host, 3…Storage system, 4…NAND flash memory, 5…DRAM, 6…Controller, 7…Link, 8…Flit, 11…CPU, 12…NAND I / F, 13…DRAM I / F, 14…Host I / F, 21…CPU, 22…RAM, 23…Storage I / F, 31…Credit management department, 32…Packet generation department, 33…Packet sending department, 351…Receive credit management table, 352…Send credit management table, 41…Credit management department, 42…Packet receiving department, 43…Packet parsing department, 44…Notification control department, 451…Receive credit management table, 452…Send credit management table, 51…DLLP payload, 511…DLLP type, 512…DLLP type specific information information), 81…TLP, 82…DLP, 83…CRC, 84…ECC. Detailed Implementation
[0025] Hereinafter, the embodiments will be described with reference to the accompanying drawings.
[0026] (First Embodiment)
[0027] First, refer to Figure 1 An example of the configuration of an information processing system including the electronic device of the first embodiment will be described. Information processing system 1 is a system for data transfer between electronic device 1T and electronic device 1R. In the case of data transfer, one of the two electronic devices 1T and 1R functions as a transmitter to send data, and the other functions as a receiver to receive the data. Figure 1 The example illustrates the case where electronic device 1T is a transmitter and electronic device 1R is a receiver.
[0028] Electronic device 1T and electronic device 1R are connected, for example, via a serial interface including a link 7 that enables them to be interconnected. This serial interface conforms, for example, to the PCIe Gen6 standard. The PCIe Gen6 standard specifies Flit mode. Flit mode is a mode in which data is transmitted in units called Flits. In Flit mode, data received from the upper layer is broken down, for example, into Flits of 256 bytes each, and transmitted in Flit units.
[0029] Specifically, Flit8 is transmitted from electronic device 1T to electronic device 1R via link 7. That is, electronic device 1T sends Flit8 to electronic device 1R via link 7. Electronic device 1R receives Flit8 from electronic device 1T via link 7. When electronic device 1T is the receiver and electronic device 1R is the transmitter, Flit8 can also be transmitted from electronic device 1R to electronic device 1T via link 7.
[0030] The following is a specific example of the case where electronic device 1T is a storage system and electronic device 1R is a host device.
[0031] Figure 2 This is a block diagram illustrating an example of the configuration of a storage system and host devices.
[0032] Host device 2 is an information processing device that stores data in storage system 3. Host device 2 is, for example, a storage server that stores large amounts of diverse data in storage system 3, or a personal computer. Hereinafter, host device 2 will be referred to as host 2.
[0033] Storage system 3 is a semiconductor storage device configured to write data to and read data from non-volatile memory. The non-volatile memory is, for example, NAND flash memory 4. Storage system 3 is also referred to as a storage device. Storage system 3 is implemented, for example, as a solid-state drive (SSD) including NAND flash memory 4.
[0034] Storage system 3 can be used as storage for host 2. Storage system 3 can be connected to host 2.
[0035] The interface used to connect host 2 to storage system 3 conforms to PCIe and NVM Express. TM (NVMe TM Standards such as )
[0036] (Composition of storage system 3)
[0037] The storage system 3 includes, for example, NAND flash memory 4, dynamic random access memory (DRAM) 5, and a controller 6.
[0038] NAND flash memory 4 includes one or more memory chips. Each memory chip includes a memory cell array. The memory cell array includes multiple blocks. Each block includes multiple memory cells configured to store data in a non-volatile manner. Each block functions as the smallest unit of data erasure. A block is also called an erase block or a physical block. Each block includes multiple pages. Each page includes multiple memory cells connected to a single word line. Each page functions as the unit of data write and data read operations. Additionally, a word line can also function as the unit of data write and data read operations.
[0039] DRAM5 is a volatile memory. DRAM5 storage areas can be allocated, for example, as firmware (FW) storage areas and cache areas for logical-physical address translation tables. DRAM5 storage areas can also be allocated as buffer areas for temporarily storing data received from the outside (reception buffer) and buffer areas for temporarily storing data to be sent to the outside (transmission buffer).
[0040] Controller 6 is a memory controller that controls the NAND flash memory 4 and DRAM 5. Controller 6 is implemented, for example, through a system-on-a-chip (SoC) circuit.
[0041] The controller 6 includes, for example, a central processing unit (CPU) 11, a NAND interface circuit (NAND I / F) 12, a DRAM interface circuit (DRAM I / F) 13, and a host interface circuit (host I / F) 14. These CPU 11, NAND I / F 12, DRAM I / F 13, and host I / F 14 can be connected via bus 10. The controller 6 may also include static random access memory (SRAM). SRAM is volatile memory. The SRAM is connected to various parts within the controller 6, for example, via bus 10. The SRAM can store at least a portion of the data (information) stored in the aforementioned DRAM 5. For example, the storage area of the SRAM can also be allocated as a receive buffer and a transmit buffer.
[0042] CPU 11 is a processor configured to control NAND I / F 12, DRAM I / F 13, and host I / F 14. CPU 11 performs various processes by executing a process flow (FW) that loads data from NAND flash memory 4 into DRAM 5. The FW is a control program containing a group of commands for causing CPU 11 to perform various processes. This processing includes command processing for handling various commands from host 2. The operation of CPU 11 is controlled by the FW executed by CPU 11. The functions of each part within controller 6 can be implemented either by dedicated hardware within controller 6 or by CPU 11 executing the FW.
[0043] The NAND I / F12 electrically connects the controller 6 to the NAND flash memory 4. The NAND I / F12 is compatible with interface standards such as toggle double data rate (toggle DDR) and open NAND flash interface (ONFI).
[0044] The NAND I / F12 functions as a NAND control circuit that controls the NAND flash memory 4. The NAND I / F12 can also be connected to multiple memory chips within the NAND flash memory 4 via multiple channels. By driving multiple memory chips in parallel, widening the access bandwidth between the NAND flash memory 4 and the controller 6 is achieved.
[0045] DRAM I / F13 functions as a DRAM control circuit that controls access to DRAM5.
[0046] The host I / F14 is a circuit that functions as an interface for communication between the storage system 3 and the host 2 (i.e., an external electronic device). The host I / F14 includes circuitry for sending packets to the host 2 and for receiving packets from the host 2. Packets are, for example, packets conforming to the PCIe standard. Packets may include, for example, commands, responses, or user data. Commands may be, for example, input / output (I / O) commands or control commands. I / O commands may be, for example, read commands or write commands. Control commands may be, for example, unmap commands (trim commands).
[0047] The host I / F14 includes, for example, a credit management unit 31, a packet generation unit 32, and a packet sending unit 33 as circuitry for sending packets to the host 2.
[0048] Credit management unit 31 is a circuit that manages credits in data transmission via link 7 between storage system 3 and host 2, categorized by type. Credits are the basis for flow control (FC) in data transmission. For example, if storage system 3 and host 2 comply with the PCIe standard, the credit categories are Posted Request headers (PH), Posted Request Data payload (PD), Non-Posted Request headers (NPH), Non-Posted Request Data payload (NPD), Completion headers (CplH), and Completion Data payload (CplD). Flow control is used to prevent overflow of the receive buffer in the receiving electronic device 1R (in this case, host 2) and to control the sending electronic device 1T (in this case, storage system 3) to transmit data according to the credits.
[0049] The credit management unit 41 includes a storage area 35. The storage area 35 is, for example, composed of SRAM. In the storage area 35, for example, a receive credit management table 351 and a send credit management table 352 are stored. The receive credit management table 351 is a table used to manage credit amounts representing the amount of data that can be received from an external source (here, host 2) by each category. The credit amounts representing the amount of data that can be received from an external source are also referred to as receive credit amounts. The send credit management table 352 is a table used to manage credit amounts representing the amount of data that can be sent to an external source by each category. The credit amounts representing the amount of data that can be sent to an external source are also referred to as send credit amounts. For a specific example of the configuration of the receive credit management table 351 and the send credit management table 352, refer to... Figure 3 and Figure 4 To be described later.
[0050] Credit Management Unit 31 uses Receive Credit Management Table 351 to manage the amount of credit received by each category. Specifically, upon initiation of communication with Host 2, Credit Management Unit 31 determines and manages the initial value of the amount of credit received for each category based on the storage capacity of the receive buffers allocated to each of the multiple credit categories. Furthermore, Credit Management Unit 31 manages the current amount of credit received for each category based on the free capacity of the receive buffers corresponding to each category. The current amount of credit received for a certain category is, for example, the amount of credit received after changing from the initial value of the amount of credit received for that category in accordance with the reception of data from Host 2 and the processing of that data.
[0051] For example, when new data is saved to the receive buffer corresponding to a certain category, the credit management unit 31 updates the current receive credit amount for that category by subtracting the credit amount based on the amount of saved data from the current receive credit amount for that category. Conversely, when data is discarded from the receive buffer corresponding to a certain category, the credit management unit 31 updates the current receive credit amount for that category by adding the credit amount based on the amount of discarded data to the current receive credit amount for that category.
[0052] Furthermore, the credit management unit 31 uses the transmission credit management table 352 to manage the transmission credit amount by category. Specifically, upon initiation of communication with the host 2, the credit management unit 31 manages the initial value of the transmission credit amount (i.e., the reception credit amount in the host 2) for each category as notified by the host 2. Moreover, the credit management unit 31 updates the current transmission credit amount for a category based on the change (increase or decrease) in credit for that category notified by the host 2. In other words, the current transmission credit amount for a category is, for example, the credit amount that changes from the initial value of the transmission credit amount for that category in accordance with the transmission of data to the host 2 and the processing of that data by the host 2.
[0053] For example, if host 2 notifies the consumption of a certain category of sending credits, the credit management unit 31 updates the current sending credit amount for that category by subtracting the notified consumption amount from the current sending credit amount managed for that category. Similarly, if host 2 notifies the recovery amount of a certain category of sending credits, the credit management unit 31 updates the current sending credit amount for that category by adding the notified recovery amount to the current sending credit amount managed for that category.
[0054] The packet generation unit 32 is a circuit that generates packets to be sent to the host 2. The packet is, for example, a Flit8. For example, when the CPU 11 requests the transmission of data to the host 2, the packet generation unit 32 generates a Flit8 that includes at least a portion of that data. The data requested for transmission may include data related to transactions in the host 2. The packet generation unit 32 may also cooperate with the credit management unit 31 to generate a Flit8 that also includes information indicating the current credit amount received for each category. This information indicating the current credit amount received for each category is also referred to as credit information. The packet generation unit 32 sends the generated Flit8 to the packet sending unit 33.
[0055] The packet sending unit 33 is a circuit connected to the host 2 via a serial interface. This serial interface includes a link 7 that connects the host 2 to the storage system 3. The packet sending unit 33 is, for example, equivalent to the physical layer (PCIe PHY) defined by the PCIe standard. The packet sending unit 33, for example, has a physical connection conforming to the PCIe standard. The packet sending unit 33 performs interface operations to physically send data via the link 7. Specifically, the packet sending unit 33, for example, sends Flit8 received from the packet generation unit 32 to the host 2 via the link 7.
[0056] Link 7 consists of multiple lanes. Each lane is a pair of signal lines used for transmitting signals from host 2 to storage system 3 and from storage system 3 to host 2. Figure 2 Link 7, consisting of four channels 0, 1, 2, and 3, is shown as an example.
[0057] Through the above configuration, the storage system 3 manages and controls the data transmission between itself and the host 2.
[0058] (The composition of host 2)
[0059] The host 2 includes, for example, a CPU 21, random access memory (RAM) 22, and memory interface circuitry (memory I / F) 23. These components, such as the CPU 21, RAM 22, and memory I / F 23, can be connected via a bus 20.
[0060] CPU 21 is a processor configured to control RAM 22 and memory I / F 23. CPU 21 performs various processes, for example, by executing programs loaded into RAM 22. Programs executed by CPU 21 include, for example, operating systems, device drivers, and application programs. Processing performed by CPU 21 includes issuing commands to memory system 3 and receiving responses to those commands. The operation of CPU 21 is controlled by the programs executed by CPU 21. The functions of various parts within host 2 can be implemented through dedicated hardware within host 2 or through programs executed by CPU 21.
[0061] RAM22 is a volatile memory. RAM22's storage areas can be allocated, for example, as program storage areas. RAM22's storage areas can also be allocated as buffer areas (receive buffers) for temporarily storing data received from the outside, and as buffer areas (transmit buffers) for temporarily storing data to be sent to the outside.
[0062] Storage I / F23 is a circuit that functions as an interface for communication between host 2 and storage system 3 (i.e., external electronic device). Storage I / F23 includes circuitry for sending packets to storage system 3 and circuitry for receiving packets from storage system 3.
[0063] The storage I / F23 includes, for example, a credit management unit 41, a packet receiving unit 42, a packet parsing unit 43, and a notification control unit 44 as circuitry for receiving packets from the storage system 3.
[0064] Credit management unit 41 is a circuit that manages credits in data transmission via link 7 between host 2 and storage system 3, categorized by type. Credit management unit 41 includes storage area 45. Storage area 45 is, for example, composed of SRAM. In storage area 45, for example, a receive credit management table 451 and a send credit management table 452 are stored. Receive credit management table 451 is a table used to manage, by type, the amount of credit (receive credit) representing the amount of data that can be received from the outside (here, storage system 3). Send credit management table 452 is a table used to manage, by type, the amount of credit (send credit) representing the amount of data that can be sent to the outside (send credit) representing the amount of data that can be sent to the outside.
[0065] Credit Management Department 41 uses Receive Credit Management Table 451 to manage the amount of credit received by each category. Specifically, upon initiation of communication with Storage System 3, Credit Management Department 41 determines and manages the initial value of the amount of credit received for each category based on the storage capacity of the receive buffers allocated to each of the multiple credit categories. Furthermore, Credit Management Department 41 manages the current amount of credit received for each category based on the free capacity of the receive buffers corresponding to each category. The current amount of credit received for a certain category is, for example, the amount of credit received after changes from the initial value of the amount of credit received for that category, in accordance with the receipt of data from Storage System 3 and the processing of that data.
[0066] For example, when new data is saved to the receive buffer corresponding to a certain category, the credit management unit 41 updates the current receive credit amount for that category by subtracting the credit amount based on the amount of saved data from the current receive credit amount for that category. Conversely, when data is discarded from the receive buffer corresponding to a certain category, the credit management unit 41 updates the current receive credit amount for that category by adding the credit amount based on the amount of discarded data to the current receive credit amount for that category.
[0067] Furthermore, the credit management unit 41 uses the transmission credit management table 452 to manage the transmission credit amount by category. Specifically, upon initiation of communication with the storage system 3, the credit management unit 41 manages the initial value of the transmission credit amount (i.e., the reception credit amount in the storage system 3) for each category as notified by the storage system 3. Moreover, the credit management unit 41 updates the current transmission credit amount for a category based on the change in credit amount for that category notified by the storage system 3. In other words, the current transmission credit amount for a category is, for example, the credit amount that changes from the initial value of the transmission credit amount for that category in accordance with the transmission of data to the storage system 3 and the processing of that data by the storage system 3.
[0068] For example, if the storage system 3 notifies the consumption of a certain category of transmission credits, the credit management unit 41 updates the current transmission credit amount for that category by subtracting the notified consumption amount from the current transmission credit amount managed for that category. Similarly, if the storage system 3 notifies the recovery amount of a certain category of transmission credits, the credit management unit 41 updates the current transmission credit amount for that category by adding the notified recovery amount to the current transmission credit amount managed for that category.
[0069] The packet receiving unit 42 is a circuit connected to the storage system 3 via a serial interface (more specifically, link 7). The packet receiving unit 42 corresponds, for example, to the physical layer defined by the PCIe standard. The packet receiving unit 42, for example, has a physical connection conforming to the PCIe standard. The packet receiving unit 42 performs interface operations to physically receive data via link 7. Specifically, the packet receiving unit 42 receives Flit8 from the storage system 3, for example, via link 7. The packet receiving unit 42 sends the received Flit8 to the packet parsing unit 43.
[0070] The packet parsing unit 43 is a circuit that parses the Flit8 received from the packet receiving unit 42. Specifically, the packet parsing unit 43 performs error detection and correction processing on the data included in the Flit8. If no error is detected, or if the detected error has been corrected, processing is performed on the data included in the Flit8. Specifically, the data in the Flit8 used for transactions in the host 2 is processed by, for example, the storage I / F 23 and the CPU 21. In addition, if credit information representing the receiving credit amount in the storage system 3 is included in the Flit8, the packet parsing unit 43 can determine whether the credit information corresponds to the sending credit amount managed by the credit management unit 41 for each category. For example, the packet parsing unit 43 compares the credit information with the sending credit amount managed by the credit management unit 41 for each category. That is, the packet parsing unit 43 can determine whether the sending credit amount for the storage system 3 is correctly managed by the sending credit management table 452 based on the credit information representing the receiving credit amount for each category in the storage system 3. The packet parsing unit 43 sends the determination result of each category to the notification control unit 44.
[0071] The notification control unit 44 controls the notification (output) based on the judgment result received from the packet parsing unit 43. Specifically, for example, regarding a certain category, if the credit information in Flit8 does not correspond to the sending credit amount managed by the sending credit management table 452, the notification control unit 44 outputs an error. Alternatively, the notification control unit 44 may output information indicating whether the credit information in Flit8 corresponds to the sending credit amount managed by the sending credit management table 452 for each category. Or, the notification control unit 44 may output information indicating the category in which the credit information and sending credit amount do not correspond.
[0072] Through the above configuration, host 2 manages and controls the data transmission between host 2 and storage system 3.
[0073] Furthermore, the host I / F14 of the storage system 3 also includes the same configuration as the packet receiving unit 42, the packet parsing unit 43, and the notification control unit 44. That is, the host I / F14 can perform the same receiving, parsing, and outputting of Flit8 (credit information for each category) as the aforementioned storage I / F23. Hereinafter, the configuration of the host I / F14 that is identical to the packet receiving unit 42, the packet parsing unit 43, and the notification control unit 44 will be simply referred to as the packet receiving unit 42, the packet parsing unit 43, and the notification control unit 44 of the host I / F14.
[0074] Furthermore, the storage I / F23 of host 2 also includes the same configuration as the packet generation unit 32 and the packet transmission unit 33. That is, the storage I / F23 can transmit Flit8, including credit information for each category, in the same way as the aforementioned host I / F14. Hereinafter, the configuration of the storage I / F23 that is identical to the packet generation unit 32 and the packet transmission unit 33 will be simply referred to as the packet generation unit 32 and the packet transmission unit 33 of the storage I / F23.
[0075] Here, the composition of the receiving credit management form 351 and the sending credit management form 352 will be explained.
[0076] Figure 3 The following is an example of the structure of the Credit Receiver Management Table 351. The Credit Receiver Management Table 351 includes multiple entries corresponding to multiple credit categories. Each entry includes a category field and a credit amount field.
[0077] The category field represents information that uniquely identifies the corresponding category. This unique identification information could be, for example, the category name. Specifically, the category field can be set to, for example, any one of PH, PD, NPH, NPD, CplH, and CplD as specified by the PCIe standard.
[0078] The Receive Credits field represents the amount of data (Receive Credits) of the corresponding category that can currently be received from Host 2. Receive Credits are represented, for example, by the number of data units corresponding to the category. For instance, the Receive Credits for PH are represented by the number of data units corresponding to PH that can currently be received from Host 2.
[0079] exist Figure 3 In the example shown, the credit for receiving PH is 5. This means that host I / F14 can currently receive 5 PHs from host 2. Additionally, the credit for receiving PD is 10. The credit for receiving NPH is 3. The credit for receiving NPD is 7. The credit for receiving CplH is 20. The credit for receiving CplD is 22.
[0080] With the above configuration, the host I / F14 can use the receive credit management table 351 to manage the receive credit amount for each category in the storage system 3.
[0081] Furthermore, the receiving credit management table 451 within host 2 has, for example, the same structure as the receiving credit management table 351. Therefore, the storage I / F 23 of host 2 can use the receiving credit management table 451 to manage the amount of receiving credit for each category in host 2.
[0082] Figure 4 This illustrates an example of the structure of the credit management table 352. The credit management table 352 includes multiple entries corresponding to various credit categories. Each entry includes a category field and a credit amount field.
[0083] The category field represents information that can uniquely identify the corresponding category.
[0084] The Send Credits field represents the amount of data (send credits) of the corresponding category that can currently be sent to Host 2. Send credits are represented, for example, by the number of data units corresponding to the category. For instance, the send credits for PH are represented by the number of data units corresponding to PH that can currently be sent to Host 2.
[0085] exist Figure 4 In the example shown, the credit for sending PH is 33. This means that host I / F14 can currently send 33 PHs to host 2. Additionally, the credit for sending PD is 15. The credit for sending NPH is 5. The credit for sending NPD is 12. The credit for sending CplH is 20. The credit for sending CplD is 11.
[0086] With the above configuration, the host I / F14 can use the transmission credit management table 352 to manage the transmission credits for each category in the storage system 3.
[0087] Furthermore, the transmission credit management table 452 within host 2 has, for example, the same structure as the transmission credit management table 352. Therefore, the storage I / F 23 of host 2 can use the transmission credit management table 452 to manage the transmission credit amount for each category in host 2.
[0088] Next, the credit information sent from storage system 3 to host 2 will be explained. As mentioned earlier, the credit information sent from storage system 3 to host 2 represents the current amount of credit received for each category in storage system 3.
[0089] Figure 5An example of credit information being sent from storage system 3 to host 2 is shown. Here, in storage system 3, DRAM 5 is used as a receive buffer for receiving data from host 2 via link 7. Furthermore, in DRAM 5, the initial value of the credit amount for receiving PD is set to 200, and the initial value of the credit amount for receiving NPD is set to 100. Figure 5 In this document, the credit amount for receiving other categories is omitted from the record, but the credit amount for receiving each category is managed, for example, by the credit management table 351 within the storage system 3.
[0090] First, storage system 3 uses InitFC, one of the data link layer packets (DLLP), to send information representing the initial value of the received credit for each category (initial value information) to host 2 via link 7. Figure 5 (1)). The InitFC, which includes initial value information, is sent immediately after the training process (i.e., the initialization sequence) of link 7 in the initialization of host I / F14 and storage I / F23 is completed. Specifically, in the InitFC, storage system 3 notifies host 2, for example, that the initial value of the PD's receive credit is 200 and the initial value of the NPD's receive credit is 100. In addition, DLLP is used, for example, for the transmission of information related to flow control between electronic devices.
[0091] Host 2 receives initial value information from storage system 3. Host 2 uses transmission credit management table 452 to manage the initial value of the receiving credit amount for each category based on the received initial value information. That is, in transmission credit management table 452, host 2 sets the transmission credit amount for PD to 200 and the transmission credit amount for NPD to 100.
[0092] Here, we envision a scenario where data is sent from host 2 to storage system 3, and 50 of the NPD credits have been consumed. In this case, in storage system 3, the NPD receiving credits are reduced from 100 to 50. Figure 5 (2)). Furthermore, storage system 3 uses UpdateFC, one of the DLLPs, to send information (update information) indicating that 50% of the NPD's receive credits have been consumed to host 2 via link 7. Figure 5(3)). Furthermore, the storage system 3 can also notify the host 2 that a total of 50 of the NPD's receive credits have been consumed by sending multiple UpdateFCs based on the progress of data reception from the host 2. The multiple UpdateFCs may include, for example, update information indicating that 20 of the NPD's receive credits have been consumed, and update information indicating that 30 of the NPD's receive credits have been consumed. Additionally, the UpdateFC may also send update information indicating the amount of receive credits recovered. That is, the update information indicates the change in receive credits (i.e., either the amount consumed or the amount recovered).
[0093] Host 2 receives at least one update message from storage system 3 via at least one UpdateFC, indicating that a total of 50 of the NPD's receiving credits have been consumed. Based on the received update message, Host 2 updates the sending credit management table 452 in a manner that displays the NPD's sending credits as 50 (100-50). Figure 5 (4) in the middle.
[0094] Then, storage system 3 sends Flit8, which includes credit information representing the current receiving credit amount of PD as 200 and credit information representing the current receiving credit amount of NPD as 50, to host 2 via link 7. Figure 5 (5)). Credit information is stored, for example, in the DLLP payload included in Flit8. Furthermore, regarding the specific method for sending Flit8 containing credit information, please refer to [reference needed]. Figures 6 to 11 To be described later.
[0095] Host 2 receives credit information for each category from storage system 3. Host 2 may, for example, use the received credit information for each category and the sending credit amount for each category shown in sending credit management table 452 to determine whether the correct sending credit amount for each category is managed in sending credit management table 452. If the received credit amount for a certain category indicated by the received credit information does not correspond (or is inconsistent) with the sending credit amount for that category shown in sending credit management table 452, host 2 determines that there is an error in the managed sending credit amount for that category.
[0096] In this way, storage system 3 sends the initial value information, update information, and credit information related to the credit amount received for each category to host 2 via link 7. Host 2 manages the credit amount for each category using the sending credit management table 452 based on the initial value information, update information, and credit information received from storage system 3.
[0097] Furthermore, the current receive credits for each category in the DRAM5 (receive buffer) of storage system 3 are information that can be obtained internally by storage system 3, but are difficult for debuggers of information processing system 1 to obtain. Also, the current transmit credits for each category managed by transmit credit management table 452 of host 2 are information that can be obtained internally by host 2, but are difficult for debuggers to obtain.
[0098] The debugger is an operator who analyzes performance and faults in data transmission between host 2 and storage system 3. For example, the debugger can obtain initial value information, update information, and credit information transmitted via link 7 by tracing the bus. If the debugger obtains the initial value information and all update information sent by storage system 3, they can calculate the current receiving credit in storage system 3. In other words, if the debugger does not obtain the initial value information or any update information, they cannot obtain the current receiving credit.
[0099] In PCIe standards developed to date (e.g., PCIe 6.x standards), the sending of initial value information (InitFC) and update information (UpdateFC) is specified, but the sending of credit information is not specified. Furthermore, it is also possible that in PCIe standards under development, such as PCIe 7.x and later, the sending of credit information will not be specified.
[0100] However, the storage system 3 in this embodiment sends not only initial value information and update information, but also credit information. Therefore, the debugging personnel can obtain the current receiving credit amount for each category in the storage system 3 simply by acquiring the credit information. Thus, if, for example, the performance of data transmission (more specifically, packet transmission) from the host 2 to the storage system 3 degrades, the debugging personnel can determine whether the main cause is due to the depletion of receiving credits or due to the internal processing of the storage system 3. Furthermore, if, for example, a fault occurs where the host 2 manages an incorrect credit amount as the current receiving credit amount in the storage system 3, the debugging personnel can identify the occurrence of this fault. In this way, the debugging personnel can easily analyze the performance, faults, etc., of data transmission from the host 2 to the storage system 3 using the credit information. Therefore, the storage system 3 can improve the debugging efficiency of the debugging personnel by sending credit information.
[0101] Furthermore, regarding the transmission of initial value information, update information, and credit information related to the credit amount received for each category from host 2 to storage system 3, it can also be said to be similar to the reference. Figure 5 The explanation given earlier is the same.
[0102] Reference Figures 6 to 11 This section explains the specific methods for sending Flit8 data, including credit information.
[0103] Figure 6 An example of the data layout for Flit8 is shown. Here, an example is given where the size of Flit8 is 256 bytes and it is transmitted using four channels 0 to 3 within link 7.
[0104] Flit8 consists of 256 data sections 80, each in bytes. The 256 data sections 80 are data sections 80 from 0 to 255. In Flit8, the 256 data sections 80 are configured to be transmitted in groups of four, using four channels 0 to 3, starting from the beginning.
[0105] The 236 bytes of data 80, from the 0th to the 235th, constitute a transaction layer packet (TLP) 81. TLP 81 is a packet used to transmit transaction layer data. Transaction layer data is, for example, transaction data used to send data to a destination electronic device (e.g., host 2 or storage system 3).
[0106] The 6 bytes of data 80 following TLP81 (i.e., data 80 from the 236th to the 241st bytes) constitute the data layer packet (DLP) 82. For example... Figure 6 As shown, the 6-byte data section 80 constituting DLP82 is also referred to as DLP0 to DLP5. DLP82 is a packet used to transmit data at the data link layer. Data at the data link layer includes, for example, data used to support the management of link 7.
[0107] Specifically, DLP0 and DLP1, for example, store information specifying the type of DLLP payload. The type of DLLP payload can be, for example, a Regular DLLP Payload, an Optimized Update Flow Control DLLP Payload, or a FlitMarker DLLP Payload. DLP2 through DLP5 are equivalent to DLLP payloads. For details on the specific structure of DLLP payloads, please refer to... Figure 7 To be described later.
[0108] The 8 bytes of data 80 following DLP82 (i.e., data 80 from the 242nd to the 249th bytes) constitute a cyclic redundancy check (CRC) code 83. Figure 6In this CRC code 83, the 8-byte data portion 80 is denoted as CRC0 to CRC7. CRC code 83 is a CRC code for TLP81 and DLP82. Hereinafter, CRC code 83 will be simply referred to as CRC83.
[0109] The 6 bytes of data 80 following the CRC code 83 (i.e., data 80 from the 250th to the 255th bytes) constitute the error correction code (ECC) 84. Figure 6 In this context, the 6-byte data section 80 that constitutes ECC84 is denoted as ECC0 to ECC5. ECC84 is an ECC protocol for TLP81, DLP82, and CRC83.
[0110] Based on this data layout, for example, Flit8 generation and Flit8 parsing can be performed. Furthermore, Figure 6 The Flit8 data layout shown is an example. The Flit8 data layout can, for example, be changed depending on the number of channels used for Flit8 transmission.
[0111] In Flit8, DLLP payloads can be used as regular DLLP payloads. Furthermore, when NoOperation (NOP) is specified as the type of DLLP used as a regular DLLP payload, the first byte of data 80 (DLP2) in the 4-byte DLLP payload is set to indicate the value of NOP, and the subsequent 3 bytes of data 80 (DLP3 to DLP5) become a region that can store arbitrary data.
[0112] Furthermore, for example, in the case where there is no data to be sent via the DLLP payload, NOP is specified as the type of DLLP. In this case, arbitrary data is stored, for example, in the subsequent 3 bytes of data section 80.
[0113] Therefore, the electronic devices 1T and 1R of this embodiment are configured such that, when there is no data to be transmitted via the DLLP payload, NOP is specified as the type of DLLP, and arbitrary data is stored in the subsequent 3-byte data section 80. This allows for efficient utilization of the 3-byte data section 80 within the DLLP payload.
[0114] Figure 7 This shows an example of the format of a DLLP payload used as a regular DLLP payload. See reference... Figure 6As previously described, the 4-byte DLLP payload 51 is equivalent to DLP2 to DLP5 included in Flit8. The DLLP payload 51 includes a 1-byte DLLP type 511 (DLP2) and 3 bytes of DLLP type-specific information 512 (DLP3 to DLP5).
[0115] DLLP type 511 is a region that sets the bit sequence (bit string) representing the type of DLLP payload 51. For example, when NOP is specified as the type of DLLP payload 51, the bit sequence "00110001" is set in DLLP type 511.
[0116] DLLP type-specific information 512 is a region that sets information corresponding to DLLP type 511. When NOP is specified in DLLP type 511, arbitrary data can be stored in DLLP type-specific information 512.
[0117] In information processing system 1, credit information is transmitted between electronic device 1T and electronic device 1R by utilizing DLLP type-specific information 512 in DLLP payload 51, which is specified with NOP in DLLP type 511. Specifically, for example, credit information is transmitted from storage system 3 to host 2. Additionally, for example, credit information is transmitted from host 2 to storage system 3.
[0118] Figure 8 This shows an example of credit information stored in DLLP payload 51. Figure 8 In this representation, the 4-byte data section 80 constituting the DLLP payload 51 is represented as a bit sequence from bit #31 to bit #0. The 8-bit bit sequence from bit #31 to bit #24 corresponds to DLLP type 511. The 24-bit bit sequence from bit #23 to bit #0 corresponds to DLLP type-specific information 512.
[0119] In DLLP type 511, set the value of the specified NOP to "00110001".
[0120] In DLLP type-specific information 512, multiple credit information corresponding to multiple credit categories are set. Specifically, in order to set multiple credit information, the bit sequence from bit #23 to bit #0 is divided into multiple partial bit sequences (data sections). Furthermore, multiple credit information is stored (set) as multiple partial bit sequences. The credit information represents the current received credit amount for the corresponding category.
[0121] exist Figure 8In the example shown in (a), the credit categories are PH, PD, NPH, NPD, CplH, and CplD. To store the six credit information corresponding to each of the six categories, the bit sequence from bit #23 to bit #0 is divided into six partial bit sequences, each with a bit length of 4 bits.
[0122] The following bit sequences are allocated to the credit information of PH: Bit #23 to Bit #20. The following bit sequences are allocated to the credit information of PD: Bit #19 to Bit #16. The following bit sequences are allocated to the credit information of NPH: Bit #15 to Bit #12. The following bit sequences are allocated to the credit information of NPD: Bit #11 to Bit #8. The following bit sequences are allocated to the credit information of CplH: Bit #7 to Bit #4. The following bit sequences are allocated to the credit information of CplD: Bit #3 to Bit #0.
[0123] Here, the credit information of PH, stored as a partial bit sequence from bit #23 to bit #20, will be explained. The partial bit sequence from bit #23 to bit #20 is referred to as the PH bit sequence. The other partial bit sequences mentioned above are similarly referred to as such.
[0124] Figure 8 (b) shows an example of credit information for a PH stored as a PH bit sequence. The bit length of the PH bit sequence is 4 bits. Therefore, the PH bit sequence can be stored using 16 (=2) bits. 4 The credit level for receiving PH is represented by 10 levels.
[0125] Specifically, for example, PH uses the bit sequence "0000" to represent a received credit amount of 0. PH uses the bit sequence "0001" to represent a received credit amount of 1. PH uses the bit sequence "0010" to represent a received credit amount of 2. PH uses the bit sequence "0011" to represent a received credit amount of 3. Similarly, PH uses the bit sequence "1101" to represent a received credit amount of 13. PH uses the bit sequence "1110" to represent a received credit amount of 14. Furthermore, PH uses the bit sequence "1111" to represent a received credit amount of 15 or higher.
[0126] The format of the DLLP type-specific information 512 used in the transmission of credit information (hereinafter also referred to as the credit information format) is pre-shared between the storage system 3 and the host 2. Specifically, the credit information format is shared, for example, during the training process of link 7 in the initialization of host I / F 14 and storage I / F 23. That is, the credit information format is shared during the training process before reaching the link power state L0, which is the normal operating state (active state). The credit information format includes, for example, the configuration of bit sequences for each category in the DLLP type-specific information 512, and the correspondence between the values of the bit sequences for each category and the credit amount to be received. Host I / F 14 and storage I / F 23 store the information representing the credit information format in an Ordered Set used in the training process, for example. Alternatively, a new Ordered Set may be specified for storing the information representing the credit information format. Thus, host I / F 14 and storage I / F 23 can share the credit information format based on the Ordered Set in the training process.
[0127] Furthermore, PH can be represented using bit sequences that are not limited to Figure 8 The example shown in (b) uses credit for any of the 16 levels of reception.
[0128] Figure 9 Other examples of credit information represented by a bit sequence PH are shown. Here, the bit sequence PH is used in such a way that, when the received credit amount is below a threshold, it represents the received credit amount itself; and when the received credit amount exceeds the threshold, it represents the range including the received credit amount. The threshold can be set arbitrarily. Furthermore, the range including the received credit amount can be, for example, a range from credit amount P to credit amount Q, or a range above credit amount P. Additionally, P is an integer greater than or equal to 0, and Q is an integer greater than P.
[0129] exist Figure 9 In the example shown, the threshold is 10. Therefore, when the received credit amount is any one of 0 to 10, PH represents the received credit amount itself using a bit sequence. When the received credit amount is 11 or higher, PH represents the range encompassing that received credit amount using a bit sequence.
[0130] Specifically, for example, PH uses the bit sequence "0000" to represent a received credit amount of 0. PH uses the bit sequence "0001" to represent a received credit amount of 1. PH uses the bit sequence "0010" to represent a received credit amount of 2. Similarly, PH uses the bit sequence "1001" to represent a received credit amount of 9. PH uses the bit sequence "1010" to represent a received credit amount of 10. Thus, when the received credit amount is less than 10, PH uses the bit sequence to represent the received credit amount itself.
[0131] Additionally, for example, PH uses the bit sequence "1011" to represent a received credit amount ranging from 11 to 15. PH uses the bit sequence "1100" to represent a received credit amount ranging from 16 to 20. PH uses the bit sequence "1101" to represent a received credit amount ranging from 21 to 30. PH uses the bit sequence "1110" to represent a received credit amount ranging from 31 to 40. PH uses the bit sequence "1111" to represent a received credit amount greater than 41. Thus, when the received credit amount exceeds 10, PH uses a bit sequence to represent the range encompassing that received credit amount. The larger the received credit amount, the wider the range encompassing that received credit amount can be set. For example, the range from 21 to 30 is wider than the range from 11 to 15 for a received credit amount of 11. Furthermore, regarding the width of the range encompassing the credit amount received, it can also include a range beyond those containing a specific value or more of the credit amount received (in...). Figure 9 Except for the range of receiving credits of 41 or more, all other credits are set to the same value regardless of their size.
[0132] Similar to the PH bit sequence, the PD bit sequence, NPH bit sequence, NPD bit sequence, CplH bit sequence, and CplD bit sequence can each be represented by 16 levels to indicate the corresponding category of receiving credit.
[0133] Furthermore, the storage of credit information in the DLLP payload 51 is one example. Credit information can also be stored in any area within Flit8 that does not affect the storage of data to be sent to host 2. Alternatively, any information not limited to credit information can be stored in the DLLP payload 51. The information stored in the DLLP payload 51 can be information about the current state of any quantity, such as the amount of credit, which is managed by the controller 6 (more specifically, host I / F14) based on initial value information and update information, indicating the state of the internal resources of the storage system 3.
[0134] (Flit sends action)
[0135] Next, the Flit transmission action will be explained. The Flit transmission action is an action used to send Flit8, which includes credit information representing the current amount of credit to be received, to an external electronic device. Here, the case where the storage system 3 sends Flit8 to the host 2 is illustrated.
[0136] Figure 10 An example of a Flit transmission operation in storage system 3 is shown. The Flit transmission operation is performed by the credit management unit 31, the packet generation unit 32, and the packet transmission unit 33. The credit management unit 31 manages the amount of credit for receiving and the amount of credit for transmitting for each category using the receive credit management table 351 and the transmit credit management table 352 respectively. The packet generation unit 32 includes, for example, a TLP generation unit 321, a DLP generation unit 322, a CRC generation unit 323, and an ECC generation unit 324.
[0137] The TLP generation unit 321 uses the transmission credit amount for each category obtained from the transmission credit management table 352 to determine whether the TLP81, which includes the transaction layer data to be transmitted (hereinafter also referred to as object data), can be sent to the host 2 for each category. Figure 10 (1)). Specifically, the TLP generation unit 321 calculates the credit amount consumed for sending object data (i.e., the credit amount consumed by the host 2 for receiving object data) for each category. The credit amount consumed for sending object data is also referred to as the first credit consumption amount. The TLP generation unit 321 obtains the sending credit amount for each category from the sending credit management table 352. The TLP generation unit 321 determines whether the first credit consumption amount is less than or equal to the sending credit amount for all categories. If the first credit consumption amount is less than or equal to the sending credit amount for a certain category, the TLP generation unit 321 determines that it is possible to send the TLP 81, which includes object data and corresponds to that category, to the host 2. On the other hand, if the first credit consumption amount exceeds the sending credit amount for a certain category, the TLP generation unit 321 determines that it is impossible to send the TLP 81, which includes object data and corresponds to that category, to the host 2. Hereinafter, the case in which the TLP 81, which includes object data, can be sent to the host 2 will be explained.
[0138] TLP generation unit 321 generates TLP81 including object data. TLP generation unit 321 sends the generated TLP81 to CRC generation unit 323 and ECC generation unit 324. Figure 10 (2) and (3) in the middle.
[0139] Next, the DLP generation unit 322 obtains the current credit amount for each category from the credit management table 351. Figure 10(4)). The DLP generation unit 322 generates a DLP 82 that includes information (credit information) representing the current credit amount received for each category. In the DLP 82, a regular DLLP payload is specified as the type of DLLP payload. In addition, the DLP 82 includes a DLLP payload 51. The DLLP payload 51 includes a DLLP type 511 that is specified with NOP and DLLP type-specific information 512 that stores the credit information for each category. The DLP generation unit 322 sends the generated DLP 82 to the CRC generation unit 323 and the ECC generation unit 324. Figure 10 (5) and (6) in the middle.
[0140] The CRC generation unit 323 generates CRC83 for TLP81 and DLP82. In generating CRC83, for example, a predefined generator polynomial is used. The CRC generation unit 323 then sends the generated CRC83 to the ECC generation unit 324. Figure 10 (7) in the middle.
[0141] ECC generation unit 324 generates ECC84 for TLP81, DLP82, and CRC83. ECC generation unit 324 then sends Flit8, including TLP81, DLP82, CRC83, and ECC84, to packet sending unit 33. Figure 10 (8) in the middle.
[0142] Furthermore, packet sending unit 33 sends Flit8 to host 2 via link 7. Figure 10 (9) in the middle.
[0143] Through the above Flit sending action, storage system 3 sends Flit8, which includes credit information for each category, to host 2. Thus, host 2 can retrieve the credit information for each category from the received Flit8.
[0144] Furthermore, the same Flit transmission operation is performed on host 2. That is, host 2 sends Flit8, which includes credit information for each category, to storage system 3. Thus, storage system 3 is able to retrieve the credit information for each category from the received Flit8.
[0145] Credit information for each category is stored in DLP82, which is part of Flit8. More specifically, credit information for each category is stored, for example, in the absence of data to be transmitted as DLLP payload 51, in DLLP type-specific information 512 within DLLP payload 51. Therefore, in information processing system 1, credit information is transmitted in a manner that does not strain the bandwidth of link 7 or unnecessarily consume resources. Thus, credit information can be transmitted efficiently between storage system 3 and host 2.
[0146] Figure 11 This is a flowchart illustrating an example of the steps of the transmission control processing performed in storage system 3. The transmission control processing is for transmitting Flit8, which includes credit information representing the current amount of credit received, to an external electronic device (here, host 2). Host I / F 14 of storage system 3 performs the transmission control processing, for example, at the timing when Flit8 (more specifically, TLP81) is to be transmitted. Here, it is assumed that in the transmitted Flit8, NOP can be specified as the type of DLLP within the DLLP payload 51.
[0147] First, host I / F14 calculates the credit amount (first credit consumption) consumed by host 2 for each category in order to receive the transaction layer data (object data) to be sent (step S101). Host I / F14 obtains the sending credit amount for each category from the sending credit management table 352 (step S102). Then, host I / F14 determines whether it is possible to send TLP81, which includes object data, to host 2 based on the first credit consumption and the sending credit amount for each category (step S103). Specifically, host I / F14 determines whether the first credit consumption is less than or equal to the sending credit amount for all categories.
[0148] If it is impossible to send TLP81, which includes object data, to host 2 (in step S103, this is "No"), host I / F14 terminates the transmission control process. That is, if the first credit consumption exceeds the transmission credit for a certain category, host I / F14 determines that it cannot send Flit8, which includes object data and corresponds to that category, to host 2, and terminates the transmission control process.
[0149] If it is possible to send TLP81, which includes object data, to host 2 (Yes in step S103), host I / F14 generates TLP81, which includes object data (step S104).
[0150] Next, the host I / F14 obtains the credit amount for each category from the credit management table 351 (step S105). Specifically, the host I / F14 obtains, for example, the credit amounts for PH, PD, NPH, NPD, CplH, and CplD from the credit management table 351. Using the obtained credit amounts for each category, the host I / F14 generates a DLP82 including a DLLP payload 51 containing NOP and credit information for each category (step S106). More specifically, the host I / F14 generates a DLLP payload 51 including (1) a DLLP type 511 with NOP specified, and (2) DLLP type-specific information 512 containing multiple credit information representing the credit amounts for all categories.
[0151] Host I / F14 calculates CRC83 for the generated TLP81 and DLP82 (step S107). Host I / F14 calculates ECC84 for the generated TLP81, DLP82, and the calculated CRC83 (step S108). Then, Host I / F14 sends Flit8, which includes TLP81, DLP82, CRC83, and ECC84, to Host 2 via Link 7 (step S109) and ends the transmission control process.
[0152] Through the above transmission control processing, host I / F14, when capable of transmitting TLP81 including object data, uses the DLLP payload 51 within Flit8 to send credit information representing the current received credit amount for each category to host 2. By using the DLLP payload 51, which is part of the area of Flit8, host I / F14 can send credit information to host 2 in a manner that does not strain the bandwidth of link 7 or unnecessarily consume resources. Therefore, host I / F14 can efficiently transmit credit information to host 2.
[0153] Alternatively, the same transmission control process can be performed via the storage I / F23 of host 2. In this case, the transmission credit management table 352 used in step S102 is replaced by the transmission credit management table 452 within host 2, and the reception credit management table 351 used in step S105 is replaced by the reception credit management table 451 within host 2. Thus, storage I / F23 uses the DLLP payload 51 within Flit8 to send credit information representing the current reception credit amount for each category to storage system 3. By using the DLLP payload 51, which is part of Flit8, storage I / F23 can send credit information to storage system 3 in a manner that does not strain the bandwidth of link 7 or unnecessarily consume resources. Therefore, storage I / F23 can efficiently transmit credit information to storage system 3.
[0154] (Flit receive action)
[0155] Next, the Flit receiving operation will be explained. The Flit receiving operation is an operation used to receive Flit8, which includes credit information indicating the current credit amount to be received, from an external electronic device. Here, the case where host 2 receives Flit8 from storage system 3 is illustrated.
[0156] Figure 12 An example of a Flit receiving operation in host 2 is shown. The Flit receiving operation is performed by the credit management unit 41, the packet receiving unit 42, the packet parsing unit 43, and the notification control unit 44. The credit management unit 41 manages the receiving credit amount and the sending credit amount for each category separately using the receiving credit management table 451 and the sending credit management table 452. The packet parsing unit 43 includes, for example, an ECC processing unit 431, a CRC processing unit 432, a TLP processing unit 433, and a DLP processing unit 434.
[0157] First, packet receiving unit 42 receives Flit8 (from storage system 3) Figure 12 (1)). The packet receiving unit 42 sends the received Flit8 to the ECC processing unit 431. Figure 12 (2) in the middle.
[0158] The ECC processing unit 431 obtains TLP81, DLP82, CRC83, and ECC84 from the Flit8 received from the packet receiving unit 42. Furthermore, the ECC processing unit 431 uses ECC84 to perform error detection and correction processing on TLP81, DLP82, and CRC83. If no error is detected during the error detection and correction processing, or if a detected error has been corrected, the ECC processing unit 431 sends the error-detected and corrected TLP81, DLP82, and CRC83 to the CRC processing unit 432. Figure 12 (3)). In addition, if an error is detected in the error detection and correction process and the detected error cannot be corrected, the ECC processing unit 431 requests the storage system 3 to resend Flit8.
[0159] The CRC processing unit 432 receives TLP81, DLP82, and CRC83 after error detection and correction processing from the ECC processing unit 431. The CRC processing unit 432 uses CRC83 to perform error detection processing on TLP81 and DLP82. If no error is detected during the error detection processing, the CRC processing unit 432 sends TLP81 to the TLP processing unit 433. Figure 12 (4) of the above means that the DLP82 is sent to the DLP processing unit 434. Figure 12 (5)). In addition, if an error is detected in the error detection process, the CRC processing unit 432 may also request the storage system 3 to resend Flit8.
[0160] The TLP processing unit 433 receives TLP81 from the CRC processing unit 432. The TLP processing unit 433 performs processing corresponding to the data included in TLP81. Specifically, the TLP processing unit 433 stores TLP81 in RAM 22 (receive buffer). Furthermore, the TLP processing unit 433 sends information indicating the amount of credit consumed for each category corresponding to the received (stored) TLP81 to the credit management unit 41. Figure 12 (6)). Furthermore, the TLP processing unit 433 can also send information that determines the amount of credit consumed in each category to the credit management unit 41. The information that determines the amount of credit consumed in each category is information indicating the type of TLP 81. The types of TLP 81 include, for example, memory read, memory write, input / output (I / O) read, I / O write, configuration read, configuration write, no data message, data message, and various completions.
[0161] Credit Management Department 41 receives information from TLP Processing Department 433 indicating the credit consumption amount corresponding to the receipt of TLP 81. Based on the received information, Credit Management Department 41 updates the Received Credit Management Table 451. Specifically, when the received information indicates a credit consumption amount for a certain category, Credit Management Department 41 determines the entry corresponding to that category in Received Credit Management Table 451. Furthermore, Credit Management Department 41 updates the credit amount shown in the determined entry to the value obtained by subtracting the credit consumption amount from the current value.
[0162] Alternatively, the credit management unit 41 may update the received credit management table 451 based on the increase or decrease of data in each category stored in the receive buffer (e.g., RAM 22). In this case, the credit management unit 41 may also not receive information from the TLP processing unit 433 indicating the amount of credit consumed corresponding to the reception of TLP 81.
[0163] The DLP processing unit 434 receives the DLP 82 from the CRC processing unit 432. The DLP processing unit 434 obtains credit information for each category included in the DLP 82. Additionally, the DLP processing unit 434 obtains the transmission credit amount for each category from the transmission credit management table 452. Figure 12(7)). Furthermore, the DLP processing unit 434 determines whether the credit information corresponds to the amount of credit sent for each category.
[0164] Specifically, when the credit information represents the credit amount itself, the DLP processing unit 434 determines whether this credit amount is consistent with the credit amount to be sent. Alternatively, when the credit information represents a range including the credit amount, the DLP processing unit 434 determines whether the credit amount to be sent is included within that range. If the credit amount to be sent is included within that range, the DLP processing unit 434 determines that the credit amount represented by the credit information is consistent with the credit amount to be sent. If the credit amount to be sent is not included within that range, the DLP processing unit 434 determines that the credit amount represented by the credit information is inconsistent with the credit amount to be sent.
[0165] The DLP processing unit 434 sends the determination result for each category, indicating whether the credit information corresponds to the amount of credit sent, to the notification control unit 44. Figure 12 (8) in the middle.
[0166] The notification control unit 44 issues a notification based on the determination result received from the DLP processing unit 434. Specifically, the notification control unit 44 may, for example, output an error message regarding a certain category where the credit information and the amount of credit to be sent do not correspond. Alternatively, the notification control unit 44 may also notify external parties (e.g., debugging personnel) of information indicating whether the credit information and the amount of credit to be sent correspond for each category. Or, the notification control unit 44 may also notify external parties of information indicating that the credit information and the amount of credit to be sent do not correspond to a category.
[0167] Furthermore, the DLP processing unit 434 can also send credit information for a category that does not correspond to the amount of credit sent to the credit management unit 41 if such a category exists. The credit management unit 41 can also use the credit information received from the DLP processing unit 434 to update (correct) the corresponding category entries in the credit management table 452.
[0168] Through the above Flit receiving action, host 2 receives Flit8, which includes credit information for each category, from storage system 3. Host 2 can use the credit information for each category to, for example, confirm whether the amount of credit sent for each category in storage system 3 (i.e., the amount of credit received for each category in storage system 3) is correctly managed by the sending credit management table 452.
[0169] Furthermore, the same Flit receiving operation is performed in storage system 3. That is, storage system 3 receives Flit8 from host 2, which includes credit information for each category. Storage system 3 can use the credit information for each category to, for example, confirm whether the amount of credit sent for each category in host 2 (i.e., the amount of credit received for each category in host 2) is correctly managed by the sending credit management table 352.
[0170] Figure 13 This is a flowchart illustrating an example of the steps of the receive control processing performed in host 2. The receive control processing corresponds to Flit8 received from storage system 3. The storage I / F23 of host 2 performs the receive control processing based on the fact that Flit8 has been received from storage system 3 via link 7.
[0171] First, the storage I / F23 obtains TLP81, DLP82, CRC83, and ECC84 from the received Flit8 (step S201). The storage I / F23 then uses the obtained ECC84 to perform error detection and correction processing for TLP81, DLP82, and CRC83 (step S202). Here, it is assumed that no error was detected during the error detection and correction processing, or that any detected error has been corrected.
[0172] Next, memory I / F23 uses CRC83 to perform error detection processing for TLP81 and DLP82 (step S203). Here, it is set that no error was detected in the error detection processing.
[0173] Memory I / F23 saves TLP81 in the receive buffer (step S204). The receive buffer is, for example, part of the storage area of RAM22. For example, based on TLP81 saved in the receive buffer, the CPU21 performs transaction layer processing.
[0174] Additionally, the storage I / F23 updates the receive credit management table 451 based on the amount of credit consumed by TLP81 in storing it in the receive buffer (step S205). Specifically, the storage I / F23 determines, for example, the category and amount of credit consumed by TLP81. The storage I / F23 subtracts the determined consumption amount from the receive credit amount in the entry in the receive credit management table 451 corresponding to the determined category.
[0175] Next, the memory I / F23 obtains the DLLP payload 51 from the DLP82 (step S206). Using the obtained DLLP payload 51, the memory I / F23 determines whether the DLLP type is NOP (step S207). That is, the memory I / F23 determines whether a bit sequence representing NOP is set in the DLLP type 511 within the DLLP payload 51.
[0176] If the DLLP type is not NOP ("No" in step S207), the storage I / F23 terminates the receive control process. Alternatively, the storage I / F23 can also process the DLLP payload 51 according to the DLLP type, including DLLP types other than NOP.
[0177] When the DLLP type is NOP (Yes in step S207), the storage I / F 23 selects one category (hereinafter referred to as the object category) from multiple credit categories (step S208). The storage I / F 23 obtains the credit information of the object category from the DLLP payload 51 (step S209). The credit information of the object category represents the amount of TLP81 data (the credit amount for receiving data of the storage system 3) that the storage system 3 can currently receive from the host 2, including the data of the object category. Specifically, the storage I / F 23 obtains a bit sequence from the region within the DLLP payload 51 corresponding to the object category. Based on the obtained bit sequence, the storage I / F 23 obtains the credit information of the object category. The credit information represents the credit amount itself or a range of credit amounts.
[0178] Storage I / F23 obtains the transmission credit amount for the object category from the transmission credit management table 452 (step S210). That is, storage I / F23 obtains the amount of TLP81 data (the transmission credit amount of host 2) that host 2 can currently send to storage system 3, including data related to the object category. Furthermore, storage I / F23 determines whether the credit information obtained from DLLP payload 51 corresponds to the transmission credit amount of host 2 regarding the object category (step S211). Specifically, if the credit information represents the credit amount itself, storage I / F23 determines whether that credit amount is equal to the transmission credit amount of host 2. Additionally, if the credit information represents a range of credit amounts, storage I / F23 determines whether the transmission credit amount of host 2 is within that range.
[0179] If the credit information corresponds to the sending credit amount of host 2 ("Yes" in step S211), the storage I / F 23 outputs information indicating that the sending credit amount for the object category is correctly managed by the sending credit management table 452 (step S212). Specifically, the storage I / F 23, for example, notifies the outside world that the correct sending credit amount for the object category is being managed. Alternatively, the storage I / F 23 may omit the output indicating that the sending credit amount for the object category is being correctly managed. The processing performed by the storage I / F 23 proceeds to step S214.
[0180] If the credit information does not correspond to the sending credit amount of host 2 ("No" in step S211), the storage I / F 23 outputs information indicating that an error has occurred in the sending credit amount for the object category (step S213). Specifically, the storage I / F 23 notifies an external entity that an error has occurred in the sending credit amount for the object category. Alternatively, the storage I / F 23 may replace the sending credit amount set in the entry in the sending credit management table 452 corresponding to the determined category with the receiving credit amount shown in the credit information. Then, the processing performed by the storage I / F 23 proceeds to step S214.
[0181] Next, the storage I / F23 determines whether there are other unprocessed credit categories (step S214).
[0182] If there are other unprocessed credit categories ("Yes" in step S214), the processing performed by storage I / F23 returns to step S208. That is, storage I / F23 performs processing related to the credit information in the DLLP payload 51 and the amount of credit to be sent by host 2 regarding the other credit category.
[0183] If all credit categories have been processed (No in step S214), the memory I / F23 ends the receive control process.
[0184] Through the above-described receive control processing, the storage I / F23 performs processing corresponding to the Flit8 received from the storage system 3. Specifically, when the DLLP payload 51 with a specified NOP is included in the Flit8, the storage I / F23 obtains credit information representing the current receive credit amount for each category in the storage system 3. By using the DLLP payload 51, which is part of the Flit8 area, the storage I / F23 can obtain the credit information in a way that does not strain the bandwidth of the link 7 or unnecessarily consume resources. Therefore, the storage I / F23 can obtain the credit information efficiently transmitted from the storage system 3.
[0185] Alternatively, the same receive control process can be performed by the host I / F14 of storage system 3. In this case, the receive credit management table 451 used in step S205 is replaced by the receive credit management table 351 within storage system 3, and the transmit credit management table 452 used in step S210 is replaced by the transmit credit management table 352 within storage system 3. Thus, with the DLLP payload 51, which is specified with NOP, included in Flit8, host I / F14 obtains credit information representing the current receive credit amount for each category in host 2. By using the DLLP payload 51, which is part of the area of Flit8, host I / F14 can obtain credit information in a way that does not strain the bandwidth of link 7 or unnecessarily consume resources. Therefore, host I / F14 can obtain credit information efficiently transmitted from host 2.
[0186] (Second Implementation)
[0187] In the first embodiment, Flit8, which includes credit information of all categories, is transmitted between electronic devices.
[0188] In contrast, in the second embodiment, Flit8 containing at least one type of credit information from all categories is transmitted between electronic devices. In other words, in the second embodiment, credit information from all categories is transmitted across multiple Flit8s.
[0189] The electronic devices 1T and 1R (e.g., storage system 3 and host 2) of the second embodiment are configured the same as those of the electronic devices 1T and 1R of the first embodiment. The method of storing credit-related information in the DLLP payload 51 within Flit8 differs between the second and first embodiments. The following mainly describes the differences from the first embodiment.
[0190] In both the storage system 3 and the host 2, the packet generation unit 32 (more specifically, the DLP generation unit 322) is configured, for example, to store a combination of a category identifier and credit information in the DLLP payload 51. The category identifier is information that can uniquely identify the corresponding credit category.
[0191] Figure 14 This shows an example of a combination of category identifiers and credit information stored in DLLP payload 51. For example... Figure 14 As shown in (a), the DLLP payload 51 includes DLLP type 511 (a bit sequence from bit #31 to bit #24) and DLLP type specific information 512 (a bit sequence from bit #23 to bit #0). The value “00110001” for the specified NOP is stored (set) in DLLP type 511.
[0192] In DLLP type-specific information 512, one category identifier and one credit information corresponding to the category determined by the category identifier are stored. Specifically, the category identifier is stored as a 3-bit bit sequence from bit #23 to bit #21. The bit sequence from bit #23 to bit #21 is called the category bit sequence. The credit information is stored as a 21-bit bit sequence from bit #20 to bit #0. The stored credit information can be used in 2... 21 The credit level is used to represent the corresponding category of credit.
[0193] Figure 14 (b) shows an example of a category identifier set in a category bit sequence. The category bit sequence has a bit length of 3 bits. Thus, the category bit sequence can represent a maximum of 8 categories.
[0194] Specifically, for example, the category bit sequence "000" corresponds to the category identifier for PH. The category bit sequence "001" corresponds to the category identifier for PD. The category bit sequence "010" corresponds to the category identifier for NPH. The category bit sequence "011" corresponds to the category identifier for NPD. The category bit sequence "100" corresponds to the category identifier for CplH. The category bit sequence "101" corresponds to the category identifier for CplD.
[0195] Figure 14 The correspondence between categories and category identifiers shown in (b) is an example. The format of credit information, including any correspondence between categories and category identifiers, is pre-shared in storage system 3 and host 2, for example. The method for sharing the format of credit information is as previously described in the first embodiment.
[0196] Furthermore, in both the storage system 3 and the host 2, the packet generation unit 32 may be configured to store N combinations of category identifiers and credit information in the DLLP payload 51. N is, for example, an integer greater than or equal to 1 and less than the total number of credit categories (e.g., 6).
[0197] Figure 15 This illustrates an example of N combinations of category identifiers and credit information stored in the DLLP payload 51, and the number of categories N. The number of categories N is the number of categories of credit information transmitted using one DLLP payload 51. For DLLP type 511, see reference... Figure 14 As previously stated.
[0198] In DLLP type-specific information 512, N combinations of category identifiers and credit information and the number of categories N are stored.
[0199] Specifically, for example, the number of categories N is stored as a bit sequence from bit #23 to bit #21. For example, when the number of categories N is 3, "011" is stored as a bit sequence from bit #23 to bit #21.
[0200] Furthermore, the bit sequence from bit #20 to bit #0 is divided into N partial bit sequences to store N combinations of category identifiers and credit information. The bit lengths of the N partial bit sequences can be either the same or different. Each of the N partial bit sequences stores one of the N combinations of category identifiers and credit information.
[0201] exist Figure 15 The example illustrates a case where the number of categories N is 3 and the bit lengths of the N partial bit sequences are different. The bit sequence from bit #20 to bit #0 is divided into 3 partial bit sequences to store the 3 combinations of category identifier and credit information. The 3 partial bit sequences include the partial bit sequence from bit #20 to bit #15, the partial bit sequence from bit #14 to bit #8, and the partial bit sequence from bit #7 to bit #0.
[0202] The first combination of category identifier and credit information is stored in a portion of the bit sequence from bit #20 to bit #15. More specifically, the category identifier of the first combination is stored in a 3-bit bit sequence from bit #20 to bit #18. The credit information of the first combination is stored in a 3-bit bit sequence from bit #17 to bit #15. The credit information of the first combination can be represented by 8 (= 2 3 The credit level is represented by 10 levels to indicate the credit level of the corresponding category.
[0203] The second combination of category identifier and credit information is stored in a portion of the bit sequence from bit #14 to bit #8. More specifically, the category identifier of the second combination is stored in a 3-bit bit sequence from bit #14 to bit #12. The credit information of the second combination is stored in a 4-bit bit sequence from bit #11 to bit #8. The credit information of the second combination can be represented using 16 (= 2 4 The credit level is represented by 10 levels to indicate the credit level of the corresponding category.
[0204] The third combination of category identifier and credit information is stored in the bit sequence from bit #7 to bit #0. More specifically, the category identifier of the third combination is stored in the 3-bit bit sequence from bit #7 to bit #5. The credit information of the third combination is stored in the 5-bit bit sequence from bit #4 to bit #0. The credit information of the third combination can be stored using 32 (= 2 5The credit level is represented by 10 levels to indicate the credit level of the corresponding category.
[0205] Regarding the correspondence between category identifiers and categories, please refer to... Figure 14 (b) is as described above. Furthermore, the format of the credit information, including the correspondence between the values of the bit sequences stored as credit information and each category of the received credit amount (or including the range of received credit amounts), is pre-shared, for example, in the storage system 3 and the host 2. The method for sharing the format of the credit information is as described above in the first embodiment.
[0206] pass Figure 14 or Figure 15 The DLLP payload 51, as shown, is configured such that a Flit8 of the DLLP payload 51, which stores N credit information items from all categories of credit information, is transmitted between the storage system 3 and the host 2. In this case, both the storage system 3 and the host 2 obtain credit information of all categories by receiving their respective multiple Flit8s, each containing a DLLP payload 51 storing N credit information items. By storing N credit information items in a single DLLP payload 51 instead of storing all categories of credit information, it is possible to increase the number of credit levels that can be represented by each credit information item.
[0207] Figure 16 This is a flowchart illustrating an example of the steps of the transmission control processing performed in storage system 3. The transmission control processing is a process for transmitting Flit8, which includes credit information representing the current amount of credit received corresponding to each of the N credit categories, to an external electronic device (here, host 2). Host I / F14 of storage system 3 performs the transmission control processing at the timing when Flit8 is to be transmitted. Here, it is assumed that in the transmitted Flit8, NOP can be specified as the type of DLLP within the DLLP payload 51.
[0208] Figure 16 The transmission control process shown, except for the processes for generating DLP82 in steps S305 and S306, is similar to the referenced process. Figure 11 The transmission control process described earlier is the same. That is to say, Figure 16 The transmission control process includes steps S301 to S304 and steps S307 to S309. Figure 11 The processes from step S101 to step S104 and from step S107 to step S109 in the transmission control process are the same. Therefore, the processes of step S305 and step S306 will be explained below.
[0209] The host I / F14 obtains the receiving credit amount for each of the N categories to be sent from the receiving credit management table 351 (step S305). Specifically, the host I / F14 obtains N receiving credit amounts corresponding to, for example, the N categories of PH, PD, NPH, NPD, CplH, and CplD from the receiving credit management table 351. The host I / F14 uses the obtained N receiving credit amounts to generate a DLP82 including a DLLP payload 51 containing N combinations of category identifiers and credit information and NOP (step S306). More specifically, the host I / F14 generates a DLLP payload 51 including (1) a DLLP type 511 with NOP specified and (2) DLLP type-specific information 512 containing N combinations of category identifiers and credit information.
[0210] Through the above transmission control processing, host I / F14 uses the DLLP payload 51 within Flit8 to send credit information representing the current received credit amount for each of the N categories to host 2. By using the DLLP payload 51, which is part of Flit8, host I / F14 can send credit information to host 2 in a way that does not strain the bandwidth of link 7 or consume unnecessary resources. Therefore, host I / F14 can efficiently transmit credit information to host 2.
[0211] In addition, with Figure 11 Similarly, the transmission control processing, Figure 16 The transmission control processing can also be performed by the storage I / F23 of host 2. Therefore, host 2 can also achieve the same actions and effects as storage system 3.
[0212] Furthermore, regarding the receiving control processing, besides accepting credit information of N categories instead of all categories, it is consistent with the reference... Figure 13 The receive control process described above is the same. Furthermore, Figure 13 The step S208 of selecting the credit category (object category) in the receive control process is replaced by a process that determines the object category based on the category identifier in the DLLP payload 51.
[0213] As explained above, the first and second embodiments enable the efficient transmission of information related to data transmission between electronic devices.
[0214] The host I / F14 of storage system 3 (or the storage I / F23 of host 2) performs communication between storage system 3 and host 2. The packet parsing unit 43 (more specifically, the TLP processing unit 433) of host I / F14 (or storage I / F23) saves the data received from host 2 (or storage system 3) in RAM (e.g., DRAM 5 or RAM 22). The credit management unit 31 (or credit management unit 41) manages multiple receiving credits, which correspond to multiple categories and each represents the amount of data of the corresponding category that can be received from host 2 (or storage system 3) at present. The packet generation unit 32 and the packet sending unit 33 send Flit8, which includes credit information representing at least one of the multiple receiving credits, to host 2 (or storage system 3).
[0215] Therefore, host I / F14 (or storage I / F23) uses Flit8 (more specifically, DLLP payload 51) to send credit information representing the current received credit amount for at least one category to host 2 (or storage system 3). By using a portion of Flit8, host I / F14 (or storage I / F23) can send the credit information to host 2 (or storage system 3) in a manner that does not strain the bandwidth of link 7 or unnecessarily consume resources. Thus, host I / F14 (or storage I / F23) can efficiently transmit credit information to host 2 (or storage system 3).
[0216] The host I / F14 of storage system 3 (or the storage I / F23 of host 2) performs communication between storage system 3 and host 2. The packet parsing unit 43 (more specifically, the TLP processing unit 433) of host I / F14 (or storage I / F23) stores the data received from host 2 (or storage system 3) in RAM (e.g., DRAM 5 or RAM 22). The credit management unit 31 (or credit management unit 41) manages multiple transmission credits and receives Flit8 containing credit information from host 2 (or storage system 3). These multiple transmission credits correspond to multiple categories, each representing the amount of data of the corresponding category that can currently be sent to host 2 (or storage system 3). The credit information represents the receiving credit, which corresponds to one of the multiple categories and represents the amount of data of one category that host 2 (or storage system 3) can currently receive. The packet parsing unit 43 compares the transmission credit corresponding to one category with the credit information.
[0217] Thus, host I / F14 (or storage I / F23) receives Flit8 (more specifically, DLLP payload 51) from host 2 (or storage system 3) containing credit information for each category. Host I / F14 (or storage I / F23) can use the credit information for each category to, for example, confirm whether the amount of credit sent for each category in host 2 (or storage system 3) (i.e., the amount of credit received for each category in host 2 (or storage system 3)) is correctly managed by the sending credit management table 352 (or sending credit management table 452).
[0218] The packet generation unit 32 of the storage system 3 (or host 2) manages a first quantity (e.g., a credit for receiving) representing the state of the internal resources of the storage system 3 (or host 2), and sends a first packet (e.g., InitFC) representing the initial value of the first quantity, a second packet (e.g., UpdateFC) representing the increase or decrease value of the first quantity, and a third packet (e.g., Flit8) representing the current value of the first quantity to the host 2 (or storage system 3) via the packet sending unit 33.
[0219] Therefore, the storage I / F23 of host 2 (or host I / F14 of storage system 3) can use the first packet, the second packet, and the third packet to confirm whether the first quantity in storage system 3 (or host 2) has been transmitted correctly.
[0220] The various functions described in the first and second embodiments can each be implemented by a circuit (processing circuit). Examples of processing circuits include a programmed processor, such as a central processing unit (CPU). This processor executes the described functions by executing a computer program (command set) stored in memory. The processor can be a microprocessor containing electrical circuitry. Examples of processing circuits also include digital signal processors (DSPs), application-specific integrated circuits (ASICs), microcontrollers, controllers, and other electrical circuit components. Other components besides the CPU described in these embodiments can also be implemented by processing circuits.
[0221] Several embodiments of the present invention have been described, but these embodiments are provided as examples and are not intended to limit the scope of the invention. These new embodiments can be implemented in a wide variety of other ways, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included within the scope and spirit of the invention, and are included within the scope of the invention as described in the claims and its equivalents.
Claims
1. An electronic device comprising a random access memory and an interface circuit, The interface circuit is configured to perform communication between the electronic device and an external electronic device, and to store data received from the external electronic device in the random access memory. The interface circuit is further configured to, Multiple credit values are managed, each corresponding to a different category, and each representing the amount of data of the corresponding category that can currently be received from the external electronic device. A first packet, comprising credit information representing at least one of the plurality of credit values, is sent to the external electronic device.
2. The electronic device according to claim 1, The interface circuit is configured to send the first packet, which includes multiple credit information representing the multiple credit values, to the external electronic device.
3. The electronic device according to claim 2, The first package is the flow control unit package specified by the PCI Express standard. The traffic control unit packet includes a data link layer packet. The interface circuit is configured to store the multiple credit information as multiple first data parts within the data link layer packet.
4. The electronic device according to claim 1, The interface circuit is configured to send the first packet of credit information, which also includes a category identifier representing one of the plurality of categories and a credit amount corresponding to the one of the plurality of credit amounts, to the external electronic device.
5. The electronic device according to claim 4, The first package is the flow control unit package specified by the PCI Express standard. The traffic control unit packet includes a data link layer packet. The interface circuit is further configured to, The category identifier is stored as a second data section within the data link layer packet. The credit information is stored as a third data section within the data link layer packet.
6. The electronic device according to claim 3 or 5, The interface circuit is further configured to store data representing the type of a specific data link layer packet as the fourth data section within the data link layer packet.
7. The electronic device according to claim 6, The specific data link layer packet type is defined by the No Operation (NOP) as specified in the PCI Express standard.
8. The electronic device according to claim 1, The multiple categories include the Publication Request Header (PH), Publication Request Data Payload (PD), Non-Publication Request Header (NPH), Non-Publication Request Data Payload (NPD), Completion Header (CplH), and Completion Data Payload (CplD), as defined by the PCI Express standard.
9. The electronic device according to claim 1, Each of the multiple credit values represents the amount of data that can currently be received from the external electronic device for the corresponding category by the number of data units corresponding to the corresponding category.
10. An electronic device comprising random access memory and interface circuitry, The interface circuit is configured to perform communication between the electronic device and an external electronic device, and to store data received from the external electronic device in the random access memory. The interface circuit is further configured to, Multiple primary credit values are managed, each corresponding to a different category, and each category represents the amount of data of the corresponding category that can currently be sent to the external electronic device. The external electronic device receives a first packet containing credit information representing a second credit value, wherein the second credit value corresponds to one of the plurality of categories and represents the amount of data that the external electronic device can currently receive for that one category. The first credit score and the credit information corresponding to the first category are compared.
11. The electronic device according to claim 10, The interface circuit is further configured to output an error if the first credit value corresponding to the one category does not correspond to the credit information.
12. The electronic device according to claim 10, The first packet includes multiple credit information items representing multiple second credit values, each second credit value corresponding to a multiple category and each representing the amount of data that the external electronic device can currently receive for the corresponding category. The interface circuit is configured to compare the first credit value corresponding to the one category and the credit information corresponding to the one category among the plurality of credit information.
13. The electronic device according to claim 12, The first package is the traffic control unit package specified by the PCIExpress standard. The traffic control unit packet includes a data link layer packet. The interface circuit is configured to obtain the multiple credit information from multiple first data portions within the data link layer packet.
14. The electronic device according to claim 10, The first package also includes a category identifier representing the one category. The interface circuit is configured to compare the first credit value and the credit information corresponding to the first category based on the first category identifier.
15. The electronic device according to claim 14, The first package is the traffic control unit package specified by the PCIExpress standard. The traffic control unit packet includes a data link layer packet. The interface circuit is configured as follows: The category identifier is obtained from a second data section within the data link layer packet. The credit information is obtained from a third data section within the data link layer packet.
16. The electronic device according to claim 13 or 15, The interface circuit is further configured to obtain data representing the type of a specific data link layer packet from the fourth data section within the data link layer packet.
17. The electronic device according to claim 16, The specific data link layer packet type is defined by the No Operation (NOP) as specified in the PCI Express standard.
18. The electronic device according to claim 10, The multiple categories include the Publication Request Header (PH), Publication Request Data Payload (PD), Non-Publication Request Header (NPH), Non-Publication Request Data Payload (NPD), Completion Header (CplH), and Completion Data Payload (CplD), as defined by the PCI Express standard.
19. The electronic device according to claim 10, Each of the plurality of first credit values represents the amount of data of the corresponding category that can currently be sent to the external electronic device by means of the number of data units corresponding to the corresponding category. The second credit value represents the amount of data that the external electronic device can currently receive for the category by the number of data units corresponding to the category.
20. An electronic device comprising an interface circuit and a control circuit, The control circuit is configured as follows: The first quantity representing the state of the internal resources of the electronic device is managed. The first packet, representing the initial value of the first quantity, the second packet, representing the increase or decrease of the first quantity, and the third packet, representing the current value of the first quantity, are sent via the interface circuit.