Lookup table optimization for programming languages ​​targeting synchronous digital circuits

Abstract

A programming language and a compiler are disclosed that optimize the use of a lookup table (LUT) on a synchronous digital circuit (SDC) such as a programmed field programmable gate array (FPGA). The LUT is optimized by merging multiple computational operations into the same LUT. The compiler parses the source code into an intermediate representation (IR). Each node of the IR representing an operator (e.g., '&', '+') is mapped to a LUT that implements the IR. The compiler iteratively traverses the IR, merging adjacent LUTs into a LUT that performs two operations and performing input removal optimization. Additional operators can be merged into the merged LUT until all LUT inputs are assigned. Pipeline stages are then generated based on the merged LUTs, and the SDC is programmed based on the pipeline and the merged LUTs.

Description

Background Art

[0001] A hardware description language ("HDL") is a modeling language used by hardware engineers to describe the structure and behavior of electronic circuits, most of which are typically digital logic circuits. Examples of HDLs include Very High Speed ​​Integrated Circuit ("VHSIC") HDL and VERILOG.

[0002] HDL typically requires many lines of code to simulate digital logic circuits. Creating this code is very time-consuming, even for hardware engineers who are very familiar with HDL. In addition, the more lines of code there are in a design, the more likely it is that the design will include errors or perform poorly.

[0003] Because HDLs typically utilize a programming paradigm different from imperative programming languages, software engineers who are not very familiar with HDLs typically have difficulty utilizing these languages. As a result, electronic circuits created by software engineers and generated from HDLs may also include errors or perform poorly.

[0004] Presented herein are responses to these and other technical challenges made by the present disclosure. Summary of the invention

[0005] Techniques for optimizing the use of lookup tables (LUTs) on synchronous digital circuits (SDCs) such as programmed field programmable gate arrays (FPGAs) are disclosed. Through implementation of the disclosed techniques, hardware engineers can achieve significant performance gains and hardware efficiency by reducing the number of LUTs required to implement some types of circuit designs while improving performance. For software engineers with some or no experience designing circuits using HDLs, the disclosed techniques provide a familiar programming paradigm that can be used to generate high-performance circuit designs. Other technical benefits not specifically mentioned herein can also be implemented through implementations of the disclosed subject matter.

[0006] To implement the technical advantages briefly mentioned above, the LUT is optimized by merging multiple computational operations into the same LUT and by identifying inputs that are unchanged or can be omitted in other ways. The computational operations are merged before defining the pipeline stages. This allows a wider range of optimizations than if the pipeline stages were defined first and then the optimizations were applied within a given pipeline stage. The optimizations are applied iteratively along with conventional optimizations so that it can be determined that the merged LUT can omit inputs, making the LUT available for further merging.

[0007] In some configurations, the compiler parses the source code into an abstract syntax tree (AST). The AST can be converted into an intermediate representation (IR) - a data structure used internally by the compiler. The IR may include a function set (a function set for each function identified in the source code), each function of the function set includes a basic block set, and each basic block of the basic block set includes a sequence of computational operations. Each computational operation of the IR representing an operator (e.g., '&', '+') is mapped to one or more LUTs that implement the operator. In some configurations, the compiler traverses the IR and merges two (or more) LUTs into a single LUT that performs two (or more) operations. Additional operators can be merged into the merged LUT until all LUT inputs are utilized. Additionally or alternatively, the compiler can infer that the LUT input has a specific value and use this information to perform additional optimizations, such as by removing inputs from the LUT. The compiler can iteratively merge LUTs, identify constraints on input values, omit input variables when the output of the LUT does not depend on the input variables, and apply other optimizations to further reduce the number of pipeline stages, SDC areas, and execution time. The pipeline stages are then generated based on the merged LUTs.

[0008] For example, the expression "z = (a & b) | c", can be parsed into an IR with a node for the '&' operator and a node for the '|' operator. Each node can be replaced with a corresponding LUT (e.g., truth tables for '&' and '|'). When the compiler traverses the IR, the truth tables for '&' and '|' can be combined into a single table that takes three inputs (a, b, and c) and provides an output based on the expression "(a & b) | c". The resulting LUT is then output as a single pipeline stage.

[0009] In some configurations, the compiler further optimizes the LUT by performing a bit-by-bit analysis of the variables. For example, if the expression "(a&b)|c" is performed on eight-bit values ​​'a', 'b', and 'c', the LUT merge is performed on eight different IRs, one for each bit. If the compiler can infer a constraint on one bit, but not another, it will optimize the IR for that one bit. For example, if the compiler infers that the second bit of 'b' is always 1, 'b' will be omitted from the LUT that executes "a&b" for the second bit. However, if the same content cannot be displayed for the first or third bit, 'b' will still be a parameter of the corresponding LUT. Optimizing a LUT to omit parameters allows additional operations to be merged into the LUT.

[0010] In some configurations, bitwise LUT optimizations are extended across basic programming blocks—i.e., sequences of expressions that have only one exit upon entry. The compiler can analyze a basic block in a function, its immediate predecessor, and other basic blocks within the function. If constraints on a variable can be inferred within the function based on the value provided by the immediate predecessor when it enters the basic block, then optimizations can be performed within the basic block. For example, if the fifth bit of 'b' in "a&b" is known to be '1' based on analysis of the predecessor block, then the LUT that executes the fifth bit of "a&b" can be optimized to output the value of 'a' (because for any x, x AND 1 = x).

[0011] In some scenarios, a variable output by a basic block is used as an input to one of its predecessors (e.g., in a for loop). In this case, the inferred constraints on the variable can be used to further optimize the predecessor block. This can allow cascading of optimizations, as new constraints implemented in the predecessor block can allow further optimization of the basic block, and so on.

[0012] Implementations of the technology disclosed herein can reduce SDC area, the number of pipeline stages, the number of registers used to pass data between pipeline stages, and the number of clock cycles used to execute a given computational expression. Other technical benefits not specifically identified herein can also be implemented by implementations of the disclosed technology.

[0013] It should be understood that the above subject matter can be implemented as a computer-controlled apparatus, a computer-implemented method, a computing device, or an article of manufacture such as a product of a computer-readable medium. These and various other features will be apparent by reading the following detailed description and viewing the associated drawings.

[0014] This Summary is provided to introduce in simplified form a brief description of some aspects of the disclosed technology that will be further described in the following Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended that this Summary be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all of the disadvantages mentioned in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is a computational architecture diagram illustrating aspects of a system disclosed herein for generating a synchronous digital circuit based on program source code including programming constructs mapped to the synchronous digital circuit;

[0016] Figure 2is a hardware architecture diagram showing aspects of an illustrative example synchronous digital circuit including several hardware pipelines, each having a plurality of pipeline stages, and computational units that may be defined and implemented using the disclosed techniques;

[0017] Figure 3 is a hardware architecture diagram showing the mapping of functions written in the disclosed language to hardware circuits;

[0018] Figure 4 is a block diagram showing how code is parsed into AST and converted into IR;

[0019] Figure 5 is a block diagram illustrating mapping an expression to an IR and optimizing the IR by merging lookup tables;

[0020] Figure 6 is a block diagram showing the mapping of more complex expressions to IR;

[0021] Figure 7 is a block diagram illustrating a basic block analysis of a variable including a loop formed by backward chaining;

[0022] Figure 8 is shown in the description reference Figure 1-7 A flow chart of a routine for describing aspects of the operation of the system for LUT optimization;

[0023] Fig. 9 is a computer architecture diagram showing an illustrative computer hardware and software architecture for a computing device that may implement aspects of the techniques presented herein; and

[0024] Fig.10 is a network diagram illustrating a distributed computing environment in which aspects of the disclosed technology may be implemented. DETAILED DESCRIPTION

[0025] The following specific embodiments are directed to high-level languages ​​and compilers that optimize the use of LUTs. As briefly discussed above, embodiments of the technology disclosed herein reduce SDC area, the number of pipeline stages, the number of registers used to pass data between pipeline stages, and the number of clock cycles used to execute a given computational expression. These technical advantages are implemented by reducing the number of LUTs, clock cycles, and registers used to execute a given function. Other technical benefits not specifically mentioned herein may also be implemented by embodiments of the disclosed subject matter.

[0026] Although the subject matter described herein is presented in the general context of an SDC executed on a personal computer, those skilled in the art will appreciate that other embodiments may be performed in conjunction with other types of computing systems and modules. Those skilled in the art will also appreciate that the subject matter described herein may be practiced using other computer system configurations, including handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, computing or processing systems embedded in devices (such as wearable computing devices, automobiles, home automation, etc.), minicomputers, mainframe computers, etc.

[0027] In the following detailed description, reference is made to the accompanying drawings which form a part hereof and which are shown by way of illustration of specific configurations or examples. Referring now to the drawings, in which like numerals represent like elements throughout the several views, aspects of lookup table optimization for a programming language targeting SDC will be described.

[0028] Figure 1 1 is a computational architecture diagram showing aspects of an illustrative system 100 disclosed herein for defining and generating a synchronous digital circuit ("SDC") 112 based on program source code 102 that includes programming constructs that map to the SDC 112. The SDC may be implemented by gate arrays, FPGAs, application specific integrated circuits ("ASICs"), and other types of circuit devices. Although the disclosed subject matter is primarily described in the context of an SDC 112 implemented in an FPGA, it should be understood that the techniques disclosed herein may be utilized to define an SDC 112 implemented using other types of devices.

[0029] like Figure 1 As shown, the illustrative system 100 includes a compiler 104 that compiles program source code 102 to generate hardware description language ("HDL") code or a low-level representation of a circuit (such as a netlist). As briefly discussed above, HDL is a modeling language used by hardware engineers to describe the structure and behavior of electronic circuits, most of which are typically digital logic circuits. Examples of HDLs include VHSIC HDL and VERILOG.

[0030] As will be described in detail below, the program source code 102 is expressed using a multithreaded imperative programming language designed to target the SDC 112. The disclosed language provides many features of languages ​​such as C and JAVA, such as function calls, for-loops, arithmetic operators, and conditional statements. However, the disclosed language includes constructs that map directly to the underlying SDC 112 hardware implementation. This enables both hardware and software engineers to reason about performance and be efficient in optimizing their designs. As described above, this can also make software engineers familiar with the language and save hardware engineers from dealing with various types of errors that occur when coding in HDL.

[0031] The disclosed multithreaded imperative programming language is imperative because program statements are executed one after another, and is multithreaded because multiple execution threads can be executed in parallel. As described above, a thread is a collection of local variables that are executed when a hardware circuit processes the local variables.

[0032] The threads described herein are similar to, but different from, software threads. While software threads maintain a call stack including local variables and execute code in memory, threads described herein are collections of local variables that are moved through hardware circuits. While software threads have locations in executable code determined by instruction pointers, the disclosed threads have physical locations on the SDC at a given point in time. An SDC can execute hundreds, thousands, or even millions of threads, and SDC execution can be pipelined, i.e., different threads can be executed simultaneously in different stages of the circuit.

[0033] As will be described in more detail below, language constructs may be defined in program source code 102 that is mapped to a circuit implementation. A language construct is a syntactically permitted portion of a program that may be formed from one or more lexical tokens. The language constructs described herein are mapped to a circuit implementation that guarantees thread ordering (i.e., threads will exit the circuit implementation in the same order that they entered).

[0034] As will be described in more detail below, the circuit implementation generated by the configuration disclosed herein can be implemented as an SDC in an FPGA, a gate array, an ASIC, or another type of suitable device. Another hardware component such as a NIC can be configured with an FPGA, a gate array, or an ASIC to implement the desired functionality.

[0035] like Figure 1As shown, a compiler 104 can compile a program source code 102 including one or more of the language constructs disclosed herein into a circuit description, in this example, HDL code 106. The HDL code 106 can be provided to an HDL synthesis tool 108, which in turn can generate a bitstream 110 that can be used to program an SDC 112, such as, for example, on an FPGA. When targeting an ASIC, the HDL code 106 can be provided to an ASIC manufacturer for production in a factory.

[0036] Figure 2 1 is a hardware architecture diagram showing aspects of an illustrative example SDC 112, which includes several hardware pipelines 200A-200C (or "pipelines") that can be defined and implemented using the disclosed techniques. Each hardware pipeline has a plurality of pipeline stages 206, and each pipeline stage 206 has a computation unit 208. Figure 2 As shown, program source code 102 may be compiled into pipeline 200A- 200C of hardware computing unit 208 .

[0037] The pipelines 200A-200C may be connected by a first-in-first-out ("FIFO") queue (also referred to herein as "multiple FIFOs" or "queues"). The pipelines 200A-200C implement the functionality defined by the program source code 102. The FIFO 202 stores data values, provides input to the pipelines 200, and stores output generated by the pipelines 200. For example, the SDC 112 includes a pipeline 200A that feeds its output to the FIFO 202A. The pipeline 200B in turn takes its input from the FIFO 202A and provides its output to the FIFO 202B. The pipeline 200C takes its input from the FIFO 202B.

[0038] In some configurations, pipeline 200 implements a policy circuit 210 that determines when to retrieve the next value(s) from FIFO 202. For example, policy circuit 210 may require that an input FIFO (e.g., FIFO 202A in the case of pipeline 200B) is not empty and an output FIFO (e.g., FIFO 202B) is not full before retrieving a value from the input FIFO (e.g., FIFO 202A) for processing.

[0039] like Figure 2As shown, pipeline 200 may be composed of one or more pipeline stages 206A-206B. Execution is pipelined by concurrently executing different threads in different stages 206 of pipeline 200. The results of a stage may be stored in register 204 and provided to the next stage 206 for the duration of the next clock cycle.

[0040] Each pipeline stage 206 may include one or more computational units 208B such as an adder 208A and a lookup table ("LUT") 208B. In the illustrated example, the adder 208A may perform basic operations such as addition, subtraction, and multiplication. The computational units may also implement Boolean operators (e.g., "OR," "NOR," "XOR," etc.) or other custom logic provided by the SDC manufacturer.

[0041] The computation unit may also be implemented by a user programmable lookup table 208B. The illustrated LUT 208B depicts a two-input truth table that maps two input bits to a single output bit. The LUT 208B may be configured to support different numbers of input bits. To generate more complex output values, such as characters or 8-bit integers, multiple LUTs 208B may be used, each connected to a different bit of the input variable.

[0042] The computational unit may temporarily store the result in a register 204 (or "flip-flop"). The contents of such a register may be provided to other computational units in the same or different pipelines 200. The register 204 may capture the value at the input when the connected digital clock transitions from 0 to 1, and provide that value at the output until the end of the next clock cycle (i.e., until the clock transitions from 0 to 1 again). The register may also include an enable line. If the enable line is set to false, the register will not perform the above operations, maintaining the current output value over multiple clock cycles.

[0043] It should be understood that for the purposes of this discussion, Figure 2 The pipeline architecture shown in has been simplified. The programming language constructs described herein can be utilized to implement a more complex SDC 112 having a plurality of Figure 2 More components shown.

[0044] Figure 3300 is a hardware architecture diagram illustrating aspects of one mechanism disclosed herein for mapping functions written in the disclosed language to hardware circuits, according to one embodiment. Program source code 302 includes a function 'f()' 304 written in the disclosed language. Function 'f()' 304 takes two parameters: 'x' 306 and 'y' 308 and returns an integer. Function 'f()' has two expressions: expression 310 performs an addition and stores the result in a local variable 'z', while expression 312 returns the result of a multiplication.

[0045] Function 'f()' 304 is mapped to hardware circuit 314, which includes computation units 316 and 318, registers 320 and 322. Hardware circuit 314 has two stages - a first stage 324 that performs the addition described in expression 310 and a second stage 326 that performs the multiplication described in expression 312. Each stage is executed in a single clock cycle, and the result of each stage is stored in a register.

[0046] Continuing with the example, stage 324 performs a "+1" operation on parameter 'x' 306, storing the result ('z') in register 322. During stage 324, parameter 'y' 308 is provided directly to register 320. During stage 326, computation unit 318 multiplies the values ​​of 'y' and 'z'. The result is stored in register 328.

[0047] Hardware circuit 314 may be executed by threads 330, of which only some are depicted. An SDC may execute hundreds, thousands, or millions of threads. As described above, a thread is a collection of local variables that are executed when local variables are processed by a hardware circuit. For example, thread 330A has a value 332 (x=1 and y=2), and thread 330A executes function 'f()' 304 when value 332 is processed by hardware circuit 314. The value returned by the function may be added to the set of local variables, and at any time, if it is known that a particular variable will no longer be used by the hardware circuit, the variable may be removed from the set of local variables.

[0048] SDC execution may be pipelined, i.e., different threads may be executed simultaneously within different stages of the circuit. Table 334 depicts variables from different threads at different stages as pipelined execution of hardware circuit 314 occurs. Column 336 shows values ​​stored between (i.e., before and after) stages: 336A includes values ​​of x and y provided by threads 330A, 330B, and 330C, while column 336B includes values ​​after stage 324 has been executed, and column 336C includes values ​​after stage 326 has been executed. Rows 338A-C show values ​​stored after consecutive clock cycles.

[0049] For example, row 338A indicates that thread 330A is about to enter hardware circuit 314 with value 332A (x=1 and y=2). Between rows 338A and 338B, a clock cycle occurs, and the result of executing thread 330A in stage 324 is depicted in 332B (y=2, the hold from 332A, and z=2, the result of the “+1” operation). At the same time, value 340A (x=3 and y=5) from thread 330B is about to enter hardware circuit 314. Between rows 338B and 338C, another clock cycle occurs, and the result of thread 330A executing stage 326 is depicted in 332C (“4”). At the same time, the result of thread 330B executing stage 324 is depicted in 340B (y=5 and z=4), and value 342 from thread 330C is about to enter hardware circuit 314 (x=7 and y=1). Pipelined Execution Pipelined execution enables higher throughput by increasing SDC utilization—that is, more SDCs are performing useful work at a given point in time than if only one thread could execute hardware circuit 305 at a time.

[0050] Figure 4 4 is a block diagram showing how code is parsed into an AST and converted into an IR. In some configurations, source code 402 is compiled into an AST 404 by a compiler 104. In this example, source code 402 includes three functions, 'f()', 'g()', 'h()', where 'f()' calls 'g()', and 'g()' calls 'h()'. AST 404 includes operator nodes, such as operator 406, and operands, such as operand 408. AST 404 can be used to generate IR 410, IR 410 having a function set 412, each function in function set 412 is divided into a basic block set 416, each basic block in basic block set 416 includes a sequence of computational units. For example, IR 414 implements function 'g()'.

[0051] Figure 5 5 is a block diagram illustrating mapping an expression to an IR and optimizing the IR by merging lookup tables. In some configurations, an expression 502 is mapped to an AST 508 by mapping each operator of the expression to an operator node and each operand of the expression to an operand node. While this example maps an expression to an AST, statements, code blocks, functions, or entire programs are similarly considered.

[0052] For example, '&' operator 504A is mapped to "AND" node 504B and '|' operator 506A is mapped to "OR" node 506B. In this example, the '&' operator is applied first, so operands 'A' and 'B' are mapped to operand nodes 510A and 510B, respectively. The result 'X' of the "AND" node 504B, together with the operand node 512 ('C'), is the operand of the "OR" node 506B.

[0053] Once the AST has been generated, it can be traversed to generate the IR 514. As described above, the IR can include a set of functions, each function of the set of functions includes a set of basic blocks, and each basic block of the set of basic blocks includes a sequence of computational units. The IR is used by the compiler 104 to optimize the generated code, both the new techniques disclosed herein and traditional techniques. These techniques can be applied iteratively, so that one optimization can enable another optimization that was not previously applicable.

[0054] In this example, both computation units 516 and 518 are part of basic block 514. Computation units 516 and 518 implement AND operator 504B and OR operator 506B, respectively. In some configurations, computation units 516 and 518 are replaced by LUTs 520 and 522, respectively, that perform corresponding operations.

[0055] The LUT is a truth table that maps each combination of binary input parameters to an output parameter. In LUT 520, column 524 represents the value of 'A', column 526 represents the value of 'B', and column 528 represents the value of 'A' AND 'B' (i.e., the result generated by the truth table for a given combination of input values). For example, if 'A=1' and 'B=0', which corresponds to the third row of LUT 520, the output value is 0. Similarly, LUT 522 has column 530 representing the value of 'X', column 532 representing the value of 'C', and column 534 representing the value of 'X' OR 'C'.

[0056] Once the operator nodes have been replaced by LUTs, the IR can be traversed to determine if any LUTs can be merged. In some configurations, LUTs can be merged if one LUT is an operand of another LUT and if the combined LUT requires fewer inputs than the maximum number allowed by the target device. In other configurations, the merging process produces a LUT that requires more inputs than the maximum number allowed by the target SDC. In this case, subsequent processing traverses the IR and decomposes the oversized LUT into two or more smaller LUTs.

[0057] For example, basic block 535 depicts LUT 536 - merging the results of LUT 520 and LUT 522. Rather than performing two operations, "AND" 504 followed by "OR" 506, LUT 536 performs the same function using a single operation taking three parameters, (the three parameters are column 538 ('A'), column 540 ('B'), and column 542 ('C')), producing a result in column 544.

[0058] Basic block 535 may then be used to generate SDC 546. Circuit 546 may include a computation unit 547 implemented by LUT 536. Computation unit 547 takes operands 510A, 510B, and 512 ('A', 'B', 'C' respectively) as input and stores the result in register 548.

[0059] Figure 6 is a block diagram showing the mapping of a more complex expression to an IR. In this embodiment, it is assumed that the target SDC has a three-bit LUT, indicating that each LUT can support no more than three parameters. This limitation is only an example of LUT capacity and is chosen to simplify the drawings and description. Higher and lower capacity LUTs are similarly considered.

[0060] Figure 6 Depicted is a code block 601 that calls a function 'foo()', which is depicted in code block 602. Code block 601 randomly generates a Boolean variable 'e' (i.e., the "rnd()" function randomly returns a value of '0' or '1'). Next, variable 'f' is set to "not 'e'", i.e., if 'e' is '1' then 'f' is set to '0'. Next, variable 'g' is set to "fxor e", which will always result in a value of '1'. In some embodiments, the compiler 104 analyzes the IR associated with code block 601 to make a determination that 'g' will always be '1'. Ultimately, code block 601 calls function 'foo()', passing in two random values ​​for parameters 'a' and 'b', a value of 'g' ('1') for parameter 'c', and a value of 'e' for parameter 'd'. Although some parts are omitted for clarity, each statement in function "foo()" is mapped to a computational unit, for example, "x=a&b" is mapped to computational unit 604A, "y=x|c" is mapped to computational unit 606A, and "return y xor d" is mapped to computational unit 608A.

[0061] The compiler 104 may then perform an optimization step 605, replacing the computational units 604B-608B with corresponding LUTs 604B-608B. The LUT applies an "AND" operator to 'a' and 'b', producing a value for 'x', the LUT 606B applies an "OR" operator to 'x' and 'c', producing a value for 'y', and the LUT 608B applies an "XOR" operator to 'y' and 'd'. Once the substitution is complete, the compiler 104 may iteratively perform optimizations, each of which may derive information about the LUTs (and other computational units, such as adders, multiplexers, etc.), input variables, and output variables that enable additional optimizations.

[0062] For example, compiler 104 can perform optimization 607 by merging LUTs 604A and 604B into LUT 604A, which performs "A&B|C" in a single lookup. This merge is possible because LUT 604B is an input to LUT 606B, and because the resulting LUT 610A does not require more than a maximum number of inputs (three in this example). LUT 608B is also not merged into LUT 610A because adding an additional parameter (i.e., "d") would cause the LUT for the target SDC to be too large (i.e., four inputs).

[0063] The compiler 104 may then apply one or more optimizations 609 based on knowing that parameter 'c' is '1'. As discussed above, this knowledge is based on an analysis of code block 601. To make this determination, the compiler must know that for a call to 'foo()', the value of 'c' is '1'. If code block 601 includes a single call to 'foo()', then the analysis is complete. If 'foo()' is called elsewhere, then the compiler 104 must be able to make similar determinations for the other call sites as well. Although Figure 6 The constraints on variables are described at the function level (i.e., the constraints are determined at the function boundary). The constraints on variables can also be analyzed at the basic block level, as shown below. Figure 7 discussed.

[0064] In some configurations, by knowing that 'c' is '1', the compiler can exclude input 'c' from LUT 610A by eliminating all rows of LUT 610A where 'c' is '0' (i.e., by removing the first, third, fifth, and seventh rows of LUT 610A). This leaves LUT 610B with two remaining inputs 'a' and 'b'. By eliminating input 'c', the compiler makes LUT 610B mergeable with another LUT.

[0065] The compiler 104 may also analyze the output of the LUT 610B to identify patterns that enable further optimization. For example, the compiler may determine that the output is constant - i.e., regardless of the values ​​of 'a' and 'b', the output is the same ('1'). When this determination is made, the optimization step 611 may replace the LUT 610 with a constant value '1' 612. Other patterns in the output of the merged LUT may be identified, such as a relationship to one of the remaining parameters. For example, the output may be equal to one of the inputs, in which case the LUT may be replaced with the input value (i.e., the register storing the input value). Similarly, the output may be the opposite of the input, in which case the LUT may be further reduced to a "NOT" operation applied to the input.

[0066] In some configurations, once the constant value of 'c' has been propagated and used to optimize LUT 610 to know that "y" always has the value '1', optimization 611 analyzes LUT 608B by splitting it into two halves, one of 'y' being '1' and the other of 'y' being '0'. Compiler 104 then determines that the return value (i.e., the result of LUT 608C) is always the opposite of the value of 'd' (i.e., the return value is "not 'd'" or "!d". Thus, optimization step 613 replaces LUT 612 and 608B with LUT 614, which implements "not 'd'".

[0067] Figure 6 Two circuit diagrams 616 and 629 are included, showing possible additional optimizations by combining input removal optimization (i.e., optimization steps 611 and 613) with LUT merging optimization. Circuit diagram 616 depicts how the circuit will be implemented after optimization step 607. Hardware circuit 616 is a pipeline circuit with two stages. The first stage performs an "&|" operation 620 (i.e., an "AND then OR" operation) on variables 'a', 'b', and 'c' 618. The result of the first stage is stored in register 622. During the first stage, variable "d" 624 is stored in register 626. Subsequently, the second stage performs an "XOR" operation 628 on the result of the "AND then OR" operation 620 and the variable "d".

[0068] However, circuit diagram 629 depicts the circuit resulting from the complete optimization process. Hardware circuit 629 has a single stage that applies the '! ' operator ("NOT" operator) to 'd' 630. One of ordinary skill will appreciate the significant reduction in SDC area, the reduction in the number of stages, and the potential removal of variables such as 'c' or 'y' from the IR. In addition, by removing input variables (i.e., by removing 'y' from LUT 608B), LUT capacity is freed up to perform additional merges. For example, if code block 602 does not return "y xor d", but includes additional statements, additional calculation operators can be merged into LUT 614.

[0069] Figure 7 is a block diagram showing basic block analysis of variables including loops formed by backward chaining ("backward chaining"). A basic block is a section of code that, once entered, has only one exit. Basic block analysis is used to identify constraints on variables, such as whether a variable 'c' is always '1', or whether "a XOR b" is always '0'.

[0070] In some configurations, the basic block analysis performs control flow analysis on the program source code 102. The analysis identifies basic blocks, such as basic blocks 702, 704, 710, 714, and 720. The analysis also determines when execution can pass from one basic block to another basic block. For example, execution can pass from basic block 702 to basic block 710, but not from basic block 710 to basic block 702, and not from basic block 702 to basic block 704.

[0071] In some configurations, basic block analysis then identifies constraints on a given variable by determining whether all predecessor blocks provide the same value to the given variable. One technique for identifying these constraints is constant propagation - the process of replacing known constant values ​​at compile time. However, other types of constraints can also be determined, including multi-variable constraints, where the constraint depends on the values ​​of two or more variables (e.g., 'A XOR B' is always 0). Other constraint detection techniques include common subexpression elimination (i.e., replacing repeated expressions with constant values) and dead store elimination (i.e., identifying variables that are assigned to but never used).

[0072] Constraint analysis may be performed for each bit of a multi-bit variable. For example, the analysis of block 702 may determine whether the value of 'C' 706 is subject to the constraint of "??? 1100", where '?' indicates that the value of the bit is unknown, '1' indicates that the value of the bit is always '1', and '0' indicates that the value of the bit is always '0'. Similarly, the analysis of block 704 may indicate that 'C' 708 is subject to the constraint of "??? 1111".

[0073] Thus, when execution is from block 702, the first two bits of 'C' (positions 0 and 1) are known to be '0', while the bits in positions two and three are known to be '1'. However, because 'C' may also be provided by basic block 704, in which case bits zero through three are '1', only the values ​​of positions two and three may be constrained to be a value ('1').

[0074] Basic block 710 is the beginning of a loop that provides additional opportunities for constraints on flow between basic blocks, enabling additional variables to be omitted from the LUT, which allows more operations to be merged. Preliminary analysis of basic block 710 may show that 'D' is subject to the "??110?" constraint 712. Basic block 714 may be analyzed under the given constraints, and it is determined that variable 'E' is subject to the "10101100" constraint. However, 'E' is also provided as an input to basic block 710 (e.g., as a loop counter), and therefore this constraint may be used to further analyze basic block 710. In some embodiments, for constraints 718 on 'D', "??110000" may be determined. This analysis may continue, as new constraints on 'D' may reveal additional constraints on additional variables.

[0075] Analysis may continue once the constraints converge to stable values ​​for the basic block 714. LUT optimization may be performed based on the constraints derived for the basic block.

[0076] Figure 8 is a flow chart of a routine 800 according to one embodiment disclosed herein, which illustrates a method for performing a Figure 1-7 It should be understood that the aspects of the system described herein with respect to LUT optimization of a programming language targeted by SDC are described above. Figure 7 The logical operations of the and other figures may be implemented (1) as a sequence of computer-implemented acts or program modules running on a computing device and / or (2) as interconnected machine logic circuits or circuit modules within a computing device.

[0077] The specific implementation of the technology disclosed herein is a matter of choice depending on the performance and other requirements of the computing device. Therefore, the logical operations described herein are referred to as states, operations, structural devices, actions or modules in different ways. These states, operations, structural devices, actions and modules can be implemented with hardware, software, firmware, special digital logic, and any combination thereof. It should be understood that more or less operations than those shown in the figure and described herein can be performed. These operations can also be performed in an order different from those described herein.

[0078] The routine 800 begins at operation 802, where a source code listing is received. In some configurations, the source code listing includes one or more expressions, such as one or more operators and associated operands, function calls and associated parameters, and the like.

[0079] Routine 800 continues at operation 804, where one or more expressions are parsed into an AST. The AST may include nodes for operators identified within the one or more expressions, and nodes for operands. Similarly, the AST may include nodes for function calls, and associated nodes for function parameters.

[0080] The routine 800 continues at operation 806 where the operator nodes in the AST are converted to IR.

[0081] Routine 800 continues at operation 808, where the operator in the IR is replaced by a LUT that performs the operation. For example, the '^' operator indicates a bitwise 'XOR', so the 'XOR' node may be associated with a LUT that performs the 'XOR' operation. Some operators may have two parameters, which are associated with a two parameter LUT. However, operators with any number of parameters are similarly considered.

[0082] The routine 800 continues at operation 810 where adjacent lookup tables are merged in the IR. In some configurations, lookup tables are considered adjacent when one lookup table is an operand of another lookup table. For example, in the expression "(A&B)|C", the '&' and '|' operators are adjacent because the '&' operator is an operand of the '|' operator.

[0083] Additional constraints may be applied to the merging. For example, when LUTs are merged, input values ​​provided to the individual LUTs will be routed to the merged LUT. Thus, LUTs will only be merged if the total number of parameters is less than the defined maximum number of LUT parameters for the targeted SDC.

[0084] Routine 800 continues at operation 812 where an execution pipeline is generated by placing the merged LUTs into a single pipeline stage. This can result in fewer pipeline stages being used to perform the same operation.

[0085] The routine 800 continues at operation 814 where the SDC is programmed based on the generated execution pipeline. After operation 814, the routine 800 continues to operation 816 where it ends.

[0086] Fig. 9 is a computer architecture diagram showing an illustrative computer hardware and software architecture for a computing device that can implement aspects of the techniques presented herein. Specifically, Fig. 9The architecture illustrated in the may be used to implement a server computer, a mobile phone, an e-reader, a smart phone, a desktop computer, an AR / VR device, a tablet computer, a laptop computer, or another type of computing device.

[0087] Fig. 9 The illustrated computer 900 includes a central processing unit 902 ("CPU"), system memory 904, including random access memory 906 ("RAM") and read-only memory 908 ("ROM"), and a system bus 910 that couples memory 904 to CPU 902. A basic input / output system ("BIOS" or "firmware"), including basic routines that help transfer information between components within the computer 900 (such as during startup), may be stored in ROM 908. The computer 900 also includes a mass storage device 912 for storing an operating system 922, application programs, and other types of programs. The mass storage device 912 may also be configured to store other types of programs and data.

[0088] The mass storage device 912 is connected to the CPU 902 through a mass storage controller (not shown) connected to the bus 910. The mass storage device 912 and its associated computer-readable media provide non-volatile memory for the computer 900. Although the description of computer-readable media included herein refers to a mass storage device, such as a hard disk, a CD-ROM drive, a DVD-ROM drive, or a USB memory key, it should be understood by those skilled in the art that computer-readable media can be any available computer storage media or communication media that can be accessed by the computer 900.

[0089] Communication media includes computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any delivery medium. The term "modulated data signal" refers to a signal that has one or more of its characteristics changed or set in some way to encode the information in the signal. By way of example and not limitation, communication media include wired media such as a wired network or a direct wired connection, and wireless media such as acoustic, radio frequency, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

[0090] By way of example and not limitation, computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. For example, computer storage media include, but are not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid-state memory technology, CD-ROM, digital versatile disks ("DVD"), HD-DVD, Blu-ray or other optical storage, cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by the computer 900. For purposes of the claims, the term "computer storage media" as used herein, and its corresponding variations, does not include waves or signals themselves or communications media.

[0091] According to various configurations, the computer 900 can operate in a networked environment using a logical connection to a remote computer via a network such as a network 920. The computer 900 can be connected to the network 920 via a network interface unit 916 connected to the bus 910. It should be understood that the network interface unit 916 can also be utilized to connect to other types of networks and remote computer systems. The computer 900 may also include an input / output controller 918 for receiving and processing input from a plurality of other devices, including a keyboard, a mouse, a touch input, an electronic stylus ( Fig. 9 Similarly, the input / output controller 918 can send data to a display screen or other type of output device (also not shown). Fig. 9 ) provides an output.

[0092] It should be understood that the software components described herein, when loaded into CPU 902 and executed, can transform CPU 902 and the entire computer 900 from a general-purpose computing device to a special-purpose computing device, which is customized to facilitate the functions presented herein. CPU 902 can be composed of any number of transistors or other discrete circuit elements, which can take any number of states individually or collectively. More specifically, in response to the executable instructions included in the software modules disclosed herein, CPU 902 can operate as a finite state machine. These computer executable instructions can transform CPU 902 by specifying how CPU 902 switches between states, thereby transforming the transistors or other discrete hardware elements that constitute CPU 902.

[0093] Encoding the software modules presented herein can also transform the physical structure of the computer-readable medium presented herein. In different embodiments of this specification, the specific transformation of the physical structure depends on various factors. Examples of these factors include, but are not limited to, the technology used to implement the computer-readable medium, whether the computer-readable medium is characterized as a main memory or an auxiliary memory, etc. For example, if the computer-readable medium is implemented as a semiconductor-based memory, the software disclosed herein can be encoded on the computer-readable medium by transforming the physical state of the semiconductor memory. For example, the software can transform the state of the transistors, capacitors or other discrete circuit elements that constitute the semiconductor memory. The software can also transform the physical state of these components in order to store data thereon.

[0094] As another example, the computer readable medium disclosed herein can be implemented using magnetic or optical technology. In this embodiment, when the software is encoded in a magnetic or optical medium, the software presented herein can transform the physical state of the magnetic or optical medium. These transformations can include changing the magnetic properties of a specific location in a given magnetic medium. These transformations can also include changing the physical characteristics or properties of a specific location in a given optical medium to change the optical properties of these locations. Without departing from the scope and spirit of this specification, other transformations of physical media are possible, and the aforementioned examples are provided only for the convenience of this discussion.

[0095] In view of the above, it should be understood that many types of physical transformations occur in the computer 900 in order to store and execute the software components presented herein. It should also be understood that Fig. 9 The architecture of the computer 900 shown, or a similar architecture, may be utilized to implement other types of computing devices, including handheld computers, video gaming devices, embedded computer systems, mobile devices such as smartphones, tablet computers, and AR / VR devices, and other types of computing devices known to those skilled in the art. It is also contemplated that the computer 900 may not include Fig. 9 All components shown may include Fig. 9 Other components not explicitly shown in the drawings may be used in conjunction with Fig. 9 Completely different architecture as shown.

[0096] Fig.10 1 is a network diagram illustrating a distributed network computing environment 1000 in which aspects of the disclosed technology may be implemented according to various embodiments presented herein. Fig.10As shown, one or more server computers 1000A can be interconnected with multiple client computing devices via a communication network 920 (which can be any one or a combination of a fixed line or wireless LAN, WAN, intranet, extranet, peer-to-peer network, virtual private network, Internet, Bluetooth communication network, dedicated low voltage communication network or other communication networks), these client computing devices, such as but not limited to, tablet computers 1000B, game controllers 1000C, smart watches 1000D, phones 1000E, such as smart phones, personal computers 1000F and AR / VR devices 1000G.

[0097] In a network environment where the communication network 920 is the Internet, for example, the server computer 1000A can be a dedicated server computer that is operable to process and transmit data to and from the client computing devices 1000B-1000G via any one of a number of known protocols, such as the Hypertext Transfer Protocol (“HTTP”), the File Transfer Protocol (“FTP”), or the Simple Object Access Protocol (“SOAP”). In addition, the networked computing environment 1000 can utilize various data security protocols, such as the Secure Sockets Layer (“SSL”) or the Pretty Good Privacy Protocol (“PGP”). Each of the client computing devices 1000B-1000G can be equipped with an operating system that is operable to support one or more computing applications or terminal sessions, such as a web browser ( Fig.10 ), or other graphical user interfaces ( Fig.10 ), or a mobile desktop environment ( Fig.10 ), to gain access to the server computer 1000A.

[0098] The server computer 1000A can be communicatively coupled to other computing environments ( Fig.10 ) and receives data about participating user interactions / resource networks. In illustrative operation, a user ( Fig.10 ) can interact with computing applications running on client computing devices 1000B-1000G to obtain required data and / or execute other computing applications.

[0099] Data and / or computing applications may be stored on one or more servers 1000A and communicated to collaborating users via client computing devices 1000B-1000G over the example communication network 920. Fig.10 1000A) can request access to specific data and applications that reside in whole or in part in the server computer 1000A. Such data can be transferred between the client computing devices 1000B-1000G and the server computer 1000A for processing and storage.

[0100] Server 1000A can host computing applications, processes and applets for data and application generation, authentication, encryption, communication, and can communicate with other server computing environments ( Fig.10 Not shown), third-party service providers ( Fig.10 (not shown), network attached storage ("NAS"), and storage area network ("SAN") work together to enable application / data processing.

[0101] It should be understood that Fig. 9 The computational architecture shown in Fig.10 The distributed network computing environment shown has been simplified for ease of discussion. It should be understood that the computing architecture and distributed network computing environment may include and utilize many more components, devices, software programs, network devices, and other components not specifically described herein.

[0102] The disclosure presented herein also includes the subject matter set forth in the following clauses:

[0103] Clause 1: A computer-implemented method executed on a computing device, comprising: receiving a source code listing including an expression; parsing the expression into an intermediate representation including computational units, the computational units mapping to operators in the expression; associating at least two computational units in the intermediate representation with a lookup table; merging the lookup tables in the intermediate representation into a merged lookup table; defining an execution pipeline by assigning the merged lookup table to stages in the execution pipeline; and programming a synchronous digital circuit based on the execution pipeline and the merged lookup table.

[0104] Clause 2: The computer-implemented method of clause 1, wherein merging adjacent lookup tables comprises merging a first lookup table and a second lookup table, and wherein for a given input, the merged lookup table generates the same output as the first lookup table and the second lookup table.

[0105] Clause 3: The computer-implemented method of any of Clauses 1 to 2, wherein adjacent lookup tables are iteratively combined until a defined maximum number of inputs in the combined lookup tables are used.

[0106] Clause 4: The computer-implemented method of any of Clauses 1 to 3, wherein the expression is analyzed on a bit-by-bit basis.

[0107] Clause 5: The computer-implemented method of any of Clauses 1 to 4, wherein bits of an expression are analyzed independently to identify constraints on variables in the expression.

[0108] Clause 6: The computer-implemented method of any of Clauses 1 to 5, wherein the constraint is determined by analyzing values ​​of variables provided by one or more predecessor basic blocks.

[0109] Clause 7: The computer-implemented method of any of Clauses 1 to 6, wherein the constraint indicates that the variable has a specific value for the expression.

[0110] Clause 8: The computer-implemented method of any of Clauses 1 to 7, wherein the merged lookup table has constrained variables as input parameters, and wherein the merged lookup table is modified to omit the variables.

[0111] Item 9: A computing device: one or more processors; and at least one computer storage medium having computer executable instructions stored thereon, which, when executed by the one or more processors, causes the computing device to: receive a source code listing comprising an expression; parse the expression into an intermediate representation comprising computational units, the computational units mapping to operators in the expression; associate at least two computational units in the intermediate representation with a lookup table; for each bit in the expression: merge adjacent lookup tables in the intermediate representation into a merged lookup table; define an execution pipeline by assigning the merged lookup tables to stages in the execution pipeline; and program a synchronous digital circuit based on the execution pipeline and the merged lookup tables.

[0112] Clause 10: The computing device of clause 9, wherein the adjacent lookup tables include a first lookup table and a second lookup table, and wherein the first lookup table is adjacent to the second lookup table when an output of the first lookup table is an input to the second lookup table.

[0113] Clause 11: The computing device of any of clauses 9 to 10, wherein bits of an expression are analyzed independently to identify constraints on variables in the expression.

[0114] Clause 12: The computing device of any of clauses 9 to 11, wherein the constraint is determined by subexpression elimination analysis, dead store elimination analysis, or constant propagation analysis of the expression.

[0115] Clause 13: A computing device according to any of clauses 9 to 12, wherein the source code listing is parsed to identify a cycle of a basic block including a plurality of basic blocks, the plurality of basic blocks including a cycle of a basic block associated with a loop, and wherein the constraint is determined by analyzing the value of the variable as the variable propagates through the cycle of the basic block.

[0116] Clause 14: The computing device of any of clauses 9 to 13, wherein merging adjacent lookup tables comprises merging a first lookup table and a second lookup table, and wherein for a given input, the merged lookup table generates the same output as the first lookup table and the second lookup table.

[0117] Item 15: At least one computer storage medium having computer executable instructions stored thereon, which when executed by one or more processors cause a common computing device to: receive a source code listing including an expression; parse the source code listing into an intermediate representation including computational units, the computational units mapping to operators in the expression; associate at least two computational units in the intermediate representation with a lookup table; for each bit in the expression: determine a constraint on a variable in the expression; merge adjacent lookup tables in the intermediate representation into a merged lookup table based in part on the constraint; define an execution pipeline by assigning the merged lookup table to a stage in the execution pipeline; and program a synchronous digital circuit based on the execution pipeline and the merged lookup table.

[0118] Clause 16: The at least one computer storage medium of clause 15, wherein adjacent lookup tables are iteratively combined and input parameters of the lookup tables are iteratively omitted until a defined maximum number of inputs in the combined lookup tables are used.

[0119] Clause 17: At least one computer storage medium of any of clauses 15 to 16, wherein each bit of the expression is analyzed independently to identify constraints on variables in the expression.

[0120] Clause 18: The at least one computer storage medium of any of clauses 15 to 17, wherein the constraint is determined by analyzing values ​​of variables provided by one or more predecessor basic blocks.

[0121] Clause 19: At least one computer storage medium according to any of clauses 15 to 18, wherein a constraint indicates that a variable has a specific value for an expression.

[0122] Clause 20: At least one computer storage medium according to any of clauses 15 to 19, wherein the lookup table has constrained variables as input parameters, the lookup table being modified to omit the variables.

[0123] Based on the foregoing, it should be understood that a system for LUT optimization of a programming language targeting SDC has been disclosed herein. Although the subject matter presented herein is described in a language specific to computer structural features, methods and transformation actions, specific computing machines, and computer-readable media, it should be understood that the subject matter set forth in the appended claims is not necessarily limited to the specific features, actions, or media described herein. Instead, these specific features, actions, and media are disclosed as example forms of implementing the claimed subject matter.

[0124] The above subject matter is provided by way of illustration only and should not be construed as limiting. Various modifications and changes may be made to the inventive subject matter described herein without following the illustrated and described example configurations and applications, and without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A computer-implemented method executed on a computing device, comprising: receiving a source code listing including an expression; parsing the expression into an intermediate representation comprising a first lookup table and a second lookup table, the first lookup table performing a first operator in the expression, the second lookup table performing a second operator in the expression; Merging the first lookup table and the second lookup table into a merged lookup table, wherein the merged lookup table executes the first operator and the second operator; defining an execution pipeline that implements the expression, wherein the execution pipeline includes a plurality of pipeline stages, wherein a pipeline stage of the plurality of pipeline stages receives an input value from a first register, performs an operation based in part on the input value and the merged lookup table, and provides an output value to a second register; as well as A synchronous digital circuit is programmed to implement the execution pipeline.

2. The computer-implemented method of claim 1 , wherein the first lookup table maps a first set of input variables to a first output variable, wherein the second lookup table maps a second set of input variables to a second output variable, wherein the second set of input variables includes the first output variable and wherein the merged lookup table maps at least some of the first and second sets of input variables to the second output variable.

3. The computer-implemented method of claim 1 , wherein the expression comprises additional lookup tables, and wherein the additional lookup tables are iteratively merged into the merged lookup table until a defined maximum number of inputs to the merged lookup table are used.

4. The computer-implemented method of claim 1 , wherein the expression comprises a lookup table input variable, the lookup table input variable comprising a plurality of bits, wherein a plurality of merged lookup tables are generated, each merged lookup table targeting one of the plurality of bits, the method further comprising: analyzing the expression to identify bits of the plurality of bits having constrained values: and The lookup table input variable is omitted from the merged lookup table associated with the constrained bits of the lookup table input variable.

5. The computer-implemented method of claim 1, wherein the expression is analyzed on a bit-by-bit basis to identify constraints on variables in the expression.

6. The computer-implemented method of claim 5, wherein the constraint is determined by analyzing values ​​of the variable provided by one or more predecessor basic blocks, each of the one or more predecessor basic blocks comprising a sequence of computational operations.

7. The computer-implemented method of claim 5, wherein the constraint indicates that the variable has a specific value for the expression.

8. The computer-implemented method of claim 7, wherein the merged lookup table has the constrained variables as input parameters, and wherein the merged lookup table is modified to omit the variables.

9. A computing device comprising: one or more processors; as well as at least one computer storage medium having computer executable instructions stored thereon, the computer executable instructions, when executed by the one or more processors, causing the computing device to: receiving a source code listing including an expression, the expression including a plurality of operators; parsing the expression into an intermediate representation comprising a lookup table, the lookup table implementing a corresponding operator of the plurality of operators in the expression; On a bit-by-bit basis: merging two or more lookup tables into a merged lookup table; defining an execution pipeline that implements the expression, wherein the execution pipeline includes a plurality of stages, wherein on a clock cycle, a pipeline stage of the plurality of stages receives an input value from a first register, performs an operation based in part on the input value and the merged lookup table, and provides an output value to a second register; as well as A synchronous digital circuit is programmed to implement the execution pipeline.

10. The computing device of claim 9, wherein the two or more lookup tables include a first lookup table and a second lookup table, and wherein the first lookup table is merged with the second lookup table when an output variable of the first lookup table is an input variable to the second lookup table.

11. The computing device of claim 9, wherein a lookup table is generated for each bit position of each operator, and wherein the instructions further cause the computing device to: identifying a constraint on a bit in a variable in the expression; and The variable is omitted from the merged lookup table associated with the bit position of the one bit of the variable.

12. The computing device of claim 11, wherein the constraint is determined by a subexpression elimination analysis, a dead store elimination analysis, or a constant propagation analysis of the expression.

13. The computing device of claim 11, wherein the source code listing is parsed to identify a cycle of a basic block including a plurality of basic blocks, the plurality of basic blocks including a cycle of a basic block associated with a loop, and wherein the constraint is determined by analyzing a value of the variable as the variable propagates through the cycle of the basic block.

14. The computing device of claim 11, wherein merging two or more lookup tables comprises merging a first lookup table and a second lookup table, and wherein for a given input, the merged lookup table generates the same output as the first lookup table and the second lookup table.

15. At least one computer storage medium having stored thereon computer executable instructions which, when executed by one or more processors, cause a common computing device to: receiving a source code listing including an expression; parsing the source code listing into an intermediate representation comprising lookup tables that implement operators found in the expression, wherein the lookup tables comprise a first lookup table, a second lookup table, a third lookup table, and a fourth lookup table; On a bit-by-bit basis: determining constraints on variables in the expression; Merging the first lookup table and the second lookup table into a first merged lookup table; based in part on the constraint, omitting from the first merged lookup table one or more bits of a first input value associated with the first lookup table; merging the third lookup table and the fourth lookup table into a second merged lookup table; defining an execution pipeline that implements the expression, wherein the execution pipeline includes a plurality of stages, wherein a first pipeline stage of the plurality of pipeline stages receives the first input value from a first register, performs a first operation based in part on the first input value and the first merged lookup table, and provides a first output value to a second register, and wherein a second pipeline stage of the plurality of pipeline stages receives the first output value from the second register as a second input value, performs a second operation based in part on the second input value and the second merged lookup table, and provides a second output value to a third register; as well as A synchronous digital circuit is programmed to implement the execution pipeline.

16. The at least one computer storage medium of claim 15, wherein additional lookup tables are iteratively merged with the first merged lookup table until a defined maximum number of inputs of the first merged lookup table are used.

17. The at least one computer storage medium of claim 15, wherein each bit of the expression is analyzed independently to identify constraints on variables in the expression.

18. The at least one computer storage medium of claim 15, wherein the constraint is determined by analyzing values ​​of the variable provided by one or more predecessor basic blocks.

19. The at least one computer storage medium of claim 15, wherein the constraint indicates that the variable has a specific value for the expression.

20. The at least one computer storage medium of claim 15, wherein a lookup table having the variables constrained as input parameters is modified to omit the variables.

Images