4 ms·

Automated CPU Design with AI

95 points by skilled 3y ago

xeonmc 3y ago
Pentium FDIV bug, round two incoming.
- throwawaymaths 3y ago
  I believe this is placement, not circuit optimization or logic gate programming. Unless there's something creepy like line noise causing bugs or side effects piling up, something like the FDIV bug is unlikely.
  - thesz 3y ago
    The problem with FDIV is that function was not verified fully. AMD used ACL2 for complete symbolic verification of their FPU and discovered that their 50 million tests test suite still allowed for some bugs to pass. Here's the same problem - in their approach, a function is specified by some of input-output pairs and their algorithm discovers BDD representation of such function. These input-output pairs may be incomplete to specify function fully, giving the opportunity for something akin to FDIV bug.
brucethemoose2 3y ago
> The implemented program is executed on a Linux cluster including 68 servers, each of which is equipped with 2 Intel Xeon Gold 6230 CPUs. > We verify our output netlist on the FPGAs and tape out the chip with 65nm technology. The automatically designed CPU was sent to the manufacturer in December 2021.
granthamb 3y ago
It wasn't clear to me that they had implemented a page table (I think that's the S extensions?) which I would think would make the I/O space much more complex and difficult to represent. Lack of VA translation would make this CPU much less comparable to a 486SX.
- thesz 3y ago
  They implemented basic ISA. No virtual memory extensions were implemented. They compared performance of 80486 with their tapeout at 65nm (20 years of technology betterment). Judging from this, I suspect they may introduced long delays into some of the circuitry. They also "cleverly" avoided exponential blow up of any BDD representation by not implementing any multiplier or divider. Their ISA is RISC-V32IA, which does not include multipler.
behnamoh 3y ago
Wasn’t Google Tensor already designed by one of Google’s AIs? I remember it made a big deal because people thought Google could improve their chips much faster than the competition.
- rowanG077 3y ago
  That was just placement not abstract circuit design.
optimalsolver 3y ago
Could some really alien CPU architectures be discovered with this method? Just wondering how far from human design-space you could end up with this.
- ninkendo 3y ago
  Silicon validation is a huge part of the overall cost of bringing up a chip, because it’s so important that the physical hardware do what it’s supposed to do. So it’s gonna be limited to behaving exactly as the validation specifies, which likely will limit how “alien” it will actually be.
bsder 3y ago
I find this paper extremely suspicious. If this actually worked, it should be able to cough up a 6502, 6809, 8051, etc. as well since they are so much simpler--especially since they even mention a Commodore 64. The fact that they don't do this stinks very strongly. There are other concerning signs in the paper as well.
- staunton 3y ago
  Why should it produce those designs? Are they in any known sense optimal?
  - sitkack 3y ago
    I don't think any reviewer of the paper would ask why they didn't use one the processors mentioned. I think of lots of reasons to do it with a riscv * lots of excellent simulators and emulators * great tool chains * both software (Verilog, VHDL) implementations as well as hardware * regular, compact instruction set (no condition codes) Using anything besides RISC-V would have been an order of magnitude harder.
  - bsder 3y ago
    > Why should it produce those designs? Are they in any known sense optimal? Yes. 6502 was quite cheap for the day so is much more optimal for cost than most designs. The 6809 was done fixing the mistakes of the 6800 and it's implementation is much more orthogonal. The 6800 and 8051 are probably the best documented. All of them have extremely long lived tool chains and support. Pick your optimality. In addition, then "Why should it produce a RISC-V design?" RISC-V is definitely sub-optimal on quite a few fronts. If a system is doing actual CPU design, as claimed by the paper, those designs (6502, 6809, 8051) are a simple sanity check. The designs are extensively documented to the point that we have web pages that simulate them down to the transisitor. You should be able to provide a "relatively" small input and get back a compatible design as an output. A 6502 has only 3500 or so transistors. That's on the order of the complexity they claim in the paper. This would prevent someone like me from saying: "You basically stuffed a RISC-V design into the training set, managed to launder it through ML/AI to get the computer to cough it back up, then deployed a legion of humans to patch the result suffciently that it could be called "Linux compatible", and finally barfed out a publication with 6 pages of link references in a 12 page paper." Here's the touchstone for whether AI is doing chip design: "When AI can distinguish between control plane and datapath and synthesize and place them differently, AI is doing actual design."
amelius 3y ago
I didn't read the paper but judging from the abstract it's probably a technique for design space exploration. I.e., they manually designed the CPU but left a (large) number of parameters open, then used AI to find an optimum for those parameters. So anything the AI did was completely correctness-preserving. Note that this may sound like it's a small achievement, but keep in mind that for modern CPUs the search of the design space is hugely important, and probably the reason for the success of e.g. Apple's M1.
- brutusborn 3y ago
  If so, would there be any difference between this and existing EDA approaches? As I understood it, component placement and routing was already done somewhat automatically?
dooglius 3y ago
Doesn't seem to be any discussion of what the inputs and outputs actually are here, at least for the "coarse-grained" approach. Suspect there is some "scaffolding" around e.g. register map and memory access, and the rest is essentially learning a map from (instruction, register input vals)->(register output val, control registers for memory access)
- brutusborn 3y ago
  From Fig. 1, sounds like they test against a set of expected input/output pairs based on the ISA document. So I’m guessing the input is the ISA and predefined components like gates and connections, and the output is the location of those components and a set of connection routes.
westurner 3y ago
From the abstract; "Pushing the Limits of Machine Design: Automated CPU Design with AI" (2023) https://arxiv.org/abs/2306.12456 https://arxiv.org/abs/2306.12456 : > [...] This approach generates the circuit logic, which is represented by a graph structure called Binary Speculation Diagram (BSD), of the CPU design from only external input-output observations instead of formal program code. During the generation of BSD, Monte Carlo-based expansion and the distance of Boolean functions are used to guarantee accuracy and efficiency, respectively. By efficiently exploring a search space of unprecedented size 10^{10^{540}}, which is the largest one of all machine-designed objects to our best knowledge, and thus pushing the limits of machine design, our approach generates an industrial-scale RISC-V CPU within only 5 hours. The taped-out CPU successfully runs the Linux operating system and performs comparably against the human-designed Intel 80486SX CPU. In addition to learning the world's first CPU only from input-output observations, which may reform the semiconductor industry by significantly reducing the design cycle, our approach even autonomously discovers human knowledge of the von Neumann architecture. The von Neumann (and Mark) architectures have an instruction pipeline bottleneck maybe by design for serial debuggability; as compared with IDK in-RAM computing with existing RAM geometries? (See also: "Rowhammer for qubits") (Edit: High-Bandwidth Memory; hbm2e vs gddr6x (2023) https://en.wikipedia.org/wiki/High_Bandwidth_Memory https://en.wikipedia.org/wiki/High_Bandwidth_Memory ) Hopefully part of the fitness function is determined by the presence and severity of hardware side channels and electron tunneling; does it filter out candidate designs with side-channel vulnerabilities (that are presumed undetectable with TLA+)?
- westurner 3y ago
  And then maybe someday design reconfigurable - probably modular - semiconductor fabrication facilities and capabilities to produce the AI EDA chip design(s)?
calf 3y ago
The contribution of this paper is showing that given a hardware I/O test set, a Monte-Carlo type procedure can be used to iteratively construct a reasonably compact Boolean circuit representation (by manipulating BDDs). The toy example in the paper is an 8-bit adder. So given many examples of 8-bit addition, their procedure constructs a possible logic circuit for it. Then they still have to pass it onto standard logic synthesis tools. The RISC CPU example is the same, which means the resulting logic is not even a pipelined design. There are NO microarchitectural design optimizations (the authors propose this as future work, somehow). So given the C++ simulation I/O test traces of some CPU design, it is possible to extract a logic circuit for it, one that is not blowing up exponentially--mainly because the proposed algorithm is enough to separate a control and data path (ALU)--but yet it does not give any consideration to architectural optimizations like pipelining, caches, or anything else in the standard CPU architecture book by Patterson & Hennessy. The main point is that something like this could be used to bridge a design specification to an unoptimized logic function, so this is purely "functional" as opposed to architectural. It's a step but does not reflect the rather grandiose title of the paper.

95 points by skilled 3y ago

xeonmc 3y ago

Pentium FDIV bug, round two incoming.

throwawaymaths 3y ago
I believe this is placement, not circuit optimization or logic gate programming. Unless there's something creepy like line noise causing bugs or side effects piling up, something like the FDIV bug is unlikely.
- thesz 3y ago
  The problem with FDIV is that function was not verified fully. AMD used ACL2 for complete symbolic verification of their FPU and discovered that their 50 million tests test suite still allowed for some bugs to pass. Here's the same problem - in their approach, a function is specified by some of input-output pairs and their algorithm discovers BDD representation of such function. These input-output pairs may be incomplete to specify function fully, giving the opportunity for something akin to FDIV bug.

brucethemoose2 3y ago

> The implemented program is executed on a Linux cluster including 68 servers, each of which is equipped with 2 Intel Xeon Gold 6230 CPUs. > We verify our output netlist on the FPGAs and tape out the chip with 65nm technology. The automatically designed CPU was sent to the manufacturer in December 2021.

granthamb 3y ago

It wasn't clear to me that they had implemented a page table (I think that's the S extensions?) which I would think would make the I/O space much more complex and difficult to represent. Lack of VA translation would make this CPU much less comparable to a 486SX.

thesz 3y ago
They implemented basic ISA. No virtual memory extensions were implemented. They compared performance of 80486 with their tapeout at 65nm (20 years of technology betterment). Judging from this, I suspect they may introduced long delays into some of the circuitry. They also "cleverly" avoided exponential blow up of any BDD representation by not implementing any multiplier or divider. Their ISA is RISC-V32IA, which does not include multipler.

behnamoh 3y ago

Wasn’t Google Tensor already designed by one of Google’s AIs? I remember it made a big deal because people thought Google could improve their chips much faster than the competition.

rowanG077 3y ago
That was just placement not abstract circuit design.

optimalsolver 3y ago

Could some really alien CPU architectures be discovered with this method? Just wondering how far from human design-space you could end up with this.

ninkendo 3y ago
Silicon validation is a huge part of the overall cost of bringing up a chip, because it’s so important that the physical hardware do what it’s supposed to do. So it’s gonna be limited to behaving exactly as the validation specifies, which likely will limit how “alien” it will actually be.

bsder 3y ago

I find this paper extremely suspicious. If this actually worked, it should be able to cough up a 6502, 6809, 8051, etc. as well since they are so much simpler--especially since they even mention a Commodore 64. The fact that they don't do this stinks very strongly. There are other concerning signs in the paper as well.

staunton 3y ago
Why should it produce those designs? Are they in any known sense optimal?
- sitkack 3y ago
  I don't think any reviewer of the paper would ask why they didn't use one the processors mentioned. I think of lots of reasons to do it with a riscv * lots of excellent simulators and emulators * great tool chains * both software (Verilog, VHDL) implementations as well as hardware * regular, compact instruction set (no condition codes) Using anything besides RISC-V would have been an order of magnitude harder.
- bsder 3y ago
  > Why should it produce those designs? Are they in any known sense optimal? Yes. 6502 was quite cheap for the day so is much more optimal for cost than most designs. The 6809 was done fixing the mistakes of the 6800 and it's implementation is much more orthogonal. The 6800 and 8051 are probably the best documented. All of them have extremely long lived tool chains and support. Pick your optimality. In addition, then "Why should it produce a RISC-V design?" RISC-V is definitely sub-optimal on quite a few fronts. If a system is doing actual CPU design, as claimed by the paper, those designs (6502, 6809, 8051) are a simple sanity check. The designs are extensively documented to the point that we have web pages that simulate them down to the transisitor. You should be able to provide a "relatively" small input and get back a compatible design as an output. A 6502 has only 3500 or so transistors. That's on the order of the complexity they claim in the paper. This would prevent someone like me from saying: "You basically stuffed a RISC-V design into the training set, managed to launder it through ML/AI to get the computer to cough it back up, then deployed a legion of humans to patch the result suffciently that it could be called "Linux compatible", and finally barfed out a publication with 6 pages of link references in a 12 page paper." Here's the touchstone for whether AI is doing chip design: "When AI can distinguish between control plane and datapath and synthesize and place them differently, AI is doing actual design."

amelius 3y ago

I didn't read the paper but judging from the abstract it's probably a technique for design space exploration. I.e., they manually designed the CPU but left a (large) number of parameters open, then used AI to find an optimum for those parameters. So anything the AI did was completely correctness-preserving. Note that this may sound like it's a small achievement, but keep in mind that for modern CPUs the search of the design space is hugely important, and probably the reason for the success of e.g. Apple's M1.

brutusborn 3y ago
If so, would there be any difference between this and existing EDA approaches? As I understood it, component placement and routing was already done somewhat automatically?

dooglius 3y ago

Doesn't seem to be any discussion of what the inputs and outputs actually are here, at least for the "coarse-grained" approach. Suspect there is some "scaffolding" around e.g. register map and memory access, and the rest is essentially learning a map from (instruction, register input vals)->(register output val, control registers for memory access)

brutusborn 3y ago
From Fig. 1, sounds like they test against a set of expected input/output pairs based on the ISA document. So I’m guessing the input is the ISA and predefined components like gates and connections, and the output is the location of those components and a set of connection routes.

westurner 3y ago

From the abstract; "Pushing the Limits of Machine Design: Automated CPU Design with AI" (2023) https://arxiv.org/abs/2306.12456 https://arxiv.org/abs/2306.12456 : > [...] This approach generates the circuit logic, which is represented by a graph structure called Binary Speculation Diagram (BSD), of the CPU design from only external input-output observations instead of formal program code. During the generation of BSD, Monte Carlo-based expansion and the distance of Boolean functions are used to guarantee accuracy and efficiency, respectively. By efficiently exploring a search space of unprecedented size 10^{10^{540}}, which is the largest one of all machine-designed objects to our best knowledge, and thus pushing the limits of machine design, our approach generates an industrial-scale RISC-V CPU within only 5 hours. The taped-out CPU successfully runs the Linux operating system and performs comparably against the human-designed Intel 80486SX CPU. In addition to learning the world's first CPU only from input-output observations, which may reform the semiconductor industry by significantly reducing the design cycle, our approach even autonomously discovers human knowledge of the von Neumann architecture. The von Neumann (and Mark) architectures have an instruction pipeline bottleneck maybe by design for serial debuggability; as compared with IDK in-RAM computing with existing RAM geometries? (See also: "Rowhammer for qubits") (Edit: High-Bandwidth Memory; hbm2e vs gddr6x (2023) https://en.wikipedia.org/wiki/High_Bandwidth_Memory https://en.wikipedia.org/wiki/High_Bandwidth_Memory ) Hopefully part of the fitness function is determined by the presence and severity of hardware side channels and electron tunneling; does it filter out candidate designs with side-channel vulnerabilities (that are presumed undetectable with TLA+)?

westurner 3y ago
And then maybe someday design reconfigurable - probably modular - semiconductor fabrication facilities and capabilities to produce the AI EDA chip design(s)?

calf 3y ago

The contribution of this paper is showing that given a hardware I/O test set, a Monte-Carlo type procedure can be used to iteratively construct a reasonably compact Boolean circuit representation (by manipulating BDDs). The toy example in the paper is an 8-bit adder. So given many examples of 8-bit addition, their procedure constructs a possible logic circuit for it. Then they still have to pass it onto standard logic synthesis tools. The RISC CPU example is the same, which means the resulting logic is not even a pipelined design. There are NO microarchitectural design optimizations (the authors propose this as future work, somehow). So given the C++ simulation I/O test traces of some CPU design, it is possible to extract a logic circuit for it, one that is not blowing up exponentially--mainly because the proposed algorithm is enough to separate a control and data path (ALU)--but yet it does not give any consideration to architectural optimizations like pipelining, caches, or anything else in the standard CPU architecture book by Patterson & Hennessy. The main point is that something like this could be used to bridge a design specification to an unoptimized logic function, so this is purely "functional" as opposed to architectural. It's a step but does not reflect the rather grandiose title of the paper.