Telemetry generation for field hardware testing

Abstract

Embodiments of the present disclosure relate to telemetry generation for field hardware testing. A system for capturing hardware telemetry is provided, including a hardware component encoded with hardware logic for transmitting a telemetry stream into a memory of a computing device. The system also includes a hardware component driver stored in the memory, the hardware component driver configured to parse the telemetry stream, populate a telemetry structure defined within a telemetry event pattern based on values parsed from the telemetry stream, and generate a telemetry record including the populated telemetry structure.

Description

[0001] This application is a divisional application of the invention patent application with international application number PCT / US2020 / 057578, application date October 28, 2020, entering the Chinese national stage on April 27, 2022, Chinese national application number 202080075602.7, and invention name “Telemetry Generation for Field Hardware Testing”. Technical Field

[0002] In recent years, the availability of cloud computing services, which leverage the pooled computing power of multiple machines to collect and aggregate performance information related to deployed software products, has significantly improved traditional software testing methods. For example, a cloud-based data service can include hundreds to hundreds of thousands of computers, each running a version of the software product. Some computers may run less proven versions of the software product, while a larger percentage of computers run older, better proven versions. As the newer version of the software becomes more mature, it is deployed on a larger share of the machines. During this process, the computers executing the software product may continuously generate error log information and send it to a centralized aggregation server. Aggregated error log information allows software developers to continuously improve the software product and deploy new, better code versions.

[0003] Although this is shifting towards cloud computing test environments for software, the testing of hardware components remains largely unchanged. Before being integrated into consumer computing devices, hardware components are typically designed and tested in a laboratory to be complete. However, certain programmable hardware components, such as field programmable gate arrays (FPGAs), can benefit from the types of large-scale statistics currently collected during software testing on cloud-based computing nodes. Although existing hardware testing techniques can be utilized to observe hardware telemetry in a selected environment and / or capture a large amount of telemetry data, current technology does not provide any architectural mechanism for capturing selected hardware telemetry values from integrated circuits (ICs) that have been deployed on-site (e.g., installed in an end-user's machine), or for meaningfully interpreting such data without a large amount of burdensome and sometimes unbearable manual effort. Summary of the Invention

[0004] According to one implementation, a method for field testing of a hardware component includes receiving a telemetry stream from the hardware component in a memory buffer of a computing device in response to execution of hardware logic by the hardware component, populating a predefined telemetry structure within a telemetry event schema based on values parsed from the telemetry stream, and writing a telemetry record including the populated telemetry structure to a memory of the computing device.

[0005] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0006] Other implementations are also described and listed herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 An example system is shown that creates a telemetry log of event data related to the execution of a hardware component.

[0008] Figure 2 An example system for generating and processing telemetry of field hardware components is shown.

[0009] Figure 3 Another example system for capturing in-situ telemetry related to the performance of an integrated circuit chip is shown.

[0010] Figure 4 Example operations for capturing telemetry for field hardware testing are shown.

[0011] Figure 5 An example schematic diagram of a processing device implementing aspects of the disclosed technology is shown. DETAILED DESCRIPTION

[0012] A field programmable gate array (FPGA) is a semiconductor device based on a matrix of configurable logic blocks connected by programmable interconnects. After manufacture, the FPGA can be reprogrammed to the desired application or functional requirements. This feature distinguishes FPGAs from application-specific integrated circuits (ASICs) that are custom-made for specific design tasks. Although one-time programmable FPGAs are available, the main types are SRAM-based, which can be reprogrammed as the design evolves.

[0013] In traditional testing of integrated circuits (ICs) such as FPGAs and ASICs, hardware developers construct gate-level schematic circuits and convert the designed hardware logic into a text-based representation of the circuit (e.g., a netlist) that is compiled into a binary format and downloaded into a simulator device coupled to the IC. The simulator provides test data patterns to the IC and records the IC's outputs, which are then manually observed by an operator. However, as IC technology advances, this approach has become less feasible. For example, current FPGA designs can support more than 20 million equivalent gates, plus a processor platform and a range of communication, digital signal processing (DSP) and other functional blocks. The complexity of these components makes exhaustive testing of these chips using traditional simulators prohibitive in terms of time and cost.

[0014] In some test scenarios, hardware developers use embedded logic analyzers (e.g., signal taps) ) to automatically capture and display signals within FPGA circuits. Unlike traditional simulations, these logic analyzers run in actual hardware (not within a simulator) to provide developers with output useful for debugging (e.g., waveforms of logic signals within the design). However, due to the aforementioned complexity of FPGA circuits, these tools generate and capture large amounts of data (e.g., thousands of sampled voltages)—in other words, to reconstruct the logic states present in the FPGA after the fact. Consequently, the output from these tools can be extremely difficult for developers to understand and analyze.

[0015] The technology of the present disclosure provides a framework for configuring hardware components (e.g., devices that can functionally operate without executing software) with hardware logic that outputs a telemetry bitstream including telemetry values that provide information about how the device is physically operating and what the device is doing. The systems and methods disclosed herein provide solutions that facilitate autonomously summarizing the state of the hardware logic (digital signals output from the IC) in a manner that reports the logic state of the IC (hardware telemetry) directly to the end user.

[0016] In one implementation, a software device driver is generated for interpreting and capturing hardware telemetry data related to the functionality of an integrated circuit (IC) installed on a user's machine. The software device driver is developed based on the same hardware logic that configures the hardware component to output a digital telemetry stream. When loaded into a memory in a processing device that includes the hardware component, the driver can be executed by the processor to interpret the output telemetry stream, populate data fields of a telemetry database schema (e.g., telemetry event data) with values parsed from the telemetry bit stream, and write telemetry records that include field tags and associated populated field values. Due to the preservation of semantic information (e.g., a database schema that assigns structure and meaning to the digital values captured within the output telemetry data stream), hardware telemetry for a single configuration of a hardware device can be collected and aggregated from multiple (e.g., thousands) of different devices, statistically processed, and used for further design work.

[0017] The above-described methods effectively allow for large-scale field testing of hardware components similar to current field methods for software deployment. For example, the presently disclosed methods can allow for extensive testing of hardware configurations on hundreds or thousands of devices that can utilize the hardware components in different ways and / or in different environments. For programmable ICs such as FPGAs, telemetry data can be used to inform the development of hardware logic upgrades (e.g., patches) that can be used to reconfigure the FPGA to improve the functionality of the deployed design.

[0018] Figure 1An example system 100 is shown that creates a telemetry log of event data (e.g., health, safety, and housekeeping data) related to the execution of a hardware component (e.g., an integrated circuit (IC) 114). While the disclosed techniques may provide particular advantages for reprogrammable ICs (e.g., field programmable gate arrays (FPGAs)) that can be debugged and updated in the field, it should be understood that aspects of the disclosed techniques may be utilized in conjunction with any type of IC for which telemetry capture is useful (e.g., ongoing research and development of chip designs).

[0019] In various implementations, while IC 114 may be any type of integrated circuit, IC 114 is shown as a reprogrammable chip (e.g., an FPGA) that is capable of being reprogrammed after it is deployed in the field on computing device 102 (within an end user's computing environment). Figure 1 1. Example programming of IC 114 is shown. Here, IC design developer 122 generates a hardware design template 124 that provides an algorithmic description of the desired behavior of IC 114. In one implementation, hardware design template 124 defines what is to be captured on IC 114 and sent as a first-in, first-out (FIFO) structure that is moved from IC 114 and into memory (e.g., volatile memory 116). Hardware design template 124 is instantiated to create a class instance, which in turn is compiled by hardware logic compiler 104 to generate a bitstream 126 to be deployed to a user computer (e.g., computing device 102). When loaded onto IC 114, bitstream 126 physically configures the electronic components within IC 114 (e.g., various shift registers and lookup tables) to implement the behavior algorithmically described by hardware design template 124.

[0020] As will be discussed in more detail with respect to the following figures, the hardware design template 124 can be instantiated with respect to one or more telemetry structure record definitions so that the IC output 114 includes a digital telemetry stream 128 of digital signals associated with the telemetry record structure definitions. For example, a developer can define hardware telemetry records of interest using a high-level database schema language that defines a representation that can then be executed in other languages. For example, bindings or protocol buffers can be used to define telemetry record structures of interest, and the hardware design template 124 can be instantiated to act on one or more defined telemetry record structures to generate class instances. Compilation of the class instances generates a bitstream 126 that can be loaded onto the IC 114 so that the IC 114 outputs digital signals that can be used to infer the logical states (field values) of those telemetry record structures.

[0021] As used herein, the term "telemetry record" is intended to refer to the various logical states that exist in association with observed digital signals collected from within a hardware component. For example, a digital signal may refer to sampled voltages at different sampling points within an IC. The observation of certain digital signals can mean that certain logical states are true or false. For example, a set of observed voltage combinations can be used to infer that the IC is currently performing a specific function. In contrast to digital signals, telemetry records reference the logical state of the IC, for example by identifying the processing operation performed by the IC, rather than simply reporting the observed digital signals.

[0022] According to one implementation, IC design developer 122 instantiates a telemetry pipeline that provides instructions for analyzing a series of digital signals and decomposing them into telemetry records (e.g., telemetry record 130) that include inferred logical states of IC 114. The telemetry pipeline additionally includes logic for deciding whether telemetry records should be emitted based on other digital signals, which allows IC design developer 122 to reduce the number of emitted records by encoding a policy regarding when those records are interesting enough to retain.

[0023] In addition to providing the bitstream 126 generated from the hardware design template 124 to the computing device 102, the IC design developer 122 uses the telemetry scheme generator 134 to generate a telemetry event scheme 120 based on the hardware design template 124. The telemetry event schema 120 is, for example, a schema that stores semantic data related to the telemetry records defined in the HW design template 124, including their fields, functions, dependencies, etc. The telemetry event schema 120 includes processor-executable instructions for parsing the digital telemetry stream 128 to analyze the digital signals and inferring the field values (logical states) of the telemetry structure used to generate the bitstream 126 from those digital signals.

[0024] When IC 114 executes the hardware logic programmed via bitstream 126, IC 114 outputs the resulting digital telemetry stream 128 to a telemetry buffer 106 in volatile memory 116 (e.g., RAM) of computing device 102. For example, digital telemetry stream 128 is emitted from IC 114 as a FIFO, and telemetry buffer 106 receiving the FIFO may be a ring buffer. In other embodiments, telemetry buffer 106 is a non-ring buffer. For example, telemetry buffer 106 may manage a free list of entries allocated to telemetry records based on event categories, and this data may be migrated to a more permanent storage location in an order dictated by the relative priority or criticality of the records (e.g., first-in, first-out). In another implementation, telemetry buffer 106 manages a scratchpad to hold blocks of entries, which are then collectively migrated to a more permanent storage location (e.g., first-in, first-out).

[0025] When the digital telemetry stream 128 is written to the telemetry buffer 106, the IC driver 110 reads and interprets the bits in the digital telemetry stream 128 by using the telemetry event pattern 120, which includes information identifying a predetermined data structure and fields corresponding to the respective digital bits within the digital telemetry stream 128. The IC driver 110 parses the telemetry buffer 106 and populates the fields in the telemetry event pattern 120 based on the identified corresponding digital values parsed from the digital telemetry stream 128.

[0026] The data of the populated telemetry event pattern 120 is then written to the telemetry record 130. Figure 1 In the example shown, the telemetry records 130 are stored in the non-volatile memory 136 (e.g., disk or SSD-based storage) of the computing device 102. In other implementations, the telemetry records 130 may be sent to one or more remote persistent storage locations instead of or in addition to being saved locally on the computing device 102 at a local storage location.

[0027] In the illustrated implementation, the IC driver 110 sends telemetry records 130 to one or more cloud-based servers (e.g., telemetry aggregation servers 132), where the data is stored, aggregated, processed, and / or analyzed to provide statistical information about the performance of the IC 114 in various different instances of chip implementation across many different processing devices. The aggregated hardware telemetry data is then stored in the telemetry aggregation servers 132, which in turn can be queried and accessed by the IC design developers 122 to provide statistical information that can inform redesigns or updates (e.g., patches) to the hardware logic programmed on the IC 114 via the bitstream 126. For example, analyzing telemetry records across various machines can be used to infer which disks or network paths may be overloaded, slow, showing signs of degradation, etc.

[0028] In some cases where IC 114 is not reprogrammable (e.g., IC 114 is an ASIC), IC 114 is initially programmed with telemetry capture logic during a factory initialization process, and the programmed logic remains unchanged throughout the useful life of IC 114. Even in this case, the telemetry data captured and stored in telemetry aggregation server 132 can be used to inform manufacturers, hardware designers, or other entities about the functionality of the chip, such as to inform development efforts for future released chip designs.

[0029] Figure 2An example system 200 for generating and processing telemetry for hardware components is shown. Specifically, the system 200 is shown as performing operations for programming an IC (e.g., FPGA 208) to output a digital telemetry stream, and for building a driver (e.g., FPGA driver 216) capable of interpreting the digital telemetry stream to infer corresponding logic state information on a user computing device. Figure 2 In FIG. 2 , the IC is shown as FPGA 208 ; however, in different implementations, the IC may take other forms.

[0030] During initial design operations, a developer drafts one or more telemetry record structure definitions 202 that define telemetry structures of interest. For example, the telemetry record structure definitions 202 can be written using tools such as Bond or protocol buffers, which define representations that can then be executed in other languages. By way of example and not limitation, the telemetry record structure definitions 202 include telemetry structures 204 and 206, each further defined by fields such as fields 222 and 224. The developer also creates a template 220 that can be instantiated to act on the telemetry structures 204 and 206 to generate corresponding hardware logic 212 (e.g., a bitstream) that can be loaded onto the FPGA 208.

[0031] In one implementation, template 220 defines a record (e.g., a FIFO) to be transmitted by FPGA 208. The digital signals included in the transmitted record depend on the telemetry structure (e.g., 204 or 206) used to instantiate template 220. The transmitted record includes digital signal information that can be used to infer the logic state of the associated defined telemetry structure 204 or 206.

[0032] In general, the telemetry record structure definition 202 and template 220 together define a high-level schema that can be used to define, capture, and interpret a set of semantically interesting data records that can help hardware designers understand what the FPGA 208 is processing. The types of telemetry records defined in the telemetry record structure definition 202 can vary significantly depending on the purpose for which the FPGA 208 is being used. By way of example and not limitation, the telemetry structures 204 and 206 define the start and end of IO operations. For example, when the FPGA 208 is programmed to function as a memory controller, telemetry records associated with these events may be useful. Figure 2In the example of FIG, telemetry structures 204, 206 each include a plurality of fields (e.g., fields 222, 224) that include a current cycle count, a tag indicating the type of telemetry event that has occurred (e.g., "IoOperationStart"), the type of I / O operation (e.g., write, read, flush), the LBA start of the operation, and the length of the operation. By way of example and not limitation, these example fields represent logic state information that can be inferred based on the values of digital signals output by FPGA 208 whenever FPGA 208 performs an action associated with a defined telemetry event (e.g., whenever a new I / O operation begins or ends). Other telemetry events can vary significantly depending on the nature of the use of FPGA 208.

[0033] In various implementations, the template 220 can be generated in a high-level synthesis language (e.g., "Catapult-C" from Mentor Graphics or "Vivado HLS" from Xilinx) or a low-level hardware description language (e.g., Verilog). When the template 220 is instantiated using one or more telemetry record structure definitions 202 and compiled by a compiler (not shown), the compiler generates hardware logic 212 (sometimes referred to as a "netlist") and a hardware bitstream symbol table 210.

[0034] As described above, the hardware logic 212 includes the necessary information for programming the FPGA 208 to output a telemetry stream comprising digital signal values associated with the telemetry structures 204, 206 used to instantiate the template 220. In one example implementation, the hardware logic 212 defines a FIFO that receives digital signal information associated with the defined telemetry structure each time an associated telemetry event occurs. The hardware logic 212 may also define hardware logic for writing a record comprising the data placed in the FIFO to a memory (e.g., RAM).

[0035] The hardware bitstream symbol table 210 stores the names and associated logic state information (e.g., function names, objects, classes, etc.) for all defined telemetry structures that are acted upon when the template 220 is instantiated. A telemetry pattern generator 214 is executed by the processor to parse the hardware bitstream symbol table 210 to automatically generate code (e.g., FPGA driver 216) that interprets the digital telemetry stream generated by the FPGA 208 when the hardware logic 212 is executed.

[0036] Because the telemetry structures 204, 206 and templates 220 are defined in advanced mode, the telemetry pattern generator 214 can use this information to construct a similar telemetry event pattern 218 within the FPGA driver 216 and automatically generate code that can populate the telemetry event pattern 218 based on information present in the digital telemetry stream output by the FPGA 208. For example, the FPGA driver 216 can be programmed to recognize each different type of digital telemetry value written to RAM (e.g., each bit in the digital telemetry stream 128) and semantically mark those values associated with the corresponding fields defined in the telemetry event pattern 218. In other words, the FPGA driver 216 includes the telemetry event pattern 218 and instructions for populating the telemetry event pattern 218 and its associated field values (logical states) based on the digital telemetry stream output by the FPGA 208. This population scheme can be stored within a telemetry record in a permanent storage location, such as a local or remote disk or SSD-based storage. In one implementation, telemetry records are migrated to a big data analytics system such as Azure Data Lake Service, which allows for complex data aggregation and analysis of large volumes of records.

[0037] In the above system, using the predefined telemetry event patterns 218 allows new types of telemetry events to be added to the telemetry stream and stored at very low cost, simply by updating the pattern and hardware logic.

[0038] Figure 3 Another example system 300 for generating and capturing field telemetry related to the performance of an IC chip is shown. System 300 includes a user computing device 302 including an FPGA 314 programmed with hardware logic to transmit a digital telemetry stream 310 in FIFO format, which is placed in a telemetry buffer 306 in the main memory (RAM) of the user computing device 302. The user computing device 302 includes a processor 308 that communicates with the FPGA 314 via an I / O bus. Although Figure 3 The telemetry stream 310 is shown being written directly from the FPGA 314 into the telemetry buffer 306 , but some implementations may write the telemetry stream 310 to the telemetry buffer 306 by first routing the telemetry stream 310 to the processor 308 via the I / O bus 318 and then writing the telemetry stream 310 along a path between the processor 308 and the main memory 316 .

[0039] The user computing device 302 includes an FPGA driver 304 loaded into the main memory 316 and executable by the processor 308 to interpret the telemetry stream 310 output by the FPGA 314. According to one implementation, the FPGA driver 304 is executable to collect the digital telemetry stream 310 from the telemetry buffer 306, parse the telemetry stream for specific digital telemetry values corresponding to a predetermined telemetry record of interest, populate the fields (logical states) of the telemetry event pattern with the identified corresponding values, and write the telemetry record 328 to the non-volatile memory of the user computing device 302 including the populated telemetry event pattern. The FPGA driver 304 can further be executed to migrate the telemetry record 328 to the telemetry aggregation server 330 periodically or upon request, which receives other similar telemetry records from other user computing devices that also include FPGAs programmed with the same hardware logic.

[0040] Hardware developers 334 can query telemetry aggregation server 330 to request telemetry event data, which can be used to troubleshoot issues (errors) with the hardware logic of FPGA 314. In some implementations, understanding the problem can be achieved solely by querying and analyzing data from the stored telemetry event log. In other cases, hardware developers 334 can feed the telemetry event log records to a hardware simulator 336, which can be used to simulate the hardware logic loaded onto the FPGA. While simulation may be slow, hardware simulator 336 can allow hardware developers 334 to observe the state of relevant components of the FPGA associated with each telemetry event defined in the telemetry record (e.g., by effectively observing the voltage value at a specific gate associated with each defined telemetry event). Collecting and using telemetry records 328 in this manner effectively allows hardware developers 334 to re-simulate and understand issues that arise on ICs deployed in the field. Using this information, hardware developers can identify changes to the hardware logic to fix the issue, update the hardware logic accordingly, and make the updated logic available for download and installation on user computing devices.

[0041] In one implementation, hardware simulator 336 is enhanced to show telemetry event data from telemetry log 328 associated with each observed simulated state of the FGPA hardware logic. Hardware simulator 336 can compare the logged data (e.g., the actual output of the hardware logic) with the state data (i.e., the state data expected to be output by the simulator per the original design) and use this comparison to update the hardware logic and evaluate the functionality and effectiveness of each hardware update.

[0042] Figure 4Example operations 400 for generating and capturing telemetry data for field hardware testing are shown. A compile operation 402 compiles a template that acts on a defined telemetry structure to generate a hardware bitstream symbol table and is executable to cause a hardware component (e.g., an FPGA or other component that does not execute software) to output hardware logic for a telemetry stream. A parse operation 404 parses the hardware bitstream symbol table to generate semantic data (e.g., a pattern) for mapping bit values in the telemetry stream to corresponding data structures defined in the template that represent telemetry events for the hardware component. A load operation 406 loads the hardware logic onto the hardware component. A receive operation 408 receives the telemetry stream from the hardware component in a memory buffer. A pattern fill operation 410 executes a driver that uses the semantic data to parse the telemetry stream to generate values for the hardware logic corresponding to the telemetry structure acted upon by the template. A write operation 412 writes a telemetry record that includes the telemetry structure populated based on the values parsed from the telemetry stream.

[0043] Figure 5 Schematic diagram illustrating an example of a processing device 500 suitable for implementing aspects of the disclosed technology. The processing device 500 includes: one or more processor units 502, memory 504, a display 506, and other interfaces 508 (e.g., buttons). The processor unit 502 may include one or more processors (CPU or GPU) for executing software on one or more ICs such as ASICs or FPGAs. The memory 504 typically includes volatile memory (e.g., RAM) and non-volatile memory (e.g., flash memory). An operating system 510 (e.g., operate, The phone operating system or a specific operating system designed for the gaming device) resides in memory 504 and is executed by processor unit 502, but it should be understood that other operating systems may also be used.

[0044] Such as Figure 1 One or more application programs 512 of the IC driver 110 are loaded into the memory 504 and executed by the processor unit 502 on the operating system 510. The application 512 can receive input from various input local devices such as a microphone 534 or input accessories 535 (e.g., a keypad, mouse, stylus, touchpad, game keyboard, racing wheel, joystick). In addition, the application 512 can provide network connectivity (e.g., mobile phone network, etc.) via a wired or wireless network by using more communication transceivers 530 and antennas 538. ). The processing device 500 may also include various other components, such as a positioning system (e.g., a global positioning satellite transceiver), one or more accelerometers, one or more cameras, an audio interface (e.g., a microphone 534, an audio amplifier and speaker, and / or an audio jack), and a storage device 528. Other configurations may also be employed.

[0045] The processing device 500 further includes a power supply 516 that is powered by one or more batteries or other power sources and provides power to the other components of the processing device 500. The power supply 516 can also be connected to an external power supply (not shown) (which recharges or recharges the internal battery) or other power sources. In an example implementation, the processor unit 502 includes an FPGA, and the application 512 includes an IC driver (e.g., Figure 1 IC driver 110).

[0046] Processing device 500 may include various tangible computer-readable storage media and intangible computer-readable communication signals. Tangible computer-readable storage can be implemented by any available media accessible by processing device 500 and includes volatile and non-volatile storage media, removable and non-removable storage media. Tangible computer-readable storage media exclude intangible and transient communication signals and include volatile and non-volatile, removable and non-removable storage media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Tangible computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVDs) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible medium that can be used to store the desired information and is accessible by processing device 500. In contrast to tangible computer-readable storage media, intangible computer-readable communication signals may embody computer-readable instructions, data structures, program modules, or other data residing in a modulated data signal such as a carrier wave or other signal transmission mechanism. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, intangible communication signals include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0047] Some implementations may include products. Products may include tangible storage media (storage devices) that store logic. Examples of storage media may include one or more types of processor-readable storage media capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. Examples of logic may include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, operating segments, methods, processes, software interfaces, application program interfaces (APIs), instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof. In one implementation, for example, a product may store executable computer program instructions that, when executed by a computer, cause the computer to perform methods and / or operations according to the described implementations. Executable computer program instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, etc. Executable computer program instructions can be implemented according to a predefined computer language, method or syntax to instruct a computer to perform a certain operation segment. These instructions can be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0048] An example method disclosed herein provides: receiving a telemetry stream from a hardware component in response to execution of hardware logic within the hardware component; populating a telemetry structure defined within a telemetry event pattern based on values parsed from the telemetry stream; and writing a telemetry record to a memory of a computing device. The telemetry structure represents a logical state of the hardware component, and the telemetry record includes the populated telemetry structure.

[0049] Another example method according to any of the foregoing methods further provides: instantiating a template to act on defined telemetry structures to generate class instances, each telemetry structure representing at least one telemetry event of a hardware component; compiling the class instances to generate a hardware bitstream symbol table and hardware logic; loading the hardware logic onto the hardware component; parsing the hardware bitstream symbol table to generate a telemetry event pattern; and storing a driver in a memory of a computing device, the driver including instructions for generating telemetry records using the telemetry event pattern.

[0050] In a further example method of any of the foregoing methods, the hardware logic transmits the telemetry stream in a first-in-first-out (FIFO) structure.

[0051] In a further example method of any of the foregoing methods, writing the telemetry record further comprises writing the telemetry record to non-volatile memory in a computing device comprising the hardware component.

[0052] In yet another example method of any of the foregoing methods, the method further provides for migrating the telemetry records to a remote database, the remote database storing other telemetry records collected in response to execution of the hardware logic within other hardware components on a different computing device.

[0053] In another example method of any of the foregoing methods, the method further provides: querying a remote database for selected values associated with the telemetry structure defined within the telemetry event pattern; and receiving from the database observed values associated with the telemetry structure on each of the different computing devices.

[0054] In yet another example method of any of the foregoing methods, the hardware component is a reprogrammable chip, and the method further includes deploying an update to the hardware configuration of the reprogrammable chip on each of the different computing devices based on the value received from the remote database.

[0055] In a further example method of any of the foregoing methods, the hardware component is a field programmable gate array.

[0056] An exemplary system disclosed herein includes: a hardware component encoded with hardware logic for transmitting a telemetry stream to a telemetry buffer within a memory of a computing device; a hardware component driver stored in the memory and configured to: parse the telemetry data stream; populate a telemetry structure defined within a telemetry event pattern based on values parsed from the telemetry stream; and generate a telemetry record including the populated telemetry structure. The telemetry structure represents a logical state of the hardware component.

[0057] In another example system of any of the foregoing systems, the system further includes a compiler and a telemetry pattern generator. The compiler is stored in the memory and configured to generate a hardware bitstream symbol table and hardware logic based on at least one defined telemetry structure representing telemetry events of the hardware component. The telemetry pattern generator is stored in the memory and executable to parse the hardware bitstream symbol table to generate a telemetry event pattern.

[0058] In yet another example system of any of the foregoing systems, the hardware logic transmits the telemetry stream in a first-in-first-out (FIFO) structure.

[0059] In a further example system of any of the foregoing systems, the hardware component driver is further configured to write the telemetry record to a non-volatile memory in a computing device including the hardware component.

[0060] In a further example system of any of the foregoing systems, the hardware component driver is further configured to migrate the telemetry records to a remote database that stores other telemetry records collected in response to execution of the hardware logic within other hardware components on a different computing device.

[0061] In yet another example system of any of the foregoing systems, the hardware component is a field programmable gate array.

[0062] An exemplary memory device disclosed herein encodes computer-executable instructions for executing a computer process comprising: generating a hardware bitstream symbol table and hardware logic based on at least one defined telemetry structure representing a logical state of a hardware component. The hardware logic is executable to cause the hardware component to transmit a telemetry stream. The computer process further comprises: parsing the hardware bitstream symbol table to generate a telemetry event pattern, the telemetry event pattern being used to map bit values in the telemetry stream to field values of the defined telemetry structure; autonomously generating a driver comprising computer-executable instructions for: reading a telemetry data stream transmitted from the hardware component; populating the telemetry event pattern based on values parsed from the telemetry data stream; and writing a telemetry record comprising the populated telemetry event pattern.

[0063] In another example memory device of any of the foregoing memory devices, the hardware component is a field programmable gate array.

[0064] In yet another example memory device of any of the foregoing memory devices, the hardware logic transmits the telemetry stream in a first-in-first-out (FIFO) structure.

[0065] In yet another example memory device of any of the foregoing memory devices, the telemetry stream is stored in RAM.

[0066] In yet another example memory device of any of the aforementioned memory devices, the driver is further executable to migrate the telemetry records to a remote database that stores other telemetry records collected in response to execution of the hardware logic within other hardware components on a different computing device.

[0067] In another example memory device of any of the foregoing memory devices, the hardware component does not execute software.

[0068] An example system disclosed herein includes means for receiving a telemetry stream from a hardware component in response to execution of hardware logic within the hardware component, means for populating a telemetry structure defined within a telemetry event pattern based on values parsed from the telemetry stream, and means for writing a telemetry record to a memory of a computing device. The telemetry structure represents a logical state of the hardware component, and the telemetry record includes the populated telemetry structure.

[0069] The implementations described herein are implemented as logical steps in one or more computer systems. The logical operations may be implemented as: (1) a sequence of processor-implemented steps executed in one or more computer systems, and (2) interconnected machine or circuit modules within one or more computer systems. Implementation is a matter of choice, depending on the performance requirements of the computer systems being used. Accordingly, the logical operations making up the implementations described herein are variously referred to as operations, steps, objects, or modules. Furthermore, it should be understood that the logical operations may be performed in any order unless otherwise expressly stated or the claim language inherently requires a particular order. The above specification, examples, and data, together with the accompanying appendix, provide a complete description of the structure and use of the exemplary implementations.

Claims

1. A method comprising: receiving a telemetry stream from a hardware component in a memory buffer of a computing device, the hardware component associated with execution of hardware logic by the hardware component; populating a telemetry event pattern based on one or more bit values of the telemetry stream, the telemetry event pattern mapping the one or more bit values of the telemetry stream to a telemetry structure defined by the telemetry event pattern to represent a logical state of the hardware component; as well as A telemetry record is generated that includes the defined telemetry structure, the defined telemetry structure representing the logical state of the hardware component.

2. The method according to claim 1, comprising: Instantiating a template to act on the defined telemetry structure to generate a class instance, wherein the defined telemetry structure represents at least one telemetry event of the hardware component; Compiling the class instance to generate a hardware bitstream symbol table and the hardware logic; loading the hardware logic onto the hardware component; as well as A driver is stored, the driver including instructions for generating the telemetry record using the telemetry event pattern.

3. The method of claim 1, wherein the hardware logic transmits the telemetry stream in a first-in-first-out (FIFO) structure.

4. The method of claim 1 , wherein generating the telemetry record further comprises: The telemetry record is written to non-volatile memory of the computing device including the hardware component.

5. The method according to claim 1, further comprising: The telemetry records are migrated to a remote database that stores other telemetry records collected in association with execution of the hardware logic by other hardware components.

6. The method of claim 5, wherein the defined telemetry structure is a first telemetry structure, and the method further comprises: querying the remote database for one or more values associated with a second telemetry structure defined within the telemetry event pattern; The one or more values observed in association with the second telemetry structure on each of a plurality of different computing devices are received from the remote database.

7. The method of claim 6, wherein the hardware component is a reprogrammable chip, and the method further comprises: An update to the hardware configuration of the reprogrammable chip is deployed on each computing device of the plurality of different computing devices based on the value received from the remote database.

8. The method of claim 1, wherein the hardware component is a field programmable gate array.

9. A method comprising: generating a telemetry event pattern based on a hardware bitstream symbol table, wherein the telemetry event pattern is used to map bit values of a telemetry stream from a hardware component to field values of a defined telemetry structure, wherein the defined telemetry structure represents a logical state of the hardware component; receiving the telemetry stream from the hardware component in a memory buffer, the hardware component associated with execution of hardware logic by the hardware component; populating the defined telemetry structure of the telemetry event pattern based on one or more bit values of the telemetry stream; as well as A telemetry record is generated that includes the defined telemetry structure populated.

10. The method of claim 9, wherein the hardware component is a field programmable gate array.

11. The method of claim 9, wherein the hardware logic transmits the telemetry stream in a first-in-first-out (FIFO) structure.

12. The method of claim 9, wherein the telemetry stream is stored in random access memory (RAM).

13. The method according to claim 9, further comprising: The telemetry records are migrated to a remote database that stores other telemetry records collected in association with execution of the hardware logic by other hardware components. The method of claim 13 , wherein the hardware component does not execute software.

15. A system comprising: at least one processor; as well as The memory stores instructions that, when executed by the at least one processor, cause the system to perform a set of operations, the set of operations comprising: generating a telemetry event pattern based on a hardware bitstream symbol table, wherein the telemetry event pattern is used to map bit values of a telemetry stream from a hardware component to field values of a defined telemetry structure, wherein the defined telemetry structure represents a logical state of the hardware component; receiving the telemetry stream from the hardware component in a memory buffer, the hardware component associated with execution of hardware logic by the hardware component; populating the defined telemetry structure of the telemetry event pattern based on one or more bit values of the telemetry stream; and A telemetry record is generated that includes the defined telemetry structure populated.

16. The system of claim 15, wherein the hardware component is a field programmable gate array.

17. The system of claim 15, wherein the hardware logic transmits the telemetry stream in a first-in-first-out (FIFO) structure.

18. The system of claim 15, wherein generating the telemetry record further comprises: The telemetry record is written to non-volatile memory of a computing device including the hardware component.

19. The system of claim 15, wherein the defined telemetry structure is a first telemetry structure, and the set of operations further comprises: querying a remote database for one or more values associated with a second telemetry structure defined within the telemetry event pattern; The one or more values associated with the second telemetry structure on each of a plurality of different computing devices are received from the remote database.

20. The system of claim 19, wherein the hardware component is a reprogrammable chip, and the set of operations further comprises: An update to the hardware configuration of the reprogrammable chip is deployed on each computing device of the plurality of different computing devices based on the value received from the remote database.

21. A method comprising: aggregating a plurality of telemetry records for a set of hardware components, wherein each telemetry record for a hardware component in the set of hardware components comprises a defined telemetry structure, the defined telemetry structure representing a logical state of the hardware component; receiving a request from a computing device to query the plurality of telemetry records; processing the plurality of telemetry records to generate an aggregated processing result; as well as The aggregated processing result is provided in response to the request to query the plurality of telemetry records.

22. A method according to claim 21, wherein each telemetry record includes a mapping of one or more bit values of the telemetry stream according to a telemetry event pattern, and the mapping maps the one or more bit values of the telemetry stream to a telemetry structure defined by the telemetry event pattern to represent the logical state of the hardware component.

23. The method of claim 21, further comprising: receiving an indication of updated hardware logic from the computing device; as well as The updated hardware logic is provided for updating a hardware component in the set of hardware components.

24. The method of claim 21, wherein: The plurality of telemetry records are aggregated from a plurality of computing devices; and Each computing device of the plurality of computing devices includes an implementation of the hardware component.

25. The method according to claim 21, wherein providing the aggregated processing result further comprises: Telemetry event data corresponding to the processing result and for the set of hardware components is provided.

26. The method of claim 21, wherein the aggregate processing result includes statistical information related to the plurality of telemetry records.

27. The method of claim 21, wherein the hardware component is a field programmable gate array (FPGA).

28. A method comprising: querying a telemetry aggregation server to request telemetry information related to hardware logic of a set of hardware components; Receiving the requested telemetry information from the telemetry aggregation server includes at least one of the following: a telemetry record for a hardware component in the set of hardware components, the telemetry record comprising a defined telemetry structure representing a logical state of the hardware component; or telemetry event data of the hardware components of the set of hardware components; processing the telemetry information using a hardware simulator to simulate hardware logic of the set of hardware components; as well as An indication of a hardware logic update for the set of hardware components is provided to the telemetry aggregation server.

29. The method of claim 28, wherein the set of hardware components is a plurality of hardware components, and the telemetry information comprises aggregated telemetry information for the plurality of hardware components.

30. The method of claim 29, wherein the telemetry information comprises aggregated processing results for the plurality of hardware components.

31. The method of claim 28, wherein the hardware simulator processes the telemetry information to reconstruct a state of a hardware component based on the telemetry information.

32. The method of claim 31, wherein the state of the hardware component comprises a voltage value for a corresponding gate associated with a telemetry event in the telemetry information.

33. The method of claim 28, wherein providing an indication of the hardware logic update is responsive to receiving from a user a change to hardware logic based on the simulated logic of the set of hardware components.

34. A system comprising: at least one processor; as well as The memory stores instructions that, when executed by the at least one processor, cause the system to perform a set of operations, the set of operations comprising: aggregating a plurality of telemetry records for a set of hardware components, wherein each telemetry record for a hardware component in the set of hardware components comprises a defined telemetry structure, the defined telemetry structure representing a logical state of the hardware component; receiving a request from a computing device to query the plurality of telemetry records; processing the plurality of telemetry records to generate an aggregated processing result; and The aggregated processing result is provided in response to the request to query the plurality of telemetry records.

35. A system according to claim 34, wherein each telemetry record includes a mapping of one or more bit values of a telemetry stream according to a telemetry event pattern, and the mapping maps the one or more bit values of the telemetry stream to a telemetry structure defined by the telemetry event pattern to represent the logical state of the hardware component.

36. The system of claim 34, wherein the set of operations further comprises: receiving an indication of updated hardware logic from the computing device; as well as The updated hardware logic is provided for updating a hardware component in the set of hardware components.

37. The system of claim 34, wherein: The plurality of telemetry records are aggregated from a plurality of computing devices; and Each computing device of the plurality of computing devices includes an implementation of the hardware component.

38. The system of claim 34, wherein providing the aggregated processing result further comprises: Telemetry event data corresponding to the processing result and for the set of hardware components is provided.

39. The system of claim 34, wherein the aggregate processing result includes statistical information related to the plurality of telemetry records.

40. The system of claim 34, wherein the hardware component is a field programmable gate array (FPGA).

Images