Best Place To BuildThis Indian Startup is Reinventing Chip Design | Neel Gala, CTO/Co-Founder, InCore Semiconductors
CHAPTERS
- 0:00 – 0:52
Why chip bugs are catastrophic: one bad transistor, $5M wasted
Neel opens with a vivid explanation of how unforgiving chip design is: millions of transistors must work perfectly, and a single bug can kill a multi-million-dollar prototype. This frames why verification, iteration speed, and risk management are existential concerns in semiconductors.
- •Chip prototypes can cost millions and still fail to boot due to tiny design bugs
- •Hardware iteration is slow and expensive compared to software
- •Risk-aversion in chip companies comes from recall/respins being devastating
- •Verification becomes a major time and cost sink
- •Motivation for tools/platforms that reduce iteration time
- 0:52 – 2:49
Podcast setup + defining a microprocessor in plain language
The host introduces the show and Neel Gala (CTO/co-founder of InCore Semiconductors). Neel explains what a microprocessor is and why it’s the ‘brain’ translating software intent into hardware actions.
- •Show premise: meeting builders at IIT Madras
- •Neel’s role at InCore and the company’s positioning (fabless, invested, awardee)
- •Processor as the brain of electronic devices
- •Instruction execution: turning code into actions via 1s and 0s
- •Processors underpin anything ‘smart’ that acts autonomously
- 2:49 – 8:33
Shakti’s origin: building what India couldn’t access (and discovering RISC‑V)
Neel recounts how limited access to modern proprietary processor tech pushed the IIT Madras team to build their own path. They evaluated OpenPOWER but found it impractical for academia, then adopted the early, compact RISC‑V spec—leading to Shakti’s creation and naming.
- •Problem: top institutes in India got only old/limited proprietary tech access
- •Innovation needs resources; curiosity alone isn’t enough
- •OpenPOWER was paid, complex, and not suitable as a starting point
- •Early engagement with Berkeley’s emerging RISC‑V spec
- •Shakti name: ‘POWER’ translated to Sanskrit; pivot to RISC‑V enabled execution
- 8:33 – 10:41
From academic project to strategic adoption: parity goals and first real customers
The Shakti team’s initial goal wasn’t to beat the world—it was to match what India already used and begin replacements in strategic sectors. Neel explains early engagement with DRDO and the push for ‘product thinking’ rather than publishing-only outcomes.
- •Goal: parity with processors used in Indian strategic systems
- •Built a basic pipeline processor and targeted real replacement opportunities
- •Early collaboration with DRDO to replace older MIPS-based systems
- •Commercial mindset: don’t build in a vacuum; build for usability
- •Shakti as an indigenous mission tied to national self-reliance
- 10:41 – 15:05
What InCore does: cores, subsystems, SoCs—explained with an IIT campus analogy
Neel transitions to InCore’s mission: delivering RISC‑V solutions beyond just CPU cores. He breaks down chip composition—core vs subsystem vs SoC—and maps each piece to an IIT Madras campus analogy to make the architecture intuitive.
- •InCore delivers RISC‑V ‘solutions’: cores + subsystems + SoCs + surrounding IP
- •Core as computational engine; SoC/subsystem includes memory, peripherals, interconnect
- •Campus analogy: admin building (core), gates/peripherals, roads (NoC/interconnect), security, departments/accelerators
- •Selling just a core is hard—customers want an integrated, usable platform
- •InCore aims to enable fast ‘mix and match’ system construction
- 15:05 – 20:46
Selling semiconductor IP: what customers receive and how IP is (imperfectly) protected
The conversation unpacks what ‘IP’ means in semiconductors: not a chip, but hardware design code and deliverables. Neel explains typical protections (obfuscation/encryption), the trade-off with debuggability, and InCore’s approach of keeping high-level sources private while sharing Verilog outputs.
- •IP in chip design is delivered as code (e.g., Verilog), not physical silicon
- •Design written in higher-level languages (e.g., Bluespec) then converted for customers
- •Protection methods: encryption/obfuscation vs customer need for visibility/debugging
- •InCore keeps high-level ‘secret sauce’ closed and shares low-level Verilog
- •Full protection is unrealistic; too much locking makes IP unusable
- 20:46 – 27:52
Chip design lifecycle: 12–18 months, and why InCore targets the first 4 months
Neel lays out the end-to-end chip lifecycle from spec to demo, highlighting that the earliest phase (spec-to-RTL freeze) alone can consume months. He explains why conventional flows are serialized across design, verification, FPGA prototyping, and software bring-up—and how parallelizing with ready collaterals can shrink timelines dramatically.
- •Full chip journey: spec → RTL → physical design → fab → packaging → boards → demo
- •Typical cycle: 12–18 months; early design phase often ~4 months
- •Integration requires procuring many licensed IP blocks (Wi‑Fi, Bluetooth, etc.)
- •Conventional flow is serialized, delaying software and validation teams
- •InCore aims to provide day-one collaterals (HW/SW/emulation/verification) to compress iteration
- 27:52 – 31:59
Making silicon innovation faster: SoC generator platform, PPA trade-offs, YAML-like abstraction
Neel introduces InCore’s SoC generator concept: rapidly generating SoC variants and iterating on power-performance-area (PPA) trade-offs without manual RTL surgery. The platform turns architectural changes into higher-level configuration changes and can deliver verification suites early, enabling many iterations in short time windows.
- •SoC generator = rapid composition and re-composition of reusable IP blocks
- •Enables fast exploration of trade-offs (performance vs power vs area)
- •PPA defined and tied to real product constraints (battery life, frequency, cost/size)
- •Manual RTL edits are slow; generator makes changes via configuration (e.g., YAML)
- •Outputs include more than RTL—also verification/test collateral to start from day one
- 31:59 – 36:00
Why AI won’t ‘take over’ chip design soon: data scarcity, hallucinations, and trust
The host challenges why AI can’t do chip generation overnight. Neel argues AI can help as a copilot (especially for verification), but end-to-end generation is blocked by risk, reproducibility requirements, lack of open training data, and proprietary advantage held by large incumbents with decades of internal design data.
- •AI today is a copilot, not a fully trusted autonomous generator for chips
- •Verification can benefit, but humans must stay in the loop due to risk/recall costs
- •Hallucinations and non-determinism are unacceptable for silicon sign-off
- •Training data is scarce and often academic, producing non-productized outputs
- •AI may become an interface to SoC-gen tools rather than the generator itself
- 36:00 – 41:29
Staying in India: the paper-shredder moment and building for strategic sovereignty
Neel shares a personal turning point: preparing US university applications until Prof. Kamakoti challenged him—leading to shredding the documents and committing to build in India. The discussion connects this mindset to national security concerns: inability to reverse engineer chips, potential backdoors, and the need for indigenous control over critical infrastructure.
- •Anecdote: shredding foreign university applications after mentorship intervention
- •Patriotism and ‘build, not just consume’ as a driving force
- •Strategic risk: dependence on foreign chips for defense, grids, banking, Aadhaar, etc.
- •Chips are hard to audit; you can’t easily prove what a chip does *not* do
- •Shakti positioned as part of the answer, but needs broader commercialization/adoption
- 41:29 – 45:13
From researcher to founder: ‘what’s possible’ vs ‘what’s needed’ and selling before building
Neel reflects on the transition from academia to entrepreneurship—shifting from optimizing technology to understanding market needs. He emphasizes learning to listen, shipping earlier, and validating demand because building the wrong semiconductor product can waste years.
- •Academia optimizes for possibility; startups must optimize for need
- •Engineers tend to over-perfect; customers often value early, imperfect solutions
- •‘Sell before you build’ is crucial in an 18-month product cycle industry
- •First customer interactions de-risk direction and prevent costly misalignment
- •Mindset shift: stop thinking only in engineering hours—think company and market
- 45:13 – 53:56
Scaling an IP startup: first customer, investor expectations, and the fear of attempting
The conversation moves to the realities of scaling: winning the first ‘silicon-proof’ customer, managing investors/government/customer pulls, and shortening sales cycles through references. Neel highlights a key founder lesson—ask hard questions early, even without leverage, to detect red flags and avoid being led astray.
- •‘Silicon-proof’: others trust you after someone successfully ships with your IP
- •First customer is hardest and can require extreme flexibility and support
- •Founders are always selling: to employees, investors, and customers
- •Competing priorities can pull product direction; market clarity matters
- •Overcoming fear of attempting/asking for guarantees helps avoid bad partnerships
- 53:56 – 1:00:10
RISC‑V in the world: breaking ISA monopolies and enabling open opportunity
Neel explains instruction sets as the critical interface between hardware and software—and why proprietary ISAs created monopolies (x86, Arm, Power). RISC‑V changes the game with a simple, extensible, permissive model that enables customization and broad ecosystem participation, positioning it as a durable global standard.
- •ISA is the hardware–software contract; controlling it controls ecosystems
- •Major proprietary ISA blocks: x86 (Intel), Arm (mobile/embedded), Power (servers)
- •RISC‑V offers a small base and extensibility vs large mandatory instruction sets
- •Permissive model: not copyleft; enables commercial customization without fees
- •Broad adoption through major companies and a thriving standards community
- 1:00:10 – 1:11:52
India-specific innovation + closing advice: curriculum, DLI support, and building with long-term responsibility
Neel connects RISC‑V openness to India’s ability to build ground-up solutions for local constraints and strategic needs. He closes with advice for young builders: reduce fear of failure, take advantage of improved ecosystem support (like DLI), and balance ambition with long-term thinking—including personal reflections on becoming a father while building a startup.
- •Open ecosystems help build India-specific solutions rather than importing ill-fitting ones
- •Need for broader RISC‑V adoption and updated curriculum to avoid ‘old styles’
- •Government initiatives (e.g., DLI) materially reduce tooling costs for startups
- •Advice: don’t fear failure; ask ‘stupid’ questions; attempt boldly
- •Personal reflection: fatherhood adds urgency, maturity, and long-term perspective
