TechTechPotato
Keller argues instruction set architectures dictate negligible efficiency differences compared to physical dataflow structures, positioning simplified designs like RISC-V and modular matrix tiles to outpace legacy processors as AI workloads expand.
AI-assisted summary of [7] Jim Keller, Silicon Wizard 🧙♂️ — original source. Check the original for full context.
Source published:
Key ideas
- Jim Keller argues that instruction set architectures (ISAs) have minimal impact on peak processor performance, as six basic instructions dominate 80% of execution and suboptimal encodings introduce at most a 10% to 20% efficiency penalty. (19:44)
- Moore's Law is constrained by organizational misalignment between equipment toolmakers and fabricators rather than hard physics, with functioning semiconductor junctions theoretically viable down to approximately ten atoms across critical dimensions. (37:49)
- Modern computing has split into three distinct categories—CPUs, GPUs, and dedicated AI processors—driven by vastly differing requirements for branch prediction, memory latency, and dense matrix graph execution. (21:44)
- When turning around underperforming chip engineering teams, Keller advocates reorganizing existing internal talent rather than bringing in outside teams, pointing to AMD's Zen core turnaround which was executed predominantly by company veterans. (44:00)
Detailed notes
## Background This wide-ranging interview was published by Dr. Ian Cutress on the YouTube channel TechTechPotato on June 21, 2021. The discussion explores whether legendary silicon architect Jim Keller was truly the 'father of Zen,' covering his tenures across AMD, Intel, Apple, DEC, and Tesla, alongside his philosophies on engineering management, processor architectures, and the future of compute as CTO of Tenstorrent.
## TL;DR In this extensive conversation, Jim Keller demystifies his reputation as the 'father of Zen,' emphasizing that AMD's turnaround was driven by distributed collaboration, long-tenured internal engineers, and clean-slate organizational resets. He examines why instruction set differences between x86, Arm, and RISC-V matter far less than execution predictability and memory bottlenecks, arguing that modern compute is fracturing into CPUs, GPUs, and spatial AI hardware. Drawing on decades of leadership across DEC, Apple, Tesla, and Intel, Keller shares how he scales organizations by matching individuals to the right problems, removing political operators, and leveraging subconscious problem-solving. He remains bullish on Moore's law and discusses how future computing will evolve beyond traditional planar silicon toward photonics, biological assembly, and AI-designed black-box processors.
## Atmosphere & style The interview feels intimate, reflective, and intellectually invigorating, contrasting Dr. Ian Cutress's structured technical queries with Keller's candid, off-the-cuff storytelling. Keller speaks with the relaxed clarity of an experienced veteran who has seen repeated industry cycles, effortlessly weaving microarchitectural details together with references to Carl Jung, Shakespeare, and personal reflections on dyslexia. The dynamic carries an unpretentious, whiteboarding vibe where corporate posturing is stripped away in favor of pragmatic engineering realities and honest human psychology.
## Bulletin - [19:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1184s) Jim Keller argues that instruction set architectures (ISAs) have minimal impact on peak processor performance, as six basic instructions dominate 80% of execution and suboptimal encodings introduce at most a 10% to 20% efficiency penalty. - [37:49](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2269s) Moore's Law is constrained by organizational misalignment between equipment toolmakers and fabricators rather than hard physics, with functioning semiconductor junctions theoretically viable down to approximately ten atoms across critical dimensions. - [21:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1304s) Modern computing has split into three distinct categories—CPUs, GPUs, and dedicated AI processors—driven by vastly differing requirements for branch prediction, memory latency, and dense matrix graph execution. - [44:00](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2640s) When turning around underperforming chip engineering teams, Keller advocates reorganizing existing internal talent rather than bringing in outside teams, pointing to AMD's Zen core turnaround which was executed predominantly by company veterans.
## Key takeaways - [00:32](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=32s) Keller joined AMD in an operational VP role rather than as an advisory architect to directly align microarchitectural direction with team execution, establishing the foundation for Zen. - [05:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=316s) Keller dismisses the sole 'Father of Zen' title, crediting a distributed team across Austin, Fort Collins, Sunnyvale, Boston, and India with the core and SoC development. - [07:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=436s) Architectural rewrites rarely start completely from zero code; they generally retain or adapt 20% to 80% of RTL while restructuring bottlenecks, layouts, and dataflow pipelines. - [18:24](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1104s) Engineering team sizes remain capped around 150 contributors due to flat human cognitive capacity, requiring electronic design automation (EDA) and abstraction layers to absorb scale. - [19:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1184s) Branch prediction tables, instruction boundary predictors, and cache structures consume vastly more silicon area in modern out-of-order CPUs than decode logic, making x86 decoding overhead negligible. - [26:48](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1608s) RISC-V currently offers the cleanest and fastest target for clean-slate computer design due to its absence of legacy commercial instructions and architectural cruft. - [25:47](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1547s) Dedicated AI processors must combine matrix math with integrated general-purpose vector and scalar cores on the same silicon fabric to eliminate off-chip PCIe data transfer bottlenecks. - [37:49](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2269s) Semiconductor manufacturing pacing relies heavily on equipment suppliers like ASML and Applied Materials, whose technological innovations outpace individual fabrication companies. - [49:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2977s) Early career engineers develop fastest by committing deeply to solving hard problems under superior leadership rather than rapidly switching groups to pursue superficial breadth. - [54:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3277s) Organizational leadership and team debugging are better informed by classical literature, Carl Jung, and Machiavelli than conventional business management books. - [01:17:21](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4641s) Conscientious, introverted engineers often need to deliberately learn self-promotion and extroverted communication to secure resources for ambitious technical architectures. - [01:26:14](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5174s) Software-enforced security boundaries inevitably fail as code expands, making hardware-enforced isolation essential against side-channel and hypervisor vulnerabilities. - [01:33:47](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5627s) Future computing paradigms will likely move past planar silicon lithography into photonics, biological molecular assembly, and quantum neutral-atom arrays designed via AI systems.
## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=0s) Jim Keller's Role and Responsibilities at AMD
Ian Cutress introduces the second installment of his interview series with Jim Keller, who is serving as the CTO of AI startup Tenstorrent. While reciting Keller’s storied career spanning DEC, Apple, AMD, Intel, Broadcom, SiByte, and Tesla, Keller immediately chimes in with a quick correction: “I worked at AMD twice.”
Cutress dives directly into Keller's second stint at AMD, noting that much of the public associates him with Zen, the Project SkyBridge initiative, and AMD’s resurgence against Intel. Cutress asks Keller to clarify the rampant community confusion regarding his actual day-to-day contributions: was he in the trenches nailing down the microarchitecture for Zen, Zen 2, and Zen 3, or was he an executive setting up teams, signing off on architectural targets, and concentrating on the Arm counterpart (K12) and Infinity Fabric?
Keller sets the scene at the time he rejoined AMD. The company was relying on Bulldozer and Jaguar. Although both had interesting elements, neither achieved market success, roadmaps were not sufficiently aggressive, and AMD was falling further behind Intel. He points out that when already trailing a competitor, “you better be catching up, not falling behind.” He initially took charge as vice president of the CPU team, which was roughly 500 people. Over the subsequent three years, his organization expanded to include the SoC team, the fabric team, and several IP groups, swelling to roughly 2,400 to 2,500 people with a staff of around 15 senior directors and senior fellows.
Because of the scale of the role, Keller was not personally writing RTL. Though he views himself primarily as a computer architect rather than a corporate manager, he deliberately wanted that management seat:
> “I knew that the technical changes we had to make would be involved in getting people aligned to it, and I didn't want to be the architect on the side arguing with the VP about why somebody could or couldn't do the job or why this was the right or wrong decision.”
He pitched this premise to AMD Chief Technology Officer Mark Papermaster, who agreed to give it a try. Keller emphasizes that having executive authority alone does not solve the problem, because “people don't really do what they're told to do, right? They're do—they do what they're inspired to do.” His mandate was assessing who could execute the vision, breaking the habit of people clinging to their past work, and combating the assumption that things could not be fundamentally redesigned. Keller entered with the premise that conditions were severe enough that nearly everything required an overhaul, effectively flipping the burden of proof: instead of proving why a new idea was good, teams had to prove why an old implementation was worth keeping.
While he wasn't personally drawing every block diagram or generating RTL, he guided the architectural vision alongside key technical talent—such as Mike Clark, Leslie Barnes, Jay Fleischman, and Debjit Das Sarma. The effort spanned Zen, its Arm sibling, follow-on integration, a revamped SoC methodology, and systemic IP refactoring.
```mermaid flowchart TD accTitle: Keller's Multi-Team Organization at AMD accDescr: Diagram showing Jim Keller leading multiple distributed teams across the Zen CPU and SoC roadmap.
subgraph Leadership["Executive Architectural Leadership"] JK["Jim Keller<br/>(VP / Chief Nudge)"] MP["Mark Papermaster<br/>(CTO)"] JK <-->|"Alignment & Strategy"| MP end
subgraph OrgTeams["Distributed Engineering Teams"] direction TB Austin["Austin Team<br/>Core Execution & Front End<br/>(Mike Clark, Steve Hale, Suzanne)"] Colorado["Colorado Team<br/>Floating Point & Cache"] Sunnyvale["Sunnyvale Team<br/>Arm Front End / K12"] Boston["Boston Team (Harry Fair)<br/>Excavator Finishing & Physical Design"] SoC["SoC & Fabric Teams (Austin & India)<br/>SoC 15 & Infinity Fabric"] end
JK --> Austin JK --> Colorado JK --> Sunnyvale JK --> Boston JK --> SoC ```
[05:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=316s) The "Father of Zen" Moniker and Distributed Engineering
Cutress asks Keller whether he accepts the widely used title "Father of Zen," or if that honor belongs elsewhere. Keller deflects the label, joking about being “one of the uncles” instead, and points out:
> “Success has a lot of authors, failure has one, so that was the success.”
He explains that Zen was a massive collaboration among distributed teams across the world: - The core execution engine and front end were driven in Austin by engineers including Mike Clark, Steve Hale, and Suzanne. - The floating-point unit and cache hierarchy were built by the team in Fort Collins, Colorado. - The Arm front end for the paired K12 project was centered in Sunnyvale. - The SoC design was split between Austin and India, supported by a global design methodology team. - Crucial organizational moves occurred simultaneously, such as handing off Excavator to Harry Fair’s Boston group to complete its design and physical implementation, freeing up core teams to focus on Zen.
Rather than claiming solitary authorship, Keller describes his function as “the instigator and the chief nudge, and you know, part architect, part, you know, it's a transformational leader.”
[07:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=436s) Roadmap Longevity and Architectural Rewrites
Cutress asks if the pipeline of designs Keller influenced is fully out in the wild, or if remnants of his five-year roadmap are still emerging. Keller explains that building an entirely new architecture—paired with "SoC 15," the internal design effort that created the fabric and interconnect—inherently means laying out a multi-generation runway. He compares it to his earlier work at Apple: when creating a clean-slate core, you must build “big bones.”
When seeking CPU speedups, Keller observes there are fundamentally only two levers: expanding the primary underlying structures or tweaking specific microarchitectural features. Zen established wide structural bones, leaving a straightforward list of architectural performance enhancements planned out over multiple consecutive years.
Cutress brings up that AMD described Zen 3 as a complete ground-up rewrite, asking if that reflects Keller's original plans. Keller demystifies what chip teams mean by "rewrites." Even on a clean-slate top-level project like the original Zen, engineers deliberately port over functional RTL blocks from previous designs like Bulldozer and Jaguar, adapting them to fit the new top-level framework:
> “Hardware guys are super good at using code when it suits them, and so when they say they did a big rewrite, you know, they probably took some pieces and, you know, re-architected them at the top, but when they built the code, you know, it wouldn't surprise me somewhere between 20 and 80 percent of the code was the same stuff or mildly modified.”
Keller notes that true architectural rewrites are about correcting structural layout and dataflow bottlenecks rather than throwing away every line of RTL: “The key is to get the structure right and then reuse code as needed as opposed to taking something that's complicated and trying to tweak it to get somewhere.”
[09:52](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=592s) Career Longevity: Is Tenstorrent a "Forever Home"?
Cutress notes that Keller has continually moved between prominent companies across his career—including DEC, AMD, Apple, Tesla, Intel, and now Tenstorrent alongside his former colleague Ljubisa Bajic—and asks bluntly whether Tenstorrent is destined to be his "forever home."
Keller pushes back on the characterization that he has always been a nomad. He points out that he spent 15 years at Digital Equipment Corporation (DEC). That tenure encompassed two distinct engineering eras: - Designing refrigerator-sized minicomputers using emitter-coupled logic (ECL) within DEC’s mid-range systems division. - Transitioning to the Alpha microprocessor group, building what were then considered monstrously large chips—300 mm² silicon consuming 50 watts, a power budget that shocked the industry at the time.
After DEC, Keller joined AMD for his first tour of duty during the late-1990s dot-com boom. That fast-paced period produced the K7/Athlon, the K8/Opteron, 64-bit x86 extensions (AMD64), HyperTransport, and dual-socket multiprocessor server topologies, kicking off the cycle of building transformative technologies in intense multi-year bursts.
[11:04](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=664s) Career Transitions: SiByte, P.A. Semi, Apple, Tesla, and Joining Tenstorrent
Jim Keller traces the path of his career across the semiconductor industry, noting that although observers often view him as someone who jumps frequently between companies, his stints have often involved substantial longevity and clear deliverables. During the late 1990s internet boom, he joined SiByte, which was later acquired by Broadcom; across four years there, his group shipped several generations of products. He subsequently moved to P.A. Semi to build low-power PowerPC architectures, but the company shifted focus away from selling its product standalone with an eye toward being acquired by Apple. Keller moved to Apple directly, and when Apple bought P.A. Semi soon after, he integrated with those teams. Between P.A. Semi and Apple, he spent seven continuous years developing Apple's custom silicon foundations.
```mermaid flowchart LR accTitle: Jim Keller Career Trajectory accDescr: Sequence of Jim Keller's key roles across major semiconductor and tech firms. subgraph Early["Foundational Systems"] SB["SiByte / Broadcom<br/>(4 Years)"] --> PA["P.A. Semi"] PA --> AP["Apple<br/>(7 Years combined)"] end subgraph Growth["Architectural Revolutions"] AP --> AMD["AMD<br/>(Zen Architecture)"] AMD --> TS["Tesla<br/>(Hardware 3 / FSD)"] TS --> IN["Intel<br/>(Silicon Eng. Group)"] end subgraph Startup["Next-Gen Compute"] IN --> TT["Tenstorrent<br/>(CTO & President)"] end ```
After Apple, Keller returned to AMD, where he spearheaded the architecture teams before jumping to Tesla. At Tesla, his team delivered the Hardware 3 (Full Self-Driving) computer from scratch:
> “Standing start to driving the car in 18 months, I don’t think that’s ever been done before.”
Tesla manufactured roughly one million of those custom processors the prior year. Addressing his mindset as an engineer and executive, Keller acknowledges his specific operational strengths:
> “I like either a clean piece of paper or a complete disaster, you know, that seems to be the things I do best at. It's good to know yourself; I'm not an operational manager.”
Now serving as CTO and President of AI processor startup Tenstorrent, Keller emphasizes that he has significant personal financial equity and deep professional commitment to his colleagues there, viewing it as a long-term venture aimed at capitalizing on explosive machine-learning compute workloads.
- SiByte: 4 years through Broadcom acquisition; delivered multiple product generations. - P.A. Semi / Apple: Combined 7 years developing custom silicon architectures. - Tesla Hardware 3: Designed and deployed from scratch to production vehicle testing in 18 months; over 1,000,000 units manufactured in the past year. - Tenstorrent: Keller holds major equity and leadership roles (CTO and President) with an explicit commitment to stay long-term.
---
[13:21](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=801s) Restructuring Silicon Engineering at Intel
Reflecting on his tenure at Intel, Keller describes the sheer scale of the Silicon Engineering Group, which encompassed roughly 10,000 engineers and dozens of concurrent system-on-chip (SoC) developments:
> “The team was 10,000 people... It was something like 60 or 70 SoCs in flight at time, literally from, you know, design to, you know, prototyping, debugging, and production.”
While Keller originally believed he was joining Intel purely to architect novel computing technologies, he ended up devoting the bulk of his energy to deep organizational and CAD methodology transformations. Intel had traditionally succeeded by building massive monolithic client and server processors. A few years prior to his arrival, the company had begun transitioning toward a modern "SoC IP" design reuse strategy, but the shift was faltering. Keller observed that simply taking monolithic heritage designs and chopping them up into modular IP blocks failed because reusable IP requires fundamentally different design collateral, qualification libraries, process technology characterizations, and automated tooling.
Managing that scale meant Keller operated almost entirely through vice presidents and senior fellows, juggling up to 14 discrete meetings a day. When Ian Cutress jokingly asks how he got anything done under such a schedule, Keller clarifies what senior executive leadership actually entails:
> “I don't get anything done; like I told you, I was the Senior Vice President... The key thing about getting somewhere is knowing where you're going and then put an organization in place that knows how to do that.”
He spent his time setting direction, making critical architectural judgment calls, and steering personnel adjustments rather than coding directly, quipping that while he wrote little source code, he sent thousands of text messages to keep execution aligned.
---
[15:57](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=957s) Assessing Intel Leadership and Career Longevity
When asked whether he would ever return to Intel now that veteran engineer Pat Gelsinger has taken over as CEO, Keller remains noncommittal, explaining that he is fully committed to his work in the rapidly expanding AI hardware sector. Nevertheless, he speaks highly of Gelsinger's technical heritage:
> “He definitely cares a lot about Intel and he's had real success in the past, so he's definitely going to bring a lot more technical focus to the company.”
At the same time, Keller pushes back against common external narratives by noting that he genuinely enjoyed working alongside former Intel CEO Bob Swan.
Pondering whether decades of pivoting between high-performance computing, low-power mobile architectures, and AI accelerators ever gets boring, Keller explains that the core challenge remains perpetually fresh even if the physics of computation never changes:
> “Computers at the bottom, they just, you know, you add ones and zeros together... It’s not that complicated, but... the building block shifted from, you know, 200 gates to four teraflops, so that’s kind of a wild transformation.”
On the DEC VAX 8800 early in his career, systems were built from gate arrays packing a mere 200 logic gates per chip. By contrast, Tenstorrent's Tensix processor cores each deliver four trillion operations per second (4 TOPs), arrayed across more than 100 cores per die. Keller notes that while the raw scale and automated electronic design tooling evolved exponentially, human cognitive capacity evolved not at all.
---
[18:24](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1104s) Organizational Scaling: The Limit of Human Bandwidth
Discussing whether modern engineers require greater interpersonal and soft skills to navigate modern multi-layered technology stacks, Keller rejects the premise that individuals can simply shoulder broader multidisciplinary burdens through personal effort alone:
> “Here’s the fundamental truth: people aren’t getting any smarter, right? So people can’t work across more things, that’s just dumb. Right, you do have to build tools and organizations that support people's ability to do complicated things.”
To illustrate this constraint, Keller highlights that the DEC VAX 8800 design team had approximately 150 engineers. Decades later, the Apple engineering team that built the foundational Hurricane custom processor core consisted of almost the exact same head count: about 150 people. The productivity difference did not stem from wider individual communication nets, but from modern design automation: - Placement and routing tools went from handling 200 gates to over 2,000,000 gates automatically. - Simulation farms scaled from single machines to thousands of compute nodes running concurrent regressions. - The social bandwidth of individual contributors remained completely flat.
Keller observes that an engineer required to communicate deeply with more than five people in a single working day will quickly lose focus and effectiveness. True scaling, therefore, depends on constructing clear organizational abstraction boundaries rather than forcing individual engineers to multitask across wider human and technical surface areas.
---
[19:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1184s) The Reality of Instruction Sets: x86 vs. Arm vs. RISC-V
Addressing the persistent industry debate over instruction set architectures (ISAs)—specifically x86 versus Arm versus RISC-V—Keller dispels the belief that the ISA fundamentally dictates modern high-performance processor performance. In practice, code execution is overwhelmingly dominated by a tiny handful of foundational primitives:
> “Eighty percent of the execution is like six instructions: load, store, add, subtract, compare, and branch. You pretty much covered it.”
```mermaid flowchart TD accTitle: Execution Breakdown and Predictor Dominance accDescr: Illustration showing how six instructions dominate execution and branch prediction dominates die area. subgraph Operations["Execution Profile (~80% of Workloads)"] direction LR I1["Load / Store"] I2["Add / Subtract"] I3["Compare / Branch"] end subgraph Hardware["Die Area Allocation"] direction LR P["Predictors & Branch Tables<br/>(Determines limits of modern IPC)"] D["Decoder ROM & Logic<br/>(Historically ~33-50%, now negligible)"] end Operations -.->|"Governed by"| P ```
While suboptimal instruction encodings can cost an architecture 10% to 20% in raw efficiency, modern microarchitectural techniques have largely neutralized the traditional penalties of variable-length instructions like x86. Historically, variable-length x86 code was notoriously complex to decode compared to clean, fixed-length RISC formats. In modern super-pipelined out-of-order processors, however, designs rely on dense branch target and instruction-boundary prediction tables to map instruction locations in advance: - **Historical Silicon Distribution**: Early RISC implementations held a significant edge because early x86 chips devoted 30% to 50% of their total die area to microcode ROM. - **Modern Silicon Distribution**: On modern nanometer process nodes, instruction decoders, adder circuits, and microcode ROMs are minuscule features on the die. - **Fixed vs. Variable Length**: Fixed-length instructions remain beneficial for tiny low-power microcontroller designs, but in large high-performance cores, branch predictors and predecode hardware comfortably dwarf decode logic overhead.
Keller concludes that the primary barrier limiting modern computer performance is predictability—especially branch prediction and cache predictability—rather than the surface-level mechanics of the instruction set syntax itself.
[21:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1304s) Predictors, Adders, and Three Kinds of Computers: CPU, GPU, and AI
Jim Keller explains how modern CPU design has shifted its transistor budget toward prediction. Modern chips rely heavily on instruction predictability, branch predictability, and data locality. Because modern branch predictors must anticipate complex program behavior, they have grown dramatically in size—to the point where the predictors are significantly larger than the execution adders themselves. This creates a fundamental contrast between CPUs, GPUs, and specialized AI hardware:
```mermaid flowchart TD accTitle: Comparison of Three Compute Paradigms accDescr: Diagram illustrating differences in workload handling between CPUs, GPUs, and AI engines.
subgraph CPU["CPU (Complex Control & C Programs)"] C1["Large Predictors & Caches"] --> C2["Few Threads, Complex Logic"] C2 --> C3["Optimized for Serial Code & Branches"] end
subgraph GPU["GPU (Massive Fine-Grained Parallelism)"] G1["Thousands of Simple Threads (~6,000)"] --> G2["Massive Array of Adders/ALUs"] G2 --> G3["'Army of Ants' Processing 8M Pixels"] end
subgraph AI["AI Engine (Coarse Matrix & Graph Compute)"] A1["Fewer Threads, Massive Multipliers"] --> A2["Spatial Mesh of ~4 TOPS Tiles"] A2 --> A3["Optimized for Dataflow & Large Math"] end ```
GPU advocates often point out that their chips eliminate branch predictors in favor of raw compute, packing in vastly more adders and subtractors because they execute workloads in parallel. Keller notes that while this trade-off makes sense for parallel graphics pipelines, GPUs struggle at running standard C programs. GPUs were architected to execute shader programs over millions of pixels—a modern GPU might manage 6,000 threads executing thousands of instructions per frame across 8 million pixels, behaving like “an army of ants carrying around grains of sand.”
In contrast, dedicated AI supercomputers tackle problems that are inherently large rather than composed of tiny individual pixel tasks. They feature massive matrix multipliers and a much smaller number of threads executing large volumes of math. Keller emphasizes that the industry has split into three distinct categories of machines: CPUs, GPUs, and AI processors. While Nvidia attempts to straddle the middle ground by enhancing GPUs for AI workloads—achieving undeniable success despite considerable architectural complexity—this mirrors historical patterns where general-purpose CPUs added vector extensions to handle small vector tasks while leaving heavy workloads to dedicated GPUs.
As Jim Keller summarizes: > “So there's genuinely three different kinds of computers: CPUs, GPUs, and AI.”
---
[23:42](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1422s) Graph Computing and Sizing the AI Engine: The Tenstorrent Architecture
Ian Cutress brings up Keller’s prior comments that moving beyond simple matrix multiplication requires mapping out massive graph structures, which is central to Tenstorrent’s design as a graph compiler and compute engine. Keller frames this progression through the evolution of hardware math capabilities alongside transistor budgets:
* **Scalar math** ($A = B + C \times D$): The baseline era when transistor counts were severely limited. * **Vector math**: Transistor growth allowed an entire equation or vector lane to execute in a single operational step. * **Matrix math**: Further transistor density enabled hardware matrix multipliers. * **Spatial / Graph compute**: Deconstructing massive operations across distributed processing blocks.
Keller cautions that hardware efficiency collapses if a matrix multiplier becomes too large, because the energy cost of moving data across an oversized execution unit wastes immense amounts of power. The goal is to identify an optimal block size—neither as tiny as an individual GPU thread nor so massive that a single matrix engine monopolizes the entire die. Tenstorrent targets medium-sized processing blocks rated around 4 TOPS (tera-operations per second), a figure Keller humorously recalls used to represent supercomputing scale.
Because an AI workload is structured as a graph of massive mathematical operations that decompose into subgraphs, the architecture maps these operations across an array of distributed 4 TOPS processors, allowing data to flow directly between them across the silicon. Keller notes that while he and his colleague Raja Koduri used to refer to this paradigm as "spatial" compute, "graph" is a more precise description.
---
[25:47](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1547s) Tightly Coupling Vector Engines and General-Purpose Compute
Addressing Cutress's query about Tenstorrent integrating vector units and general-purpose processor cores into next-generation graph processing nodes, Keller confirms that AI pipelines cannot survive on pure matrix math alone. In real-world AI pipelines, workloads frequently need general-purpose processing or require running a C program directly on intermediate results output by an AI layer.
Integrating general-purpose CPU cores with vector units directly onto the same silicon fabric drastically minimizes transfer latency and keeps power consumption reasonable compared to round-tripping data across PCIe buses to a host CPU. Keller highlights that balancing this hybrid partition remains one of the most active frontiers in computer architecture:
> “And by the way, that's a little computer architecture research area, like what's the right—everybody has this idea what's the right mix with accelerated computing and general purpose computing, and how are people using it, and how do you build it in a way programmers can actually use it?”
---
[26:48](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1608s) Arm vs x86 vs RISC-V: The Lifecycle of ISA Bloat
When Cutress asks whether he cares about the competition between Arm and x86, Keller reflects on the predictable historical lifecycle through which all instruction set architectures (ISAs) accumulate bloat:
| ISA | Origins & Early Design | Sources of Accumulated Bloat & Complexity | Current Status | |:--- |:--- |:--- |:--- | | **x86** | Clean, simple 8-bit architecture; openly licensed by Intel to seven companies | Expanded across 16-bit, 32-bit, and 64-bit eras; added paging, hardware virtualization, legacy modes, and complex vector extensions | Heavily weighed down by legacy compatibility | | **Arm** | Clean, minimalist 32-bit RISC architecture designed as a simpler alternative to x86 | Added 16-bit Thumb, the cumbersome `IT` (If-Then) instruction, register-overlay vector/floating-point extensions, 64-bit mode, and specialized boot/security logic | Significantly more complex than its initial release | | **RISC-V** | Developed in academia as a clean, modern, open-standard ISA | Early in its lifecycle; free from commercial baggage, obsolete modes, or unnecessary extensions | Simplest and fastest foundation for building modern high-performance cores |
```mermaid flowchart LR accTitle: ISA Evolution and Complexity Accumulation accDescr: Flow diagram showing how ISAs inevitably transition from clean simplicity to complex bloat over time.
A["Clean, Simple ISA<br/>(Targeted Feature Set)"] -->|"Add Extensions & Modes"| B["Commercial Expansion<br/>(Market Demands & Back-Compat)"] B -->|"Refuse to Deprecate"| C["Legacy Baggage<br/>(Feature-on-Feature Interactivity)"] C -->|"Diminishing Returns"| D["New Clean Slate Emerges<br/>(e.g., RISC-V)"] ```
Keller explains that every architecture begins clean. When x86 arrived, it competed with chips like the Motorola 6800 and the MOS 6502 (all of which Keller programmed early in his career). Over four decades, however, features layered onto features without subtracting the past. Arm followed the same path: though originally celebrated for its purity compared to x86, it quickly accumulated complexity through Thumb, the reviled `IT` conditional execution instruction, and overlapping floating-point registers.
RISC-V represents the fresh alternative simply because of its age and pedigree. Born in university research environments where designers had no interest in bolting on superfluous commercial junk, it contains the critical core instructions necessary for performance without decades of technical debt. When selecting an ISA to build an ultra-fast modern core, Keller asserts:
> “If I was just going to say I want to build a computer really fast today, and I want it to go fast, RISC-V is the easiest one: it's the simplest one, it's got all the right features, it's got the right top eight instructions that you actually need to optimize, it doesn't have too much junk.”
Keller notes that complexity theory and engineering dynamics inevitably trigger diminishing returns. Engineers add ten good features that each improve capabilities on paper, but the cross-interactions between them make subsequent development exponentially more difficult. Customers and marketing managers demand that no legacy feature ever be removed, yet simultaneously gravitate toward newer, simpler architectures that only execute 70% of legacy functions but execute them dramatically faster.
---
[30:24](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1824s) Managing Legacy Baggage and the Modular CPU Architecture
Cutress questions whether x86 will ever be comprehensively overhauled or if it will simply linger as a legacy standard while alternatives like RISC-V take over. Keller points out that when AMD engineered the Zen architecture, they cleaned house by deprecating many ancient 16-bit operational paths and obsolete quirks.
The architectural secret to managing legacy instructions is isolation: support compatibility where necessary, but keep the legacy logic entirely decoupled from the high-performance execution pipeline, utilizing emulation or low-overhead fallback paths rather than letting legacy instructions dictate core clock timing or wiring.
Keller contrasts historical CPU layout with modern methodologies: * **Historical pipeline design**: In older CPUs, the boundaries separating functional blocks—instruction fetch, dispatch, execution, load/store, and L2 cache—were crisscrossed by hundreds of unbuffered wires whose signaling depended on fragile sub-cycle clock phases. * **Modern decoupled architecture**: Modern high-performance CPUs are partitioned into semi-autonomous processing domains. Interfaces communicate across structured instruction boundaries using packetized handshakes and acknowledge (`ACK`) protocols.
As Keller describes, modern processor interiors no longer resemble an intractable tangle of random signals; instead, a modern high-performance CPU functions as roughly eight distinct computers networked together on a single die, each executing dedicated stages such as instruction fetch, dispatch, integer execution, and memory management.
[031:46] The Cost of Violating Abstraction Layers
Keller explains that in chip architecture, when designing a modular unit—such as a floating-point unit—a disciplined design allows an engineer to overhaul it entirely without disrupting adjacent modules. The breakdown of this principle usually happens when under pressure: an engineer thinks, “boy, if I could just add these five wires between these two boxes, I could get rid of this problem.” Keller cautions that every hack violating an architectural abstraction creates technical debt: “Every time you violate the abstraction layer, you've created a problem for future Jim.” Over time, small shortcuts compound into architectural calcification and kill design velocity.
Ian Cutress asks Keller where this pervasive engineering ethos took root. Keller laughs at Cutress calling it a “pervasive element” of his personality, joking that he repeats the principle constantly to convince himself. He traces the realization back to his transition between Digital Equipment Corporation (DEC) and AMD:
* **DEC Alpha 21264 (EV6):** Architected alongside Dirk Meyer, EV6 relied on DEC's custom, transistor-level methodology. Keller jokes that when asked what was in their design library, his answer was simply “both of them: N devices and P devices.” Engineers rolled custom circuits with 22 different flip-flop variants, resulting in a short, tight, out-of-order execution pipeline that had immense internal interdependencies, making it excruciating to build and verify. * **AMD K7 (Athlon):** AMD used a standard cell library approach. Rather than dozens of hand-crafted variations, AMD designers relied on a clean abstraction layer between the transistors and the designers, utilizing just two primary flip-flop designs: “a big one and a little one.” Even prior to advanced automated place-and-route tools, this disciplined abstraction was far more productive. * **The S2K Bus to HyperTransport Evolution:** On the EV6 system bus (which was later licensed to AMD as the S2K bus), Keller and his team designed complex bespoke transactions for snoops, loads, stores, reads, and writes. Keller explained the implementation to Kourosh Gharachorloo, a friend at Digital Western Research Laboratory who later became a prominent security expert at Google. Gharachorloo shook his head and told him flatly: “Jim, that's not the way you do this.” He taught Keller the concept of virtual channels—establishing abstract channels of information before assigning wire-level bit encodings or bus commands. That design critique led directly to HyperTransport, AMD’s packetized, high-speed interconnect architecture. * **The K8 Misstep:** Keller admits that on their initial swing at K8, they temporarily backtracked into transistor-level thinking because he and his circuit partner, Pat Patla (or his circuit counterpart), were exceptionally comfortable reading raw transistors together. Keller realized that relying on a small handful of people who hold the whole transistor layout in their heads is an unsustainable way to scale computer engineering.
```mermaid flowchart TD accTitle: Evolution of Design Abstraction in Jim Keller's Work accDescr: Progression from transistor-level custom design at DEC Alpha to decoupled modular architectures at AMD Zen.
subgraph Alpha ["DEC Alpha (EV6)"] A1["Custom Transistor Level<br/>(22 flip-flop types, N/P devices)"] A2["S2K Bus<br/>(Tightly coupled command wires)"] end
subgraph Transition ["Architectural Maturation"] B1["Kourosh Gharachorloo Critique:<br/>Virtual Channels & Abstract Routing"] B2["Cell Library Abstraction<br/>(2 flip-flops: big & little)"] end
subgraph ModernZen ["AMD (K7, HyperTransport & Zen)"] C1["HyperTransport Packetized Fabric"] C2["Clean Front-End / Back-End Partition<br/>(200-engineer team split across clean contract)"] end
Alpha --> Transition Transition --> ModernZen ```
Keller emphasizes that abstraction layers are fundamentally human-scaling mechanisms: “If you want to build something bigger and more complicated, you better solve the abstraction layers, because people aren't smarter, and if you put more than 100 people on it, it'll slow down, not speed up.” Humans naturally maintain close familiarity with an inner circle of 10 to 20 people and can reasonably track up to 50 to 100 colleagues. Once an organization exceeds 100 engineers, everyone outside becomes a semi-stranger, requiring cleanly enforced contractual boundaries between design components.
When Keller built the original Zen architecture at AMD with a team of roughly 200 people, he enforced a strict architectural separation: approximately half the team built the front-end fetch/decode pipeline, while the other half worked on the back-end execution engine. Because the functional boundary interface was sharply defined, engineers on either side rarely had to haggle over internal microarchitectural details behind that contract.
---
[037:49] Why Moore's Law Isn't Dead
Cutress asks Keller if his relaxed stance on the continuation of Moore's Law comes from apathy or an assumption that foundry engineers will somehow resolve it. Keller rejects the notion of apathy outright: “Super proactive... that's not apathetic at all, like I know a lot of details about it.”
Keller argues that people conflate Intel's specific execution delays on its 10nm node with the fundamental limits of semiconductor physics. While Intel slipped, TSMC's roadmap proceeded cleanly because TSMC paced its cadence against ASML's EUV (Extreme Ultraviolet) machine availability:
1. **TSMC Node Pacing:** TSMC executed half-steps, delivering first-generation 7nm with standard deep ultraviolet (DUV) immersion lithography, moving to 7nm+ with initial EUV layers, scaling down to 5nm with broader EUV usage, and continuously refining lithography masks. 2. **Equipment Vendors as the True Locus of Innovation:** The public frequently views TSMC, Intel, and Samsung as the sole drivers of semiconductor progress, but Keller points out that the true locus of innovation sits within equipment makers like ASML and Applied Materials. ASML's market capitalization surpassed Intel's precisely because the equipment manufacturers design and construct the foundational tools that foundries run. TSMC alone committed to purchasing roughly 150 EUV machines by 2023.
Keller rejects claims that physical limits have been reached, pointing out that modern developments like X-ray lithography show clear paths forward. He cites Richard Feynman’s famous lecture: “There's lots of room at the bottom.” Keller states that when counting the number of atoms across a modern transistor gate, significant headroom remains: you only need roughly ten atoms across a junction before disruptive quantum tunneling and leakage dominate.
Keller describes semiconductor scaling as a complex interplay between toolmakers and fabrication craftsmen. Tool manufacturers build equipment with distinct lithography, deposition, and etching capabilities, while foundry process engineers act as master craftsmen who determine layer heights, aspect ratios, and pitch geometries. While toolmaker-foundry coordination misalignments occasionally cause multi-year delays, Keller insists that these bottlenecks are engineering alignment hurdles, not hard limits imposed by fundamental physics.
- TSMC’s execution roadmap was built around early tool adoption and multi-stage steps (7nm DUV $\rightarrow$ 7nm+ EUV $\rightarrow$ 5nm EUV). - Equipment makers like ASML and Applied Materials bear the primary research and development burden for next-generation lithography tooling. - Keller notes that a functional semiconductor junction can theoretically operate with as few as ten atoms across the critical dimension before quantum effects disrupt standard transistor behavior.
[42:06](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2526s) Lithography Beyond EUV: X-Rays, Multi-Patterning, and Innovation Bandwidth
Ian Cutress presses Jim Keller on the physical limits of lithography, noting that while High-NA EUV is slated to arrive within a couple of years, Keller had previously brought up x-ray lithography—a technology Ian points out is not even on his own immediate radar. Keller reflects on the commercialization timeline, recalling that new semiconductor manufacturing technologies typically enter production in highly targeted fashion rather than all at once. When extreme ultraviolet (EUV) lithography was initially integrated into DRAM manufacturing, it was deployed for just a single critical step or two before expanding. Keller estimates that initial commercial experimentation with x-rays might begin around 2023 or 2024, meaning teams are already actively playing with and testing working machines.
Keller points out that the transition from deep optical lithography (DUV) to EUV represented roughly a 10x reduction in wavelength. That optical era required extreme multi-patterning and intricate optical proximity corrections, resulting in bizarre interference patterns on masks. While EUV initially permitted direct printing of fine features, Keller explains that the exact same engineering tricks are now being reapplied to EUV itself, with EUV multi-patterning coming online around the 3nm node. Beyond the optics, making these nodes work introduces a cascade of thorny physics problems, from extreme material purity to microscopic temperature stabilization to prevent mechanical drift. Despite the daunting complexity, Keller remains confident that the industry will not stall out.
> “There's literally hundreds of thousands of people working on it so, you know, every group of 10 people have an innovation, there's more than enough innovation bandwidth.” — Jim Keller
- EUV was first introduced in DRAM fabrication for only one or two mask steps before widespread adoption. - The leap to EUV provided roughly a 10x reduction in wavelength over previous optical wavelengths. - EUV multi-patterning is anticipated around the 3nm node as feature sizes shrink below the single-exposure resolution limits.
---
[44:00](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2640s) Finding vs. Building a Team: Michelangelo’s Marble and Avoiding Clones
Ian shifts the conversation to Keller’s well-known track record of moving across top hardware companies and asks how he approaches building engineering teams, particularly whether he prefers bringing former colleagues along. Keller reframes the premise by distinguishing between *building* a team and *finding* one that already exists. He draws an analogy to the Galleria dell'Accademia (which he references alongside the statue of David), recalling the massive twenty-by-twenty-foot blocks of quarried marble sitting outside. Michelangelo looked at the raw stone and understood the sculpture was already inside; the only task was carving away the excess marble. Keller explains that in any company with a thousand employees, a world-class engineering team is already present in the building. During his tenure at AMD, he hardly hired anyone from the outside; instead, he simply identified, redeployed, and reorganized the exceptional talent already there.
In contrast, when Keller joined Tesla, he had to build an entire silicon team from scratch because no one at the company had ever designed chips. While he hired some familiar faces initially, he broadened recruitment to people he had never met before. Keller warns against a common executive failure mode: senior leaders jumping between companies and dragging an entourage of 20 loyalists with them. A 20-person cohort is just large enough to recreate their old environment and isolate the rest of the company, cutting off the local organization and preventing fresh thinking. Because every engineering group eventually gets stuck in a local minimum, combining one person from ten different high-performing teams often produces a superior result, as the new group actively debates and selects the best practices from their respective backgrounds.
Keller notes that an engineer who struggles in one environment can suddenly flourish when surrounded by different perspectives that challenge old assumptions. He admits that earlier in his career, he dismissed Digital Equipment Corporation founder Ken Olsen’s philosophy, but decades of management experience proved it right:
> “I used to—Ken Olsen at Digital said there's no bad employees, there's just bad employee-job matches. When I was younger I thought that was stupid, but I work with more people, I've seen it happen so many bloody times that you know, I've even fired people who went on to be really successful because they weren't doing a good job because they were stuck and emotionally they were committed to something that wasn't working.” — Jim Keller
```mermaid flowchart TD accTitle: Team Formation Approaches accDescr: Contrasting the approach of importing a cloned team versus composing a diverse team or unlocking existing talent.
subgraph AntiPattern["The Entourage Trap"] A["Leader arrives at new company"] --> B["Imports 20 former colleagues"] B --> C["Reproduces prior environment & local minimum"] C --> D["Alienates existing organization"] end
subgraph BestPractice["Adaptive Composition"] E["Evaluate context"] --> F{"Team exists?"} F -->|"Yes (e.g. AMD)"| G["Carve the marble: reorganize & redeploy internal talent"] F -->|"No (e.g. Tesla)"| H["Hire mix of trusted peers & external outsiders"] G --> I["High-trust, adaptive culture"] H --> J["Synthesize best practices across backgrounds"] end ```
---
[47:45](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2865s) Culture, Trust, and the Poison of Office Politics
Ian asks whether hiring should deliberately push against a company's existing culture or conform to it. Keller explains that it depends entirely on the operational phase. When an organization needs radical innovation, bringing in people who push against the grain is mandatory. However, if a complex project is already executing smoothly, injecting agitators will only create friction and derail delivery. The best engineers are adaptable: they can integrate seamlessly into a running project to push it across the finish line, while quietly building relationships and social capital so that they have the internal support to execute a pivot on the subsequent cycle.
At the core of high-functioning engineering organizations is unshakeable mutual trust. Keller illustrates this with a vivid hypothetical: if a stranger tells you to jump off a bridge, you refuse; but if a teammate who has bled with you through hard battles says the jump is going to hurt but you will survive, you leap without hesitating. When political operators enter the picture, that trust evaporates. Keller defines organizational politics as individuals manipulating the working environment for personal status rather than the project's success.
> “And teams that trust each other are way more effective than ones that have to do everything with contracts, negotiation, and politics.” — Jim Keller
Keller argues that political manipulators simply have to be removed immediately. The sole exception is when an executive is political but ties their political survival directly to flawless operational execution; even then, random internal politicking across lower ranks creates toxic drag and massive organizational stress.
---
[49:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2977s) Advice for Early-Career Engineers: The Tension Between Breadth and Depth
Ian asks whether early- and mid-career engineers should rotate regularly between projects to keep from stagnating in a narrow specialty. Keller agrees that career growth requires exposure to steep learning curves, but warns that rapid movement can backfire if handled improperly.
> “You learn fastest when you're doing something new working for somebody that knows way more than you.” — Jim Keller
If an early-career engineer realizes they are no longer learning or that their immediate leadership provides no inspiration, Keller recommends seeking a change. However, there is a dangerous creative tension between versatility and specialization. Keller cautions that he has seen engineers bounce across three or four different teams in rapid succession under the pretext of accumulating broad experience, only to emerge possessing deep expertise in absolutely nothing. In those instances, an engineer would have been far better served by staying put on a single challenging problem long enough to master fundamental principles deeply before attempting to generalize.
---
[50:22](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3022s) Jim Keller's Mentors: From Family Dynamics to the Legends at DEC
Ian asks Keller about the mentors who shaped his early career, inquiring about the leaders, architects, and thinkers he looked up to. Keller traces the origin of his mindset directly to his parents. His father was a professional engineer, while his mother possessed exceptional verbal and linguistic intelligence, later starting a career as a therapist. Because Keller struggled with dyslexia and could not read easily as a child, he assumed he took after his engineer father; over time, he realized his underlying cognitive style was much closer to his mother's analytical and interpersonal nature.
When Keller entered the tech industry at Digital Equipment Corporation (DEC), he found himself working directly under legendary computer architect Bob Stewart. Stewart was a powerhouse who designed landmark minicomputers and systems, including the PDP-11/44, the PDP-11/70, the VAX-11/780, and the DEC Computer Interconnect (CI) bus.
> “Somebody said every project he ever worked on earned a billion dollars, back when that was a huge number.” — Jim Keller
Surrounding Stewart was an extraordinary cohort of architects and researchers across DEC and its Western and Systems Research Labs (WRL/SRC). Keller had the opportunity to interact with and learn from pioneers like Butler Lampson, Chuck Thacker, and Nancy Kronenberg, who served as a formative mentor to him when he was just starting out in engineering.
- Bob Stewart's portfolio included foundational DEC architectures: the PDP-11/44, PDP-11/70, VAX-11/780, and the Computer Interconnect (CI) architecture. - DEC research environments exposed Keller directly to computer science legends, including Butler Lampson, Chuck Thacker, and Nancy Kronenberg.
[52:03](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3123s) Early Career Obliviousness and Arguing with Gordon Bell
Reflecting on his earliest years in the computer industry, Jim Keller recalls working alongside legendary figures, including one of the chief architects behind the VMS operating system at Digital Equipment Corporation (DEC). Looking back on whether he was intimidated by or idolized these luminaries, Keller confesses that he was simply oblivious to who they were at the time. During his very first week at DEC, new hires were being trained on a schematic drawing tool called Valid Logic Systems—a precursor to the Mentor Graphics era of electronic design automation.
In the middle of the training session, a man walked into the room, began asking questions, and lectured the group on hierarchical design. Unaware of the speaker's identity, Keller immediately began challenging him, breaking down why parts of hierarchical design were reasonable and why other parts were completely stupid. The two engaged in an intense hour-long debate. Once the man walked out, someone informed Keller that his debate partner was Gordon Bell, the legendary computer architect and Vice President of R&D at DEC. Keller replied, “Who's that?” When told Bell was DEC's head of engineering, Keller retorted: “Well, he's wrong about half the stuff he just said. I hope I straightened it out.” Attributing that boldness to a possible lack of serotonin activation rather than intentional bravado, Keller notes that it was more of a personal blind spot than a deliberate virtue.
Asked by Ian Cutress whether he has matured at all since those days, Keller laughs and remarks that he hasn't matured “a bit,” before admitting that his perspective on people has fundamentally evolved. Early in his career, he found himself getting nervous when giving talks and was frustrated that colleagues wouldn't simply do the right thing without coaxing. Over time, Keller realized that understanding how people think, what motivates them, and how to debug team dynamics is both crucial and satisfying. He also learned to reframe nervous energy into excitement, recalling how he felt zero dread when walking out in front of 2,000 people at an Intel conference. His passion for computer architecture remains as intoxicating as ever; when a friend’s wife once asked what they put in the water because engineers talk of nothing but computers, Keller's view was simple: building machines that change the world is immensely fun.
- Gordon Bell debated Keller for an hour on hierarchical design during Keller's first week at DEC, entirely unaware that the new hire had no idea who he was. - Valid Logic Systems was the CAD/drawing environment Keller trained on before the dominance of Mentor Graphics tools. - “Well, he's wrong about half the stuff he just said,” said Jim Keller after finding out the person he argued with was Gordon Bell.
---
[54:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3277s) Reading Thousands of Books and the Engineering Value of Shakespeare
Cutress notes that Keller seems to spend considerable effort studying the human condition and how people operate rather than just mouthing off at senior executives. Keller explains that books provide an unmatched return on investment: an author spends 20 years living, synthesizes their best ideas with passion, and a reader can effortlessly find the top titles on Amazon. While people often search for a short list of three or four life-altering books, Keller argues that it is the sheer volume that matters: reading a single book might occasionally spark change, but reading a thousand books is guaranteed to transform one's life.
Keller highlights that classic literature offers profound lessons for corporate environments. Reading Shakespeare or Niccolò Machiavelli reveals timeless dynamics of human nature: palace politics, devious actors, hardworking minions carrying the load, and the occasional hero stepping forward to save the day. Those patterns unfolded 500 years ago, and they play out inside modern corporate America every single day. Keller points out that anyone managing technical organizations without studying those fundamental dynamics is operating blind.
Before stepping into his first major management executive role, Keller recognized he needed a systematic framework for organizational thinking. He reached out to Venkatesh Rao, the author of the *Ribbonfarm* blog, using a "consult with me / buy me a coffee" link on the site. Keller and Rao spent hours talking before Keller joined AMD, and Rao supplied him with a tailored reading curriculum on organizational structure. Keller dutifully worked through the entire list. When he arrived in the corporate world, he discovered that while he had assumed every executive diligently studied management literature, almost none of them did: most managers read superficial books like *Good to Great*, which offer pleasant anecdotes but little structural depth. In Keller's assessment, a manager seeking real insight would learn far more about organizational behavior by reading Carl Jung than mainstream business bestsellers.
```mermaid flowchart TD accTitle: Value of Reading for Technical Leadership accDescr: Flow showing how historical human patterns inform corporate engineering management.
subgraph Literature ["Human Experience Literature"] A["Classical Literature<br/>(Shakespeare, Machiavelli)"] B["Psychology & Systems<br/>(Carl Jung, Venkatesh Rao)"] end
subgraph CorePatterns ["Timeless Social Patterns"] C["Power politics & devious actors"] D["Minions executing daily work"] E["Occasional hero saving the project"] end
subgraph Application ["Corporate America"] F["Debugging team friction"] G["Engineering management & alignment"] end
A --> C A --> D A --> E B --> F C & D & E --> G F --> G ```
- Venkatesh Rao of the *Ribbonfarm* blog provided Keller with an executive reading curriculum prior to Keller's leadership tenure at AMD. - “Reading the thousand books will change your life, that's for damn sure,” said Jim Keller regarding the compounding impact of wide reading. - “You'd be better off reading Carl Jung than Good to Great if you want to understand management,” said Jim Keller.
---
[57:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3436s) Reading Breadth, Passive Book Clubs, and Social Media Attention Spans
Keller recounts his journey as a reader, noting that he did not properly learn to read until fourth grade. However, because his parents belonged to a book club, by seventh or eighth grade he had devoured virtually every title in the family house. His early favorites included contemporary fiction writers like John Updike and John Barth. He was especially struck by the science fiction of Doris Lessing, whose novels functioned as deep psychological inquiries that expanded his thinking during formative years.
Over the last decade, his reading habits shifted from fiction toward history, anthropology, psychology, and mysticism. Cutress mentions that listeners frequently ask about Keller's reading habits, especially after Keller stated on Lex Fridman's podcast that he used to read two books a week, with many fans wishing Keller would host a "passive Jim Keller book club" on Twitter. Keller responds that while he reads continuously, his current intake consists of blog posts, technical essays, and disparate material. Moreover, he admits he lacks the sustained attention span required for social media: if he set up a public book-recommendation feed, he would inevitably abandon it for weeks at a time.
- Keller struggled to read until the fourth grade before clearing out his parents' library by middle school. - Influential authors from Keller's youth include John Updike, John Barth, and Doris Lessing's psychological science fiction series. - Though he historically read two complete books a week, his current intake leans heavily toward online essays, blogs, and multidisciplinary non-fiction.
---
[59:22](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3562s) Information Absorption, Meditation, and Prepping Dreams to Solve Problems
Cutress asks how Keller prevents his mind from wandering when consuming information and how he ensures he actually retains technical and conceptual material. Keller laughs, replying that he does not worry about retention at all. Unlike readers who laboriously highlight, annotate, and test their recall, Keller reads purely for interest and ideas. He notes that the commercial publishing model forces authors to write 250-page books regardless of whether they have 50 pages of substance or 500 pages of deep thought. Readers often encounter a brilliant 50-page thesis followed by 200 pages of filler written just to satisfy publisher length requirements.
Keller relies on a subconscious assimilation process rather than memorization. He meditates regularly, reflecting quietly on whatever problems or concepts occupy his thoughts. He believes human memory is not an indexable database where every fact and source citation can be retrieved on command; instead, compelling ideas absorb into the subconscious and reshape the reader's underlying personality and problem-solving intuition:
> “Your brain is this kind of weird thing: you don't actually have access to all the ideas and thoughts and things you've read, but your personality seems to be well informed by it. And I trust that process, so I don't worry that I can't remember somebody's name, because their idea may have changed who I was and I don't remember which book it came from.”
Beyond passive absorption, Keller deliberately uses his sleep cycles for technical problem-solving. Before falling asleep, he consciously directs his mind toward a specific engineering bottleneck or conceptual puzzle, effectively loading it into his subconscious. He finds that his mind will either directly work on the issue during dreams or discard the surface-level distraction to reveal the deeper, underlying problem he actually needed to address.
- Keller rejects manual highlighting and memorization drills, viewing the commercial 250-page publishing standard as largely padded. - Regular meditation serves as his filter for digesting concepts and integrating them into his overall thought architecture. - Keller deliberately primes his dreams prior to sleep by mentally reviewing difficult architectural problems, allowing subconscious processing to tackle the roadblock overnight.
[01:01:58](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3718s) Work-Life Balance, Sleep, and Time Allocation
The discussion turns to daily schedules, sleep habits, and managing workload when facing critical deadlines. While some executives claim to require only four hours of sleep a night, Jim Keller prefers seven. Calculating his daily priorities, Keller jokes that an ideal day would require around 34 hours to comfortably accommodate everything he likes doing: working out, spending time with his kids, sleeping, eating, reading, and working. He describes work as the unusual variable because it possesses an infinite capacity to consume more time than intended. Although he genuinely loves the process of engineering, he finds it a constant discipline to avoid letting work crowd out everything else.
Ian Cutress asks what gets sacrificed first when tight product deadlines loom, noting that time-to-market has been a central pressure across Keller's career. Surprisingly, Keller responds that exercise does not get cut; rather, his core management tactic is aggressive delegation. Once he finds his workload overflowing in a specific area, he identifies someone who possesses more enthusiasm for that task and transfers ownership. Keller explains that he personally prefers tackling unsolved problems rather than micromanaging execution.
```mermaid flowchart TD accTitle: Jim Keller Work Delegation Strategy accDescr: Flowchart illustrating Keller's workload management approach of delegating routine execution to focus on unsolved problems.
subgraph Capacity["Workload Threshold"] A["Unsolved Technical Problems"] --> B{"Workload Exceeds Capacity?"} end
subgraph Execution["Delegation & Focus"] B -->|"Yes"| C["Identify Teammate with High Enthusiasm"] C --> D["Delegate Presentations & Iterative Tasks"] D --> E["Preserve Time for Exercise, Family & High-Level Architecture"] B -->|"No"| F["Drive Core Technical Breakthroughs"] end ```
Keller jokes about his tenure at Tesla: “I was the laziest person at Tesla, as best I could tell.” While Tesla had an intense culture where employees often worked twelve-hour days to visibly demonstrate commitment, Keller worked roughly 9:00 AM to 7:00 PM. He protected his personal routine, running at lunch and utilizing a weightlifting room located at the Deer Creek facility next to the machine shop. Similarly, at large organizations like AMD and Intel, Keller relied on having strong staff members. Whenever administrative burdens like presentation preparation began consuming too much bandwidth, he reassigned the projects to colleagues eager for the opportunity and took time off.
[01:03:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3824s) The Value of Public Talks, Media, and Clarifying Ideas
Cutress inquires why Keller commits time to press interviews and marketing appearances, questioning whether such activities take time away from technical work and amount to "just talk." Keller firmly rejects this notion: “It's not just talk, you know I worked on some really interesting stuff, so I like to talk about it.” He illustrates how external communications serve internal corporate goals. While at Intel, Keller observed that many internal engineers were demoralized by the widespread narrative that Moore's Law had ended. Keller believed Moore's Law was very much alive and felt it was unacceptable for the primary semiconductor manufacturer to concede defeat on its core competency. By discussing the viability of Moore's Law in public interviews, those perspectives were amplified across the industry and echoed back into Intel, successfully shifting internal morale. He found he could influence more engineers inside Intel through external talks than through internal channels alone.
Beyond corporate messaging, Keller values the intellectual rigor demanded by explaining complex engineering concepts. Engaging with passionate journalists and analysts forces him to structure and clarify his own thoughts. Keller explains that a person only truly understands a concept when they can articulate it plainly; attempting to explain an idea often exposes hidden gaps in logic. Public speaking compels him to eliminate unnecessary noise, distill concepts to their fundamentals, and test the strength of his ideas.
- External interviews act as a lever to shape internal engineering sentiment at scale. - Structuring ideas for external audiences forces engineers to strip out false assumptions and fluff. - Keller's core motivation across all these engagements remains direct: “I had a mission to, you know, build faster computers—that's what I like to do.”
[01:05:29](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3929s) Visualization Superpowers, Dyslexia, and Grit
Cutress brings up the famous dictum—often attributed to Richard Feynman or Carl Sagan—that an inability to explain a concept to a first-year college student proves one does not truly understand it. Keller agrees that Feynman was a master of exposition in works like the *Feynman Lectures on Physics*, yet notes an ironic caveat: Feynman's intuitive grasp of mathematics was so extraordinary that his idea of a "simple" step often relied on leaps of logic that no one else in the room could follow, such as calculating complex orbital geometries in five effortless mental steps.
Turning to his own internal cognitive process, Keller shares how he conceptualizes engineering problems: “If I had one super power, it's like I feel like I can visualize how computer actually runs.” When designing architecture or developing performance models, he visualizes the end-to-end operation of the processor in his mind before transcribing it into code. He attributes this visualization capability to a blend of innate wiring, deliberate practice, and a coping mechanism developed from an adult diagnosis of dyslexia.
Discussing nature versus nurture, Keller downplays raw innate intelligence. He points out that exceptionally gifted individuals often struggle later in life because early tasks came too easily, preventing them from developing the work ethic required for complex setbacks. Keller remarks: “So I'm not that smart, definitely, so persistence and, you know, what they call grit is super useful.” Semiconductor design requires endless cycles of subtle optimization and iteration, demanding engineers who refuse to give up when designs hit obstacles. He warns young engineers against pursuing paths dictated by parental or societal expectations—such as entering management for vanity rather than passion—noting that chasing someone else's dream destroys the intrinsic drive required to master difficult technical domains.
[01:08:52](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4132s) Mentoring Through High Standards and Accountability
When asked if he plans to formalize his leadership role into something like a "Jim Keller School of Semiconductor Design," Keller chuckles and emphasizes that his primary driver has always been execution rather than academic instruction. His focus is on tangible, high-stakes targets: “I'm mostly mission-driven, like we're gonna build Zen, we're gonna build Autopilot.”
When building teams to execute those missions, Keller evaluates his people closely to understand what holds them back. When addressing underperformance, his direct intervention is often forceful. Keller reflects with amusement on how subordinates perceive this interaction: “People later on told me that I was mentoring them, and I'm thinking, I thought I was kicking your ass.”
Keller’s advice often extends beyond schematic design into lifestyle fundamentals, such as urging team members to fix their diet and physical health when he notices they lack energy. When addressing career plateaus, Keller diagnoses whether an engineer is genuinely mismatched with their tasks or simply obsessed with corporate ladder-climbing. He argues that political jockeying is counterproductive: “The best way to have status is to do something great and everybody thinks you're great; having status by trying to claw your way up is terrible because everybody thinks you're a climber.” True mentorship, in his view, flows directly out of keeping teams focused entirely on solving massive, consequential problems.
[01:11:06](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4266s) Mentoring Through Missions and Personal Debugging
Jim Keller explains that true mentoring cannot happen in an abstract vacuum. When people ask him simply to “mentor” them, he struggles with the lack of context: “I have a hard time doing that just quote mentoring people because what's the mission?” If someone comes asking to get better without an anchor, it quickly falls apart into irrelevant requests like wanting to play the violin better. Instead, effective growth happens when tied directly to an ambitious goal, such as building the world's fastest autopilot processor.
Once everyone is aligned around a mission, Keller notes that technical roadblocks are rarely the primary hurdle. Most of the friction is deeply personal. Engineers bring their entire lives to work, dealing with physical health issues, relationship troubles, parenting stress, and stalled careers. For a massive chip project to succeed, leaders must take these personal struggles seriously, even when engineers hide their real concerns behind “no-fly zones” or recite safe problems they assume management wants to hear. Once you help individuals work through those underlying issues, the project accelerates, and only then do they look back and consider you a mentor.
```mermaid flowchart TD accTitle: Jim Keller's Mission-Driven Mentorship Flow accDescr: A flow illustrating how setting a clear technical mission reveals personal roadblocks that, once resolved, lead to project success and perceived mentorship.
subgraph Mission ["The Mission"] A["Define Ambitious Goal<br/>(e.g., Fastest Autopilot Chip)"] end
subgraph Discovery ["Uncovering Obstacles"] A --> B["Identify Project Impediments"] B --> C["Personal & Workplace Roadblocks<br/>(Health, Career Stall, Family)"] end
subgraph Resolution ["Resolution & Impact"] C --> D["Debug Real Problems & Clear Blockers"] D --> E["Project Delivery & Perceived Mentorship"] end ```
[01:13:03](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4383s) Proudest Career Moments and Turning Zen Around
When Dr. Ian Cutress asks Keller whether he has a specific proudest moment, project, or accolade in his career, Keller shares that his best memories stem from moments of collaborative breakthrough. He recalls working with Becky Loop at Intel, where they were wrestling with complex quality issues across multiple architectural layers. Frustrated by the confusing data, Keller felt an immense rush of excitement when Loop walked in one day with a single visual diagram that completely clarified the situation and established a clear path to resolution.
This leads Keller to reminisce about the Tesla autopilot chip and the creation of AMD’s Zen architecture. At the time, the broader industry had written off AMD, believing the company simply could not design competitive microprocessors anymore: “Everybody thought the AMD team couldn't shoot straight and now I was very intrigued with the possibility of building a really great computer with the team everybody thought was you know out of it.” Keller emphasizes that the core team responsible for Zen—veterans like Mike Clark, Leslie Barnes, and Suzanne Plummer—were seasoned company lifers with 25 to 30 years of tenure who had already proven their ability on earlier projects.
The turnaround required honest self-assessment, clear goal setting, and confronting deep organizational defeatism. Keller recalls an iconic turning point when Suzanne Plummer informed him that the Zen team had lost faith in their ability to pull off the project:
- Keller immediately drove to the airport in California to take the first flight out, meeting the team in Austin the following morning at 8:00 AM. - He insisted on a large room equipped with abundant whiteboard space to confront roughly 30 frustrated engineers head-on. - Over two exhaustive days, the team documented every single perceived roadblock on the boards. Keller handed over the markers whenever someone knew how to tackle an issue, transforming the meeting from a defensive standoff into active problem-solving. - Mike Clark played a vital role in reinforcing confidence by declaring that every single issue listed on the boards was solvable. - Keller emphasizes that convincing a team requires relentless repetition: “How often do you have to go convince somebody? As many times as necessary.”
[01:17:21](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4641s) Silent Heroes and Learning to Play the Corporate Game
Ian asks whether there are unsung “silent heroes” in the tech world who never receive adequate credit for their achievements. Keller responds immediately that this describes the vast majority of working engineers. While high-powered corporate lawyers easily bill $800 an hour in Silicon Valley, exceptionally talented engineers often just want to keep their heads down, write clean RTL, eliminate every bug, and deliver flawless designs—such as an engineer taking immense personal pride in quietly shipping their eighth-generation memory controller without errors.
Because conscientious engineers are overwhelmingly introverted, they rarely promote themselves. Keller reflects on his own transformation, noting that he had to consciously adopt extroverted behaviors if he wanted the scope and resources to build truly massive computing projects: “I decided I wanted to build bigger projects and to do that you have to pretend to be an extrovert and you have to promote yourself.” He explains that senior decision-makers rarely take the time to audit technical code to find the most capable architect; they simply defer to whoever is the most visible, confident, and talked about. For an engineer aiming to rise above a principal engineer title into director-level management and executive ranks, learning the political and psychological dynamics of the corporate ecosystem is mandatory. Keller recommends studying foundational texts on human nature and power politics—such as William Shakespeare, Carl Jung, and Niccolò Machiavelli—to understand how that stratum of an organization actually operates. As the conversation wraps, Ian transitions toward Keller's perspective on the rivalry between industry titans like Intel, AMD, and Apple.
[01:20:04](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4804s) Intel vs AMD vs Apple: Corporate Cultures and Public Interfaces
Jim reflects on having worked across many major semiconductor companies, noting that he genuinely enjoyed his time at all of them. Today, his focus is drawn toward the emerging wave of AI startups and the broader revolution taking place in computing architectures. At the corporate level, companies driven by stock prices and boards will naturally fight their market battles, but Jim emphasizes that his personal connection remains with the engineers who do the actual work.
```mermaid flowchart TD accTitle: Tech Giants Operating Models Comparison accDescr: Contrasts Apple's insular consumer-box model with Intel and AMD's open component-ecosystem approach.
subgraph Apple["Apple: Vertically Integrated & Insular"] A1["Consumer Touchpoint: Aluminum / Glass Box"] A2["Operates like a 'Secret Society'"] A3["Great engineers, but isolated from wider technical world"] end
subgraph ComponentMakers["Intel & AMD: Open Component Ecosystem"] B1["Sell foundational components across diverse products"] B2["Tangible public engineering touchpoint (PCIe lanes, perf, bugs)"] B3["Directly impact broad developer and enthusiast communities"] end ```
When comparing corporate cultures, Jim contrasts Apple's approach with that of Intel and AMD. Apple maintains a notoriously insular posture toward the rest of the industry, presenting its work to users through sleek aluminum or glass enclosures. Jim observes that while Apple's engineers are exceptionally talented, their internal secrecy cuts them off from wider participation in the broader technical community. By contrast, Intel and AMD operate as component suppliers whose products power a vast spectrum of devices built by other companies. As a result, the engineering work done at Intel and AMD interfaces with the outside world far more directly; engineers and enthusiasts engage closely with tangible metrics such as architectural performance, PCIe lane configurations, and errata.
> “Intel and AMD sell components that go into many people's products so their interface to the public is more, you know, tangible in terms of the what the engineers do.” — Jim Keller
---
[01:21:40](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4900s) AI-Driven Chip Design and the Evolution of Unfathomable Systems
Ian asks whether electronic design automation (EDA) tools and emerging AI techniques will eventually design complex, multi-million-transistor microprocessors that are entirely unfathomable to human engineers. Jim points out that contemporary cutting-edge microprocessors from AMD, Intel, and Apple are already so complex that no single human can comprehend every detail. Nevertheless, an engineer can still inspect individual register-transfer level (RTL) code or standard cell libraries and deduce their function. Trained neural networks represent a completely different paradigm: when looking at a trained weight such as `0.0015843`, a human cannot simply explain why that precise value produces the correct outcome.
To illustrate this transition in human understanding, Jim references how the philosophy of science has evolved over history, drawing directly on concepts highlighted by Stephen Wolfram:
| Epoch | Scientific Paradigm | Nature of Understanding | |:--- |:--- |:--- | | **Classical Antiquity** | Physics by Explanation (Aristotle) | Qualitative narrative descriptions of nature (often fundamentally wrong). | | **Scientific Revolution** | Physics by Equation (Newton, Copernicus) | Elegant, intelligible mathematical formulas modeling observable phenomena. | | **Algorithmic Era** | Physics by Program (Wolfram) | Complex algorithmic systems that cannot be collapsed into single concise formulas. | | **Modern AI Era** | Physics / Design by Machine Learning | Empirical black boxes whose internal parameters lack intelligible human equations. |
Jim explores the cascading implications for future chip design. Today, AI networks are trained using small computing engines delivering several teraflops. If AI systems design future microprocessors, human engineers might inspect the resulting circuit and fail to comprehend not just the weights, but the underlying arithmetic representations and physical layouts. In that world, engineers will operate at even higher abstraction layers, designing the overarching human experience while leaving the microscopic implementations to black-box machine models.
> “Physics, there was physics by explanation, that was Aristotle, you know, 1,500 years, right? He was wrong about a whole bunch of stuff. And then there was physics by equation, like Newton, Copernicus, you know, people like that. And he says, you know, Stephen Wolfram said, now there's going to be physics by program, right? There's very few programs that are you can write in one equation, programs are complicated. And he says, why isn't physics like that? Well, you know, in computing world now we have program by AI, which has no intelligible equations in it or statements, so why isn't physics going to do the same thing?” — Jim Keller
---
[01:26:14](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5174s) Hardware Security: Side-Channel Attacks and Software Fallibility
Addressing the surge in microarchitectural side-channel vulnerabilities, Ian asks whether Jim adopts a proactive or reactive stance toward hardware security. Jim clarifies that market demand dictates design priorities, noting that true security is only prioritized when stakeholders actively care about protecting specific assets. Historically, operating systems relied on virtual memory boundaries to separate processes, but system software inevitably grew so tangled that attackers could trick the supervisor code into bypassing those safeguards.
```mermaid flowchart LR accTitle: Hardware vs Software Security Boundaries accDescr: Progression from fragile software-only verification to strict hardware isolation boundaries.
subgraph SW["Software-Enforced Boundaries"] S1["Virtual Memory & OS Isolation"] S2["Software grows in complexity"] S3["Vulnerabilities & gaps introduced"] S1 --> S2 --> S3 end
subgraph HW["Hardware-Enforced Boundaries"] H1["Strict Hardware Memory Isolation"] H2["OS cannot inspect user data"] H3["Immutable physical air-gaps"] end
S3 -.->|"Requires migration to"| HW ```
Jim places little confidence in purely software-based security, remarking that complex code continually violates its own foundational premises over time. The hardware overhead required to implement secure boundaries is generally modest; the real challenge lies in designing clear threat models. While global digital security often relies de facto on security through obscurity—most individuals are simply not high-value targets among billions—robust compute systems require hard hardware isolation barriers where even the host operating system cannot inspect protected user data. Beyond silicon-level protections, the highest tiers of operational security continue to rely on physical air-gapping and physical guards.
> “Every once in a while somebody will say something like, ‘Well, this is secure because the software does X,’ and I always think, ‘Yeah, just wait 10 minutes and the software will get more complicated, which will introduce a gap in it.’” — Jim Keller
- **Nature of Side-Channel Patches:** Most discovered microarchitectural side-channel leaks turned out to be relatively straightforward to mitigate in hardware once identified. - **Architectural Shift:** Emerging system architectures prioritize mutual distrust, enforcing hardware boundaries where the hypervisor or OS is explicitly barred from viewing workload contents. - **Physical Isolation:** Ultimate compute security remains air-gapped infrastructure protected by firewalls, physical perimeter defenses, and armed guards.
---
[01:29:09](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5349s) The Ethics of General-Purpose Computing
Ian asks whether Jim weighs the ethical ramifications and potential downstream misuses of the silicon he creates, comparing purpose-built automotive silicon like Tesla's autonomous driving chips to general-purpose microprocessors sold widely across global industries.
Jim responds that general-purpose computing is inherently agnostic: once an architecture is released into the world, it can be applied toward virtually any task. Because designers cannot control every end use, evaluating the ethics of building silicon comes down to weighing aggregate outcomes. In Jim's assessment, the broad societal net positive created by expanding computational power substantially outweighs the inevitable negative misuses.
> “The funny thing about general-purpose computing is it can really be used for anything. And so the ethics is more a net good better than the net bad, and you know, for the most part I think the net good is better than the possible downsides.” — Jim Keller
[01:29:53](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5393s) Ethics of AI and Decentralized Compute
Jim Keller addresses the growing societal anxiety surrounding artificial intelligence ethics, acknowledging that algorithmic capabilities have evolved far faster than human philosophical frameworks. Current systems already exhibit a startling ability to parse what individuals think, desire, and do, leaving the ethics debate trailing behind. Keller explains that one of his core motivations for engineering lower-cost, highly programmable AI silicon—and engaging with an extensive roster of AI software startups—is to ensure AI computing resources are broadly distributed rather than monopolized. In his view, putting hardware into many hands creates a protective equilibrium rather than an entrenched monopoly:
> “And the question is you know how many people have it have that and one reason to build let's say you know lower cost AI and programmable AI is you know I hope and we're talking to quite a large number of AI software startups that you know AI hardware and computing is in more people's hands because then you have a little mutual standoff situation as opposed to one winner take all but you know the modern tech world this has been sort of a winners take all but there's actually you know literally several dozen very large companies that have you know let's say competitive relationship with each other so that's kind of complicated so I think about it some.”
Keller concludes that while he does not claim to have definitive solutions to the ethical dilemma, technological advances have historically yielded net-positive results for society, and broadening access to powerful compute remains the safest path forward.
[01:31:27](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5487s) Elon Musk, Neuralink, and the Psychology of Cryptocurrency
Ian Cutress shifts the conversation to Keller’s history of working alongside prominent figures like Steve Jobs and Elon Musk. Ian notes Keller's appearance alongside Lex Fridman at a Neuralink demonstration the prior year, asking about his relationship with Musk and Musk’s vocal advocacy for cryptocurrency. Keller clarifies that he attended the Neuralink event because he was invited by members of their development engineering team whom he knew, emphasizing that his relationship with Musk was purely professional during his tenure at Tesla rather than personal, and that they have not spoken recently.
When asked about the computational demands of cryptocurrency—especially pouring energy into an asset without obvious intrinsic utility—Keller expresses indifference toward crypto mechanics, instead framing it as a fascinating manifestation of human group psychology:
> “I mean humans are really weird where they can put value in something like gold or money or cryptocurrency and you know that's a shared belief contract and what it's based on the best I can tell hasn't mattered much.”
For Keller, shared belief contracts are the actual driving force behind currencies, political movements, technology adoption, corporate cultures, and personal philosophy: - Without a coherent shared group belief, engineering teams cannot build complex systems or get anything done. - Crypto enthusiasts prize the perception that the currency operates outside central government control, though Keller remains agnostic on whether that is true. - He views cryptocurrency not as a fundamental technological revolution, but as a symptom and arbitrary case study of how powerfully human group beliefs shape reality.
[01:33:47](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5627s) Computing Beyond Silicon: Biology, Optics, and Quantum
Looking beyond the 50-year reign of silicon microprocessors, Ian asks whether Keller contemplates what happens when the industry inevitably encounters theoretical physics limits. Keller traces the long technological arc of computing devices to illustrate how humanity continually leaps paradigms when old substrates exhaust their potential:
```mermaid flowchart LR accTitle: Evolution of Computing Substrates accDescr: A sequence tracing computing technologies from historical mechanical systems to potential future biological and quantum architectures.
subgraph Historical["Historical Eras"] direction LR A["Abacuses"] --> B["Mechanical Relays"] B --> C["Vacuum Tubes"] end
subgraph SolidState["Solid-State Silicon"] direction LR D["Discrete Transistors"] --> E["Integrated Circuits"] E --> F["Modern Multi-Gate FETs"] end
subgraph Frontier["Future Frontiers"] direction LR G["Optical Switching"] H["Biological Assembly"] I["Neutral-Atom Quantum"] end
Historical --> SolidState SolidState --> Frontier ```
Keller points to several emerging domains that could supplement or replace traditional semiconductor approaches: - **Silicon Photonics and Optics:** Keller observes that researchers routing light through polysilicon to perform optical switching have been making real, tangible strides, even if the field has famously been regarded as “ten years away for twenty years.” - **Biological Economics:** Keller highlights biology's staggering thermodynamic and capital efficiency compared to semiconductor fabrication plants:
> “The economics of biology it's like 100 million times cheaper to make a complicated molecule than it is to make a transistor like that the economics are amazing like once you have something that can recon replicate proteins like I know a company that makes proteins for a living and we did the math and it was literally a hundred million times less capital per molecule than we spend on transistors.”
- **Self-Assembly vs. Lithography:** While planar lithography prints transistors into exceptionally sophisticated, rigid arrays, biological organisms assemble complex proteins organically. Echoing Richard Feynman's famous adage that “there's plenty of room at the bottom,” Keller sees massive untapped opportunity in guiding chemical organization. - **Quantum Systems:** Keller recalls speaking with founders of a neutral-atom quantum computing startup who used optical laser arrays to cool atoms and trap them into rigid two-dimensional grids. - **AI-Guided Atomic Engineering:** Keller suggests that mastering the next level of physical architectures may require modern AI computation itself to discover and direct the precise arrangement of atoms.
The interview concludes on a warm note as Cutress thanks Keller for his extensive time, noting he still had 20 questions left on his list, and wishes Keller success in his role as CTO of Tenstorrent.
## Notable quotes > [54:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3277s) You'd be better off reading Carl Jung than Good to Great if you want to understand management. — Jim Keller
> [19:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1184s) Eighty percent of the execution is like six instructions: load, store, add, subtract, compare, and branch. — Jim Keller
> [47:45](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2865s) And teams that trust each other are way more effective than ones that have to do everything with contracts, negotiation, and politics. — Jim Keller
> [49:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2977s) You learn fastest when you're doing something new working for somebody that knows way more than you. — Jim Keller
> [01:08:52](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4132s) The best way to have status is to do something great and everybody thinks you're great; having status by trying to claw your way up is terrible because everybody thinks you're a climber. — Jim Keller
> [01:17:21](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4641s) I decided I wanted to build bigger projects and to do that you have to pretend to be an extrovert and you have to promote yourself. — Jim Keller
## Mentioned Alpha, AMD, AMD64, Apple, Applied Materials, Aristotle, Arm, ASML, Athlon, Autopilot, Becky Loop, Bob Stewart, Bob Swan, Broadcom, Bulldozer, Butler Lampson, Carl Jung, Carl Sagan, Chuck Thacker, Debjit Das Sarma, Digital Equipment Corporation (DEC), Doris Lessing, Elon Musk, Excavator, Full Self-Driving (FSD), Good to Great, Gordon Bell, Harry Fair, Hardware 3, Hurricane, HyperTransport, Ian Cutress, Intel, Isaac Newton, Jaguar, Jay Fleischman, Jim Keller, John Barth, John Updike, K12, K7, K8, Ken Olsen, Leslie Barnes, Lex Fridman, Ljubisa Bajic, Mark Papermaster, Mentor Graphics, Mike Clark, Moore's Law, MOS 6502, Motorola 6800, Nancy Kronenberg, Neuralink, Niccolò Machiavelli, Nicolaus Copernicus, Nvidia, Opteron, P.A. Semi, Pat Gelsinger, PDP-11/44, PDP-11/70, PowerPC, Raja Koduri, Ribbonfarm, Richard Feynman, RISC-V, Samsung, SiByte, Stephen Wolfram, Steve Hale, Steve Jobs, Suzanne Plummer, Tensix, Tenstorrent, Tesla, Thumb, TSMC, Valid Logic Systems, VAX 8800, VAX-11/780, Venkatesh Rao, William Shakespeare, x86, Zen, Zen 2, Zen 3
## Video description Was Jim Keller really 'the father of Zen'? In this wide-reaching interview, Jim talks to Ian about his time at AMD, Intel, and others, along with a variety of management technique advice, how to approach design, the future of Moore's Law, which instruction set matters (x86 vs Arm), but also the intersection between maturity and experience.
Written version of the interview is on AnandTech https://www.anandtech.com/show/16762/an-anandtech-interview-with-jim-keller-laziest-person-at-tesla
Jim Keller is currently CTO of Tenstorrent, a 2016 AI startup that recently secured $200m of Series C funding to go build their 4th/5th generation processors. I recently interviewed CTO Jim and CEO Ljubisa about Tenstorrent as well as the relationship between the two, which comes back to their time at AMD together.
https://www.youtube.com/watch?v=sMvudTBBQNw
0:00 Interview Part 2 0:32 Q1: What Jim Did at AMD 5:16 Q2: Father of Zen? 7:16 Q3: Everything from AMD is out? 8:41 Q4: Zen 3 a rewrite? 9:52 Q5: Is Tenstorrent a Forever Home? 13:21 Q6: What Jim Did at Intel 15:57 Q7: Would Jim Go Back to Intel? 16:38 Q8: Has it ever got boring? 18:24 Q9: Do Engineers Need People Skills? 19:44 Q10: Arm vs x86 vs RISC-V Pt 1 23:42 Q11: The right compute point for AI 25:47 Q12: Adding Vectors to AI 26:48 Q13: Arm vs x86 vs RISC-V Pt 2 29:11 Q14: Too much bloat? 30:24 Q15: Would x86 ever die? 32:33 Q16: Abstraction Layers in Life 37:49 Q17: Is Jim Worried about Moore's Law? 41:55 Q18: Beyond EUV Lithography 44:00 Q19: How to build a team 47:45 Q20: Teams and Company Culture 49:37 Q21: Recommendation for Early Career 50:22 Q22: Jim's Mentors 54:37 Q23: Understanding People 56:05 Q24: Reading more than others 58:33 Q25: Passive Jim Keller bookclub 59:22 Q26: Making sure you absorb information 1:01:43 Q27: Managing time 1:03:44 Q28: Doing interviews, marketing, 'talk' 1:06:12 Q29: Jim's Superpower? Nature vs Nurture? 1:08:52 Q30: How To Mentor People 1:13:03 Q31: Proudest Moments 1:17:21 Q32: Silent Heroes and Self-Promotion 1:19:48 Q33: Intel vs AMD, Intel vs Apple 1:21:40 Q34: AI Enabling Chip Design 1:26:14 Q35: Proactive or Reactive Security 1:29:09 Q36: Ethics of Chips Built 1:31:27 Q37: Elon, Neuralink, Cryptocurrency 1:33:47 Q38: Going Beyond Silicon 1:37:00 Cat Tax
Welcome to the TechTechPotato (c) Dr. Ian Cutress Ramblings about things related to Technology from an analyst
Patreon helps support this channel: https://www.patreon.com/TechTechPotato Also available through Patreon is special 1-on-1 consulting for the financial services industry! Many thanks to our CPU CEO Patrons
Support the channel by hitting that subscribe button, or using our Amazon affiliate link. Please note that TTP may receive a commission if you purchase anything through these links
Intel Core i7-11700K (8C/16T): https://geni.us/SreZM Intel Core i5-11600K (6C/12T): https://geni.us/T4WG Intel Core i5-11400F (6C/12T): https://geni.us/6UISblx
AMD Ryzen 9 5950X (16C/32T): https://geni.us/5950X AMD Ryzen 9 5900X (12C/24T): https://geni.us/5900X AMD Ryzen 7 5800X (8C/16T): https://geni.us/5800X AMD Ryzen 5 5600X (6C/12T): https://geni.us/5600X
Intel Core i9-10900K (10C/20T): https://geni.us/Bench2020-10900k Intel Core i7-10700K (8C/16T): https://geni.us/Bench2020-10700K
AMD Ryzen 9 3950X (16C/32T): https://geni.us/Bench2020-3950x AMD Ryzen 7 3700X (8C/16T): https://geni.us/Bench2020-3700x AMD Ryzen 5 3600 (6C/12T): https://geni.us/d08ThJ4
Follow Ian on Twitter at http://twitter.com/IanCutress Follow TechTechPotato on Twitter at http://twitter.com/TechTechPotato
#techtechpotato #jimkeller #ianinterviews
[Source](https://www.youtube.com/watch?v=AFVDZeg4RVY)