Best Place To BuildThis Indian Startup is Reinventing Chip Design | Neel Gala, CTO/Co-Founder, InCore Semiconductors
CHAPTERS
Why chip bugs are existential: one transistor can kill a $5M tape-out
Neel opens with a vivid explanation of why silicon is uniquely unforgiving: a single bug among millions of transistors can brick a prototype and force an expensive restart. This frames the industry’s risk-aversion and the motivation to shorten design cycles without sacrificing correctness.
- •Hardware prototypes are costly (multi-million-dollar) and slow to redo
- •Chips must work across millions of transistors—tiny errors can prevent boot
- •Verification paranoia is rational due to recall/tape-out risk
- •Silicon innovation is constrained by cost, time, and irreversibility
Microprocessors 101: the ‘brain’ and the hardware–software contract
Neel explains what a processor is in layman terms and introduces the key concept underneath it: the instruction set architecture (ISA). The ISA is presented as the critical interface that lets hardware and software teams work independently yet remain compatible.
- •Processor as the control/compute engine of “smart” devices
- •Code ultimately becomes 1s and 0s executed by the processor
- •ISA is the shared language between software and hardware
- •If the ISA contract breaks, both hardware and software become useless
Shakti’s origin story: building what India couldn’t access
Neel recounts the early IIT Madras context: limited access to modern proprietary architectures and funding constraints. The team explored IBM’s OpenPOWER but found it too heavy and not truly open for academic rapid implementation, pushing them toward an alternative.
- •Tier-1 access in India often lagged by decades vs leading universities abroad
- •Innovation needs curiosity—but curiosity needs funding/resources
- •OpenPOWER explored but was complex/paid-access and not academia-friendly
- •Decision point: ‘If it doesn’t exist, we should build it’
RISC-V appears: a small spec that unlocked a national processor effort
The conversation traces how Berkeley’s early RISC-V spec (short, implementable) became the turning point. IITM adopted it early, influenced the community to stabilize it, and Shakti emerged as an indigenous RISC-V-based processor initiative.
- •RISC-V spec was compact (~50 pages) and implementable quickly
- •Early adoption before formal standardization; feedback loop to Berkeley
- •2013: RISC-V’s formal birth influenced by growing implementer interest
- •Shakti name: translating ‘POWER’ into Sanskrit; mission-driven indigenous design
From academic prototype to strategic deployment: parity first, then replace imports
Neel describes the first Shakti goals: match what India already uses, then substitute legacy foreign processors in strategic sectors. Engagements with defense/atomic/aerospace stakeholders shaped requirements and pushed the project from papers toward product thinking.
- •Initial target: a practical baseline (e.g., five-stage core)
- •Work with strategic sectors to understand real constraints and needs
- •Early replacement ambition (e.g., older MIPS-class systems)
- •Product thinking vs ‘publish and abandon’: build usable, deployable tech
InCore’s focus: RISC-V ‘solutions,’ not just CPU cores
Neel introduces InCore as a fabless IP company providing more than a CPU core: subsystems, SoCs, and surrounding IP needed for a real chip. The company aims to let customers assemble complete systems quickly rather than buying a single block and doing the rest alone.
- •InCore provides cores plus interconnects, peripherals, security, accelerators
- •Customers want integrated solutions, not standalone cores
- •Portfolio designed for mix-and-match SoC building
- •Goal: drastically reduce integration time for customers
Core vs chip vs SoC: the IITM campus analogy for silicon systems
Neel breaks down terminology by mapping a chip to an IIT campus: the core is the admin building, the SoC includes gates/peripherals/memory/accelerators/security/interconnect. This clarifies how complete products require many coordinated blocks beyond the CPU.
- •Chip contains many components; the core is the primary compute engine
- •SoC/subsystem includes peripherals (USB/DDR/PCIe), memory, accelerators
- •Security blocks enforce boundaries; interconnect is the ‘roads’ for data
- •System value comes from integration, not a single block
What ‘IP’ really means in semiconductors—and how it’s bought and protected
The episode explains IP as deliverable hardware design code, not a physical chip. Neel discusses how IP is shared (often as Verilog), how companies try to prevent copying (obfuscation/encryption), and InCore’s approach of keeping high-level design ‘secret sauce’ internal while delivering lower-level RTL to customers.
- •Semiconductor IP is typically delivered as code (RTL in Verilog, etc.)
- •Protection methods: encryption/obfuscation vs customer debug visibility trade-off
- •InCore develops in higher-level languages (e.g., Bluespec) and delivers Verilog
- •Perfect protection is unrealistic; over-protection can make IP unusable
The chip design lifecycle: why it’s 12–18 months and where time is lost
Neel lays out the end-to-end flow from spec to RTL freeze to physical design to fab to boards to demos. A key bottleneck is that teams often work serially—design first, then verification, then FPGA bring-up, then software—stretching schedules and delaying learning.
- •Typical end-to-end cycle: ~12–18 months (even with shortcuts)
- •First ~4 months often spent on spec→RTL integration/iteration alone
- •Phases include IP procurement, integration, verification, emulation/FPGA, software
- •Serialization delays: downstream teams can’t start until upstream delivers
‘Make the marathon a sprint’: InCore’s SoC generator platform and YAML-driven iteration
Neel describes an SoC generator as a platform that rapidly composes systems and explores trade-offs by changing high-level configurations rather than editing large RTL by hand. Customers can iterate many times quickly to tune PPA (power, performance, area), with collateral like tests provided early to parallelize teams.
- •SoC generator enables rapid recomposition and iteration (many variants quickly)
- •Optimizes PPA: power, performance (frequency/throughput), and area (cost)
- •Abstract configuration (e.g., YAML) replaces manual RTL rewiring
- •Day-one collateral: verification suites and emulation/software hooks to parallelize
Why AI won’t ‘take over chip design’ soon: data scarcity, hallucinations, and risk
The discussion explains AI’s current role as assistive—helping with verification and corner cases—rather than fully generative design. Neel argues the industry lacks open training data, big incumbents hoard proprietary datasets, and hallucinations/reproducibility issues are unacceptable in high-stakes silicon.
- •AI today is closer to a co-pilot than an autonomous chip designer
- •Hallucinations and reproducibility issues conflict with safety-critical expectations
- •Training data is scarce in open hardware; incumbents have proprietary datasets
- •Near-term path: AI as interface/analysis layer around deterministic generators
Choosing IITM over the ‘American dream’: the paper-shredder moment and mission mindset
Neel shares the story of nearly applying abroad until Prof. Kamakoti challenged his conviction—prompting him to shred applications and stay. The moment becomes a broader reflection on patriotism, building foundational tech locally, and aligning personal ambition with national capability-building.
- •Mentorship intervention reframed ‘go abroad’ as default vs deliberate choice
- •Staying enabled deeper collaboration that later fed into Shakti’s rise
- •Core belief: India must create, not only consume foundational technologies
- •Strategic self-reliance framed as both opportunity and responsibility
From lab to market: entrepreneurship lessons, first-customer risk, and ‘silicon-proof’ credibility
Neel describes the transition from academia’s “what’s possible” to startups’ “what’s needed,” emphasizing customer discovery and shipping early. He explains why the first customer is hardest in semiconductors, how one successful deployment becomes proof for the market, and why founders must constantly sell—to employees, investors, and customers.
- •Academia optimizes for possibility; startups must optimize for need and sellability
- •Semicon requires long lead times—building the wrong thing is catastrophic
- •First customer is a ‘guinea pig’ taking recall risk; success builds trust quickly
- •‘Silicon-proof’/‘market-proof’ status shortens future sales cycles
RISC-V in global context: breaking ISA monopolies and enabling sovereign control
Neel zooms out to explain why RISC-V matters: proprietary ISAs (x86, Arm, Power) centralize control and constrain customization. RISC-V’s permissive openness lowers barriers, accelerates ecosystem growth, and supports national security needs by enabling end-to-end control and auditability—especially critical where chips can’t be easily reverse engineered for hidden behaviors.
- •Proprietary ISA licensing can restrict discussion, customization, and transparency
- •RISC-V is small/modular and permissively licensed (not copyleft)
- •Broad industry adoption (major tech firms) signals durability of the standard
- •Strategic value: reduce backdoor risk; control from spec to production for India
Closing reflections: advice to builders, fear of failure, and balancing founder life with fatherhood
Neel encourages young engineers to attempt ambitious builds in India, arguing the ecosystem has improved through awareness, government programs (e.g., DLI), and investor readiness. He closes with personal reflections on becoming a parent while running a startup—adding urgency, maturity, and long-term thinking to decision-making.
- •Ecosystem tailwinds: better awareness, initiatives reducing tool costs, more support
- •Core advice: don’t fear failure; ask “stupid” questions; attempt boldly
- •Staying vs going abroad depends on goals, but India now offers real opportunity
- •Fatherhood shifts priorities: balance, responsibility, and long-term execution
