Patent Application
20170082687
The field of invention pertains generally to the electronic arts, and, more specifically, to a de-bugging environment with a smart card.
Electronic system de-bugging has traditionally been a cumbersome, manual process in which engineers mount test probes on hardware under development and compare the actual, measured electronic signals against their designed for data levels, waveforms, timings, etc. In the case where numerous signals need to be measured in approximately the same time frame the measurement process can be especially cumbersome because a large number of probes need to be in place and their corresponding signals need to be concurrently tracked by expensive test equipment.
A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:
The power-on-reset activity of a system-on-chip is one potential difficult debugging environment. As observed in
In many cases the legacy designs were originally designed with their own unique set of bring-up/reset signals 102_1 through 102_N that have been preserved in the larger system-on-chip 100. As such, the system-on-chip 100 includes a large number of different sets of reset signals 102_1 through 102_N which may include relative to one another, e.g., different types of reset signals, different reset timing conditions and/or different reset signal voltage levels. In order for the system-on-chip 100 to power-on and/or come out of reset properly, ideally, all of the reset signal sets 102_1 through 102_N are within their specific specifications. During de-bug testing of the actual system on chip 100, verifying that all the reset signals are correct can be an extremely burdensome process.
As observed in
As an example, the application software program 204 may be designed to monitor/test multiple ones of the system-on-chip's various reset signal lines (e.g., all of them). In various embodiments, the application software program 204 is also designed to generate critical input stimuli to the PC board 201, such as an on/off signal and/or one or more system reset signals.
A “smart card” 205 removably plugs-into a connector 206 that is mounted to the PC board 201. The smart card 205, in various embodiments is a small form factor electronic system (e.g., composed of one or more semiconductor chips disposed on its own respective PC board). The smart card 205 has a network interface that allows the card to communicate over a network with the cloud service 204. The smart card 205 also has a point-to-point link interface (e.g., Universal Serial Bus, Bluetooth) that permits the smart card to communicate 2 with a user interface device 207 (e.g., a smartphone, tablet computer, laptop computer, desktop computer, etc.).
The user interface device 207 presents a graphical user interface that a user interfaces with in order to control the smart card 205 and its software. In an embodiment, through the user interface device 207 interface, a user causes 3 the application software 204 that has been written for the PC board and/or system-on-chip 202 to be downloaded 4 from the cloud service 203 and loaded onto the smart card 205.
The user, through 5 the user interface device 207, causes the smart card 205 to begin execution of the application software and its custom testing of the hardware being de-bugged. Via the aforementioned input stimuli signals provided by the smart card 205, in various embodiments, the smart card 205 can turn the PC board 201 on/off and/or reset the PC board 201 through the connector 206. Additionally, various critical signals of the PC board 201, such as multiple ones of the sets of reset signals that are applied to the system-on-chip 202 are also routed to the connector 206 so the signals on these same signal lines can be received and monitored by the smart card 205.
As the PC board 201 begins operation (e.g., during a system power-on-reset sequence), the various signal lines of the PC board 201 that have been tapped to also run as input signals to the connector 206 are received by the smart card 205 and are monitored/tested by the smart card 205 according to the routines executed by the application software program 204.
In an embodiment, the application software 204 includes test vectors that describe each of the signals as they should exist over time. The actually received signals are time-stamped and compared against test vectors with corresponding timestamp and any signals that do not match the test vector data are flagged as a problem and reported to the user interface device 207 which informs the user through its display. As such, the design engineers are immediately informed of a specific problem and its details without having to set-up test probes or manually setup testing equipment to individually track each of the signals being monitored.
In further embodiments, the waveform generation logic circuitry 305 may be further capable of receiving different power supply voltages so that the generated digital input stimuli also have programmably adjustable voltage levels. Here, in an embodiment, the smart card 301 also includes multiple programmable voltage supplies 306 to provide the waveform generation logic circuitry 305 with any of one or more different supply voltages so that input stimuli provided to the hardware under test can be provided with different logic voltage levels. For instance, as just one example, a digital signal can be provided with any of the following logic high voltage levels: 3.3v, 1.8v or 1.05v.
In a further embodiment, the smart card 301 includes FIFO circuitry 307 for fast capturing of digital signals. Here, for instance, the set of logic signals 308 being directed from the hardware being debugged to the smart card 301 can be viewed as different states of the hardware. If all of the logic signals are generated from a single clock source, each clock cycle may correspond to a new state that the FIFO circuitry 307 captures. Note that the clock signal itself may be directed to and received by the smart card and FIFO circuitry 307 so that the FIFO circuitry 307 can capture the new state information with each clock cycle.
In an embodiment, the FIFO circuitry 307 includes an associated state machine circuit that controls input sample capture to the FIFO circuitry 307 which, in turn, gives the smart card 301 some testing flexibility. For example, the state machine may be programmed with a trigger value (e.g., a specific number of clock cycles after a power on signal, a reset signal, an observed system state, etc.) and/or digital sample collection approach (collect samples on detected data change of any of the samples, collect samples on each input clock edge, etc.).
The aforementioned FIFO circuitry may be instantiated multiple times. That is, e.g., different FIFO circuits may be able to receive different sets of signals generated from different clocks where each FIFO circuit receives a particular set of signals generated from a particular clock. In this manner, state information that is generated according to different timing parameters may be fully captured by the smart card in a synchronous fashion. The FIFO circuitry 307 (and any state machine circuitry) may be implemented with one or more semiconductor chips such as a programmable logic device (PLD), field programmable gate array (FPGA) or custom designed logic circuit.
Upon collection of the state information generated by the hardware the FIFO circuitry 307 proceeds to forward the collected state information to a CPU complex 309 that includes a processor 310 and system memory 311. The collected state information that is forwarded to the CPU complex 309 is loaded into the system memory 311. In an embodiment, the custom testing application software that has been downloaded and is executing operates out of the same system memory 311. That is, the application software is loaded into the same system memory 311 that the FIFO captured state information is loaded into.
The processor 310 executes the program code and refers to the FIFO captured state information as input data. In an embodiment, as mentioned above, the application software includes or otherwise refers to previously generated test vector data that the captured data from the FIFO circuitry 307 is compared against. For the digitally collected state information from the FIFO circuitry 307, the test vectors take the form of a set of 1 s and 0s (one 0 or 1 for each signal in the vector). The application software during execution continually compares the measured sets of collected FIFO data against their corresponding test vectors. When a captured set of FIFO data does not match its particular test vector an error flag is raised by the application software and reported to the user interface device. As mentioned previously, both the test vectors and the sampled FIFO data may be time-stamped (e.g., on a relative basis) so the correct vector is compared against the correct sampled data.
As mentioned above, it is pertinent to recognize that the functionality of the CPU complex may instead be implemented with programmable hardware logic circuitry that is programmed in a customized fashion to perform the testing operations in hardware rather than software. In other possible embodiments, a CPU complex may co-exist with programmable hardware logic circuitry so that some elements of testing are performed with customized software on the CPU complex while other elements of the testing are performed in hardware customized programmed hardware logic circuitry.
The smart card 301 also includes a plurality of analog-to-digital converters 312. The plurality of analog-to-digital converters 312 can receive input signals directly from the connector 302, and/or, from one or more signals that are also sent to the FIFO circuitry 307. In the case of the later, where a same signal is routed to both the FIFO circuitry 307 and an analog-to-digital converter 312, the smart card 301 is able to not only measure the signal's logic state (with the FIFO circuitry 307) but also measure the signal's waveform shape (with the analog-to-digital circuitry 312).
In operation, as observed in
Here, referring to
If the signal was also being monitored with analog-to-digital circuitry of the smart card, the application software next compares 502 the digital samples of the signal taken by the analog-to-digital circuitry against the test vector information for the analog signal. In an embodiment, as discussed above, both the digital samples and the analog samples are time-stamped by the measurement devices (e.g., the FIFO circuitry in the case of the digital samples and the analog-to-digital converters in the case of the analog samples) so that they can be properly aligned in time
If the actually measured signal falls outside its specified profile as defined by the analog test vector, an error is flagged. The error is reported 503 to the user interface device along with the analog samples and the analog test vector information. The user interface device is then able to plot on its display the measured waveform against the profile similar to the depiction observed in
The display may also present a download icon 602 to download a particular software application to the smart card. In an embodiment, as part of the download process, the engineer initially has to “log-in” with the cloud service (e.g., with a unique user ID and password). The cloud service sends a message and data to the user interface device that causes the user interface device to display a list of application software programs that have been loaded into and registered with the cloud service for the user's account.
The user then selects one of the application software programs and, in response, the cloud service downloads the application software program to the smart card that the user interface device is communicatively coupled to. As part of the download procedure, the user interface device may identify the network address of the smart card to the cloud service, or, the user interface device may cause the smart card to identify itself to the cloud service. The display of the user interface device may also show download status (e.g., % complete, download complete, etc.) based on information sent from the smart card to the user interface device during the actual downloading.
Note that the test application software may be provided by a manufacturer of the device being tested. For example, continuing with the example above where the testing application software is to test the power-on-reset signaling of a large system on chip, the application test software may be provided by the manufacturer of the system of chip as a testing tool for their own product. Customers of the system-on-chip may order the testing application software from the chip manufacturer. The chip manufacturer uploads the application test software to the cloud service.
The display may also present an indication to the user that the application software has been properly loaded and is ready to execute 603. Again the smart card may communicate this information to the user interface device. After the user has been informed that the software is ready to execute the display may present a “start test” icon 604 to the user. In response to touching the start test icon, the user interface device sends a start test command to the smart card and the smart card causes the application software program to begin execution. The display may also indicate whether the test run by the application software has passed 605, or, if not, provide an indication of failure and any follow on information that could help isolate the problem (such as a particular signal line at a particular moment of time).
Referring briefly back to
In various embodiments, the application test software is generically written and is a part of the firmware of the smart card. The aforementioned application software program that is loaded from the cloud service is, instead of being an entire application test program, is just a record of the input stimuli to be applied and/or the test vectors against which the measured samples are compared. Various other embodiments between these two extremes are possible (e.g., some custom test execution code may be part of the test sequence information that is downloaded from the cloud service while other parts of the testing software may be generic and part of the smart card firmware).
Note that although embodiments described above were directed to hardware de-bugging, the de-bugging environment described at length could also be used to de-bug software/firmware, or software and hardware combined. Here, as is understood in the art, software/firmware often directs hardware to take certain actions that are detectible on the hardware's signal lines, and/or, responds to stimuli that are detectible on the hardware's signal lines.
Note that although embodiments above are directed to embodiments where the test application software is received through a first communication interface and the smart card communicates with the user interface device through a second communication interface, in various other embodiments, the test vectors may be received and communication with the user interface device may take place through a same communication interface.
Note that although the above examples have emphasized the de-bugging of reset signals supplied to a system-on-chip, the approach above can theoretically be applied to any hardware system and system of signal lines for which monitoring is desired. Examples include system interface bus lines (e.g., peripheral bus interfaces, memory interfaces, communication interfaces, etc.) various control lines and power supply rails. Essentially, signal lines between any component with a system, such as a computing system, may be tested as described above.
As observed in
An applications processor or multi-core processor 750 may include one or more general purpose processing cores 715 within its CPU 701, one or more graphical processing units 716, a memory management function 717 (e.g., a memory controller) and an I/O control function 718. The general purpose processing cores 715 typically execute the operating system and application software of the computing system. The graphics processing units 716 typically execute graphics intensive functions to, e.g., generate graphics information that is presented on the display 703. The memory control function 717 interfaces with the system memory 702. The system memory 702 may be a multi-level system memory such as the multi-level system memory discussed at length above. The memory controller may include a pinning engine as described above. During operation, data and/or instructions are typically transferred between deeper non volatile (e.g., “disk”) storage 720 and system memory 702. The power management control unit 712 generally controls the power consumption of the system 700.
Each of the touchscreen display 703, the communication interfaces 704-707, the GPS interface 708, the sensors 709, the camera 710, and the speaker/microphone codec 713, 714 all can be viewed as various forms of I/O (input and/or output) relative to the overall computing system including, where appropriate, an integrated peripheral device as well (e.g., the camera 710). Depending on implementation, various ones of these I/O components may be integrated on the applications processor/multi-core processor 750 or may be located off the die or outside the package of the applications processor/multi-core processor 750.
Embodiments of the invention may include various processes as set forth above. The processes may be embodied in machine-executable instructions. The instructions can be used to cause a general-purpose or special-purpose processor to perform certain processes. Alternatively, these processes may be performed by specific hardware components that contain hardwired logic for performing the processes, or by any combination of programmed computer components and custom hardware components.
Elements of the present invention may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, FLASH memory, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, propagation media or other type of media/machine-readable medium suitable for storing electronic instructions. For example, the present invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
