3 ms·

It's difficult for me to be sure, since the article makes it sound as if they're attempting something novel, but synthesis tools are standard in ASIC/FPGA desig

It's difficult for me to be sure, since the article makes it sound as if they're attempting something novel, but synthesis tools are standard in ASIC/FPGA design flows. Currently, the best synthesis tools are closed-source and extremely expensive. Imagine the benefit of having gcc/clang be free software. That is the kind of effect that is at stake here. Usually, hardware designers will write RTL code (Verilog/VHDL) which describes the hardware slightly above the gate level. In order to turn this description into a web of logic gates (called a netlist), the design is processed by a synthesizing program. The produced netlist describes exactly how many AND, NAND, OR, etc. gates are used and how they're connected, but it doesn't actually describe where the gates are placed on the chip or the route the interconnections take to connect the gates. To generate that info, the netlist is fed into another synthesis tool (usually called place and route). This is a simplified version, but even at this level of detail, there are important factors affecting chips. - How many gates? (less might be better) - How far are the gates from each other? (closer is better; less power, area, cost, timing) - How often will the gates switch? (less is better) - More.... More advanced synthesis tools improve area, cost, power, timing. They also allow designers to have less expertise and still obtain the same result as experienced designers by optimizing out micro-level inefficiencies in the design (though experienced designers will also lean on the synthesis tool).

civilitty 8y ago
To expand: compiling silicon isn't like compiling code even though it does use a hardware description language. Not only do all parts of your "code" all run at once, but you're also laying out physical transistors and mapping their connections. This is fundamentally an NP complete traveling salesman problem with an absurd exponential explosion of complexity - aka how do you route thousands or millions of connections that can't intersect on a 2D plane while still doing what the code describes. Oh and the fun part: unless you're careful, a change in a completely unrelated bit of code could break almost anything in the system by making it impossible to route connections without screwing up the timing of all the little bits. There is no type checker that can deduce whether your design will work or not and then output machine language. At the end of the day, with silicon you have to actually figure out whether your design can be physically manufactured by running a long compiler process and then testing it, often with rigorous simulations before moving to the fab process.

civilitty 8y ago

To expand: compiling silicon isn't like compiling code even though it does use a hardware description language. Not only do all parts of your "code" all run at once, but you're also laying out physical transistors and mapping their connections. This is fundamentally an NP complete traveling salesman problem with an absurd exponential explosion of complexity - aka how do you route thousands or millions of connections that can't intersect on a 2D plane while still doing what the code describes. Oh and the fun part: unless you're careful, a change in a completely unrelated bit of code could break almost anything in the system by making it impossible to route connections without screwing up the timing of all the little bits. There is no type checker that can deduce whether your design will work or not and then output machine language. At the end of the day, with silicon you have to actually figure out whether your design can be physically manufactured by running a long compiler process and then testing it, often with rigorous simulations before moving to the fab process.