Telemetry generation for field hardware testing

Abstract

A system for capturing hardware telemetry, comprising: a hardware component encoded with hardware logic for transmitting a telemetry stream to a memory of a computing device. The system also comprises: 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

Technical Field

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

[0002] Although this is shifting towards a cloud computing test environment for software, the testing of hardware components remains largely unchanged. Before being integrated into a consumer computing device, hardware components are typically designed and tested in a laboratory to be completed. However, certain programmable hardware components such as 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 an integrated circuit (IC) that has been deployed on site (e.g., installed in an end-user's machine), or for meaningfully interpreting such data without a large amount of onerous and sometimes unbearable manual effort. Summary of the invention

[0003] 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.

[0004] This Summary is provided to introduce some 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.

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

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

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

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

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

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

[0011] Field Programmable Gate Array (FPGA) is a semiconductor device based on a matrix of configurable logic blocks connected by programmable interconnects. After manufacturing, FPGA can be reprogrammed to the desired application or functional requirements. This feature distinguishes FPGA from application specific integrated circuits (ASIC) that are custom manufactured for specific design tasks. Although one-time programmable FPGAs are available, the main types are based on SRAM, which can be reprogrammed as the design evolves.

[0012] 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 (e.g., a netlist) of the circuit that is compiled into a binary format and downloaded to a simulator device coupled to the IC. The simulator provides test data patterns to the IC and records the outputs of the IC, which are then manually observed by an operator. However, with the advancement of IC technology, 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 communications, digital signal processing (DSP) and other functional blocks. The complexity of these components makes it time- and cost-prohibitive to exhaustively test these chips using traditional simulators.

[0013] In some testing scenarios, hardware developers use embedded logic analyzers (e.g. ) to automatically capture and display signals within FPGA circuits. Unlike traditional simulation, these logic analyzers run in actual hardware (not in a simulator) to provide developers with output that is useful in debugging (e.g., waveforms of logic signals within a 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), i.e., after the fact, to reconstruct the logic states that appear in the FPGA. As a result, the output from these tools is extremely difficult for developers to understand and analyze.

[0014] The technology of the present disclosure provides a framework for configuring a hardware component (e.g., a device that can operate functionally 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 help autonomously summarize 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.

[0015] 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 including the hardware component, the driver can be executed by the processor to interpret the output telemetry stream, populate data fields (e.g., telemetry event data) of a telemetry database schema with values ​​parsed from the telemetry bit stream, and write telemetry records including field tags and associated populated field values. Due to the preservation of semantic information (e.g., a database schema that gives structure and meaning to 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.

[0016] 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 may 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.

[0017] 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 may 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).

[0018] 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 An 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, the 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 out of IC 114 and into memory (e.g., volatile memory 116). The hardware design template 124 is instantiated to create a class instance, which in turn is compiled by the 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, the bitstream 126 physically configures the electronic components within IC 114 (e.g., various shift registers and lookup tables) to implement the behavior described algorithmically by the hardware design template 124.

[0019] 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.

[0020] 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 may mean that certain logical states are true or not true. For example, a set of combinations of observed voltages may be used to infer that the IC is currently performing a particular function. In contrast to digital signals, telemetry records reference the logical state of an IC, such as by identifying the processing operation performed by the IC, rather than simply reporting the observed digital signals.

[0021] 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 policies about when those records are interesting enough to retain.

[0022] 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 infer field values ​​(logical states) of the telemetry structures used to generate the bitstream 126 from those digital signals.

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

[0024] 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.

[0025] The data of the populated telemetry event pattern 120 is then written to the telemetry record 130, Figure 1 In the example of FIG. 1 , 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 permanent storage locations instead of or in addition to being saved locally on the computing device 102 at a local storage location.

[0026] 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 server 132, which in turn can be queried and accessed by the IC design developer 122 to provide statistical information that can inform redesign 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, show signs of degradation, etc.

[0027] 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.

[0028] 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) that can interpret 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.

[0029] During an initial design operation, 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 may be written using tools such as Bond or protocol buffers that 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, 206, each further defined by fields such as fields 222 and 224. The developer also creates a template 220 that may be instantiated to act on the telemetry structures 204, 206 to generate corresponding hardware logic 212 (e.g., a bitstream) that may be loaded onto the FPGA 208.

[0030] 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.

[0031] In general, 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 FPGA 208 is processing. The types of telemetry records defined in telemetry record structure definition 202 can vary significantly depending on the purpose for which FPGA 208 is being used. By way of example and not limitation, telemetry structures 204 and 206 define the start and end of IO operations. For example, when FPGA 208 is programmed to function as a storage controller, telemetry records associated with these events may be useful. In Figure 2In the example of , 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 value of a digital signal 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.

[0032] In various implementations, the template 220 may 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 with 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.

[0033] As described above, the hardware logic 212 includes the necessary information for programming the FPGA 208 to output a telemetry stream including 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 including data placed in the FIFO to a memory (e.g., RAM).

[0034] 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.

[0035] Because the telemetry structures 204, 206 and templates 220 are defined in the advanced mode, the telemetry pattern generator 214 can use such information to construct similar telemetry event patterns 218 within the FPGA driver 216 and automatically generate code that can populate the telemetry event patterns 218 based on the 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 the 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 pattern and its associated field values ​​(logical states) based on the digital telemetry stream output by the FPGA 208. This filling scheme can be stored in the 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 the Azure Data Lake Service, which allows for complex data aggregation and analysis of large volumes of records.

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

[0037] Figure 3 Another example system 300 for generating and capturing in-situ 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 for transmitting a digital telemetry stream 310 in a FIFO format that 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 into the telemetry buffer 306 from the FPGA 314 , 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 .

[0038] The user computing device 302 includes an FPGA driver 304 loaded into the main memory 316, which is 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 be further 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.

[0039] Hardware developers 334 can query telemetry aggregation server 330 to request telemetry event data, which can be used to solve problems (errors) using the hardware logic of FPGA 314. In some implementations, the problem can be understood only by querying and analyzing the data from the stored telemetry event log. In other cases, hardware developers 334 can feed telemetry event log records to hardware simulator 336, which can be used to simulate the hardware logic loaded onto the FPGA. Although the simulation may be slow, the hardware simulator 336 can allow hardware developers 334 to observe the state of the 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 way effectively allows hardware developers 334 to re-simulate and understand problems that occur on ICs deployed in the field. Using such information, hardware developers can identify changes in hardware logic to fix such problems, update the hardware logic accordingly, and make the updated logic available for download and installation on user computing devices.

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

[0041] Figure 4An example operation 400 for generating and capturing telemetry data for field hardware testing is 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 for generating values ​​of 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 filled based on the values ​​parsed from the telemetry stream.

[0042] Figure 5 Schematic diagram illustrating an example of a processing device 500 suitable for implementing aspects of the disclosed technology. Processing device 500 includes: one or more processor units 502, memory 504, display 506 and other interfaces 508 (e.g., buttons). 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. Memory 504 typically includes volatile memory (e.g., RAM) and non-volatile memory (e.g., flash memory). Operating system 510 (e.g., operate, The phone operating system or a specific operating system designed for the gaming device) resides in the memory 504 and is executed by the processor unit 502, but it should be understood that other operating systems may also be used.

[0043] 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 an input accessory 535 (e.g., a keypad, a mouse, a stylus, a touchpad, a game keyboard, a racing wheel, a joystick). In addition, the application 512 can provide a network connection (e.g., a mobile phone network, a wireless network) 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 used.

[0044] The processing device 500 further includes a power supply 516, which is powered by one or more batteries or other power sources and provides power to other components of the processing device 500. The power supply 516 can also be connected to an external power supply (not shown) (which reloads 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).

[0045] The processing device 500 may include various tangible computer-readable storage media and intangible computer-readable communication signals. Tangible computer-readable storage may be implemented by any available media accessible by the processing device 500, and includes volatile and non-volatile storage media, removable and non-removable storage media. Tangible computer-readable storage media do not include 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 disk (DVD) or other optical disk storage, cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible media that can be used to store the desired information and can be accessed by the 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.

[0046] Some implementations may include products. Products may include tangible storage media (storage devices) storing 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, applications, 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 implementation. 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.

[0047] 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.

[0048] Another example method according to any of the foregoing methods further provides: instantiating a template to act on a defined telemetry structure to generate a class instance, each telemetry structure representing at least one telemetry event of a hardware component; compiling the class instance 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.

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

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

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

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

[0053] 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.

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

[0055] 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.

[0056] In another example system of any of the foregoing systems, the system further comprises: a compiler and a telemetry pattern generator. The compiler is stored in the memory and is 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 is executable to parse the hardware bitstream symbol table to generate a telemetry event pattern.

[0057] 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.

[0058] In yet another 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.

[0059] In yet another 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.

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

[0061] An exemplary memory device disclosed herein encodes computer executable instructions for executing a computer process, the 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 emit 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 a bit value in the telemetry stream to a field value of a defined telemetry structure; autonomously generating a driver comprising computer executable instructions for: reading a telemetry data stream emitted from a hardware component; filling a telemetry event pattern based on a value parsed from the telemetry data stream; and writing a telemetry record comprising the filled telemetry event pattern.

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

[0063] 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.

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

[0065] In yet another example memory device of any of the foregoing 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.

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

[0067] 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.

[0068] The implementation described herein is implemented as logical steps in one or more computer systems. Logical operations can 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 used. Therefore, the logical operations that make up the implementation described herein are referred to as operations, steps, objects, or modules in different ways. In addition, it should be understood that the logical operations can be performed in any order unless otherwise expressly stated or the claim language inherently requires a particular order. The above description, examples, and data, together with the attached appendix, provide a complete description of the structure and use of the exemplary implementation.

Claims

1. A method comprising: generating a hardware bitstream symbol table and hardware logic executable to cause a hardware component to emit a telemetry stream based on at least one defined telemetry structure, the at least one defined telemetry structure representing a logical state of the hardware component; 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 at least one defined telemetry structure; Generate a driver, configured as: responsive to execution of the hardware logic within the hardware component, reading a telemetry stream output from the hardware component; populating a telemetry structure within the telemetry event pattern based on bit values ​​parsed from the telemetry stream; as well as A telemetry record is written to a memory of a computing device, the telemetry record including the populated telemetry structure.

2. The method according to claim 1, comprising: Instantiating a template to act on the at least one defined telemetry structure to generate a class instance, the at least one defined telemetry structure representing at least one telemetry event of the hardware component; Compiling the class instance to generate the hardware bitstream symbol table and the hardware logic; loading the hardware logic onto the hardware component; Parsing the hardware bitstream symbol table to generate the telemetry event pattern; as well as A driver is stored in the memory of the computing device.

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 writing the telemetry record further comprises: The telemetry record is written to non-volatile memory in 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 response to execution of the hardware logic within other hardware components on a different computing device.

6. The method according to claim 5, further comprising: querying the remote database for a selection value associated with a telemetry structure defined within the telemetry event pattern; Values ​​observed in association with the telemetry structure on each of the 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 of the different computing devices based on the values ​​received from the remote database.

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

9. A system comprising: a compiler stored in a memory of a computing device and configured to: generate a hardware bitstream symbol table and hardware logic based on at least one defined telemetry structure indicating telemetry events of a hardware component, the hardware logic executable to cause the hardware component to emit a telemetry stream into a telemetry buffer within the memory of the computing device; a telemetry pattern generator stored in the memory of the computing device and executable to parse the hardware bitstream symbol table to generate a telemetry event pattern; A hardware component driver is stored in the memory and is configured to: parsing the telemetry stream; populating a telemetry structure within a telemetry event pattern based on bit values ​​parsed from the telemetry stream; as well as A telemetry record is generated including the populated telemetry structure.

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

11. The system of claim 9, wherein the hardware component driver is further configured to: write the telemetry record to a non-volatile memory in the computing device including the hardware component.

12. The system of claim 9, wherein the hardware component driver is further configured to: migrate the telemetry record to a remote database that stores other telemetry records collected in response to execution of the hardware logic within other hardware components on different computing devices.

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

14. One or more memory devices encoding computer executable instructions for performing 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 executable to cause the hardware component to transmit a telemetry stream; 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 at least one defined telemetry structure; Autonomously generates a driver that is configured to: reading the telemetry stream emitted from the hardware component; populating a telemetry structure within the telemetry event pattern based on bit values ​​parsed from the telemetry stream; and A telemetry record is written that includes the populated telemetry structure.

15. The one or more memory devices of claim 14, wherein the hardware component is a field programmable gate array.

16. The one or more memory devices of claim 14, wherein the hardware logic transmits the telemetry stream in a first-in-first-out (FIFO) structure.

17. The one or more memory devices of claim 14, wherein the telemetry stream is stored in a random access memory (RAM).

18. The one or more memory devices of claim 14, wherein the driver is further executable to: The telemetry records are migrated 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.

19. The one or more memory devices of claim 18, wherein the hardware component does not execute software.

Images