Patent Application
20130179741
1. Field of the Invention
The invention relates generally to circuit design/testing, and more specifically relates to acquiring internal signals of a circuit by analyzing the circuit's design and programming test logic of the circuit to output desired internal signals based upon the analysis.
3. Discussion of Related Art
Electronic circuits perform a wide variety of tasks for electronic systems. For example, circuits may be used for data processing, data storage and retrieval, system analysis and control, and many other functions. Because electronic circuits may be subject to programming, design, or operational errors, it is desirable not only to include logic at the circuit that performs the circuit's desired task, but also to include logic at the circuit for debugging and testing purposes (e.g., for externally monitoring internal operational signals of the circuit). For example, the circuit may include test multiplexers (MUXs) along with registers that can be programmed to provide internal operational signals as outputs (e.g., specialized debug outputs) for the circuit. Utilizing MUXs to output test signals that are normally internal to the circuit ensures that the number and size of communication channels used for debug and testing purposes at the circuit is reduced, because MUXs allow a large number of internal signaling pathways to be condensed into a much smaller number of output signal paths.
Unfortunately, utilizing a hierarchy of test MUXs to provide internal debug signals results in a number of problems. For example, the registers of the test MUX hierarchy must be properly programmed in order to acquire a desired input signal and provide it to an output signal pathway for external monitoring. For circuits utilizing a large number of test MUXs, this process may be particularly complex as a user traces the desired signal's path across the test MUX hierarchy to an output for the circuit. As such, it is not uncommon for a test MUX hierarchy to be improperly programmed based upon user error. Furthermore, external documentation relied upon for programming registers for test MUXs of a given circuit may be out of date because the circuit design has been updated or altered since the documentation was prepared. If this is the case, the information describing how to program registers for the test MUXs may be inaccurate. This in turn further complicates the task of acquiring internal operational signals of the circuit.
Thus it is an ongoing challenge to map internal operational signals of an electronic circuit for output via test MUXs in a manner that is both convenient and effective.
The present invention solves the above and other problems, thereby advancing the state of the useful arts, by providing methods and systems for analyzing Register Transfer Level (RTL) representations of an electronic circuit in order to correlate register values used for programming test multiplexers (MUXs) with outputs corresponding to internal operational signals of a circuit. An RTL representation of a circuit is a digital representation of a circuit design, often utilized in Computer Aided Design (CAD) applications. Because RTL representations are an integral part of the design process for most circuits, they are typically reliably up-to-date (e.g., redesigning the circuit typically starts with redesigning the RTL representation of the circuit). Analysis of an RTL representation of a circuit allows a testing system to correlate test MUXs with internal operational signals (and to program registers of those test MUXs as well) without a danger of user error.
In one aspect hereof, a method operable as programmed instructions on a computer system is provided. The method comprises acquiring a Register Transfer Level (RTL) representation of an electronic circuit, the circuit implementing operational logic for performing tasks, the circuit further implementing test logic that may be externally programmed for providing one or more output signals corresponding to internal operational signals. The method further comprises analyzing the RTL representation to identify test multiplexers (MUXs) having registers for implementing the test logic, and correlating test register values for the test MUXs with outputs corresponding to the internal operational signals, based upon the RTL representation. Additionally, the method comprises selecting a desired internal operational signal for acquisition, and programming the test registers of the test MUXs of the circuit based on the correlated test register values to acquire the selected internal operational signal and to apply the acquired signal as one or more output signals.
Another aspect hereof provides a non-transitory computer readable medium embodying programmed instructions which, when executed by a processor, are operable for performing a method. The method comprises acquiring a Register Transfer Level (RTL) representation of an electronic circuit, the circuit implementing operational logic for performing tasks, the circuit further implementing test logic that may be externally programmed for providing one or more output signals corresponding to internal operational signals. The method further comprises analyzing the RTL representation to identify test multiplexers (MUXs) having registers for implementing the test logic, and correlating test register values for the test MUXs with outputs corresponding to the internal operational signals, based upon the RTL representation. Additionally, the method comprises selecting a desired internal operational signal for acquisition, and programming the test registers of the test MUXs of the circuit based on the correlated test register values to acquire the selected internal operational signal and to apply the acquired signal as one or more output signals.
Another aspect hereof provides a circuit testing system. The circuit testing system comprises a control unit adapted to acquire a Register Transfer Level (RTL) representation of an electronic circuit, the circuit implementing operational logic for performing tasks, the circuit further implementing test logic that is externally programmable for providing one or more output signals corresponding to internal operational signals. The control unit is further adapted to analyze the RTL representation to identify test multiplexers (MUXs) having registers for implementing the test logic, and adapted to correlate test register values for the test MUXs with outputs corresponding to the internal operational signals, based upon the RTL representation. The circuit testing system also comprises a user interface adapted to enable a user to select a desired internal operational signal for acquisition. Additionally, the circuit testing system comprises a circuit interface adapted to program the test registers of the test MUXs of the circuit based on the correlated test register values to acquire the selected internal operational signal and to apply the acquired signal as one or more output signals.
According to
Typically, test MUXs 134 will exist within a hierarchy of MUXs and registers. This hierarchy may be configured to select a variety of internal signals for application to test output(s) 144. The internal design and features of each test MUX 134 will naturally vary as a matter of design choice. For example, the internal selecting logic (i.e., the input and output paths of the MUX), the hardware registers, and the size and number of inputs and outputs all may vary across different designs of test MUXs 134. Test MUXs 134 may be coupled with each other via one or more buses, as indicated on
Test MUXs 134 may be programmed via test registers 138 in order to provide the appropriate output signals (e.g., to other test MUXs 134 or to output(s) 144). According to
Register Transfer Level (RTL) circuit model 110 comprises a representation of the digital design of electronic circuit 130. For example, RTL circuit model 110 may be the basis for the design from which circuit 130 was fabricated. In some embodiments, the RTL may be structured in accordance with Verilog Hardware Description Language (Verilog HDL). In RTL, a circuit's behavior is defined by the flow of signals as they travel between hardware registers. RTL circuit model 110 may further define the logical operations that can be performed upon signals for the circuit by programming the registers. For example, RTL circuit model 110 may include RTL expressions and statements describing and labeling the various inputs and outputs of test MUXs 134. The RTL may define a number of further features of circuit 130. For example, RTL circuit model 110 may describe the size of each bus used by test MUXs 134, and may further indicate how signals are padded or truncated as they are transferred between buses of varying size. RTL circuit model 110 may be stored in a memory accessible by testing system 120. RTL circuit model 110 reliably represents the components of circuit 130, because unlike manually generated documentation which may fail to get updated, RTL circuit model 110 is an integral part of the design process of most circuits.
Test system 120 may be used to analyze RTL circuit model 110 in order to determine how to program registers for test MUXs 134 of circuit 130. In this embodiment, test system 120 comprises control unit 122, user interface 124, and circuit interface 126. Control unit 122 may comprise, for example, a general purpose (hardware) processor and associated memory for executing programmed instructions and managing the operations of test system 120. User interface 124 may comprise, for example, instructions for generating a display provided on a display device such as a monitor or screen. The display allows a user to interact with test system 120 and receive feedback from test system 120. Circuit interface 126 comprises any components, systems, or devices capable of identifying and programming test registers 138 for test MUXs 134 of circuit 130 via communication channel 142.
Communication channel 142 and output(s) 144 may comprise any suitable signaling pathways or buses. Communication channel 142 will typically utilize serialized communications to some degree in order to reduce its physical size and complexity. In contrast, output(s) 144 will typically output test signals on a parallel bus structure so that measured signals can be accurately provided essentially in real time.
Signal analysis unit 150 includes components for receiving test output signaling via output(s) 144. As test output signaling is received by signal analysis unit 150, the signaling may be applied to a logic analyzer or other electronic acquisition/analysis components. Such equipment utilizes the test output signals to aid an engineer in testing or debugging the design of circuit 130 during its operation. Signal analysis unit 150 may comprise an independent device or an integrated component of test system 120.
While in operation, test system 120 is capable of analyzing RTL circuit model 110 to correlate register values for test MUXs 134 of circuit 130 with internal operational signals of circuit 130. This analysis may be performed in the following manner: control unit 122 may parse the RTL to identify test MUXs 134 defined within the RTL (the MUXs and associated signal paths being identified by, for example, a naming convention or format adhered to in the design of circuit 130), as well as to identify test registers 138 defined for the test MUXs 134. For example, control lines (used to carry test register values to test MUXs 134) may include an RTL prefix with the keyword “TMuxSel,” and these control lines may further include a suffix that uniquely identifies the MUX that they are used to program. The test MUX may label inputs as “TMuxInUniqueName,” and outputs as “TMuxOutUniqueName” to indicate connectivity within the test logic hierarchy for circuit 130. Each input may relate to one or more named signals.
This information may then be stored in a database, such as an XML database, for later use and potential editing. The database may be used to trace the path of an individual internal operational signals across a hierarchy of test MUXs 134. Further, the database may be used to determine how to program test registers 138 of the hierarchy in order to direct the internal operational signal through test MUXs 134 towards output(s) 144 received by test system 120.
Once combinations of register values for test MUXs 134 have been determined to yield specific internal operational signals as signals along output(s) 144, a user may select one or more internal signals via user interface 124. A selected signal may, for example, be an input of a given test MUX 134 (e.g., the user may indicate their wish to view a signal as applied to a test MUX 134). With the appropriate internal signals selected for acquisition, control unit 122 may direct circuit interface 126 to program the test registers 138 for test MUXs 134 to acquire and provide the selected signals as signals along output(s) 144.
Step 202 includes acquiring an RTL representation of a circuit. The circuit includes operational logic for performing tasks, and further includes test logic that may be externally programmed for providing one or more output signals of the circuit corresponding to internal operational signals. The internal operational signals may be acquired, for example, for purposes of testing and analyzing the operation of the circuit. An RTL representation of the circuit may be acquired by querying a user via a user interface for information that includes the RTL representation. In one embodiment, output signals from the circuit indicate a name and version number from the circuit. With this information, a corresponding. RTL representation of the circuit may be found.
Step 204 includes analyzing the RTL representation to identify test multiplexers (MUXs) and associated registers for implementing the test logic. In the RTL representation, test MUXs may be distinguished from other circuit components based upon a tag, naming convention, or other identifier included in the RTL. For example, a tag may explicitly label each test MUX as such. In a further example, test MUXs may be identified in the RTL because they use a unique data structure (i.e., a particular standard cell that is used for test MUX functions). In a still further example, test MUXs may be distinguished from other MUXs because their input/output signals are indicated in the RTL as test/debug signals. Test MUXs may also be distinguished from other MUXs of the circuit by determining that the test MUXs are coupled with a communication channel used for testing/debugging purposes (the communication channel comprising a number of signals concatenated together using standard RTL syntax).
Step 206 includes correlating test register values for the test MUXs with outputs corresponding to the internal operational signals, based upon the RTL representation. For example, the method may review the RTL for test MUXs in order to track how their outputs align with inputs of other test MUXs. In such an example, an RTL parser may be used to follow connections from test MUX inputs to test MUX outputs. The RTL wires for the inputs/outputs eventually route to one or more exit wires of the design, and the hierarchy of test logic can be created based off those connections.
Thus, a hierarchy of test MUXs can be determined This hierarchy may be used to determine how the test MUXs of the circuit may be programmed to provide internal operational signals as output signals (i.e., an internal operational signal may be traced through the test MUX hierarchy to an output signal). As a combination of test register values is determined for providing internal operational signals as output signals, a record, database, or other mapping structure may be generated. The mapping structure may describe the test logic hierarchy, and may further specifically describe the appropriate register combinations to be used to acquire a given signal. For example, a mapping structure may be a database (e.g., an XML database) that indicates a name and associated value for each register used to provide a given operational signal at an output of the circuit. In further embodiments, step 206 may be included as a part of steps 204 and/or 208.
Step 208 includes selecting desired internal operational signal(s) for acquisition. The selection may be received from a user via a user interface, or may be acquired automatically based upon a predetermined testing scheme. According to step 208, one or more signals may be selected at the same time for output via circuit 130. If no mapping structure explicitly links a set of register combinations to acquiring a selected signal as an output, step 208 may include determining a path of test MUXs for the selected signals. For example, the path may be determined by reviewing a mapping structure describing the hierarchy of test logic. Beginning with the selected internal operational signals (represented as leaf nodes of the hierarchy of test logic) the method interrogates each level of the hierarchy to find matching information for test MUXs relating to selected signals. Test registers for the test MUX may be determined, and these test registers may be analyzed to determine which values will forward the selected signals onward towards an output.
Step 210 includes programming the test registers of the test MUXs of the circuit based on the correlated test register values to acquire the selected internal operational signal(s) from the test MUX hierarchy and to apply the acquired signal(s) as one or more output signals. A circuit interface or other element may be used to program the test registers.
Thus, using method 200 of
Step 302 includes determining the selected signals. For example, a user may provide a request for selection via a user interface. From this request, the identity of each selected signal may be acquired.
Step 304 includes determining whether two or more selected signals will utilize mutually exclusive configurations of the test registers of the test MUXs of the circuit to generate output signals. In short, if signals are selected which use conflicting register settings, the signals cannot be provided together. This determination may be made, for example, by comparing a set of test register values for test MUXs for one signal with a similar set for another signal. If each of the sets requires a different setting for the same register at some point along the hierarchy, the signals may be considered conflicting (i.e., the test logic of the circuit is not capable of providing both of these signals at the same time as test outputs). If there is a conflict, the method proceeds onward to step 306. Alternatively, if no conflict is detected, then processing continues onward to step 310, wherein the method continues onward to further steps of method 200 of
Step 306 includes reporting the issue to a user. For example, an error message may be generated and provided to the user, or a list of conflicting selected signals may be provided to the user. This list of conflicting signals may be sorted into groups of signals that share the same conflicting register. Thus, each set of conflicts may be reported to the user for resolution. Step 308 includes awaiting a revised signal selection. Once a revised signal selection is made, the method returns to step 302, where the method determines the selected signals.
In further embodiments (and depending upon the complexity of the test logic in a given circuit), combinations of register selections may be used to forwarding multiple selected signals along the same bus at the same time. For example, components of the test logic may allow a register selection for forwarding both signal A and signal B along the same bus to another test logic component (so long as the register selections do not conflict and the bus is capable of supporting both signals).
The padding information may be determined by a testing system analyzing the RTL representation of circuit 600. For example, the RTL representation of the circuit may indicate the bus width for each input and output of the test MUX hierarchy, and signal padding and truncation information may be inferred from these changing bus widths. In another example, truncation may be determined based upon byte lane steering logic indicated in the RTL that masks off part of an input for a test MUX and applies another input for that byte lane. Padding may similarly be determined based upon logic described in the RTL information. Depending upon which signals have been selected for acquisition, non-selected signals may be considered padding by the testing system.
According to data structure 704, no padding is added to signals A and B before they are sent as output from test MUX 604. According to data structure 706, leading zeroes are added to signal C in order to transfer signal C from a two bit wide bus to a four bit wide bus at test MUX 606 (e.g., a representative signal C might be transformed from “11” to “0011”). Signal D however, because it is moved from a four bit bus to another four bit bus, does not need padding.
Note that inputs F and G (outputs of test MUXs 604 and 606) received along test MUX 608 may be padded from eight and four bit wide buses to a twelve bit wide output bus. Thus, these incoming signaling may need to be altered to conform with the wider bus structure. Therefore, inputs F (corresponding to signals A and B) and G (corresponding to signals C and D) are padded to make them compatible with the wider bus. F has leading zeroes added, and G has trailing zeroes added. Thus, if an original signal C was “11,” and was transformed by test MUX 606 to “0011,” it would be further transformed by test MUX 608 to become “001100000000.” Understanding how signals are padded by the various test MUXs may be important when it comes to interpreting a received signal provided as output. Without an understanding of how and where padding was added in the test logic, it would be hard, if not impossible to determine from the output signal “001100000000” whether the original signal C was “00,” “01,” “10,” or “11.”
In some embodiments, the padding may comprise leading or trailing zeroes (i.e., extra signals coupled to a logic “0”), leading or trailing ones (i.e., extra signals coupled to a logic “1”), leading or trailing random information (i.e., extra signals coupled to a floating logic value), or any sort of non-informational content combined with the received signals. Similar operations may be performed for truncation if a signal is moved from a larger bus size to a smaller bus size. Depending on whether information (and/or padding) is truncated at the leading end or the trailing end, it could change the perceived value of an internal operational signal.
While the invention has been illustrated and described in the drawings and foregoing description, such illustration and description is to be considered as exemplary and not restrictive in character. One embodiment of the invention and minor variants thereof have been shown and described. In particular, features shown and described as exemplary software or firmware embodiments may be equivalently implemented as customized logic circuits and vice versa. Protection is desired for all changes and modifications that come within the spirit of the invention. Those skilled in the art will appreciate variations of the above-described embodiments that fall within the scope of the invention. As a result, the invention is not limited to the specific examples and illustrations discussed above, but only by the following claims and their equivalents.
