Patent Grant
11809363
The present application generally relates to an electronic design automation (EDA) system. In particular, the present application is related to a system and method for debug methodology for a universal serial bus (USB) subsystem using a unique identifier (UID) approach.
With the introduction of the USB4 specification, the USB ecosystem becomes increasingly bigger and more complex. The protocol level abstraction of USB has now risen from being a communication protocol, with its own data format exchanged over a USB specific connector, to a communication protocol that combines communication protocols like USB3, display port (DP), peripheral component interconnect express (PCIe) through a common type-C connector. USB4 protocol also defines a communication protocol for direct host-to-host data communication.
USB4 protocol defines a packet structure and physical layer over the type-C connector. For the purpose of compatibility and to bring all the connected protocols under USB4 protocol, new protocol adapters are defined, which convert the specific protocol data to the USB4 protocol packet.
USB4 protocol adds a new protocol transport layer to arbitrate through the connected protocols and send packets over a link. The transport layer adds its buffers, priority, and weights to arbitrate over a plurality of sources to a single sink or distribute a single source to a plurality of sinks.
Hence, this complex subsystem brings forth its own set of verification challenges since a single error in any of the layers may show up as an unrelated error at the connected device. USB4 subsystem verification requires many teams, each working on a different USB4 protocol layer, and verification for a specific protocol layer needs enough granular details to identify a root cause for a layer-specific problem. Accordingly, localizing and identifying a root cause of a problem in a USB4 subsystem poses a substantial challenge.
USB4 subsystem performance verification is also a very important component for validation and debugging of USB designs. A delayed packet at the connected device may result in protocol level failures. Localizing and identifying a root cause of the origin of the delay in a long USB4 path is a challenge. In addition, multiple transactions can result in configuration changes in the USB4 subsystem, which may result in some protocol error. Identifying a root cause for a transaction error from erroneous memory access is a challenge.
In one embodiment, a method is disclosed. The method includes The method includes converting a first message in a first protocol format received at a first functional logical block of a plurality of functional logical blocks of an electronic subsystem into a second message in a second protocol format at the first functional logical block. The second message includes a unique identifier (UID), and generating a first trace file at the first functional logical block. The first trace file includes the UID. The method includes forwarding the second message from the first functional logical block to the second functional logical block, and generating a second trace file at the second functional logical block, wherein the second trace file includes the UID. The method includes debugging the first functional logical block and the second functional logical block based on the first trace file and the second trace file using the UID.
In another embodiment, a system is disclosed. The system includes a memory a memory configured to store operations, and one or more processors configured to perform the operations. The operations include converting a first message in a first protocol format received at a first functional logical block of a plurality of functional logical blocks of an electronic subsystem of the system into a second message in a second protocol format at the first functional logical block. The second message includes a unique identifier (UID. The operations include generating a first trace file at the first functional logical block. The first trace file includes the UID. The operations include forwarding the second message from the first functional logical block to the second functional logical block, and generating a second trace file at the second functional logical block. The second trace file includes the UID. The operations includes debugging the first functional logical block and the second functional logical block based on the first trace file and the second trace file using the UID.
In yet another embodiment, a non-transitory, tangible computer-readable device having instructions stored thereon is disclosed. The instructions when executed by at least one computing device, causes the at least one computing device to perform operations including converting a first message in a first protocol format received at a first functional logical block of a plurality of functional logical blocks of an electronic subsystem of the at least one computing device into a second message in a second protocol format at the first functional logical block. The second message includes a unique identifier (UID. The operations include generating a first trace file at the first functional logical block. The first trace file includes the UID. The operations include forwarding the second message from the first functional logical block to the second functional logical block, and generating a second trace file at the second functional logical block. The second trace file includes the UID. The operations includes debugging the first functional logical block and the second functional logical block based on the first trace file and the second trace file using the UID.
The following Detailed Description, Figures, appended Additional Figures and appended Claims signify the nature and advantages of the innovations, embodiments and/or examples of the present disclosure. All of the Figures signify innovations, embodiments, and/or examples of the present disclosure for purposes of illustration only and do not limit the scope of the present disclosure. Such figures are not necessarily drawn to scale and are part of the disclosure.
In the Figures, similar components or features may have the same, or similar, reference signs in the form of labels (such as alphanumeric symbols, e.g., reference numerals), and may signify similar or equivalent functionality. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label. A brief description of the Figures is below.
In such various figures, reference signs may be omitted as is consistent with accepted engineering practice; however, one of ordinary skill in the art will understand that the illustrated components are readily understood when viewed in the context of the illustration as a whole and the accompanying disclosure describing such various figures.
Under ‘shift-left’ software testing ideology, software testing and system testing is performed earlier in the software or system development lifecycle. In the case of systems that incorporate USB4 components, the complexity of the USB4 subsystem adds to the debug challenge. It is an objective of this disclosure to provide a powerful debug methodology to shift-left the verification lifecycle for USB4 subsystem verification using transaction traces that use a unique identifier (UID) for a USB4 packet processing across various functional blocks of the USB4 subsystem. With the approaches detailed herein, aspects allow for analyzing a transaction across various logical function blocks.
In some embodiments, a set of transaction trace files may track the lifetime of a USB4 packet in a USB4 subsystem, irrespective of the source of the packet, for example, USB3, USB4, PCIe, and DP.
In a USB4 verification subsystem, each logical function block of a plurality of functional logical blocks may have a unique functionality. The USB4 packets, received from an external peripheral and/or generated as a conversion from other type of packets such as USB3, PCIe, and/or DP, etc., may be transmitted through the subsystem. The individual trace files for each functional logical block may be generated by the verification subsystem, which records unique aspects of the USB4 packet transactions that may be performed with respect to that block. In some embodiments, a transaction corresponds to a processing operation that may be performed on a USB4 packet at functional logical block of a USB4 subsystem. A unique identifier (UID) associated with each transaction may help in analyzing the same transaction across the traces corresponding to various functional logical blocks. In some embodiments, a tracefile corresponding to each functional block of a USB4 subsystem is generated. In some embodiments, a trace file may include a record of a packet's protocol stack information and timing information. The USB4 packet using this UID may be tracked across all the trace file corresponding to various functional logical blocks of a USB4 subsystem. In some embodiments, the USB4 packet may be traced across multiple trace files by identifying the UID corresponding to the USB4 packet.
Advantages of the present disclosure include, but are not limited providing an powerful debug methodology to shift-left the verification lifecycle for USB4 subsystem verification. Another specific advantage includes providing an ability to fully debug a logical block using a detailed trace corresponding to the logical block. Another advantage of the present disclosure includes providing an ability to track a USB4 packet across multiple logical blocks, using a UID, to identify where a packet may have defaulted or encountered an error in the subsystem.
The transaction traces may help users to fully debug a specific functional logical block. With the UID reference, delay in a USB4 packet adversely affecting the performance of the USB subsystem may be identified using the transaction traces. In addition, a particular functional logical block where the USB4 packet resulted in default and/or an error can also be identified. Erroneous access to USB4 memory can be quickly localized to the faulty USB4 packet and its memory corruption.
In some embodiments, the USB4 subsystem may include functional logical blocks, such as a protocol adapter, a router, a control adapter, a register configuration space, and/or a lane adapter, etc. By way of a non-limiting example, the protocol adapter may receive packets from or transmit packets to the connected protocol stacks or USB3/PCIe/DP or a host. The router may route data between a connected protocol adapter and the lane adapter. By way of a non-limiting example, the router may have separate paths for ingress and egress packets. For example, an ingress path may receive packets incoming to the router and store it in an ingress buffer, and an egress path may schedule packets outgoing from the router from an egress buffer. The control adapter may receive and transmit control packets. By way of a non-limiting example, the control adapter may also manage the register configuration space, in which multiple configuration registers are stored. The lane adapter may encode USB4 packets for transmitting and/or decode USB4 packets upon receiving on a plurality of packet lines.
In the following section, data flow inside a USB4 subsystem, according to some embodiments, is outlined.
In some embodiments, a USB4 subsystem may include multiple elements, such as a source and a sink of protocol data from a plurality of protocol stacks, or a protocol stack-specific adapter, etc. By way of a non-limiting example, the protocol stack may be of USB3.x, PCIe, or DP. In some embodiments, the protocol data my include data resulting directly from a Host. The protocol stack-specific adapter may convert protocol data to USB4 data format and vice versa. The lane adapter may be connected to a physical interface, for example, of Type-C. The router may arbitrate packets from protocol adapters to a lane adapter and distribute packets received on the lane adapter to the plurality of protocol adapters. The USB4 subsystem may include a TMU (Time Management Unit). The TMU may schedule and receive TMU packets from the lane adapter and the router. The USB4 susbsystem may include a LMP (Link Management Packets) generator. The LMP generator may schedule router-generated LMP packets used for link management.
In some embodiments, the USB4 subsystem may include various types of data flow, such as USB4 egress from protocol adapter, USB4 ingress to protocol adapter, and USB4 control adapter exchange. Each data flow is described in detail below.
The USB4 subsystem may support individual trace files for all the logical blocks mentioned above. A logical abstraction of the USB4 subsystem and the trace file boundaries may be as shown in
In some embodiments, each USB4 packet within the USB4 subsystem may be assigned a unique identification number (UID), which may be a number imported from universal verification methodology (UVM) supported API of ‘get_inst_id.’ In some embodiments, a UVM standard function ‘get-inst-id’ may be called to return a numerical instance identifier which may be assigned to each USB4 packet as a unique identification number. The USB4 packet using this UID may be tracked across all the available trace files. In some embodiments, a search may be performed on the contents of a trace file to identify the UID corresponding to the USB4 packet. In some embodiments, the USB4 packet may be traced across multiple trace files by identifying the UID corresponding to the USB4 packet. Accordingly, the lifetime and operations on the USB4 packet in the USB4 subsystem may be analyzed.
USB4 Trace File Verbosity Control
In some embodiments, depending on the severity of the problem, the amount of information detail in a trace file corresponding to packet transformations in the USB4 subsystem may be altered based on the severity of a problem. In some embodiments, trace file writing may be controlled via a verbosity level switches. In some embodiments, a verbosity level switch enables selecting a verbosity level which may limit the extent of information that is included in a trace file. In some embodiments, altering verbosity level may improve runtime performance.
In some embodiments, the traces may support 3 levels of verbosity:
USB4 Trace File Example Use-cases:
In the following section, two use-cases of using USB4 traces in debug of USB4 subsystem data flow are discussed.
Tracking a packet originating from the protocol adapter to the USB4 physical lines:
A USB3 packet from a source 1402, such as USB3, DP, PCIe, and Host, converted to a USB4 packet.
Tracking a configuration write cycle in device router:
At 1904, the packet may arrive at the lane adapter's ingress path. In the lane adapter ingress trace 2100, as shown in
At 1906, the same packet may be tracked using the UID value in the control adapter trace file 2200, as shown in
At 1908, the memory trace records the changes in memory due to the current transaction, which is tracked with UID, as shown in memory trace records 2300, as shown in
At 1910, the control adapter, while processing the write request may generate a write response packet. As shown in
At 1912, using the UID recorded in the control port, the packet may be tracked in the egress trace 2500, as shown in
At 1914, the packet may be traced in the lane adapter Tx trace based on the UID value, as shown in a lane adapter Tx trace 2600 of
At 2702, a first message is received at a first functional logical block, in some embodiments. In some embodiments, the first functional logical block may be a protocol adapter of a USB4 subsystem. The received first message may be in a first protocol format. According to some embodiments, the first received message may be a packet corresponding to a first protocol format. According to some embodiments, a first protocol format may correspond to USB3, PCIe, or DP.
At 2703, the first message is converted into a second message in a second protocol format at the first functional block. In some embodiments, the second message may be a USB4 packet. In some embodiments, the second protocol format may be a USB format. In some embodiments, the second message includes a unique identifier (UID). In some embodiments, a UVM standard function ‘get-inst-id’ may be called to return a numerical instance identifier which may be assigned to each USB4 packet as a unique identification number.
At 2706, a first trace file corresponding to the first functional logical block is generated. In some embodiments, the first functional logical block is a protocol adapter or a lane adapter of a USB4 subsystem. In some embodiments, the first trace file includes the UID corresponding to the second message. At, 2708, the second message is forwarded from the first functional logical block to a second functional logical block. In some embodiments, the second functional logical block may be one of a router ingress component, a control adapter, a register configuration space, or a link adapter component of a USB4 subsystem.
At 2710, a second trace file corresponding to the second functional logical block is generated. In some embodiment, the second trace file includes the UID corresponding to the second message. At 2712, an analysis is performed on the first functional logical block and the second functional logical. According to some embodiments, a debugging analysis may be performed on the first functional logical block and the second functional logical. In some embodiments, an analysis is performed on the first functional logical block and the second functional logical using the first trace file and the second trace file. In some embodiments, the UID corresponding to the USB4 packet is identified in the first trace file and the second trace file to perform debugging analysis.
Specifications for a circuit or electronic structure may range from low-level transistor material layouts to high-level description languages. A high-level of abstraction may be used to design circuits and systems, using a hardware description language (‘HDL’) such as VHDL, Verilog, SystemVerilog, SystemC, MyHDL or OpenVera. The HDL description can be transformed to a logic-level register transfer level (‘RTL’) description, a gate-level description, a layout-level description, or a mask-level description. Each lower abstraction level that is a less abstract description adds more useful detail into the design description, for example, more details for the modules that include the description. The lower levels of abstraction that are less abstract descriptions can be generated by a computer, derived from a design library, or created by another design automation process. An example of a specification language at a lower level of abstraction language for specifying more detailed descriptions is SPICE, which is used for detailed descriptions of circuits with many analog components. Descriptions at each level of abstraction are enabled for use by the corresponding tools of that layer (e.g., a formal verification tool). A design process may use a sequence depicted in
During system design 2814, the functionality of an integrated circuit to be manufactured is specified. The design may be optimized for desired characteristics such as power consumption, performance, area (physical and/or lines of code), and reduction of costs, etc. Partitioning of the design into different types of modules or components can occur at this stage.
During the logic design and functional verification 2816, modules or components in the circuit are specified in one or more description languages, and the specification is checked for functional accuracy. For example, the components of the circuit may be verified to generate outputs that match the requirements of the specification of the circuit or system being designed. Functional verification may use simulators and other programs such as test bench generators, static HDL checkers, and formal verifiers. In some embodiments, special systems of components referred to as ‘emulators’ or ‘prototyping systems’ are used to speed up the functional verification.
During synthesis and design for test 2818, HDL code is transformed into a netlist. In some embodiments, a netlist may be a graph structure where edges of the graph structure represent components of a circuit and where the nodes of the graph structure represent how the components are interconnected. Both the HDL code and the netlist are hierarchical articles of manufacture that can be used by an EDA product to verify that the integrated circuit, when manufactured, performs according to the specified design. The netlist can be optimized for a target semiconductor manufacturing technology. Additionally, the finished integrated circuit may be tested to verify that the integrated circuit satisfies the requirements of the specification.
During netlist verification 2820, the netlist is checked for compliance with timing constraints and for correspondence with the HDL code. During design planning 2822, an overall floor plan for the integrated circuit is constructed and analyzed for timing and top-level routing.
During layout or physical implementation 2824, physical placement (positioning of circuit components such as transistors or capacitors) and routing (connection of the circuit components by multiple conductors) occurs, and the selection of cells from a library to enable specific logic functions can be performed. As used herein, the term ‘cell’ may specify a set of transistors, other components, and interconnections that provides a Boolean logic function (e.g., AND, OR, NOT, XOR) or a storage function (such as a flipflop or latch). As used herein, a circuit ‘block’ may refer to two or more cells. Both a cell and a circuit block can be referred to as a module or component and are enabled as both physical structures and in simulations. Parameters are specified for selected cells (based on ‘standard cells’) such as size and made accessible in a database for use by EDA products.
During analysis and extraction 2826, the circuit function is verified at the layout level, which permits refinement of the layout design. During physical verification 2828, the layout design is checked to ensure that manufacturing constraints are correct, such as DRC constraints, electrical constraints, lithographic constraints, and that circuitry function matches the HDL design specification. During resolution enhancement 2830, the geometry of the layout is transformed to improve how the circuit design is manufactured.
During tape-out, data is created to be used (after lithographic enhancements are applied if appropriate) for the production of lithography masks. During mask data preparation 2832, the ‘tape-out’ data is used to produce lithography masks that are used to produce finished integrated circuits.
A storage subsystem of a computer system (such as computer system 2800 of
The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
The example computer system 2900 includes a processing device 2902, a main memory 2904 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), a static memory 2906 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 2918, which communicate with each other via a bus 2930.
The processing device 2902 represents one or more processors such as a microprocessor, a central processing unit, or the like. More particularly, the processing device may be complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets, or processors implementing a combination of instruction sets. The processing device 2902 may also be one or more special-purpose processing devices such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device 2902 may be configured to execute instructions 2926 for performing the operations and steps described herein.
The computer system 2900 may further include a network interface device 2908 to communicate over the network 2920. The computer system 2900 also may include a video display unit 2910 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 2912 (e.g., a keyboard), a cursor control device 2914 (e.g., a mouse), a graphics processing unit 2922, a signal generation device 2916 (e.g., a speaker), graphics processing unit 2922, video processing unit 2929, and audio processing unit 2932.
The data storage device 2918 may include a machine-readable storage medium 2924 (also known as a non-transitory computer-readable medium) on which is stored one or more sets of instructions 2926 or software embodying any one or more of the methodologies or functions described herein. The instructions 2926 may also reside, completely or at least partially, within the main memory 2904 and/or within the processing device 2902 during execution thereof by the computer system 2900, the main memory 2904, and the processing device 2902 also constituting machine-readable storage media.
In some implementations, the instructions 2926 include instructions to implement functionality corresponding to the present disclosure. While the machine-readable storage medium 2924 is shown in an example implementation to be a single medium, the term “machine-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable storage medium” shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine and the processing device 2902 to perform any one or more of the methodologies of the present disclosure. The term “machine-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.
Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the data processing arts to convey the substance of their work to others skilled in the art most effectively. An algorithm may be a sequence of operations leading to the desired result. The operations are those requiring physical manipulations of physical quantities. Such quantities may take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. Such signals may be referred to as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the present disclosure, it is appreciated that throughout the description, certain terms refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage devices.
The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the intended purposes, or it may include a computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various other systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the method. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the disclosure, as described herein.
The present disclosure may be provided as a computer program product, or software, that may include a machine-readable medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium such as read-only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices, etc.
In the foregoing disclosure, implementations of the disclosure have been described with reference to specific example implementations thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of implementations of the disclosure as set forth in the following claims. Where the disclosure refers to some elements in the singular tense, more than one element can be depicted in the figures, and like elements are labeled with like numerals. The disclosure and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
The present application claims priority under 35 U.S.C. § 119(e) to U.S. Provisional Patent Application No. 63/072,397, titled “Debug methodology for a USB sub-system using unique identifier (UID) approach” and filed on Aug. 31, 2020, which is hereby incorporated by reference in its entirety for all purposes.
| Number | Name | Date | Kind |
|---|---|---|---|
| 8024171 | Korolev | Sep 2011 | B1 |
| 20060123129 | Toebes | Jun 2006 | A1 |
| 20090106741 | Dageville | Apr 2009 | A1 |
| 20150046617 | Shirlen | Feb 2015 | A1 |
| 20180189222 | Srivastava | Jul 2018 | A1 |
| 20190332558 | Goel | Oct 2019 | A1 |
| 20190335351 | Hui | Oct 2019 | A1 |
| 20200192832 | Regupathy | Jun 2020 | A1 |
| 20210055777 | Regupathy | Feb 2021 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 63072497 | Aug 2020 | US |
