Visualization system for debugging or performance analysis of SOC system

Abstract

The invention relates to a visualization system for debugging or performance analysis of an SOC system. The interface receives report information from a system on chip (SOC), where the report information includes: (1) hardware report information reported by a hardware function module included in the SOC, and (2) firmware report information reported by a firmware function module included in the SOC. The processor receives the one or more display settings and generates visual information based at least in part on: (1) the one or more display settings, (2) hardware reporting information, and (3) firmware reporting information. Visual information is displayed via a display.

Description

[0001] Cross-references to other applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 222,264, filed on July 15, 2021, entitled “PERFORMANCE VISUALIZATION SYSTEM,” which is incorporated herein by reference for all purposes. Background Art

[0003] Given the real-time nature and complexity of embedded and / or system-on-chip (SOC) systems, unexpected behavior in such systems is notoriously difficult to debug. Debugging techniques that work with other types of systems (e.g., intrusive debug probes added at key locations in non-real-time systems, "brute force" debugging in simple systems, and the addition of probes at easily accessible points in distributed systems) are not easily relocatable and / or feasible with some embedded and / or SOC systems. New technologies that provide better tools and / or techniques for analyzing, debugging, and / or monitoring such systems would be desirable. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Various embodiments of the invention are disclosed in the following detailed description and accompanying drawings.

[0005] Figure 1 is a flow chart illustrating an embodiment of a process for displaying visual information using hardware reported information and firmware reported information from a SOC system.

[0006] Figure 2 is a system diagram illustrating an embodiment of a SOC system having a reporting module in each functional module to collect and store status information.

[0007] Figure 3 is a diagram illustrating embodiments of time-based messages, event-based messages, and timestamp messages.

[0008] Figure 4 are diagrams illustrating two embodiments of aggregated and time-stamped message flows in a message capture memory.

[0009] Figure 5 is a diagram illustrating an embodiment of a flash controller implemented on a SOC system.

[0010] Figure 6 is a diagram illustrating an embodiment of performance-related visual information associated with read and write operations of a flash memory controller.

[0011] Figure 7is a diagram illustrating an embodiment of a magnified window showing information from event-based messages reported by an NVMe functional module in a flash controller.

[0012] Figure 8 is a diagram illustrating an embodiment of a process of generating visual information using latency.

[0013] Fig. 9 is a diagram illustrating an embodiment of visual information showing gap values ​​associated with the front end, middle end, and back end of a flash controller.

[0014] Fig.10 is a diagram illustrating an embodiment of visual information showing a workload metric of a flash controller.

[0015] Fig.11 is a diagram illustrating an embodiment of visual information showing bus utilization of one channel in a flash controller.

[0016] Fig.12 is a diagram illustrating an embodiment of visual information showing die access information of a flash controller.

[0017] Fig.13 is a diagram illustrating an embodiment of visual information showing statistical latency information of a flash controller.

[0018] Fig.14 is a diagram illustrating an embodiment of visual information showing bus utilization information for all four channels in a flash controller.

[0019] Fig.15 is a flow chart illustrating an embodiment of a process for displaying visual information using hardware reporting information and firmware reporting information that are generated using a template from a visualization system. DETAILED DESCRIPTION

[0020] The present invention may be implemented in many ways, including as a process; an apparatus; a system; a composition of matter; a computer program product contained on a computer-readable storage medium; and / or a processor, for example, a processor configured to execute instructions stored on and / or provided by a memory coupled to the processor. In this specification, these implementations or any other form that the present invention may take may be referred to as techniques. In general, the order of the steps of the disclosed processes may be changed within the scope of the present invention. Unless otherwise stated, a component such as a processor or memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform a task at a given time, or as a specific component manufactured to perform the task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores configured to process data such as computer program instructions.

[0021] A detailed description of one or more embodiments of the present invention is provided below, together with the accompanying drawings that illustrate the principles of the present invention. The present invention is described in conjunction with such embodiments, but the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention includes many alternatives, modifications and equivalents. In order to provide a comprehensive understanding of the present invention, many specific details are set forth in the following description. These details are provided for illustrative purposes, and the present invention can be implemented according to the claims without some or all of these specific details. For the purpose of clarity, technical materials known in the technical field related to the present invention are not described in detail so as not to make the present invention unnecessarily obscure.

[0022] Various embodiments of visualization techniques and / or systems for analyzing, debugging and / or evaluating embedded and / or system-on-chip (SOC) systems are described herein. As used herein, the terms "embedded system" and "SOC (system)" are used interchangeably. As will be described in more detail below, such visualization systems can eliminate the need for expensive analyzers that may be difficult to attach to SOC systems; such visualization systems can also provide features, tools and / or operations that are not supported by existing analyzers (e.g., they provide better insight into inefficiencies and / or errors in SOC systems).

[0023] Figure 11 is a flow chart illustrating an embodiment of a process for displaying visual information using hardware reporting information and firmware reporting information from a SOC system. In some embodiments, the process is performed by a visualization system. In some embodiments, the visualization system is implemented using a visualization program running on a (e.g., general purpose) computer. The visualization program can be implemented on an application installed on a computer, using a web-based application accessible via an Internet browser application, using a computer program product contained on a computer-readable storage medium, etc.

[0024] At 100, report information is received from a system on chip (SOC), wherein the report information includes: (1) hardware report information reported by a hardware function module included in the SOC, and (2) firmware report information reported by a firmware function module included in the SOC.

[0025] In one example of step 100, the reporting information from the SOC system is first stored on some storage system or storage medium external to both the SOC system and the computer on which the visualization application is running. Using the computer's built-in interface(s), the reporting information is retrieved from the (external) storage system or storage medium. Alternatively, in some embodiments, the reporting information is passed directly from the SOC system (which generates the reporting information) to the visualization system.

[0026] At 102, one or more display settings are received. At 104, visual information is generated based at least in part on: (1) the one or more display settings, (2) the hardware reporting information, and (3) the firmware reporting information.

[0027] At 106, the visual information is displayed. For example, a computer's built-in display (on which the visualization program is running) can be used to display the visual information. Some example screenshots are described in more detail below.

[0028] In one example of steps 102, 104, and 106, display settings associated with a "zoom in" sequence are received, and in response, corresponding zoomed in visual information is generated and displayed. An initial set of display settings can be obtained (e.g., stored in a visualization system) that is used to generate a start screen or initially displayed visual information. This start screen (at least in this example) is at the highest (e.g., hierarchical) level of the SOC, with available functional modules (e.g., which are configured to report status and / or event information). For example, a graphical user interface displaying such a start window may include a first window with a list of (e.g., available, reporting, etc.) hardware and firmware functional modules, and another window may include (as an example) corresponding wait time scatter plots associated with (e.g., high-level) operations of those functional modules.

[0029] Subsequent zoom-in instructions or interactions produce (at least in this example) an enlarged screen with performance metrics of the operations within the zoom range and a plot of the wait times for the associated operations. For example, one window in the display may be an operation metric table summarizing one or more (e.g., performance) metrics associated with one or more operations. There may also be a window showing the underlying data used to calculate a given metric for a given operation. For example, a metric may be "average wait time," and an operation may be "read from memory" or "write to memory." One window shows data for calculating the average wait time for a read operation (e.g., in the form of a wait time scatter plot), and another window shows the average wait time for a write operation.

[0030] Further zooming in may present information at the lowest and / or most detailed level, such as operation metadata, the size of the operation or the size of a piece of data associated with the operation (e.g., the size of the data being written, read, transmitted, received, transformed, etc.), the type of operation, settings associated with the operation, tag information, and resources used (e.g., from shared resources such as shared buffers, shared channels, shared RAID resources, etc.). In other words, the information displayed at a lower (lowest) level may include various messages generated from (related) hardware functional modules and / or firmware functional modules and associated with the (e.g., selected) operation and / or event of interest (e.g., see Figure 3 ) in the various fields.

[0031] In some embodiments, the visual information (e.g., generated at step 104 and displayed at step 106) is in the form of a 2D or 3D display. In one example, the workload view provides a user with a view of transactions and / or operations performed over time. In a 2D example, a line graph of a (e.g., performance) metric is shown where the x-axis is time and the y-axis is the (e.g., performance) metric. In a 3D example, the x-axis is commands (e.g., the number of commands), the y-axis is time, and the z-axis is size (e.g., the size of a given command or some of the data associated with the command). These displayed time values ​​can be obtained from the timestamps in the messages (e.g., see Figure 3 The timestamp field (330) in the event-based message (320) and the payload (344) in the timestamp message (340)).

[0032] Before describing various features and / or embodiments of the visualization system in more detail, it may be helpful to give some examples of SOC systems that generate report information (e.g., received at step 100) and are analyzed by the visualization system; more detailed examples of the report information may also be helpful. The following figures describe some example SOC systems and some examples of report information.

[0033] Figure 2 200 is a system diagram illustrating an embodiment of a SOC system, with a reporting module in each functional module to collect and store status information. In this example, the exemplary SOC system (200) includes a plurality of functional modules (202). In various embodiments, the exemplary SOC system (200) is an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc. In various embodiments, the functional module (202) is a hardware module consisting of only electronic circuits, a firmware module consisting of instruction codes operating on a processing unit, etc.

[0034] In this example, the ability to analyze (e.g., in real time or after some latency) the behavior and / or operation of each of a plurality of functional modules (202) is desired. For example, each of the functional modules may facilitate critical processing or movement of data such that subsequent analysis and / or inspection is highly satisfactory. To this end, each functional module (202) has a subcomponent, referred to in this figure as a reporting module (204), which collects status information from within its functional module, encapsulates that status information in a standardized message format, and sends the encapsulated information over a dedicated link (206) to a central message collection module, referred to in this figure as an aggregation module (208). In some embodiments, less critical and / or less interesting (from a debugging perspective) functional modules do not have a reporting module.

[0035] In this example, each reporting module (204) includes one or more reporting rules (not shown) that describe the conditions under which time-based messages and / or event-based messages are generated and sent. These reporting rules may also describe what specific registers, values, nodes, states, etc. should be included or otherwise used as state information sent to the aggregation module (208). For example, each reporting module (204) may include a controller that compares the condition(s) specified in the reporting rules with the relevant variables, states, events, etc. in that particular functional module.

[0036] In this example, messages are received from different links (206) by the aggregation module (208) and aggregated into a single aggregated stream. The timestamp is then inserted into the aggregated stream to obtain a timestamped and aggregated stream. While this example describes first aggregating and then timestamping, in some embodiments, that order is reversed.

[0037] The timestamped and aggregated streams are passed from the aggregation module (208) to the memory (210). The timestamped and aggregated streams are transported from the memory (210) to the SOC system (200) via the storage interface (216) so that the information can be exported off-chip to an (external) storage medium (218), such as flash and / or solid-state drive (SSD) memory. For example, this test infrastructure is first prototyped and / or implemented on a storage controller, and thus the storage interface (216) has already been implemented. In other words, in some embodiments, the storage interface (216) is a "production" interface that is already implemented and / or used by routine, non-debug related operations supported by the SOC (200).

[0038] From the (external) storage medium (218), the visualization system (214) is configured to ingest, filter, display and / or analyze the time-stamped and aggregated streams obtained from the storage medium (218) as directed by a user.

[0039] In one particular example, the SOC (200) (i.e., the device analyzed using the visualization system (214)) is a flash memory controller, and the storage medium (218) is a flash memory medium managed and / or controlled by the flash memory controller. In this application, because there is a readily available storage medium (218) and the SOC (200) controls writing to that storage medium (e.g., so there is no concern about any captured information being accidentally overwritten by another device), the information in the memory (210) is sent off-chip via the storage interface (216). If or when analysis by the visualization system is desired, the storage medium (216) can be accessed by the information processor to retrieve (e.g., debug) the information stored therein.

[0040] The following diagrams describe some examples of standardized message formats that may be used by the reporting module (204).

[0041] Figure 3 is a diagram illustrating embodiments of time-based messages, event-based messages, and timestamped messages. These are some examples of standardized message formats in which state information may be included. These messages may then be aggregated and timestamped to create an aggregated and timestamped stream that is stored and may be ingested by a visualization system to analyze the SOC system that generated the messages. Figure 2 In the example embodiment, the reporting module (204) can use one or more of the exemplary standardized message formats shown here to send status information to the aggregation module (208). In various embodiments, the system can support any number of standardized message formats (ie, message types).

[0042] In this example, three message types are shown identified by a type field (322) in a fixed position in the message, which in this example is the first three bits of each message. In this example, the first message type is a time-based message (300), where the first field (comprising 3 bits) is the type field (302) having a value identifying the message as a time-based message.

[0043] The Type field (302) is followed by a 3-bit Sequence field (304). This field is a time-based sequence identifier for a given functional module that operates more frequently than a given reporting module (e.g., Figure 2 204 in ) and aggregation modules (e.g., Figure 2 The time-based sequence identifier may be included based on the frequency of the link between the ports (208 in 208). For example, this is a common situation when the interconnect between the ports and the aggregation module operates at (as an example) 25% of the nominal system operating frequency, which (as described above) saves power. With a system so configured, messages may occasionally be dropped because the rate of generation (e.g., by the reporting module) is greater than the rate of absorption or transmission (e.g., by the aggregation module). This condition is detected and post-processed as a non-uniform increment of the sequence identifiers of two adjacent messages. In one example, each time a new time-based message is sent, the sequence field (304) is incremented by 1 so that if there are two or more hops, the post-processor knows that some messages have been lost. In some embodiments, the sequence number (304) is based on and / or includes some bits from the timestamp used to timestamp the message (340).

[0044] The next field in the time-based message (300) is a payload field (306) having 10 bits. For example, the time-based reporting rules may specify what state information is included in the payload field (306) in the time-based message (300). In one example, the time-based messages (300) including the value or state of the finite state machine are sent when (or when) the finite state machine is not in the idle state. These time-based messages (300) continue to be sent periodically until the finite state machine returns to the idle state, at which point the time-based message generation ceases (at least in this example).

[0045] In this example, the second type of message is an event-based message (320). As with the other message types, the first field is a 3-bit type field (322), where the value identifies the message as an event-based message.

[0046] Next is a 13-bit tag field (324) and a 3-bit subtype field (326). The subtype field (326) is sometimes referred to as an event identifier field because the various events captured and reported by event-based messages are each assigned an event number or identifier. In this example, because the subtype (i.e., event identifier) ​​field (326) has 3 bits, the event identifier ranges from 0 to 7, inclusive.

[0047] For some functional modules, having eight event identifiers is enough to uniquely identify all events that are expected to be recorded for it. However, some functional modules support many different types of operations (e.g., emission and reception), have many interesting intermediate events between the start event and the end event, and / or have control channels and data channels (each with its own relevant events). Therefore, in some cases, eight event identifiers are not enough to uniquely identify all events that are expected to be reported for it. In this example, in order to adapt to such situations, some events share event identifier values, and a certain part of the tag field (324) is used to distinguish the events of the shared event identifier value. In the case where the event identifier value is unique (that is, it is associated with only one event), the tag is used to transmit other information, such as other status information (e.g., according to the instructions in the relevant event-based reporting rules).

[0048] Next in the event-based message (320) are two reserved fields. The first reserved field (328) is a 5-bit space reserved for replacement with the identifier of the message generating function module. For example, in Figure 2 , the functional module (202) will generate the event-based message (320), but leave this first reserved field (328) blank. At the aggregation module (208), the first reserved field (328) is populated by the aggregation module (208) with an identifier associated with the functional module (202) from which the event-based message (320) is received (e.g., known because the link (206) is dedicated, not shared).

[0049] The second reserved field (330) is an 8-bit field that is reserved for replacement with a timestamp. The event message timestamp (330) is used for the same purpose as the time-based sequence identifier (304) in the time-based message (300). However, because event-based messages occur more sporadically than time-based messages, they require a larger field to capture larger time differences between event-based messages (320) or between event-based messages (320) and timestamp messages (340). As with the first reserved field (328), it is used by a reporting module (e.g., Figure 2 204) and / or functional modules (e.g., Figure 2202 in the example) leaves the second reserved field blank and in the aggregation module (e.g., Figure 2 208) in is filled.

[0050] The last field in the event-based message (320) is a 32-bit payload field (332) for carrying a payload associated with the relevant event. The specific (status) information included in the payload (332) is specified by the relevant event-based reporting rule.

[0051] Conceptually, event-based reporting (e.g., using event-based reporting rules) can be considered a (more) sparse reporting technique because only one event-based message is generated when a condition is detected. In contrast, time-based reporting (e.g., using time-based reporting rules) is a (more) intensive reporting technique because time-based messages are continuously generated when the condition is met. Therefore, time-based reporting will tend to generate many more messages than event-based reporting. To account for this difference, in this example, the size of the exemplary time-based message (300) is smaller than the size of the exemplary event-based message (320) (e.g., 16 bits for the exemplary time-based message (300) compared to 64 bits for the exemplary event-based message (320)).

[0052] The third message in this example is a timestamp message (340), which includes a 3-bit type field (342) identifying the message as a timestamp message, and a 29-bit payload field (344) used to store the value of the timestamp. In some embodiments, the timestamp written to the second reserved field (330) of the event-based message (320) is the least significant eight bits of the longer timestamp included in the payload (344) of the timestamp message (342).

[0053] In this example, the timestamp message (340) does not cross message interconnects (e.g., Figure 2 More specifically, if the message flow is interrupted for any reason (e.g., temporary storage is unavailable), the timestamp message in this example is transmitted by the aggregation module (e.g., Figure 2 208) is generated and inserted into the message capture memory (eg, Figure 2 210) in the stream for accurate representation.

[0054] As shown in this example, in some embodiments, time stamping (e.g., Figure 1 ) includes inserting a timestamp message (eg, 340) into the aggregate message stream.

[0055] This example also shows that in some embodiments, time stamping (e.g., Figure 1 ) includes writing the timestamp into a reserved field (e.g., 330) in a standardized message format (e.g., 320) reserved for timestamps.

[0056] The message sizes and formatting illustrated herein are exemplary only and are not intended to be limiting. In various embodiments, different message sizes, field sizes, and / or field locations may be used.

[0057] As in Figure 2 and 3 As shown in , in some embodiments, the report information (e.g., in Figure 1 ) includes a timestamped and aggregated message stream (eg, from an aggregation module (eg, Figure 2 208) is sent to the memory (eg, Figure 2 210), and the timestamped and aggregated message stream is provided by the SOC (e.g., Figure 2 200) included in the aggregation module (for example, Figure 2 208) is generated, which is configured to be generated from hardware functional modules (e.g., Figure 2 One of the functional modules (200) in the embodiment receives hardware event information in a standardized message format (e.g., see Figure 3 event-based messages (320) in the firmware functional module (e.g., Figure 2 One of the functional modules (200) in the embodiment receives firmware event information in a standardized message format (e.g., see Figure 3 The method further comprises: obtaining an event-based message (320) in a standardized message format, and aggregating and time-stamping hardware event information in a standardized message format and firmware event information in a standardized message format to obtain a time-stamped and aggregated message stream.

[0058] In some embodiments, timestamping (e.g., hardware event information in a standardized message format and / or firmware event information in a standardized message format to obtain a timestamped and aggregated message stream) includes writing the timestamp to a reserved field in the standardized message format reserved for timestamping.

[0059] exist Figure 3 In the example of FIG. 1 , the sizes of the three exemplary message types ( 300 , 320 , and 340 ) are carefully selected so as to be able to fit in the capture memory (e.g., Figure 2 In 210), messages can be evenly interleaved on message boundaries to prevent partial messages from being overwritten in the event of a message overwrite. The following figure shows an example of this.

[0060] Figure 4is a diagram illustrating two embodiments of aggregated and time-stamped message flows in a message capture memory. In this figure, a first memory segment (400) and a second memory segment (420) illustrate two examples of aggregated and time-stamped message flows stored in a message capture memory. For example, the two memory segments (400 and 420) illustrate Figure 2 An example of a memory (210) in.

[0061] In the first memory segment (400), a 32-bit timestamp message (402) first appears, occupying half of a 64-bit slot of the memory; the remainder of the slot is unused. In this example, each slot of the memory is 64 bits, and the timestamp message (402) has Figure 3 Example sizes and formats are shown in .

[0062] Next, three 64-bit event messages (404) each occupy one memory slot, so that the second, third, and fourth slots are occupied by event messages.

[0063] Then, a sequence of 13 time-based messages is stored (406). Each time-based message (406) is 16 bits long, so the fifth, sixth, and seventh slots each have four time-based messages per slot. In this example, the time-based messages are used to capture the state or value of the finite state machine when the finite state machine is not in an idle state (e.g., from the time it leaves the idle state until the time it returns to the idle state). Therefore, in this example, the term "state capture" is used to describe the time-based messages (406), but in other embodiments, time-based messages are used to capture or record other types of information in the functional module.

[0064] The last slot is occupied by an event-based message (408).

[0065] In this example, each event-based message (e.g., 404) occupies a single slot, while time-based messages (e.g., 406) are written to four slots. The advantage of maintaining the sizes and (slot) offsets shown here is that less overhead information needs to be saved, which would be required if (as an example) event messages could start at any offset within the slot rather than at zero offset. Similarly, if the message sizes are not multiples of each other, and the messages are not aligned with the slots shown here, then when the old message is overwritten with the new message, the random mixing of the two messages will make it very difficult to distinguish message boundaries, thereby partially creating messages. Partial messages may have missing type identifiers (to distinguish message types) and / or missing message content (making it difficult to identify the end of the message).

[0066] It is noted that the various event messages (404 and 408) and state capture (ie, time-based) messages (406) may come from a variety of functional modules, and not necessarily from a single functional module. Rather, they are aggregated at the aggregation module in the order in which they are received.

[0067] A downside to the embodiment of generating the first memory segment (400) shown is that supporting multiple message types (each with a different message size) increases the complexity of the aggregation module. For example, to ensure that the last event message (408) begins at the beginning of the last slot, the aggregation module must track the number of previous state capture (i.e., time-based) messages (406) so that if that number is not a multiple of four, one or more unused fourth slots are inserted before the last event message (408). In some applications, a less complex implementation is desired, especially if a debugging system is being implemented for the first time. The following figure shows a less complex embodiment in which only event messages are stored.

[0068] The second memory segment (420) shows an example in which only event-based messages (422) are generated and stored. That is, in this example, neither time-stamp messages nor state capture (i.e., time-based) messages are generated (e.g., by a reporting module or aggregation module).

[0069] The benefit of an embodiment where only event-based messages are generated and stored (as shown in the second memory segment (420)) is that it is much simpler for the aggregation module to store messages because there is only one type (and therefore size) of messages supported. The aggregation module does not need to keep track of timestamped messages or the number of state-capturing (i.e., time-based) messages and insert an unused fourth or half slot if needed. It is also more memory-efficient because there is no unused portion, and the total amount of memory used is less than the first memory configuration because there tend to be many state-capturing (i.e., time-based) messages, while event-based messages tend to be more sparse. For these reasons, in some embodiments, only event-based messages are generated and stored.

[0070] The following figure illustrates an exemplary flash controller (implemented on a SOC system) that is analyzed and / or debugged using a visualization system according to the techniques described herein. Then, an exemplary screenshot that may be displayed by the visualization system when debugging and / or analyzing the exemplary flash controller is described.

[0071] Figure 5 is a diagram illustrating an embodiment of a flash memory controller implemented on a SOC system. The flash memory controller (500) is Figure 2An example of a SOC system (200) in which hardware reporting information and firmware reporting information are generated and which are then used by a visualization system (e.g., based on Figure 1 ) uses that hardware reporting information and firmware reporting information for debugging and / or analysis. To maintain the readability of the diagram and for ease of explanation, a sampling of exemplary hardware functional modules and firmware functional modules is shown here; this is not intended to be a complete functional block diagram. For example, although only hardware functional modules are described herein, in some embodiments, other embodiments include firmware functional modules configured to report status information.

[0072] In this example, the flash controller (500) includes a PCI Express (PCIe) functional module (502). In some embodiments, the PCIe (502) is a hardware functional module and an IP core. For example, a third party may sell the PCIe functional module, and the purchaser "drops" the IP core into their SOC design.

[0073] Another functional module in this example is non-volatile memory (NVMe) (504). In this example, NVMe (504) is a hardware functional module that communicates with the host driver to receive host commands (e.g., initiate data extraction or copying to or from the host, etc.) and it is a logical protocol layer above the physical PCIe layer.

[0074] The LDPC decoder (506) is a hardware functional module that performs error correction decoding on data stored in the flash medium (508). For example, data stored on the flash medium (508) may experience data degradation due to charge leakage. This is particularly true for data that has been stored on the flash medium (508) for a relatively long time and / or when the flash medium (508) wears out and "leaks" (for example, when the flash medium (508) has experienced a relatively large number of program and / or erase cycles). During a read operation, when significantly degraded read data is error corrected, the LDPC decoder (506) can introduce a considerable amount of delay because the LDPC decoder must resort to more powerful decoding techniques, which also consume more time. Therefore, when analyzing the performance of the read path, the LDPC decoder (506) may be of interest because it can add significant delay.

[0075] The flash controller (500) also includes channel 0 Ncmd processor (510a) - channel 3 Ncmd processor (510d) as hardware functional modules. These functional modules are processors that interface with four channels and receive commands via the four channels. The number of channels shown here is only exemplary, and for higher throughput applications, there may be more channels.

[0076] The following table shows the Figure 5 Table 1 shows some example events reported by the functional modules shown in Table 1, which are subsequently used to analyze the performance of the flash controller (500) and / or debug the flash controller (500). For the sake of brevity, similar or identical events related to multiple functional modules are not necessarily shown. For example, each functional module may report (multiple) error events, which are useful for debugging, but for the sake of brevity, Table 1 only shows the error events of the PCIe functional module.

[0077]

[0078] Table 1: Figure 5 Example events reported by the example function module shown in FIG.

[0079] A benefit of the visualization system described herein is that it eliminates the need for external and / or physical analyzers, which may be expensive, bulky, and / or limited in some way. Figure 5 In the embodiment of the present invention, the PCIe analyzer (513) is located between the host (513) and the flash controller (500). This side of the flash controller (500) is sometimes referred to as the front end. The PCIe analyzer is sometimes used to analyze and / or debug a SOC system including a PCIe functional module (502). In this example, the visualization system provides and / or supports operations related to PCI analysis, so that a physical PCIe analyzer (513) is not required. PCIe analyzers are very expensive (e.g., on the order of hundreds of thousands of dollars), so it is desirable to be able to analyze PCI-related communications and / or operations without having to purchase a PCIe analyzer. In addition, in some instances, access to the flash controller (500) is difficult and / or there is not enough space around the flash controller (500) to attach the PCIe analyzer. For example, in an enterprise and / or cloud storage system, there may be many flash controllers that are tightly packed together, and there may not be enough space to access the flash controller and attach the PCIe analyzer (513).

[0080] Another analysis and / or tool that the visualization system may eliminate the need for is a logic analyzer (514) located between the flash controller (500) and the flash media (508). This side of the flash controller (500) is sometimes referred to as the back end. In this example, the visualization system provides and / or supports operations related to the logic analyzer, so that the logic analyzer (513) is not required. The logic analyzer (514) operates at a slower speed than the SOC system; for example, the former may only operate at a few hundred kHz, while the latter is typically in the MHz range. Therefore, when using a logic analyzer, the SOC system (e.g., 500) must be slowed down, which in some cases eliminates or hides defects or performance issues. In contrast, using the analysis techniques described herein, SOC systems can operate at their normal operating clock frequency, which helps to expose or otherwise recreate defects or performance issues. Logic analyzers (514) also tend to be memory limited, so that only a limited period and / or a limited number of signals can be captured, displayed, and analyzed. Using Figure 5 In the flash controller (500) application shown in FIG. 5 , the size of the flash media (508) (eg, where the hardware reported and firmware reported information is stored before being retrieved by the visualization system) is much larger and exceeds the storage capacity of the logic analyzer (514) by several orders of magnitude.

[0081] In addition, the features provided by the PCIe analyzer and logic analyzer may also be relatively coarse and / or incomplete compared to the features and / or tools provided by the visualization system (i.e., the visualization system provides features and / or tools that the PCIe analyzer and logic analyzer do not provide). For example, the PCIe analyzer and logic analyzer do not have access to various intermediate events within the hardware and firmware functional modules, which intermediate events may be helpful in identifying defects (e.g., determining that a system "hang" occurred because one of the firmware functional modules and / or hardware functional modules did not properly signal an end event to end an operation and / or release shared resources) and / or improving performance (e.g., having access to die usage information reported by the firmware functional modules and / or hardware functional modules to ensure that die interleaving is occurring in a (more) efficient manner). The following figures show some example displays presented by the visualization system, some or all of which are not supported by the PCIe analyzer or logic analyzer.

[0082] Figure 6 is a diagram illustrating an embodiment of performance-related visual information associated with read and write operations of a flash memory controller. In this example, display (600) shows Figure 5 The display (600) shows the latency information of multiple read and write operations performed by the flash memory controller (500) of the visualization system. Figure 1An example of the visual information displayed at step 106 in FIG.

[0083] At the top of the display are three latency charts: the left chart (602a) shows read latency and write latency, the center chart (602b) shows (only) read latency, and the right chart (602c) shows (only) write latency. All charts (602a-602c) have time as the x-axis, and in this example, the time from event-based messages (e.g., Figure 3 320) in the timestamp field (e.g., Figure 3 330) in to obtain those x-axis time values.

[0084] In this example, the read latency value is calculated by subtracting the timestamp from the message based on the "ReadXferStart" event generated by the NVMe function module (which corresponds to the start of the read operation) from the (later) timestamp from the corresponding "ReadXferEnd" event message (which corresponds to the completion of the read operation) (shown in the Read and Write Latency Chart (602a) and the Read Latency Chart (602b)). The corresponding read event message is identified by having the same value in the appropriate fields of the start and end event messages. A similar calculation can be performed for write latency using messages based on the "WriteXferStart" and "WriteXferEnd" events.

[0085] The read latency chart (602b) shows that the fastest read latency is in the range of 0-100 μs, while the slowest read latency is in the range of 1,000-1,200 μs. The write latency chart (602c) shows that the fastest write latency is in the range of 0-25 μs, while the slowest write latency is in the range of 300-400 μs. By clicking or selecting one of the slower latencies in one of the latency charts (602a-602c), the visualization system in response updates the event information window (604) to display relevant event information for the selected read or write latency. For example, this can help SOC developers identify inefficiencies in the read or write path.

[0086] In this example, the flash controller has already been manufactured, so any short-term improvements (e.g., Figure 5) can be implemented by adjusting settings (e.g., in hardware and / or firmware) and / or by updating firmware running on the SOC. Long-term (e.g., hardware) improvements to hard-coded inefficiencies can be implemented in the (hardware) register transfer language (RTL) so that the next generation of SOC systems are manufactured using those (hardware) improvements.

[0087] As shown in this example, in some embodiments, a SoC (e.g., Figure 1 ) includes a flash controller, and visual information (e.g., Figure 1 ) shown at step 106 in ) includes waiting time information.

[0088] The bottom window (604) shows the events reported by the functional modules. Each row corresponds to a functional module, and the dots in each row correspond to the events reported by that functional module. The following figure shows an enlarged view when a first cursor (e.g., cursor X) and a second cursor (e.g., cursor Y) are set to a first and a second time, respectively.

[0089] Figure 7 is a diagram illustrating an embodiment of a magnified window showing information from an event-based message reported by an NVMe functional module in a flash controller. In this example, display (700) corresponds to Figure 6 An enlarged version of the bottom window (604).

[0090] In this example, the NVMe function module (702) has been expanded to show the events Write Transfer Complete (WriteXferDone) (704a), Read Transfer Complete (ReadXferDone) (704b), and NVMe Cmd Extraction End (704c) reported by the NVMe function module (702). To the right of each event (704a-704c) are the fields, content, and / or payload of the event-based message associated with the corresponding event. As shown in this example, the Write Transfer Complete (WriteXferDone) message (706a) includes a timestamp, a ctag (e.g., a type of tag), a TAGID (e.g., a type of identifier), and a SCMDID (e.g., another identifier); the Read Transfer Complete (ReadXferDone) message (706b) includes a timestamp and a ctag, and the NVMe Cmd Extraction End message (706c) includes a timestamp, a ctag, a read / write (R / W) indicator, a TAGID, and a FLBA (e.g., a type of address).

[0091] The following figure more generally and / or formally describes in a flow chart this technique of using start and end messages to (eg, automatically) calculate wait times.

[0092] Figure 8 is a diagram illustrating an embodiment of a process for generating visual information using waiting time. Figure 1 Generating visual information at step 104 includes executing Figure 8 In one example, Figure 8 The process of Figure 2 The visualization system (214) shown in FIG.

[0093] At 800 , a start event-based message and an end event-based message are identified based at least in part on identical values ​​of unique operation identifiers in the start event-based message and the end event-based message.

[0094] For example, in Table 1 (above), there is a Read Transfer Complete (ReadXferDone) event message. NVMe can be configured to generate a related Read Transfer Start (ReadXferStart) event message. Both messages may include fields or values ​​that uniquely identify the corresponding start and end event-based messages (e.g., Figure 2 The tag field (324) or some portion of the payload field (332) in the event-based message (320) in the start and end event has the same value. This could be a command sequence number, the location of the data being processed, the location of the command, etc., and they will have the same value in the start and end event-based messages.

[0095] At 802, a waiting time is calculated by subtracting a start timestamp included in a message based on a start event from an end timestamp included in a message based on an end event. Figure 2 A timestamp field (330) in an event-based message (320) in FIG.

[0096] At 804, visual information is further generated based at least in part on the waiting time. Figure 6 , the left graph (602a) shows a plurality of read and write latencies plotted along the y-axis, the center graph (602b) shows the read latency plotted along the y-axis, and the right graph (602c) shows the write latency plotted along the y-axis. The y-axis values ​​of those plotted points are based on the calculated latency values.

[0097] Waiting time information is just one type of information that can be displayed to debug and / or analyze a SOC system (e.g., the performance of the SOC system). The following figures illustrate various display embodiments showing various visual information. By viewing visual representations of various metrics (e.g., waiting time ranges over time, gaps in continuous operations, or events in high-level operations, etc.), it is easier to identify outliers and obtain information about outliers to identify which functional modules and / or stages in the system have unexpected delays.

[0098] Fig. 9 is a diagram illustrating an embodiment of visual information showing gap values ​​associated with the front end, middle end, and back end of a flash controller. In this example, the charts (900-905) are 2D charts where the x-axis is the sequence number and the y-axis is the gap value (e.g., between consecutive events, in μs). Each chart shows the gap values ​​for different functional modules and / or different events for a given functional module.

[0099] The top chart (900) shows the gap values ​​between consecutive fetch operations at the NVMe module (“NVMeFetchModule Cost” in the chart). The second chart from the top (901) shows the gap values ​​between consecutive events or operations at the firmware front-end virtual queue (“FW FE VQ cost” in the chart). The third chart from the top (902) shows the gap values ​​between consecutive events or operations at the firmware front-end module (“FW_FE Module Cost” in the chart). The third to last chart (903) shows the gap values ​​between consecutive events or operations at the firmware mid-end virtual queue (“FW_ME VQ Cost” in the chart). The second to last chart (904) shows the gap values ​​between consecutive events or operations at the firmware mid-end module (“FW_ME ModuleCost” in the chart). The bottom graph (905) shows the gap value between request events or operations at the firmware backend virtual queue ("FW_BE_REQ VQ Cost" in the graph).

[0100] In one example illustrating how gap values ​​may be calculated, logged or recorded event information (e.g., event-based messages generated by a functional module) may include sequence numbers or other association or identification information (e.g., to identify which events are consecutive events of interest), and timing information (e.g., a timestamp field in an event-based message) may be used to calculate gaps; based on the event and timing information, gap information for consecutive events may be presented as shown herein.

[0101] Fig.10 1 is a diagram illustrating an embodiment of visual information showing workload metrics for a flash controller. In this example, the top chart (1000) shows input / output operations per second (IOPS) along the left y-axis for both reads and writes and command size for reads and writes along the right y-axis. The middle chart (1002) shows read and write throughput. The bottom chart (1004) shows a 3D chart of command size, time, and command count (as three axes) for reads and writes.

[0102] Fig.11 is a diagram of an embodiment of illustrated visual information showing bus utilization of one channel in a flash memory controller. In this example, three tables with command statistics are shown at the top: bus utilization (1100) on the left, physical command timing (1102) for channel 0 in the center, and the number of physical commands (i.e., count) per 100 μs for channel 0 (1104) on the right. These metrics are related to bus utilization from the perspective of the command code. In some applications, this helps understand whether some commands are issued more than (e.g., absolutely) necessary to achieve the desired result or operation. Chip developers or designers can review the information shown in these examples to identify performance improvements (e.g., optimizing the number, size, and / or order of commands to achieve the same functionality, but more efficiently and / or faster).

[0103] For example, a command of 0x78 (in hexadecimal) is issued by the flash controller to the flash memory to read out whether the flash memory has completed the requested write or read operation. This 0x78 is sometimes referred to as a status check in this article. Sending too many status check commands will reduce bus utilization. Understanding this overhead allows unnecessary status check commands to be identified and eliminated. For example, see the circled row (1106), which shows that the status check commands account for 3.68% of the bus utilization for the channel in question.

[0104] The bottom graphs (1108 and 1110) show the gap between SCmds (e.g., the gap between two consecutive commands passed from firmware to hardware). The top graph (1108) is a histogram and / or distribution that has been sorted according to the gap value. The bottom graph (1110) is an unsorted version of the information and is sorted by sequence number or time. In this example, each gap value is calculated by subtracting the timestamp of the previous SCmd end from the timestamp of the current (i.e., next) SCmd end.

[0105] In this example, the maximum gap (1113a and 1113b) is approximately 80μs, while the average gap value is 7.45μs. In an ideal system, there should be no outliers, especially when the deviation from the average gap value is so large. By identifying and analyzing such outliers, unnecessarily long gaps in firmware processing time can be identified and mitigated. Mitigating this gap also results in higher flash bus utilization. In this example, the information displayed is generated from hardware functional module events, but it is also helpful to represent, identify and / or isolate hardware-firmware interaction delays.

[0106] As shown in this example, in some embodiments, a SoC (e.g., Figure 1 ) includes a flash controller, and visual information (e.g., Figure 1 ) shown at step 106 in ) includes bus utilization information.

[0107] Fig.12 is a diagram illustrating an embodiment of visual information showing die access information of a flash memory controller. In this example, multiple dies are used to implement a flash memory medium (e.g., Figure 5 508 in ), and thus accessing the flash media includes selecting a die to access, and some die sequential access modes are more efficient than other modes. Generally, interleaving or switching between dies within a particular command set is bad and / or undesirable, and continuous access to the same die (e.g., within a command set) is good and / or desirable.

[0108] The visual information presented here allows the developer to quickly and easily identify any inefficiencies in the chip access sequence. In this example, there is an isolated access to die index 1 (1200), which interrupts the access sequence to die index 0 (1202a and 1202b). Identifying such undesirable die access sequences can help the developer understand the potential problem and make changes in the design so that this interleaving can be eliminated or at least reduced in frequency.

[0109] As shown in this example, in some embodiments, a SoC (e.g., Figure 1 ) includes a flash memory controller configured to manage access to a flash memory medium including a plurality of dies, and visual information (e.g., Figure 1 ) includes a die access sequence associated with a plurality of dies in the flash memory medium.

[0110] Fig.131 is a diagram illustrating an embodiment of visual information showing statistical latency information for a flash controller. In this example, a top table (1300) has a column (1302) with average latency information, a column (1304) with maximum latency information, and a column (1306) with minimum latency information.

[0111] Fig.14 14 is a diagram illustrating an embodiment of visual information showing bus utilization information for all four channels in a flash memory controller. In addition, bus utilization, physical command timing, and physical command number are shown for all four channels (e.g., see groups 1400, 1402, 1404, and 1406) rather than just a single channel. Fig.14 An example similar to Fig.11 By comparing this information side by side, it is easier to identify deviations and / or underutilization between different channels.

[0112] In the above examples, the information presented by the various analysis tools and / or operations depends on certain event-based messages in the firmware report data and / or hardware report data. Due to storage limitations, it may not always be feasible to generate all types of event-based messages. The following figures describe examples in which appropriate templates are issued by the visualization system to configure the SOC system to generate appropriate (e.g., event-based) messages that will allow the visualization system to display the desired chart, table, or other type of (e.g., visual) information.

[0113] In some embodiments, the visualization system includes various templates that describe what event-based messages should be enabled and / or otherwise reported by various functional modules for a given visual display or type of information to be reported. Fig.12 The die (index) access sequence shown in FIG. 1 can obtain a certain set of event-based messages from the functional modules in the SOC, while Fig.11 The bus utilization information shown in may require a different set of event-based messages from functional modules in the SOC.

[0114] Fig.15 is a flow chart illustrating an embodiment of a process for displaying visual information using hardware reporting information and firmware reporting information generated using a template from a visualization system. Figure 2 The visualization system (214) in Fig.15 process.

[0115] At 1500, a selection of visual information to be displayed is received. For example, via a graphical user interface of the visualization system, a user may select one of the displays, graphs, tables, or other example visual information shown above to be displayed.

[0116] At 1502, a template is obtained based at least in part on a selection of visual information to be displayed, wherein the template includes one or more report configurations for at least one of: (1) a hardware functional module included in a system on a chip (SOC) or (2) a firmware functional module included in the SOC. In some embodiments, the template is pre-generated and selected from some set of stored templates. In some embodiments, the template is generated in real time.

[0117] exist Figure 2 In an example of FIG. 1 , a template ( 220 ) is sent from a visualization system ( 214 ) to a reporting module ( 204 ) in a SOC. The reporting configuration in the template ( 220 ) is used to configure the reporting module to generate appropriate (e.g., event-based) messages for display, analysis, and / or debugging desired by a user of the visualization system.

[0118] Return to Fig.15 , at 1504, report information is received from the SOC, wherein: the report information includes: (1) hardware report information reported by hardware functional modules included in the SOC, and (2) firmware report information reported by firmware functional modules included in the SOC; and the reported information is at least partially based on one or more report configurations.

[0119] At 1506, one or more display settings are received.

[0120] At 1508, visual information is generated based at least in part on: (1) one or more display settings, (2) hardware reporting information, and (3) firmware reporting information. As described above, the template ensures that the appropriate (e.g., event-based) messages required for the desired visual information have been generated by the SOC.

[0121] At 1510, visual information is displayed. For example, this is the visual information selected at step 1500.

[0122] Although the foregoing embodiments have been described in detail for the purpose of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways to implement the invention. The disclosed embodiments are illustrative and not restrictive.

Claims

1. A system comprising: The interface is configured as: receiving a selection associated with a set of desired visual information, wherein the set of desired visual information is associated with a system on a chip (SOC) including a hardware functional module and a firmware functional module; and Receiving reported information, including selected hardware reported information and selected firmware reported information; A processor configured to select a template from a plurality of available templates based at least in part on a selection associated with a desired set of visual information, wherein the selected template is used by the SOC to generate information for the report, including by: configuring the hardware functional modules as specified by the selected template to generate information for a selected hardware report; and configuring the firmware functional modules as specified by the selected template to generate information for the selected firmware report; A display is configured to display a desired set of visual information, including information reported by using selected hardware and information reported by selected firmware.

2. The system of claim 1, wherein the hardware functional modules include one or more of: a PCI bus (PCIe) functional module, a non-volatile memory (NVMe) functional module associated with communicating with a host driver to receive host commands, or an error correction decoder.

3. The system of claim 1, wherein: Reported information includes timestamped and aggregated message flows; and The timestamped and aggregated message stream is generated by an aggregation module included in the SOC, which is configured to: receiving hardware event information in a standardized message format from a hardware functional module; receiving firmware event information in a standardized message format from a firmware function module; and The hardware event information in the standardized message format and the firmware event information in the standardized message format are aggregated and time-stamped to obtain a time-stamped and aggregated message stream.

4. The system of claim 3, wherein timestamping comprises writing the timestamp into a reserved field in a standardized message format reserved for timestamping.

5. The system of claim 3, wherein: The hardware functional modules include one or more of the following: a PCI bus (PCIe) functional module, a non-volatile memory (NVMe) functional module associated with communicating with a host driver to receive a host command, or an error correction decoder; and The hardware event information in the standardized message format includes one or more of the following: a low power event associated with a PCIe functional module, an error associated with a PCIe functional module, an end of a read associated with an NVMe functional module, an end of a write associated with an NVMe functional module, an end of a command fetch associated with an NVMe functional module, a write to a storage space used by a host driver to transmit host commands, or an end of error correction decoding associated with an error correction decoder.

6. The system of claim 1, wherein displaying a desired set of visual information comprises: identifying the start event-based message and the end event-based message based at least in part on identical values ​​of the unique operation identifier in the start event-based message and the end event-based message; calculating the waiting time by subtracting a start timestamp included in the message based on the start event from an end timestamp included in the message based on the end event; and Latency-related visual information is generated based at least in part on the latency, wherein the set of desired visual information includes the latency-related visual information.

7. The system of claim 1, wherein: The SoC includes a flash memory controller; and The interface is configured to receive a selection associated with a set of desired visual information, including by receiving one or more of: a first selection associated with display latency information, a second selection associated with display bus utilization information, or a third selection associated with a display die access sequence associated with multiple dies in a flash memory medium managed by a flash controller.

8. A method comprising: receiving, using an interface, a selection associated with a set of desired visual information, wherein the set of desired visual information is associated with a system on a chip (SOC) including a hardware functional module and a firmware functional module; Selecting, using a processor, a template from a plurality of available templates based at least in part on a selection associated with a desired set of visual information, wherein the selected template is used by the SOC to generate information for the report, including by: configuring the hardware functional modules as specified by the selected template to generate information for a selected hardware report; and configuring the firmware functional modules as specified by the selected template to generate information for the selected firmware report; Using the interface to receive reported information, including selected hardware reported information and selected firmware reported information; and A display is used to display a desired set of visual information, including information reported by using selected hardware and information reported by selected firmware.

9. The method of claim 8, wherein the hardware functional modules include one or more of: a PCI bus (PCIe) functional module, a non-volatile memory (NVMe) functional module associated with communicating with a host driver to receive host commands, or an error correction decoder.

10. The method according to claim 8, wherein: Reported information includes timestamped and aggregated message flows; and The timestamped and aggregated message stream is generated by an aggregation module included in the SOC, which is configured to: receiving hardware event information in a standardized message format from a hardware functional module; receiving firmware event information in a standardized message format from a firmware function module; and The hardware event information in the standardized message format and the firmware event information in the standardized message format are aggregated and time-stamped to obtain a time-stamped and aggregated message stream.

11. The method of claim 10, wherein timestamping comprises writing the timestamp into a reserved field in a standardized message format reserved for timestamping.

12. The method according to claim 10, wherein: The hardware functional modules include one or more of the following: a PCI bus (PCIe) functional module, a non-volatile memory (NVMe) functional module associated with communicating with a host driver to receive a host command, or an error correction decoder; and The hardware event information in the standardized message format includes one or more of the following: a low power event associated with a PCIe functional module, an error associated with a PCIe functional module, an end of a read associated with an NVMe functional module, an end of a write associated with an NVMe functional module, an end of a command fetch associated with an NVMe functional module, a write to a storage space used by a host driver to transmit host commands, or an end of error correction decoding associated with an error correction decoder.

13. The method of claim 8, wherein displaying a desired set of visual information comprises: identifying the start event-based message and the end event-based message based at least in part on identical values ​​of the unique operation identifier in the start event-based message and the end event-based message; calculating the waiting time by subtracting a start timestamp included in the message based on the start event from an end timestamp included in the message based on the end event; and Latency-related visual information is generated based at least in part on the latency, wherein the set of desired visual information includes the latency-related visual information.

14. The method of claim 8, wherein: The SoC includes a flash memory controller; and Receiving a selection associated with a set of desired visual information includes receiving one or more of: a first selection associated with display latency information, a second selection associated with display bus utilization information, or a third selection associated with a display die access sequence associated with multiple dies in a flash memory medium managed by a flash controller.

Images