This improves memory utilization, but at a cost of extra Related Worklogic. An or gate is added to combine the enable signals, and a multiplexer to combine the data signals. Our architecture for tracing datapath registers Section 4. C-Level InstrumentationRecent work has investigated inserting debug instrumentation via modifications to the C source code,rather than instrumenting the RTL circuit.
In , Monson and Hutchings show how the C code can beautomatically modified, such that for every variable assignment in the C code, a duplicate assignment isinserted, where the value is assigned to a top-level pointer. When the modified C code is synthesized bythe HLS tool the authors use Vivado HLS  , this causes top-level ports to be added to the circuit,which are driven by the various inserted assignment statements. The authors propose that these portscould be connected to trace buffers to achieve similar effect to their EOP ports from  discussedearlier in this subsection.
In , Monson and Hutchings expand upon their work, and provide an in depth analysis of howadding these extra assignments to the C code impacts the produced circuit, both in terms of area over-head, as well as execution time. In , the authors further expand the work to include tracking ofpointer values in the C code, which were unavailable in their initial works. Work in progress by Jose Pinilla at the University of British Columbia expands upon the work byMonson and Hutchings, and includes methods of modifying the C code to not only produce the dataports, but also to include the trace buffer memories to record the data, as well as logic to retrieve thesaved values from the circuit.
The main advantage to C-level instrumentation is portability; Ccode modified with debugging instrumentation could be input into several different closed-source HLStools. In contrast, RTL-level modifications either requires modifying the HLS tool to automatically adddebugging circuitry to the RTL circuit, or requires tool-specific information about the structure of theproduced RTL circuit, and how it maps back to the original software code.
Second, adding debugging at the C-level can have a larger areaoverhead, as it lacks the low-level control that RTL modification offers. Finally, as we show in thisdissertation, RTL-level debug instrumentation offers potential for customized debug circuitry that ishighly efficient for capturing circuit execution. The techniques presentedin these works are designed to detect discrepancies between the C source code and the produced RTLcircuit.
The produced RTL code is also instrumented to record the same values. Such an approach is useful for verification purposes; that is, to verify that an HLS tool is producingRTL circuits that are functionally equivalent to the C code. However, one drawback of this approachis that it is reliant upon the user-supplied test vector.
It is possible for the produced RTL code to befunctionally different than the C code, but produce the same trace values for certain input sets.
Trace-Based Post-Silicon Validation for VLSI Circuits. Authors; (view Part of the Lecture Notes in Electrical Engineering book series (LNEE, volume ). The authors discuss several key challenges in post-silicon validation and Lecture Notes in Electrical Engineering Multiplexed Tracing for Design Error.
In thesecases this approach would not detect any mismatches. The authors also show that under certain circumstances these techniques could also be useful fordebugging, not just verification; however, such cases are very limited. Only cases where a bug causesnon-deterministic behaviour, and the RTL circuit behaves differently than the C code, will be detected. The authors show this can occur for out-of-bound memory accesses, or accesses to uninitialized memory. However, for most bugs in the C code, such as logic mistakes, algorithm errors, etc. Related Work2. In the software domain, debugging optimized software code is a well studied problem.
Originally,many methods avoided debugging with optimizations [, ]. However, over time, it became moreaccepted that users would need to debug using the optimized code. In , John Hennessy providesthree reasons for debugging software with optimizations: 1 the compiler may not support disabling alloptimizations, 2 disabling optimizations may change the program behaviour and mask the bug, oftendue to external factors, and 3 because of time or size constraints, optimizations may be necessary. These same reasons exist in the HLS realm, and perhaps are even more applicable.
Interactions withother blocks are a primary debug case, and disabling optimizations could easily mask bugs. In , John Hennessy outlines challenges of creating a debugger that works with optimizedsource code. One major challenge is that optimizations may remove or reorder store operations, makingthe memory value of a variable incorrect, or commonly referred to as noncurrent. The correct, orcurrent, value of a variable may reside in a register, or be optimized away due to compiler optimizationssuch as copy propagation.
Hennessy provides a solution to noncurrent variables, which includes addingadditional information to the debug information that is generated at compile time. The debugger canuse this information to determine whether a variable value currently resides in memory or a register. LLVMuses a similar technique and inserts metadata instructions to indicate the current location of a variable. We describe this process, and how we use this information to track variable values from software tohardware, in Section 3. In , the author includes ways to visualize reordered code, such as highlighting lines of a basic Approaches and Assumptions In This Workblock using different colours to show which instructions have already executed, and which will executenext.
We use a similar technique in our debugger GUI to indicate when multiple C instructions areexecuting in the hardware simultaneously. We first put this work into context with other related work, and then provide a fault modeldescribing the type of bugs that a user could resolve using the techniques presented in this work. This choice is made to ensurethat the circuit can execute normally, and interact with the rest of the operating environment inreal time.
This is done so that the original user circuit is functionally identical to the casewhere no debug instrumentation is added this is not true if C-level instrumentation is performed,such as in [54—56]. Again, this is to ensure that bugs are not masked, and even elusive system-level bugs can be located. Source-level Debug Like other in-system HLS debugging solutions, we chose to develop techniquesthat allow for debugging using the original source code. This ensures that the debug process isaccessible to all users of HLS, both hardware and software designers. Automated Instrumentation Unlike some past works that have relied upon manually adding debugcircuitry [52, 53] , we felt it important to prototype an automated instrumentation process.
Thishas allowed us to perform experiments on large benchmarks that would be impractical to modifyby hand, and better understand how our debugging techniques scale with circuit size. Approaches and Assumptions In This WorkObservability-based Debug The approach we take in this work is to allow the user to debug their de-signs by providing observability into the executing circuit. Although software-based debuggerstypically offer both observability and controllability, we focus on the former.
Since our work employs a trace-baseddebugging approach where the user is recording at-speed execution and debugging using recordeddata, many such controllability features are not possible. Optimizing Observability Much of this dissertation focuses on providing users with as much observ-ability as possible into the executing hardware circuit. In Chapter 4 we present techniques tomaximize the length of circuit execution that can be captured into on-chip trace memories, inChapter 5 we extend these techniques to parallel circuits, and in Chapter 6 we introduce metricsto quantify the observability provided by our techniques and others.
We believe providing higherlevels of observability is key to reducing debugging times, and shortening the full developmentcycle, which is of high importance to HLS users.
Pagano, and R. Salgado, P. Because ofthis, when designing software, it is common practise to debug using the -O0 unoptimized. In contrast, in the HLS flow, circuits are automatically createdand have a set pattern and structure. For this reason, the techniquesin this dissertation may not be applicable to such types of tools. Arvind K. Shuang-Hua Yang.
As such, the primary use model of this work is for a designerto locate functional errors in his or her source program. These source code errors could be as simpleas a typo in the source code or an incorrect algorithm implementation. As described in Sections 2. Source code errors may not just be functional bugs, but could also includeperformance issues, where the implemented circuit does not achieve the desired performance. Theseperformance issues may also lead to functional errors, for example, if the circuit cannot process data Approaches and Assumptions In This Workfast enough to handle requests by other modules in the system.
All of these cases follow the model ofthe user observing the circuit execution, locating the error in their original software specification, andcorrecting it. There are many other types of faults which may be present in an HLS system. In some cases thesefaults may be observable using our techniques for circuit observation; however, they are not a resultof incorrect program specification provided by the user, and thus are not the target of this work.
Forexample, this work is not targeted at finding physical faults in the FPGA. Although such faults maymanifest as the user observes their circuit execution, the techniques we describe in the dissertation arenot useful for locating the root cause of physical errors. Such errors could includeincorrect logic synthesis, or errors in placement and routing leading to setup or hold time violations. Again, these faults could affect the circuit behaviour and may be observable using the techniques of thiswork, but we do not provide techniques to locate the source of such errors within the FPGA CAD tools.
Generally, in this work we also assume the HLS tool itself is error-free. However, even with thisassumption, in certain cases our work may be useful for locating errors within the HLS tool. For exam-ple, if the HLS tool schedules operations to execute in an incorrect order, leading to data dependencyviolations, it may be visible to the user using our debugging techniques. Since the user is debuggingthe hardware circuit, in the context of the source code, the user may also be able to observe functionalmismatches between what is supposed to occur according to the source code, and what is actually hap-pening in the hardware circuit.
Thus, the work in this dissertation may be useful to a designer of anHLS tool, attempting to resolve these mismatches. However, not all bugs in an HLS may necessarily belocated using our techniques. In addition, as we describe in Section 3. So, if the HLS tool is itself error prone, one may not be able to rely upon the accuracy of our debuggingmethods. This dependency should be considered before using our techniques to debug the HLS toolitself.
Furthermore, it should be noted that in one optimization in this dissertation, the signal restora Summarytion technique presented in Section 4. In doing so we assume these signals will be correctly implemented in the hardware,and are assuming the HLS tool implements the hardware exactly as specified by the source program. To capture these system-levelbugs, there needs to be a new framework that provides in-system debugging of HLS circuits. Thisframework must be accessible to both hardware and software designers, allowing them to debug inthe context of their original software program, while the hardware executes in the normal operatingenvironment.
In this chapter we laid the ground work for such a framework. We first discussed techniques forin-system debug of general digital circuits, as these same techniques can be applied toward an HLS-based debug flow. To understand the structure of HLS circuits, and how software code is mapped toa hardware circuit, we included a description of the steps in the HLS flow.
Finally, we provided adescription of related works toward the goal of in-system debugging of HLS circuits, describing boththeir accomplishments and shortcomings. This was followed by a description of the approaches andassumptions made in this dissertation, and how they compare to these related works. The next chapter of the dissertation presents our framework for source-level, in-system debuggingof HLS circuits. Section 3. This debug flowand instrumentation architecture form the context in which the optimizations and evaluation methodsfrom Chapters 4 to 6 are presented.
In addition, the development of this infrastructure represents a novelcontribution in itself. These components are described in detail in the following sections. Finally, Section 3. The Debugging FrameworkSource Code. The userprovides their source code to the HLS tool for compilation in the normal fashion, with no modificationto the source code required. The produced Verilog circuit is identical to whatwould be produced by an unmodified HLS tool, except that it also contains the debug instrumentationwhich allows observation into the circuit as it executes.
At this point the user can launch the debugger tool on their workstation, which connects to the FPGAdevice and communicates with the circuit via the added debug logic. Through this communication, thedebugger can control the circuit, starting and stopping execution and observing internal signal values.
The debugger looks and behaves similar to a software debugger, and allows the user to step through The Debugging Frameworkinstructions, add breakpoints, and inspect variables, all in the context of the original software program. In order to support a software abstraction level, the debugger application requires information on how thehardware maps back to the original software. Thus, the secondary role of the modified HLS tool asidefrom adding debug circuitry to the design is to output this mapping information. This information isstored in a Debug Database, which includes information about how the software entities functions, in-structions, variables, etc.
Software designers expect to able to set breakpoints and single-step their design, and areaccustomed to full visibility into the value of any variable at any point in the program. This is chal-lenging since, as described in Section 2. Providing enough infrastructure trace buffers and associated logic to provide full visibilityinto all signals in a hardware design running at-speed would require too much overhead to be practical.
To address this, we have implemented two different debug modes: 1 a live interaction mode, inwhich the user can have full visibility, but does not run the circuit at speed, and 2 a record and replaymode, in which the user can run the circuit at speed, but only has full visibility for a portion of theexecution.
Each of these is described below. Live Interaction ModeIn the live interaction mode, the system operates similar to a software debugger. The user can createbreakpoints limited by the number of hardware breakpoint units included in the instrumentation andsingle step through the code. Upon hitting a breakpoint, or completing a single step, the tool disablesthe controlling finite state machine FSM , essentially pausing the system.
Once stopped, the state ofthe circuit can be retrieved from the FPGA, including all variable values, by retrieving the most recententries in the trace buffers. Debugging using this mode involves stopping the circuit every time the user wants to inspect a value The Debugging Frameworkor check the program state; this is similar to the technique used in . As discussed previously, ifthe circuit is meant to interact with other hardware modules in the design, or other external devices, it islikely that starting and stopping the circuit will break these interactions. Record and Replay ModeThe record and replay mode provides the ability to run the circuit at-speed while preserving a software-like debug experience.
We believe that this mode is likely the most important feature in our frameworkand best illustrates how the software and hardware worlds can be bridged. This mode operates as follows. While in the live interactive mode, the user can set a breakpoint andrun the circuit to the breakpoint. As the circuit runs, instrumentation added to the circuit records thechanges to signals as well as the control flow executed by the program these values are stored on-chipin trace buffer memories.
After the program hits the breakpoint, the values in the trace buffer are readinto the debug tool, and the user can enter the replay mode. While in replay mode, the user can stillsingle-step and set breakpoints as before, however, all variable values and control flow information isobtained from the trace buffer data rather than the live values from the chip. In this way, the user canobserve what the chip did during the at-speed run, while maintaining a software-like debug interface.
Since the user is debugging using recorded data, they can single-step their design, both forwardsand backwards, providing the illusion of running the chip in reverse. Because on-chip resources are limited, the debug circuitry can only store data for a limited numberof instructions; we refer to the length of code for which data can be stored as the replay window referto Figure 2. Within the replay window a complete control-flow trace is available,allowing the user to observe which instructions are active for each execution step. Any variables thatare updated within the replay window are also available for inspection, but only after the point they areupdated; their value is unknown prior to the first update.
While in the replay mode, the user can step The Debugging Frameworkforwards and backwards through all instructions in the replay window, but can not step outside it. Ifthe user wishes to go outside the replay window, they will have to re-execute their design and move thebreakpoint to a new location in the code. Observability meansthat the user can view what occurs during execution, including the control-flow, which shows the or-dering of executed instructions, as well as the data-flow, providing the value of variables throughoutexecution.
To provide controllability, many software debuggers provide the ability to change variablevalues during debug, move the current execution point, or even change the program source code. Our debug framework focuses mainly on the Record and Replay Mode of operation, where at-speedexecution is captured and the user debugs using the recorded data.
Since we envision the debug processtaking place with recorded data, we focus on observability-based debug, rather than controllability. Our framework provides observability into the circuit execution, allowing the user to view the control-flow of their design, as well as inspect the value of variables during the captured execution. However,controllability is limited to starting and stopping the circuit, including a breakpoint to allow the circuitto stop at a certain program state. Since the user performs debugging using recorded data, certaincontrollability features, such as changing variable values during execution, or artificially altering thecontrol flow, are not possible.
During the debugging process the user may wish to change the functionality of the design. This maybe done to fix bugs and test that the solution is correct, or may simply be done to change the programbehaviour to help locate the root cause of the bug. This process may be very time consuming, which would likely discourage this approach from beingused while locating bugs, and may limit its use to only fixing the bug once found. However, future workcould explore methods to implement minor changes to the design without the need to perform a fullrecompile.
The Debugging Framework3. However,to make our framework proposal concrete, we describe it in the context of the academic open-sourceLegUp HLS tool . LegUp is widely used in the academic community, and has been downloadedby hundreds of research groups worldwide. The debug framework we present in this chapter has beenprototyped in LegUp, and is now part of the official release of LegUp.
Our prototype is added in LegUpversion 4. Although we describe our framework in the context of the LegUp flow, we believe it could beextended to any general-purpose HLS tool, provided the tool produces a circuit similar in structureto Figure 2. In order to apply these techniques to other general-purpose HLS tools, it would be necessary toobtain the mapping information detailing how both the control flow and data flow of the source codemap to FSMs, datapath elements and memories in the resulting circuit.
For the LegUp flow, we describehow we obtain this mapping in Section 3. Inaddition, the instrumented debug logic, which we describe in Section 3. Outside of the category of general-purpose tools, there exist many application-specific high-leveldesign tools and approaches that target, for instance, DSP or media streaming applications See Sec-tion 2. Such tools may be highly-specialized for a specific algorithm, and the resulting circuit maybe substantially different in structure than what is assumed in this work.
For this reason, the techniquesin this dissertation may not be applicable to such types of tools. Debugging techniques for these toolswould need to be considered on a case-by-case basis, which is beyond the scope of this work. Mapping Software to Hardware3.
In this section we describe how information is tracked through this flow in order to mapentities in the hardware back to the original software. We modify the HLS tool to automatically storethis information into a database at compile time, which we refer to as the Debug Database. Other HLS tools may include additionaltransformations and optimizations that may require further steps in the mapping process.
In addition,LegUp provides some optional optimizations that are not enabled by default, such as loop pipelining,which must be manually enabled via pragmas in the source code. Although we do not explain themapping process for all such optimizations, we believe with additional effort, it would be possible to doso. As described in Section 1. There are a few omitted optimizations that should be noted. First, we do not tackle the challengeof supporting source-to-source transformations, where the C code is automatically modified before en-tering the HLS flow.
If the designer used a third-party tool to optimize their C code, they would needto debug using the modified C code, which may not be ideal if transformations were extensive. Inaddition, it is our understanding that LegUp performs relatively little IR-level restructuring and opti-mizations compared to commercial tools. In such cases extra care would need to be taken to preservethe mapping information through these optimizations.
Despite these limitations, our framework does handle most commonly used optimizations. We trackthe software as it is transformed to IR code, through the -O3 level of compiler optimizations, andfinally through the allocation, scheduling, and binding phases as it is synthesized to RTL. Most of thismapping information comes from existing data already stored within the data structures of the HLS tool. Our contribution is demonstrating how this information can be extracted and used to build a complete, Mapping Software to Hardwareend-to-end software to hardware mapping.
Functions in the C code are mapped to functions in the IRassembly, and all C instructions are decomposed into lower level IR instructions. To enable debugging,Clang must be called with the -g flag which enables debug metadata. This metadata, which is a featurebuilt into Clang, includes information which maps each IR instruction to the line of C code from whichit was derived. For example, IR instructions may be re-ordered, dead code may be removed, functions may be auto-matically inlined, and more. LLVM is already designed to preserve the debugging metadata throughoutthese optimizations, so at this point it is still possible to map IR instructions back to their C origin.
Every IR instruction is assigned to beginexecution at a FSM state, and if the operation is a multi-cycle instruction, complete execution at anotherFSM state. Using this information, we can build an end-to-end mapping, detailing how the control flow fromthe RTL maps back to the C code; that is, for each cycle of circuit execution it is possible to determinewhich instructions from the C code are executing.
By observing the state of the FSMs, and using thescheduling information we can determine which IR instructions are executing, and using the LLVMmetadata, determine the corresponding C instructions. In the LLVM IR code, memory is allocated for variables using the alloca instruction,which returns a pointer for use in load and store instructions. When debug metadata is enabled -gflag , extra pseudo instructions llvm. The followingshows how a bit variable named sum is initialized to zero in IR code, and how metadata maps it backto the C variable. Constant propagation willcause some of the variables to be replaced with constants.
Dead code elimination, loop transformations,and other optimizations may completely optimize away some variables. A large number of variables,particularly local, scalar variables will be mapped to IR registers, removing the need to perform loadand store operations.
This is further complicated by the fact that a C code variable may reside in different locationsthroughout the program execution; for example, a variable could be mapped to memory initially, havea constant value for another portion of the program, and be mapped to one or more registers for otherparts of the program.
In fact, because the IR code is in SSA form, for variables mapped to registers,each instance in the code where the variable is updated will be assigned to a new IR register. Handlingthese complications is a necessary part of debugging optimized software refer to Section 2. During the compiler optimizations LLVM automatically inserts pseudo instructions which indicatethe current location of a variable llvm. Once the controlflow reaches the llvm. This construct works fine if the code is executed sequentially, but is not asstraightforward in an HLS system where the scheduler may execute instructions simultaneously or out Mapping Software to Hardwareof-order.
This is somewhat problematic as LLVM has no method to indicate which instruction thellvm. We make the assumption that it is linked to themost previous instruction, and consider it to take effect in the state where the previous instruction isscheduled to be executed. This may not always be accurate, as the change in variable location mayactually be dependent on some earlier instruction; unfortunately improving this system would requiresignificant modifications to the LLVM tool and optimization passes which maintain the metadata.
During synthesis to hardware, LegUp creates a memory for eachalloca instruction. Depending on whether these variables are accessed within a single function, ormultiple functions, these memories may be instantiated locally within a module, or may be located ina shared global memory at the top-level of the circuit. Each memory is accessed through a memorycontroller, and each load and store instruction in the IR is synthesized to datapath logic with sharedaccess to the memory controller.
For variables mapped to IR registers, the mapping is even more simple. Thefew exceptions to this rule occur when the register is an output of a shared functional unit; however,as explained in Section 2. Once this mapping information has been established, our debugger can determine the value of a Ccode variable using the following process.
First, the control flow trace has to be searched for the mostrecent state which contains a llvm. This indicates the current location of thevariable. For variables optimized to constants, the constant value can be provided to the user withoutthe need to inspect the hardware. If the variable is located in an IR register, the corresponding hard-ware register needs to be inspected. For variables in memory, the debugger must monitor the memorycontroller signals, or have external access to the memory controller.
ConstFSMBitsGlobalRAMs bits DistributedRAMs bits adpcm 72 15 10 1 12 aes 45 4 4 11 37 1 4 blowfish 42 1 10 10 45 1 7 dfadd 1 14 9 67 1 96 1 32 dfdiv 2 26 9 63 0 0 0 0 dfmul 83 2 19 8 41 0 0 0 0 dfsin 1 60 12 1 96 1 32 gsm 81 1 21 10 72 1 5 jpeg 22 14 13 1 28 mips 19 3 1 9 23 1 2 motion 99 11 54 10 27 1 4 sha 36 5 12 8 14 1 7 Table 3. In our prototype debugger using the LegUp HLStool, we modified the tool to output this information into a database. Although we modified the tool toexport this information, it should be noted that extracting this information did not require modificationsto the HLS process itself.
It is important to distinguish between the need to modify the HLS tool forthe purposes of extracting information, versus modifying the actual synthesis process. Obtaining thismapping information requires the former, but not the latter; the HLS flow described in Section 2. The one exception to this is that, as described in this section, the -g flag is provided to LLVMto enable debug metadata in the IR; however, our experience is that this produces little to no change tothe behaviour of the IR code.
For the This is the most widely used benchmark suite in recent academic work on HLS. Table 3. We use theversion of the benchmarks included with version 4. The source programs range in size from to lines of code, and contain 19 to source code variables. As described in the previous subsection, once mapped to hardware, the control and data flow canbe determined by observing the FSM states, as well as variables in memories and datapath registers. To extract the control flow, the number of FSM bits that need to be observed ranges from 8 to Forthe data flow, compiler optimizations will optimize away some of these variables, while others are opti-mized to constants, as indicated in the table.
Of the remaining variables, some are mapped to datapathregisters, in which the number of bits that need to be observed ranges from to The remainingvariables are mapped to memories. LegUp can optionally produce a circuit with a single global memorycontroller, or with multiple distributed memories, as will be further discussed in Section 4. The tableshows how many memories exist in both cases, as well as the number of bits of memory controllersignals that need to be observed.
Note that the number of bits can vary depending on the width anddepth of the memory, as well as whether one or two ports are used. The dfdiv and dfmul circuits haveno memory controller signals because they do not contain any variables mapped to memory.
Next, we describe the instrumentation that is added to these circuits in order to observe these signals. The debugging circuitry, which we have developed,is shown as the coloured components in the figure. Circuit Instrumentation3. Stepping and Breakpoint Unit This unit outputs an enable signal which is used to start and stop theFSMs in the user circuit, as well as a hardware breakpoint unit. To facilitate breakpoints, thedebugger configures the breakpoint unit to watch for a certain circuit state, which when hit, willdisable the FSM. Memory Arbiter The memory arbiter multiplexes access to the memory controller between the usercircuit and the debugger, allowing the debugger to access program variables located in memory.
State Encoder Collects the one-hot state signals from all FSMs within the user circuit, and encodesthem into a single fully encoded format. The encoded format is more appropriate for recordinginto trace buffer memories, as it is much more condensed and requires less memory to record. Record and Replay Unit This unit records a trace of the control FSM, updates to datapath registers,and updates to variables in memory. As the circuit is executing, data is constantly being writtento the buffers, overwriting the oldest data in the buffer. This execution occurs at normal operatingspeeds, allowing the circuit to properly interact with other components in the system.
Once thecircuit is halted, either manually, or via breakpoint, the debugger can retrieve the data stored inthe trace buffers, and replay the circuit execution. In the next chapter we describe the architectureof the Trace Recorder in greater detail. As shownin Figure 3. The Debugger Applicationallow the circuit to be started and stopped, and 2 the memory bus is rerouted through an arbitratingmultiplexer.
However, as described in Section 4. The purpose of this section is to show how such a debugging approach can address the challengesfaced by software designers debugging HLS circuits. We make our exposition concrete by presentingdetails of our prototyped debug tool, and relate each of our ideas into features of this tool. Our prototypedemonstrates that it is indeed possible to create a tool that resembles a software debugger, yet can beused to debug hardware designs running on an FPGA.
Figure 3. In thefollowing discussions, we will refer to specific aspects of this diagram. Trace-based post-silicon validation for VLSI circuits [electronic resource]. Responsibility by Xiao Liu, Qiang Xu. Imprint Cham ; New York : Springer, c Physical description 1 online resource. Series Lecture notes in electrical engineering ; v. Online Available online. SpringerLink Full view. More options. Find it at other libraries via WorldCat Limited preview.
Contributor Xu, Qiang. Alberto Sangiovanni-Vincentelli. Frank Oppenheimer. Lei Guan. Hardware Implementation of Intelligent Systems. Abraham Kandel. Embedded Multimedia Security Systems. Amit Pande.
Cloud Computing and Big Data. Weizhong Qiang. Dominique Borrione. Rolf Drechsler. Jan Haase. Distributed Embedded Smart Cameras. Christophe Bobda. Cybernetics and Mathematics Applications in Intelligent Systems. Radek Silhavy. Machine Learning and Intelligent Communications. Huang Xin-lin. Turbo Codes.
Alexandre Giulietti. Trends in Communication Technologies and Engineering Science. He Huang. Anne Remke. Real-Time Systems. Hermann Kopetz. The Hardware Trojan War. Swarup Bhunia.
Handbook of Signal Processing Systems. Shuvra S. Guangyu Sun. IT Convergence and Security Kuinam J. The Boundary-Scan Handbook. Kenneth P. Chenxin Zhang. Semiconductor Technologies in the Era of Electronics. Yong Hoon Kang. Information Security Applications. Ho-won Kim. Regular Nanofabrics in Emerging Technologies. Haykel Ben Jamaa. Mladen Berekovic. Brandon Noia. Yabin Sun. Industrial Networks and Intelligent Systems.
Leandros A. Manjul Bhushan. Nitesh Saxena. Wireless Technology. Steven Powell. Advanced Materials. Ivan A. Witold Pedrycz. Microwave Electronics. Andrey D. Advanced Materials for Integrated Optical Waveguides. Xingcun Colin Tong Ph. Languages and Compilers for Parallel Computing. Chen Ding. Communications and Networking. Bo Li. Self-Organized Quantum Dots for Memories. Tobias Nowozin. Ubiquitous Information Technologies and Applications. Youn-Hee Han.