Published: September 2026
2030 status: This article is intended to be revisited and updated as the decade unfolds.
There is a semiconductor story taking shape around India that is potentially much larger than the construction of a single fabrication plant.
At first glance, the story is straightforward: Tata Electronics is building India's first major commercial 300mm semiconductor fab at Dholera, Gujarat, in partnership with Taiwan's Powerchip Semiconductor Manufacturing Corporation, or PSMC. Tata currently describes the facility as a 50,000-wafer-per-month fab for analog and logic chips covering 28nm to 110nm technologies. Its intended markets include high-performance computing, communications, automotive, IoT and data storage.
That alone would be a major milestone for India.
But there is another revolution occurring at the same time.
Across universities, research laboratories, companies and open-source communities, increasingly sophisticated processor and accelerator designs are becoming available as reusable hardware.
RISC-V has turned the instruction set into an open standard. Open-source CPU projects are moving from tiny microcontrollers towards Linux-capable out-of-order processors. Open GPUs are beginning to acquire real graphics pipelines. Open NPUs are emerging from both universities and major technology companies. Open video processors, ISPs, storage controllers, networking cores, security processors and SoC frameworks are multiplying.
And the semiconductor design toolchain itself is becoming increasingly open.
Put those developments together with an Indian fab, and the question changes.
It is no longer simply:
Can India manufacture semiconductors?
The more interesting question is:
Could India, by the end of this decade, manufacture chips assembled from an increasingly complete ecosystem of open, modifiable and reusable silicon?
And if the answer is yes, another question follows:
Could the resulting hardware become competitive enough that an open-silicon laptop, workstation, industrial computer or even mobile platform is not merely an experiment, but a genuinely useful daily-driver product?
This is the possibility explored in this article.
First, a necessary distinction: what Dholera is today, and what it might become
It is important not to get ahead of the evidence.
As of September 2026, Tata Electronics officially describes the Dholera fab as a 28nm-to-110nm facility. The company says it is being developed with PSMC and that the technology portfolio includes 28nm, 40nm, 55nm, 90nm and 110nm processes.
Therefore, any discussion in this article of 22nm, FD-SOI or more advanced processes at Dholera is a future scenario, not a claim that Tata has already committed to those nodes at Dholera.
This distinction matters particularly because the PSMC technology-roadmap graphic accompanying this article shows a much broader progression of semiconductor technologies, including multiple logic generations and different memory and specialty processes. That roadmap should be read as a representation of the broader PSMC technology trajectory, not as a promise that every future PSMC process will automatically be transferred to Dholera.
Nevertheless, it is reasonable to ask what could happen if Dholera eventually moves beyond its initial technology portfolio.
There is precedent for thinking about 22nm as a particularly interesting destination.
IIT Madras has already fabricated an open SHAKTI processor on Intel's 22nm FinFET process. The RISECREEK SHAKTI chip was manufactured in 22nm, reached a reported 350MHz maximum closure frequency and successfully booted Linux.
Europe's eProcessor project has also fabricated a 64-bit out-of-order RISC-V processor in 22nm GlobalFoundries technology and successfully deployed silicon capable of running Linux. The European Commission's project reporting records fabrication of the single-core eProcessor ASIC at GlobalFoundries using a 22nm process.
In other words, the proposition that an open RISC-V processor can reach physical 22nm silicon is no longer theoretical.
It has already happened.
The bigger story is not 22nm. It is the stack.
A modern computer is not a CPU.
A smartphone is not a CPU.
A laptop is not a CPU.
Even an AI accelerator is not simply an accelerator.
Modern computing devices are systems containing dozens of specialised hardware blocks.
- CPU cores
- GPU cores
- vector processors
- NPUs and AI accelerators
- video encoders and decoders
- image signal processors
- memory controllers
- PCIe controllers
- USB controllers
- display controllers
- Ethernet controllers
- storage controllers
- security processors
- DMA engines
- interrupt controllers
- clocking infrastructure
- debug interfaces
- power-management logic
- wireless digital logic
- and a huge amount of glue logic.
Historically, much of that IP has been proprietary.
A company wanting to build a chip might therefore have to purchase a CPU licence, a GPU licence, an NPU licence, a PCIe controller, a USB controller, a video engine, a security block, a memory subsystem and numerous PHYs.
The licence bill can become enormous before the company has manufactured a single wafer.
The open-hardware movement attacks that problem from the opposite direction.
Instead of asking:
Which semiconductor company will sell me this IP?
the designer increasingly has another question:
Which open implementation can I start from?
That is the fundamental change.
RISC-V is the foundation, but RISC-V is not itself an open CPU
One of the most important distinctions in this entire discussion is the difference between an open instruction-set architecture and an open processor implementation.
RISC-V is an open standard ISA. It specifies the instructions and architectural interfaces that a compatible processor implements. It does not itself constitute a CPU design.
A RISC-V implementation can be open source, proprietary, licensed commercially or developed privately.
That distinction is important because the real revolution comes from the combination:
Open ISA + open processor implementations + open accelerators + open SoC infrastructure + open software + increasingly open EDA.
That is the stack.
India already has a serious starting point: SHAKTI
India does not need to invent its open CPU ecosystem from scratch.
IIT Madras has been developing SHAKTI since 2014, with the objective of creating production-grade processors, SoCs, development boards and associated software. The project presents the initiative as an open processor-development ecosystem, with its components released under a three-clause BSD licence.
SHAKTI is also broader than a single CPU.
Its roadmap contains multiple processor classes.
The E-Class targets low-power embedded applications. The C-Class targets controller and mid-range workloads. The I-Class is designed for higher-performance applications and incorporates out-of-order execution, multithreading, aggressive branch prediction and non-blocking caches. SHAKTI's M-Class roadmap targets mobile configurations, while its S-Class and H-Class roadmaps extend towards workstation, enterprise, HPC and accelerator-heavy systems.
This is precisely the kind of architecture family that becomes interesting when a country has access to domestic fabrication.
India doesn't need one universal processor.
It needs a family of processors that can be customised for different products.
The significance of the SHAKTI 22nm tapeout
The SHAKTI RISECREEK tapeout deserves particular attention because it destroys one common misconception.
Open Indian processor design is not synonymous with old 180nm silicon.
RISECREEK was fabricated by Intel on a 22nm FinFET process. IIT Madras reports a 350MHz maximum closure frequency, Linux support and an open-source design including peripherals.
The later IRIS-LV tapeout at SCL Chandigarh demonstrates a different capability: taking a SHAKTI-derived design through an Indian fabrication, packaging and board ecosystem, albeit on a much older 180nm CMOS process.
Those two achievements are complementary.
22nm SHAKTI demonstrated advanced-node open CPU silicon.
Indian SCL tapeouts demonstrated an Indian end-to-end manufacturing path.
Dholera potentially brings those two trajectories closer together.
Europe has already demonstrated the next piece: eProcessor
The European eProcessor project may be one of the most relevant projects to the Dholera story.
It was designed around RISC-V and aimed to create an open full-stack ecosystem combining a high-performance out-of-order processor with accelerators, software and supporting infrastructure.
The project completed synthesis, place-and-route and physical design and fabricated a single-core eProcessor ASIC using a 22nm GlobalFoundries process. It also developed Linux, Zephyr, OpenAMP and compiler support around the platform.
In October 2025, RISC-V International reported that the resulting European 22nm out-of-order RISC-V processor had successfully been deployed and was running Linux.
This is important for two reasons.
First, it demonstrates that open RISC-V need not remain synonymous with tiny embedded controllers.
Second, it provides an example of a European semiconductor ecosystem combining academic research, industrial participation, open hardware, accelerators, software and actual silicon.
That becomes particularly interesting when viewed alongside the rapidly deepening India–Europe semiconductor relationship.
The India–Netherlands connection changes the strategic picture
In May 2026, India and the Netherlands elevated their bilateral relationship to a Strategic Partnership for 2026–2030.
The roadmap specifically identifies semiconductors as a priority and calls for cooperation on semiconductor supply chains, research and development, technology-value-chain partnerships, startups and talent development. It also calls for connecting the Dutch Semicon Competence Centre with India's Semiconductor Mission.
Perhaps more significantly, the roadmap explicitly mentions cooperation between Eindhoven University of Technology and the University of Twente and six Indian technical institutions — IISc, IIT Bombay, IIT Delhi, IIT Gandhinagar, IIT Guwahati and IIT Madras — with support from NXP, ASML, Tata and CG Semi.
This is not merely diplomatic language about "cooperation in technology".
It is the beginning of a semiconductor knowledge and industrial network.
And it is being reinforced by actual industrial agreements.
In May 2026, Tata Electronics and ASML announced a strategic partnership under which ASML would support the establishment and ramp-up of the Dholera fab with lithography tools and solutions, while the two companies would cooperate on talent, supply-chain resilience and R&D infrastructure.
Meanwhile, the EU and India concluded negotiations for a Free Trade Agreement in January 2026, creating another layer of economic integration between India and Europe. The agreement remains subject to signature and the required internal procedures before becoming legally binding.
None of this proves that European 22nm FD-SOI technology will be transferred to Dholera.
But it makes the idea of increasingly deep semiconductor technology cooperation between India and Europe considerably less speculative than it would have been a decade ago.
The FD-SOI wildcard
One of the most interesting possibilities for the second half of this decade is the emergence of a 22nm-class FD-SOI process capability in India.
It is important not to oversimplify this.
Moving from bulk CMOS to FD-SOI is not simply a matter of changing the standard-cell library.
FD-SOI requires its own wafer/substrate ecosystem, device structures, process integration, PDK, libraries, SRAM, analogue and RF components, body-bias infrastructure and manufacturing qualification.
So it would be wrong to say that moving from conventional 22nm CMOS to 22nm FD-SOI would require "no R&D".
It would require substantial R&D.
But there is an important reason to take the idea seriously.
GlobalFoundries' 22FDX technology was explicitly developed as a 22nm two-dimensional fully-depleted silicon-on-insulator process, leveraging the company's 28nm platform. GF positioned it as a lower-cost alternative to FinFET for mainstream mobile, IoT, RF connectivity and networking applications. It also introduced dynamic body-bias control that allows designers to trade performance, power and leakage.
That is a very different transition from jumping from planar CMOS to a completely new three-dimensional FinFET manufacturing architecture.
And it is particularly relevant to the kinds of systems being discussed here.
Low-power CPUs.
NPUs.
IoT controllers.
RF connectivity.
Automotive electronics.
Edge AI.
Wearables.
Mobile processors.
Industrial control.
FD-SOI is not necessarily the right process for every one of these products. But it is sufficiently relevant that it deserves to be considered as a potential future branch of India's semiconductor technology tree.
The strategic question is therefore not simply:
Will India get 22nm?
It is:
Which 22nm technology platforms will India eventually have access to, and what ecosystem of IP will exist around them?
Google's Coral NPU is a sign of where the industry is going
One of the most revealing developments of 2025–2026 came from Google.
Google's original Coral Edge TPU is proprietary silicon.
But Google's newer Coral NPU is fundamentally different.
Google describes Coral NPU as an open-source NPU architecture intended for silicon partners and chip companies to integrate into their own products. The hardware and software are released under Apache 2.0, and Google says there are no licence fees payable to Google for use of the Coral NPU architecture or toolchain.
The design is RISC-V based and combines scalar, vector and matrix-style processing. Google describes a target of 512 GOPS using 256 MACs per cycle and an ultra-low-power target of roughly 6mW at 1GHz using 22nm technology.
That is extraordinarily relevant to this article.
Because Google has effectively demonstrated a transition in philosophy:
Proprietary Edge TPU → open NPU IP that other chip companies can integrate.
That is exactly the direction of travel that makes an open-silicon ecosystem interesting.
And Google's roadmap is itself unfinished. The initial Coral NPU release contains the scalar and vector components, while a future matrix execution unit is intended to complete the broader RISC-V NPU architecture.
By 2030, the Coral NPU of today may therefore look like the first generation of a much more capable open AI accelerator family.
NVDLA and Gemmini: the other open AI paths
Google is not alone.
NVIDIA's NVDLA project provides a free and open architecture for deep-learning inference accelerators. The open hardware repository contains RTL, test infrastructure and supporting material, and the architecture is designed to be scalable and configurable.
Berkeley's Gemmini takes another approach: it is a generator for customisable systolic-array accelerators that can be integrated with RISC-V processors such as Rocket and BOOM.
The significance is not that one of these projects will necessarily become India's NPU.
The significance is that a future chip designer may have several architectures to choose from.
And then modify them.
That is the beginning of a real IP ecosystem.
Open GPUs are the hardest test — and Vortex is changing the argument
If open CPUs are now plausible and open NPUs are becoming increasingly credible, the GPU remains the difficult frontier.
GPUs are not merely collections of arithmetic units.
A commercially useful GPU needs:
- shader execution
- thread scheduling
- memory management
- caches
- rasterisation
- texture processing
- display output
- compiler infrastructure
- drivers
- graphics APIs
- debugging
- and increasingly ray tracing and AI acceleration.
Vortex is therefore one of the most important projects to watch.
Its original research implementation demonstrated a complete open RISC-V GPGPU stack on FPGA, scaling to 32 cores on an Altera Stratix 10 and reporting 25.6 GFLOPS at 200MHz.
But the important development is what happened afterwards.
Vortex 3.0, released in June 2026, introduced a fixed-function graphics stack including a rasteriser, texture units and output mergers. It also added tensor-core structured sparsity, warpgroup matrix multiplication, a hardware kernel-management unit, a command processor, virtual-memory support, Vulkan support through Mesa, HIP integration and ASIC synthesis flows.
That is a substantial change in character.
Vortex is no longer merely an interesting open research GPU.
It is becoming a candidate for an increasingly complete graphics-and-compute platform.
Could an open GPU reach 1 TFLOPS by 2030?
Yes — as a scenario, that is entirely plausible.
But it should not be presented as a prediction with false precision.
For example, a GPU with 256 FP32 FMA lanes operating at 2GHz would theoretically provide:
256 × 2GHz × 2 FLOPs per FMA = 1.024 TFLOPS.
Alternatively, a larger number of lanes running at a lower frequency could reach the same theoretical figure.
Whether such a design would be sensible at 22nm depends on die area, memory bandwidth, cache architecture, power consumption, physical design and the workload.
But the arithmetic demonstrates something important:
One TFLOPS is not an impossible architectural target for a 22nm-class open GPU.
The harder problem is everything surrounding the arithmetic.
A 1-TFLOPS GPU without good memory bandwidth is not necessarily a good GPU.
A 1-TFLOPS GPU without mature drivers is not a good GPU.
A 1-TFLOPS GPU without rasterisation, texture processing and a graphics API is not a gaming GPU.
And a 1-TFLOPS GPU without a competent CPU and software ecosystem does not make a useful PC.
This is precisely why Vortex 3.0's progress in graphics, Vulkan, texture processing, rasterisation and ray tracing is more important than a raw FLOPS number.
The first commercially important open GPU does not need to beat NVIDIA
This is perhaps the wrong comparison to make.
The first successful open GPU does not need to compete with the fastest discrete GPU in the world.
It needs to be good enough for a meaningful market.
That market could include:
- industrial displays
- embedded graphics
- education
- thin clients
- office PCs
- development boards
- digital signage
- robotics
- edge AI
- cloud visualisation
- older games
- competitive and eSports workloads.
Competitive gaming may actually be a particularly interesting target.
Many eSports workloads do not require the enormous GPU resources demanded by the latest cinematic AAA games at maximum settings.
A future open GPU in roughly the 1-TFLOPS class, with decent memory bandwidth, a competent rasteriser, mature Vulkan support and good drivers could plausibly make a meaningful number of mainstream and competitive games playable.
That does not mean that we can promise specific 2030 game titles today. Game engines, APIs, anti-cheat systems and driver requirements will determine compatibility.
But the broader proposition is entirely reasonable:
The first commercially successful open gaming GPU does not need to defeat the world's fastest GPUs. It needs to make the open hardware ecosystem useful enough that people actually want to use it.
The CPU performance question is equally interesting
There is a common misconception that proprietary CPU IP is inherently faster than open CPU IP.
It isn't.
Performance comes from architecture and implementation.
Branch prediction.
Instruction scheduling.
Out-of-order execution.
Cache design.
Memory latency.
Vector units.
Clock frequency.
Physical implementation.
Compiler optimisation.
Power and thermal limits.
The fact that a CPU is open source does not prevent it from implementing an excellent microarchitecture.
And several projects are already moving in that direction.
XiangShan is an open high-performance RISC-V processor project from China.
BOOM is Berkeley's open out-of-order RISC-V processor.
CVA6 is a configurable Linux-capable RISC-V core.
BlackParrot is an open Linux-capable coherent multicore.
eProcessor has already reached 22nm silicon.
SHAKTI has both open architecture and physical silicon history.
The gap between "research processor" and "serious CPU" is therefore narrowing.
And the 22nm FD-SOI question makes the comparison even more interesting
GlobalFoundries' 22FDX platform was specifically designed around the performance/power/cost balance needed by mainstream mobile, IoT, RF and networking applications. GF highlighted operating voltages as low as 0.4V and dynamic body-biasing as major features.
The technology was also developed as an extension of an existing 28nm platform rather than as a completely different three-dimensional transistor architecture.
This does not make an eventual Dholera transition to FD-SOI easy.
But it makes the idea technically interesting.
If India eventually possessed:
28nm bulk CMOS
22nm-class CMOS
22nm-class FD-SOI
then different portions of the computing ecosystem could be matched to different processes.
A high-performance logic SoC might use one process.
An ultra-low-power wearable processor another.
An RF/connectivity device another.
A display driver or PMIC could remain on a mature node.
There is no reason for semiconductor sovereignty to mean one process node for everything.
Video processing: Fudan's OpenASIC demonstrates how far the idea extends
The CPU and GPU are only part of the story.
Fudan University's Video & Image Processor Laboratory has been developing open hardware video-processing IP through its OpenASIC initiative.
The laboratory has released open H.264 and H.265 encoder IP. Its H.265 project describes a synthesizable hardware encoder supporting HEVC Main Profile and targeting 4K at 30fps at 400MHz.
The H.264 project similarly provides synthesizable RTL and has been demonstrated on FPGA platforms.
These projects are a reminder that the open-silicon revolution is not about CPUs alone.
A future SoC could potentially contain:
RISC-V CPU + GPU + NPU + ISP + video encoder + security processor + storage controller.
And each component does not necessarily need to come from the same organisation.
Open ISPs could matter enormously for phones
Camera processing is one of the defining workloads of a smartphone.
Infinite-ISP is an open camera image-processing pipeline containing a growing set of image-processing modules and reference implementations, released under Apache 2.0. The project explicitly targets ASIC and FPGA design and verification.
This is an excellent example of how open hardware can evolve from an algorithmic reference implementation into a potential silicon subsystem.
By 2030, the important question will not be whether today's Infinite-ISP can compete directly with the image processors inside Apple's or Qualcomm's most advanced mobile SoCs.
The question will be whether the open ecosystem can iterate fast enough to make a good-enough camera pipeline that a manufacturer can customise for its own sensors and computational-photography algorithms.
That is a much more achievable target.
Storage is another major opportunity
Storage controllers are less glamorous than CPUs and GPUs, but they are commercially important.
IIT Madras has a particularly interesting historical contribution here.
An open-source implementation of an NVMe controller from IIT Madras was built in Bluespec and demonstrated on Xilinx FPGAs. Contemporary documentation from the Linux storage community described it as an open-source NVMe controller capable of running on Artix-7, Kintex-7 and Virtex-7 FPGA platforms.
This is exactly the kind of project that becomes interesting in a future open-silicon environment.
Consider a hypothetical Indian SSD controller:
- RISC-V CPU
- PCIe controller
- NVMe controller
- DMA engine
- ECC
- flash-translation layer
- encryption
- compression
- DRAM interface
- NAND interface.
The complete controller does not need to be written from scratch.
It can be assembled from generations of existing work.
The same is true of OpenSSD, which has existed for years as a platform for open SSD firmware and storage research.
The boring IP could become the most commercially important IP
There is an understandable tendency to focus on SHAKTI, XiangShan, Vortex and NPUs.
But the less glamorous hardware blocks may actually determine whether an open SoC becomes practical.
PCIe.
Ethernet.
SATA.
SD.
USB.
Display interfaces.
DMA.
Timers.
Memory controllers.
Debug interfaces.
LiteX is particularly relevant here.
LiteX provides a configurable SoC-building environment and an ecosystem containing components for buses, memory, Ethernet, PCIe, SATA and other common interfaces.
LitePCIe provides a configurable PCIe core under a permissive BSD licence.
LiteSATA provides a configurable SATA core.
LiteSDCard provides an open SD-card controller.
These projects are not necessarily ready to be dropped into a commercial smartphone unchanged.
That is not the point.
The point is that the designer is increasingly starting with something.
HDMI and USB illustrate the boundary between open digital IP and proprietary physical interfaces
HDMI provides a useful warning about what "open" really means.
The HDL-util HDMI project provides SystemVerilog for HDMI 1.4b output and is dual-licensed under MIT and Apache 2.0. It has been tested on FPGA platforms.
But the existence of open RTL does not automatically mean open standards compliance, open PHYs or zero commercial obligations.
Therefore:
Open RTL does not automatically mean open standards compliance, open PHYs or zero commercial obligations.
The same principle applies to USB-C, PCIe and high-speed interfaces.
The digital controller may be open.
The PHY may still need licensed IP.
The analogue interface may still be proprietary.
The finished product may still need certification.
This distinction is one of the most important caveats in the entire open-silicon thesis.
Wireless is likely to remain the hardest frontier
Wi-Fi and Bluetooth present a similar problem.
OpenWiFi is a remarkable open-source IEEE 802.11 platform containing FPGA hardware, drivers and software, and supporting SDR-based experimentation. It currently covers 802.11a/g/n functionality and has been used for research into channel-state information, packet injection, radar and other applications.
But OpenWiFi is not the same thing as a complete commercial smartphone Wi-Fi/Bluetooth chip.
RF is difficult.
It requires:
- analogue circuitry
- ADCs and DACs
- PLLs
- power amplifiers
- low-noise amplifiers
- filters
- calibration
- antenna interfaces
- process-specific device models
- regulatory compliance.
Therefore, the realistic 2030 vision is not "everything will be open".
It is:
More and more of the digital portion of the system will be open, while specialised analogue, RF, PHY and certification components may remain licensed or proprietary.
Open security hardware may be just as important as open CPUs
OpenTitan is another crucial piece of the puzzle.
It is an open-source silicon Root of Trust project backed by Google and the broader lowRISC ecosystem.
A future sovereign SoC cannot simply be fast.
It needs:
- secure boot
- key management
- hardware cryptography
- random-number generation
- debug security
- device identity
- firmware verification
- secure update mechanisms.
An open Root of Trust is therefore potentially more strategically important than an open CPU.
The CPU can be replaced.
The security architecture determines whether the entire system can be trusted.
The 2030 Open Silicon Stack
The following is the working watchlist I would use for this article between 2026 and 2030. It deliberately mixes mature projects, silicon-proven projects, research projects and emerging projects.
It is not a claim that every project below is commercially ready today. The purpose is to track the ecosystem and ask how many of these projects could move up the maturity ladder by 2030.
| Layer | Project | Function | 2026 maturity | Licence / model | Silicon / FPGA evidence | 2030 potential | Main missing piece |
|---|---|---|---|---|---|---|---|
| ISA | RISC-V | Open processor ISA | Very mature | Open standard | Huge silicon ecosystem | Foundational | Software compatibility discipline |
| CPU | SHAKTI | Indian RISC-V CPU/SoC family | High | BSD-3-Clause | 22nm + 180nm silicon | Very high | Higher-performance production hardening |
| CPU | eProcessor | European OoO RISC-V | High | Project/component specific | 22nm ASIC | Very high | Further performance/productisation |
| CPU | XiangShan | High-performance OoO RISC-V | High | Mulan PSL family | FPGA/ASIC ecosystem | Very high | Commercial physical-design ecosystem |
| CPU | BOOM | Out-of-order RISC-V | High | BSD family | FPGA/ASIC research | High | Product hardening |
| CPU | CVA6 | Linux-capable application CPU | High | Solderpad/Apache-compatible | ASIC/FPGA; 22nm FDSOI research history | Very high | Foundry-specific optimisation |
| CPU | BlackParrot | Linux-capable multicore | High | BSD-3-Clause | ASIC/tapeout history | High | Product ecosystem |
| CPU | Ibex | Small secure RISC-V core | High | Apache-2.0 | FPGA/silicon ecosystem | Very high for embedded/security | Performance ceiling |
| CPU | PicoRV32 | Compact RV32 CPU | Very mature | ISC | Extensive FPGA/ASIC use | Excellent for controllers | Not intended for laptop-class compute |
| CPU | VexRiscv | Configurable FPGA-friendly RISC-V | High | MIT | Extensive FPGA use | High for embedded/SoC | Application-class performance |
| CPU | CV32E40P | Embedded RISC-V | High | Solderpad | OpenHW ecosystem | Very high for controllers | Not laptop-class |
| Security CPU | OpenTitan | Root of Trust / security subsystem | Very high | Apache-2.0 default | Silicon deployment | Essential | Process-specific integration |
| GPU | Vortex | RISC-V GPGPU + graphics | Rapidly advancing | Open/BSD ecosystem | FPGA + ASIC flows | Potentially transformative | Drivers, performance, ecosystem |
| GPU | NyuziProcessor | Experimental GPGPU/graphics | Research | Open | FPGA | Interesting research base | Commercial maturity |
| GPU | MIAOW | Open GPU compute architecture | Research/historical | Open research | RTL/FPGA | Possible source material | Modernisation |
| NPU | Coral NPU | Google open edge-AI accelerator | Emerging/high potential | Apache-2.0 | Open RTL; silicon partners emerging | Very high | More generations + silicon |
| NPU | NVDLA | Configurable deep-learning accelerator | Mature open architecture | NVDLA Open Hardware licence | ASIC/FPGA ecosystem | High | Modernisation and ecosystem |
| NPU | Gemmini | Configurable systolic AI accelerator | High | Apache-2.0 | FPGA/ASIC research | Very high | Production optimisation |
| Vector | Ara | RISC-V Vector processor | High | Solderpad | FPGA/ASIC research | Very high | SoC integration |
| VPU | OpenASIC xk265 | H.265/HEVC encoder | Medium/high | Open source | FPGA demonstrations | High | Verification, newer codecs |
| VPU | OpenASIC xk264 | H.264 encoder | Medium/high | Open source | FPGA demonstrations | High for legacy/media | New codec generations |
| ISP | Infinite-ISP | Camera image-processing pipeline | Emerging | Apache-2.0 | ASIC/FPGA-oriented reference | High | Sensor tuning / silicon validation |
| Storage | IIT Madras NVMe Controller | Open NVMe controller | Research-proven | Open | FPGA | High | Modern NVMe + NAND/FTL hardening |
| Storage | Cosmos/OpenSSD | Open SSD platform | High for research | Open | FPGA + ARM | High for specialised storage | Commercial NAND/PHY ecosystem |
| PCIe | LitePCIe | PCIe controller | High | BSD-2-Clause | FPGA | Very high | SerDes PHY |
| Ethernet | LiteEth | Ethernet MAC | High | BSD family | FPGA | Very high | High-speed PHY |
| SATA | LiteSATA | SATA controller | High | BSD-2-Clause | FPGA | High | PHY |
| SD | LiteSDCard | SD-card controller | High | BSD-2-Clause | FPGA | Very high | Physical interface |
| Display | HDL-util HDMI | HDMI 1.4b digital logic | Medium | MIT/Apache-2.0 | FPGA | High for digital portion | PHY/compliance/licensing |
| Wireless | OpenWiFi | 802.11 digital/baseband stack | Research/advanced | AGPL + third-party components | FPGA/SDR | High for digital research | RF PHY/certification |
| SoC | LiteX | SoC builder and integration ecosystem | High | BSD | Extensive FPGA | Extremely important | ASIC-specific infrastructure |
| EDA | OpenROAD | RTL-to-GDS physical design | High | BSD-3-Clause | ASIC | Essential | Advanced-node enablement |
| EDA | OpenLane | Automated ASIC flow | High | Open | ASIC | Essential | Foundry-specific PDK integration |
| Hardware language | Chisel | Hardware construction language | High | Open source | Major RISC-V ecosystem use | Very high | Designer skill base |
| Hardware language | SpinalHDL | HDL/generator framework | High | Open source | VexRiscv and others | High | ASIC ecosystem integration |
| Verification | Verilator | Open RTL simulation | Very high | Open | Huge ecosystem | Essential | More complete verification flows |
| Firmware/OS | Zephyr | RTOS | Very high | Apache-2.0 | Large hardware ecosystem | Essential | Platform-specific enablement |
| OS | Linux | General-purpose operating system | Extremely mature | GPL | Massive | Foundation | RISC-V driver/GPU maturity |
| Desktop/mobile | Ubuntu | Commercial Linux platform | High on RISC-V | Open-source + commercial support | Multiple RISC-V platforms | Potential platform anchor | Consumer hardware enablement |
The CPU projects listed above illustrate the range already available. SHAKTI has actual Indian and 22nm silicon history; eProcessor has demonstrated a European 22nm out-of-order RISC-V processor; CVA6 has a published 22nm FD-SOI research pedigree; BlackParrot has an open multicore architecture; Ibex provides a highly verified small core; and PicoRV32 and VexRiscv provide lightweight configurable options.
The important point is not that these projects are interchangeable. They are not. The point is that an emerging open-silicon designer already has a menu.
The maturity ladder matters
One of the easiest mistakes in discussions of open silicon is to treat every GitHub repository as if it were a production chip.
It isn't.
There is a huge difference between:
- an architectural specification;
- synthesizable RTL;
- FPGA implementation;
- ASIC-ready RTL;
- tapeout;
- working silicon;
- silicon proven across multiple revisions;
- production qualification;
- commercial productisation;
- and a mature ecosystem with software, drivers, tools and long-term maintenance.
The 2030 story is therefore not that every project on GitHub will become commercial.
It is that many projects currently sitting somewhere around levels 2–5 could move several levels upward during the next four years.
Vortex is an excellent example.
The project has moved from a research GPU with FPGA demonstrations towards a significantly more complete architecture with graphics, Vulkan, tensor operations, virtual memory and ASIC synthesis flows.
Coral NPU provides another example: its initial open release already has a RISC-V scalar/vector architecture and an MLIR-based software stack, while the roadmap calls for a matrix execution unit in a future release.
That is the trend we should be watching.
The future of hardware may become increasingly software-driven
This phrase needs careful definition.
Hardware is not becoming software.
Transistors are still physical.
Wafer fabrication is still physical.
Packaging is still physical.
A mistake in silicon can still require another tapeout.
But the design process is becoming increasingly software-like.
A CPU can be parameterised.
A GPU can be configured.
An NPU can be generated.
A SoC can be assembled from reusable IP.
A hardware block can be forked.
Engineers can run continuous integration on RTL.
Formal verification can be automated.
Simulation can be integrated into software-development workflows.
Open EDA can increasingly automate physical implementation.
The resulting design can be version-controlled in Git.
A new generation can be created by modifying the previous generation.
This is why the analogy to software development is so powerful.
Imagine an Indian startup in 2030 developing a robotics SoC.
It might begin with a RISC-V CPU.
It adds a vector engine.
It adds a small Vortex GPU.
It integrates Coral NPU or another accelerator.
It adds Infinite-ISP.
It adds a video engine.
It integrates LitePCIe and Ethernet.
It adds an open security subsystem.
It adds its own robotics accelerator.
It modifies the cache hierarchy.
It optimises the design for the selected Dholera process.
It runs verification.
It produces a physical design.
It tapes out.
And then version 2 begins.
That is not quite software.
But it is much closer to software engineering than semiconductor design has traditionally been.
Why open silicon can eventually compete with proprietary IP
The argument should not be that open source is automatically better.
It isn't.
Commercial semiconductor companies possess extraordinary engineering capabilities.
They have huge verification teams, decades of experience, process-specific libraries, packaging expertise, certification infrastructure, compiler teams and enormous amounts of proprietary knowledge.
Open silicon will not erase those advantages by 2030.
But it can attack a different variable:
customisation.
A proprietary processor may be designed for a huge market.
An open processor can be modified for a smaller one.
A commercial GPU may contain capabilities that a robotics company does not need.
The robotics company can remove them.
A generic NPU may be inefficient for a particular model.
A company can modify the accelerator.
A storage controller can be customised for a particular NAND architecture.
A video engine can be tuned for a specific application.
The competitive advantage therefore becomes:
Open silicon + customisation + process optimisation + workload specialisation.
That combination could beat a proprietary chip in particular workloads even if the proprietary chip remains superior overall.
The 2030 performance hypothesis
Here is the proposition I believe is worth tracking over the next four years:
By 2030, for selected workloads, an open CPU/GPU/NPU fabricated on a mature 22nm-class process could be competitive with — and in some specialised workloads exceed — proprietary IP implemented on the same process generation.
This is not because open source possesses magical semiconductor properties.
It is because performance depends on architecture and implementation.
If an open CPU has a competitive out-of-order engine, branch predictor, cache hierarchy, vector unit, memory subsystem and physical implementation, there is no fundamental law of physics saying that it must be slower merely because its RTL is public.
The same is true of GPUs.
A GPU's performance depends on its compute resources, memory architecture, scheduling, graphics pipeline and software.
The open source label does not impose a performance penalty.
The real challenge is engineering effort.
And the open ecosystem is increasingly distributing that engineering effort across hundreds or thousands of contributors.
Vortex and the 1-TFLOPS thought experiment
Suppose that by 2030 a Vortex-derived GPU has:
- 256 FP32 FMA lanes;
- a 2GHz clock;
- a competent cache hierarchy;
- modern memory bandwidth;
- mature Vulkan support;
- hardware rasterisation;
- texture units;
- good shader compilation;
- and an improving Linux driver.
The theoretical FP32 peak would be approximately:
1.024 TFLOPS.
That would not make it an RTX-class GPU.
It would not make it a modern high-end gaming chip.
It would not automatically guarantee compatibility with every commercial game.
But it would change the conversation.
A one-teraflop open GPU with a credible graphics stack would be an enormously more useful platform than a purely research-oriented FPGA accelerator.
And if another four years of iteration brings Vortex from its current 3.0 architecture to several more generations, the question becomes genuinely interesting.
How much proprietary GPU IP would a 2030 low-cost computer actually need?
The first open gaming computer might not look like a gaming computer
One of the interesting possibilities is that the first commercially successful open GPU will not necessarily appear in a gaming PC.
It might appear in:
- industrial equipment;
- robotics;
- education systems;
- digital signage;
- edge AI;
- automotive displays;
- embedded computers;
- development boards.
Those markets can fund the engineering required to improve the GPU.
Gaming then becomes a secondary application.
And this is where eSports becomes particularly interesting.
A GPU does not have to run every future AAA title at ultra settings to become commercially useful.
If the open stack eventually handles a meaningful catalogue of competitive games at sensible settings, that alone could make it relevant to consumers.
The real milestone would therefore not be:
"Open GPU beats NVIDIA."
It would be:
"Open GPU is good enough that a normal person can use a computer built around it without thinking about the GPU's provenance."
The laptop is probably the most realistic flagship device
A laptop presents a much more manageable target than a smartphone.
A hypothetical 2030 Indian open-computing SoC could contain:
- 4–8 high-performance RISC-V CPU cores;
- vector extensions;
- a configurable GPU;
- an NPU;
- video encode/decode;
- display controllers;
- PCIe;
- USB;
- NVMe;
- Ethernet;
- security hardware;
- LPDDR memory controllers;
- and a collection of lower-power microcontrollers.
Such a chip would not need to compete with the fastest Apple, AMD or Intel processor of 2030.
It would need to be good at the workloads people actually perform.
Web browsing.
Office work.
Programming.
Video playback.
Light creative work.
AI-assisted applications.
Development.
Education.
Cloud computing.
And potentially light gaming.
That is a much more achievable target.
The smartphone is harder — but more transformative
A phone requires everything a laptop requires, plus substantially more.
- cellular modem;
- RF subsystem;
- GNSS;
- Wi-Fi;
- Bluetooth;
- camera ISP;
- display pipeline;
- power management;
- audio;
- security;
- ultra-low-power subsystems;
- advanced packaging.
For this reason, the first open Indian smartphone SoC is unlikely to be 100% open.
There may be licensed cellular PHYs.
There may be proprietary RF blocks.
There may be commercial memory PHYs.
There may be proprietary high-speed interface IP.
That is not failure.
It is how the real semiconductor industry works.
The goal is not ideological purity.
The goal is to reduce strategic dependence on proprietary IP wherever a competitive open alternative exists.
And this is where Canonical becomes extremely interesting
There is a slightly playful idea in the proposition of an Indian "Canonical India".
But underneath the joke is a serious strategic opportunity.
Canonical is already investing heavily in RISC-V.
Canonical says that Ubuntu has supported RISC-V since 2021 and that from Ubuntu 25.10 onwards its primary RISC-V baseline is the RVA23 profile. It is explicitly working with silicon vendors and hardware partners to make RISC-V production-ready across desktop, cloud, edge and IoT environments.
Canonical also provides Canonical-built Ubuntu images for a growing selection of RISC-V boards and platforms.
That makes Canonical a remarkably logical candidate for an eventual open Indian computing platform.
Not because Canonical is Indian.
Precisely because it isn't.
An internationally recognised operating system could give an Indian-designed SoC a global software identity from day one.
Ubuntu could provide the missing international layer
Imagine two hypothetical devices.
Device A says:
"Indian National Linux Platform."
Device B says:
"Ubuntu — RISC-V."
International developers immediately understand the second proposition.
They know what Ubuntu is.
They know how to develop for Linux.
They know the package ecosystem.
They know the tooling.
They know the community.
That matters.
India does not need to reinvent every layer of software to achieve computing sovereignty.
It should use the world's best open software wherever possible and concentrate domestic effort on the parts where sovereignty and differentiation matter.
In that model:
RISC-V provides the ISA.
Open silicon provides the hardware building blocks.
Linux provides the kernel.
Ubuntu provides the distribution and commercial support layer.
Indian companies build the devices.
Dholera manufactures the chips.
That is a coherent ecosystem.
The Ubuntu convergence idea is worth resurrecting
There is an interesting historical irony here.
Canonical previously pursued the idea of mobile/desktop convergence with Ubuntu Touch.
Canonical eventually stopped investing in its own phone and convergence effort in 2017.
But the underlying idea did not disappear.
UBports continues developing Ubuntu Touch, and its documentation explicitly describes convergence as the ability to move between phone, tablet and desktop experiences.
Imagine that idea returning in a world where the hardware itself is designed around RISC-V and open silicon.
A phone could be:
RISC-V + GPU + NPU + Linux + Ubuntu.
Connect it to a USB-C dock.
Add a monitor, keyboard and mouse.
Now it becomes a desktop.
The same SoC family could appear in a laptop.
A larger configuration could appear in a workstation.
A smaller configuration could appear in an embedded computer.
The software platform remains largely the same.
That is not merely an operating-system idea.
It is a hardware/software platform strategy.
Canonical India: the joke that could become a serious proposal
One could imagine a dedicated India-based Canonical engineering organisation working alongside Indian semiconductor companies and universities.
Call it "Canonical India" if we want to keep the joke.
Its job would not be to create an Indian fork of Ubuntu.
Its job would be to make RISC-V hardware feel boring.
That is a compliment.
The engineers would work on:
- RISC-V kernel enablement;
- GPU drivers;
- Vulkan;
- NPU frameworks;
- camera drivers;
- power management;
- suspend/resume;
- display support;
- Wi-Fi and Bluetooth;
- firmware;
- secure boot;
- OTA updates;
- hardware certification;
- Ubuntu Desktop;
- Ubuntu Core;
- mobile UX;
- developer tooling;
- and long-term support.
The objective would be simple:
Make an Indian RISC-V computer behave like a normal computer.
The real opportunity: an Indian computing platform
At this point, the story becomes larger than semiconductors.
Imagine an Indian company in 2030 developing a laptop.
It does not have to design the CPU from scratch.
It selects a mature RISC-V core.
It integrates an open GPU.
It integrates an open NPU.
It integrates an open security subsystem.
It integrates open storage and networking controllers.
It uses commercially licensed PHYs where necessary.
It adapts the design to the chosen process.
It runs the open EDA stack wherever practical.
It tapes out at Dholera.
It boots Ubuntu.
The same processor architecture appears in an educational board.
A smaller version appears in industrial equipment.
A larger version appears in a workstation.
A mobile variant appears in a smartphone.
Another version appears in an automotive controller.
Another becomes a network processor.
Another becomes an SSD controller.
The hardware is no longer a collection of isolated projects.
It is an ecosystem.
What Dholera would need to do to make this possible
There is an enormous difference between owning a fab and having an ecosystem around a fab.
If Dholera is to become a platform for open silicon, India should eventually build a Dholera Design Enablement Ecosystem.
That would include:
- foundry PDK access;
- standard-cell libraries;
- SRAM macros;
- IO libraries;
- PLL and clocking options;
- memory PHYs;
- PCIe PHYs;
- USB PHYs;
- high-speed SerDes;
- RF building blocks;
- reference design flows;
- OpenROAD/OpenLane integration where appropriate;
- commercial EDA reference flows;
- design-rule documentation;
- verification collateral;
- MPW/shuttle programmes;
- university access;
- packaging;
- testing;
- and silicon-debug infrastructure.
Tata already says its foundry offering is intended to include silicon-proven IP, verified EDA solutions, cloud-based design environments and design services.
The next step would be making that design ecosystem exceptionally accessible to universities, startups and open-hardware developers.
India should not build "the Indian CPU"
This is perhaps the most important policy recommendation in this entire article.
India should not try to create one government-approved CPU that everybody is required to use.
That would recreate the very centralisation that open hardware is trying to escape.
Instead:
Let IIT Madras develop SHAKTI.
Let other universities develop alternative cores.
Let startups fork and improve them.
Let industry develop proprietary RISC-V implementations.
Let XiangShan, BOOM and CVA6 remain alternative reference points.
Let Vortex compete with other GPUs.
Let Coral NPU compete with NVDLA and Gemmini.
Let Fudan's video IP compete with new projects.
Let open-source storage controllers evolve.
Let the best components win.
Then build systems from them.
That is how Linux became powerful.
Not because one organisation built everything.
Because thousands of developers could build on top of a common foundation.
The sovereignty argument is therefore different from simple import substitution
Semiconductor sovereignty is sometimes described as:
"We should manufacture chips in India instead of importing chips."
That is only one layer.
A deeper form of sovereignty is:
"We should possess enough of the architecture and design stack that we can create new chips without being permanently dependent on somebody else's IP roadmap."
That does not mean rejecting foreign technology.
Quite the opposite.
India can combine:
- American open hardware;
- European semiconductor research;
- Taiwanese manufacturing expertise;
- Dutch lithography;
- Chinese open processor research;
- Indian processor research;
- global Linux software;
- and domestic manufacturing.
Sovereignty does not require isolation.
It requires optionality.
The European connection could become a force multiplier
Europe has several things India needs.
Advanced semiconductor equipment expertise.
FD-SOI experience.
Automotive electronics expertise.
RISC-V research.
HPC research.
RF expertise.
Photonics.
University–industry collaboration.
And an increasingly explicit strategic interest in technological sovereignty.
India has:
- a huge engineering population;
- a rapidly expanding electronics market;
- major software expertise;
- large semiconductor design teams;
- a growing domestic manufacturing ecosystem;
- and Dholera.
The India–Netherlands 2026–2030 semiconductor roadmap explicitly provides a framework for connecting these ecosystems, including universities, ASML, NXP, Tata and India's leading technical institutes.
That is precisely the kind of network from which an open-silicon ecosystem can emerge.
What could a 2030 Indian open laptop actually look like?
Consider this as a thought experiment rather than a prediction.
The SoC
- 8 RISC-V application cores derived from an open high-performance design;
- RVA23-compatible software baseline;
- large shared cache;
- vector extensions;
- Vortex-derived GPU;
- Coral NPU or another open accelerator;
- video encode/decode;
- display controller;
- OpenTitan-derived security subsystem;
- PCIe;
- USB;
- NVMe;
- Ethernet;
- LPDDR controller.
The storage
An Indian-developed NVMe controller paired with NAND manufactured elsewhere or eventually domestically.
The operating system
Ubuntu.
The manufacturing
A Dholera 22nm-class process, if such a process is eventually qualified.
The graphics
A Vortex-derived GPU with a mature Vulkan stack.
The AI
An open NPU, potentially Coral NPU-derived or another accelerator.
The security
An open Root of Trust.
That computer would not necessarily beat the most expensive laptop in the world.
It wouldn't need to.
If it were inexpensive, efficient, secure, maintainable and open, it would already be an important achievement.
And then imagine the phone
Now take the same philosophy and shrink it.
Use the same ISA.
Use a smaller CPU cluster.
Use a smaller GPU.
Use the NPU aggressively.
Use an open ISP.
Use low-power video hardware.
Use FD-SOI if it proves advantageous.
Add licensed cellular and RF IP where necessary.
Run an Ubuntu-derived mobile platform.
Support USB-C.
Dock it.
Connect a monitor.
Connect a keyboard and mouse.
It becomes a desktop.
This is where the old Ubuntu convergence concept becomes newly interesting.
The hardware platform could finally be designed around the concept rather than trying to retrofit desktop behaviour onto a phone.
Why the next four years matter
The period between 2026 and 2030 is unusually important because several curves are moving simultaneously.
RISC-V is moving upwards.
It is no longer confined to tiny embedded cores.
Open GPUs are becoming more ambitious.
Vortex 3.0 is a particularly striking example.
Open NPUs are becoming more credible.
Coral NPU is perhaps the most interesting recent example because Google itself is releasing an architecture intended for third-party integration.
Open EDA is improving.
OpenROAD provides a unified open RTL-to-GDS flow under BSD-3-Clause.
European open silicon is reaching silicon.
The eProcessor is a concrete 22nm example.
India is building manufacturing capacity.
Dholera is the physical anchor.
India and Europe are building semiconductor links.
The 2026 India–Netherlands roadmap explicitly identifies semiconductor R&D, technology-value-chain partnerships and talent development as priorities.
These developments are individually important.
Together, they are much more interesting.
What could go wrong?
A serious article must discuss this.
1. The open projects may not mature fast enough
There is no guarantee that Vortex, Coral NPU, XiangShan, SHAKTI or other projects will become commercial-grade competitors.
2. Software could remain the bottleneck
A fast processor without drivers, compilers and applications is not a consumer platform.
3. High-speed PHYs remain difficult
PCIe, USB, HDMI, LPDDR, Wi-Fi and cellular interfaces frequently depend on analogue and mixed-signal IP that is not open.
4. Advanced PDK access could remain restricted
Open RTL does not equal open manufacturing.
5. Verification is brutally difficult
Modern SoCs contain billions of possible interactions.
6. Software fragmentation could undermine RISC-V
Custom extensions are powerful, but excessive fragmentation could make software portability harder.
This is one reason profiles such as RVA23 are important. Canonical has explicitly aligned its modern RISC-V support around RVA23 as a common baseline.
7. Smartphone modem technology is extremely difficult
The cellular modem may remain the least open component of an otherwise open mobile SoC.
8. Economics matter
A technically excellent chip can still fail if it costs more than an established alternative.
9. Fabrication yield matters
Open RTL doesn't eliminate the physical realities of semiconductor manufacturing.
These are not minor caveats.
They are the reasons why this article should be revisited annually rather than treated as a prediction carved in stone.
What would success actually look like by 2030?
Success would not mean:
"India has replaced Intel, AMD, NVIDIA, Qualcomm and Apple."
That is neither realistic nor necessary.
Success could instead look like this:
- multiple commercially useful RISC-V processors have been fabricated in India;
- at least one open GPU is genuinely usable in Linux systems;
- open NPUs are integrated into several Indian SoCs;
- open video and ISP blocks are silicon-proven;
- open NVMe/storage controllers are commercially deployed;
- open security hardware is routinely integrated;
- Indian startups can access a credible MPW/shuttle programme;
- Dholera provides a predictable PDK and reference design ecosystem;
- Ubuntu has excellent RISC-V desktop support;
- Linux GPU drivers work reliably;
- at least one Indian laptop platform is commercially available;
- at least one mobile/edge platform demonstrates convergence;
- and a significant percentage of the digital logic in those systems comes from open or internally developed IP rather than mandatory third-party licences.
That would already be transformative.
The ultimate goal should be optionality
There is a temptation to think about technological sovereignty as eliminating foreign dependence.
That is almost impossible in modern semiconductor manufacturing.
No country possesses every technology.
The smarter objective is optionality.
If a commercial GPU is better, use it.
If an ARM CPU is better for a particular product, use it.
If a proprietary PHY is necessary, license it.
But if an open RISC-V CPU is good enough, India should have the option to use it.
If an open NPU is competitive, use it.
If an open GPU becomes competitive, use it.
If an open video engine is good enough, use it.
If an open storage controller works, use it.
The strategic advantage is not that proprietary technology disappears.
It is that proprietary technology becomes a choice rather than a dependency.
The 2030 question we should bookmark today
Four years from now, this article should be read again.
We should ask:
- Did Dholera reach 28nm production?
- Did it expand its process portfolio?
- Did 22nm become available?
- Did any FD-SOI technology enter India's manufacturing ecosystem?
- Did PSMC's more advanced roadmap translate into additional Indian capability?
- Did SHAKTI move substantially up the performance curve?
- Did XiangShan reach commercially interesting performance?
- Did eProcessor lead to another European generation?
- Did Vortex reach the 1-TFLOPS-class scenario?
- Did Vortex become genuinely usable for 3D gaming?
- Did Coral NPU gain silicon deployments?
- Did the Coral matrix engine arrive?
- Did Gemmini and NVDLA evolve into more sophisticated production accelerators?
- Did Fudan's open video IP expand into newer codecs?
- Did Infinite-ISP reach silicon?
- Did IIT Madras' NVMe work evolve into a modern commercial controller?
- Did open PCIe and USB IP become easier to use in ASICs?
- Did open Wi-Fi progress beyond FPGA/SDR experimentation?
- Did OpenTitan become ubiquitous?
- Did OpenROAD close more of the gap with commercial EDA?
- Did Ubuntu become a genuinely strong RISC-V desktop platform?
- Did an Indian laptop use a predominantly open SoC?
- Did an Indian smartphone use an increasingly open application processor?
- Did Canonical become deeply involved in such a platform?
- And most importantly: did open silicon become something companies actually use because it made economic sense?
The deeper question: what if hardware starts behaving like software?
This may ultimately be the most important idea in the entire story.
For decades, hardware was dominated by scarcity.
Scarce processor architectures.
Scarce IP.
Scarce EDA tools.
Scarce manufacturing access.
Scarce knowledge.
Scarce design teams.
The software revolution demonstrated what happens when knowledge becomes reusable.
One operating system can support millions of applications.
One compiler can support thousands of projects.
One open library can be incorporated into thousands of products.
One open-source project can be forked, modified and improved by thousands of people.
Semiconductors are beginning to acquire some of these characteristics.
A processor can be forked.
A GPU can be modified.
An NPU can be integrated.
A storage controller can be adapted.
A SoC can be assembled from reusable blocks.
A physical-design flow can be automated.
A new chip generation can be created by modifying the previous one.
And increasingly, a chip's architecture can be treated as a software-defined design object long before it becomes physical silicon.
From GitHub to GDSII to Dholera
That is the sequence that could define the next phase of open hardware:
GitHub
↓
RTL
↓
Simulation and formal verification
↓
FPGA
↓
ASIC physical design
↓
GDSII
↓
Dholera
↓
Packaged silicon
↓
Ubuntu/Linux
↓
Consumer or industrial product
The distance between those steps is still enormous.
But it is shrinking.
And that is why Dholera could become more important than its wafer capacity
It would be easy to measure Dholera in wafers.
50,000 wafers per month.
300mm.
28nm.
40nm.
55nm.
90nm.
110nm.
Those numbers matter.
But the larger strategic value may eventually be measured in something else:
How many Indian and international designs can Dholera make possible?
How many startups can tape out?
How many university projects can reach silicon?
How many open-source cores become process-qualified?
How many Indian companies can build specialised chips?
How many foreign customers choose Dholera because the ecosystem makes custom silicon easy?
How many engineers learn the entire chain from architecture to wafer?
That is the metric that could matter more in the long run.
The opportunity for India is not to copy Silicon Valley
India does not need to build another Intel.
It does not need to build another NVIDIA.
It does not need to reproduce Taiwan's semiconductor industry exactly.
It could build something different.
A semiconductor ecosystem in which open architectures, open IP, Indian design talent, European technology partnerships, Taiwanese manufacturing expertise, Dutch semiconductor equipment and global open-source software coexist.
That would be a distinctly 21st-century model.
The Open Silicon Decade
Perhaps the most important development of the next four years will not be a single processor.
It will be the accumulation of many small successes.
A better CPU here.
A better GPU there.
A new NPU.
A working video encoder.
A better ISP.
An NVMe controller.
A PCIe core.
A security subsystem.
A better compiler.
A better driver.
A better PDK.
A better physical-design flow.
A better fabrication process.
Each development reduces the amount of proprietary technology that a new chip designer must purchase.
Eventually, the pieces become enough.
Enough to build a computer.
Enough to build a server.
Enough to build a robot.
Enough to build an automotive controller.
Enough to build an AI accelerator.
Enough to build a phone.
Enough to build a laptop.
And eventually, perhaps, enough to build a complete computing platform.
What I would bet on for 2030
If forced to make a set of predictions today, I would not predict that open silicon will defeat proprietary silicon across the board.
I would make a narrower and, I believe, more interesting bet.
By 2030, the distinction between open and proprietary silicon will be much less economically important than it is today.
Some proprietary processors will remain dramatically faster.
Some proprietary GPUs will remain dramatically more capable.
Some proprietary modems and PHYs will remain indispensable.
But there will also be classes of CPUs, GPUs, NPUs, controllers and accelerators where an open implementation is simply good enough.
And once it is good enough, its openness becomes economically powerful.
The manufacturer can customise it.
The university can inspect it.
The startup can fork it.
The country can maintain it.
The software community can optimise for it.
The foundry can qualify it.
And the next generation can be built on top of the previous one.
The most ambitious possibility
Imagine looking back from 2030.
Dholera has matured.
India has multiple generations of domestic semiconductor manufacturing experience.
RISC-V has become a normal architecture rather than an alternative architecture.
SHAKTI has gone through several more generations.
XiangShan has evolved further.
eProcessor has produced successors.
Vortex has become a credible open graphics/compute platform.
Coral NPU has gone through several revisions and is present in third-party SoCs.
OpenTitan is commonplace in security architectures.
Open video and ISP blocks are silicon-proven.
Open storage controllers have matured.
Open PCIe and networking infrastructure is routine.
Open EDA is significantly better than it was in 2026.
Ubuntu provides an increasingly polished RISC-V desktop experience.
And an Indian laptop is sitting on a desk.
It boots Ubuntu.
Its CPU is RISC-V.
Its GPU is derived from an open architecture.
Its NPU is open.
Its security subsystem is open.
Its storage controller is open.
Its SoC was designed in India.
Its silicon was manufactured at Dholera.
It is not the fastest computer in the world.
It doesn't have to be.
It works.
It is affordable.
It is maintainable.
It is customisable.
Its architecture can be inspected.
And an Indian startup can design the next generation without asking permission from the owner of a proprietary CPU architecture.
At that point, something much larger than a semiconductor fab has been built.
An ecosystem.
And that may be the real meaning of semiconductor sovereignty
Semiconductor sovereignty is not about manufacturing every transistor inside national borders.
It is about ensuring that a country has enough capability, knowledge, infrastructure and alternatives that its technological future cannot be dictated entirely by somebody else's roadmap.
Open silicon provides one possible path to that sovereignty.
RISC-V provides the architectural foundation.
Open CPU, GPU, NPU, VPU, ISP, storage and security projects provide increasingly reusable building blocks.
Open EDA reduces barriers between RTL and physical design.
European semiconductor cooperation provides another technology and talent bridge.
ASML and the Dutch ecosystem provide access to an extraordinary semiconductor manufacturing knowledge network.
PSMC provides the initial Dholera manufacturing partnership.
And Tata provides the physical Indian manufacturing anchor.
Then Linux and Ubuntu can provide the software layer that makes the resulting hardware internationally usable.
The pieces are not yet a complete system.
But for the first time, enough pieces exist to make the system worth imagining.
Conclusion: The chip may increasingly begin with a Git repository
The semiconductor industry has traditionally been built around proprietary knowledge.
The next generation may be built around reusable knowledge.
That does not mean proprietary semiconductor companies disappear.
They will remain essential.
But the boundary between licensed IP and open IP may become much less important.
Some open projects will fail.
Some will remain academic.
Some will become niche components.
Some will become commercial products.
And a few may become foundational.
The most interesting possibility is that by 2030 a chip designer will no longer begin with a blank page.
They will begin with an ecosystem.
A CPU.
A GPU.
An NPU.
A vector processor.
A video engine.
An ISP.
A storage controller.
PCIe.
Ethernet.
USB.
A security subsystem.
An SoC framework.
A compiler.
An operating system.
An EDA flow.
And, potentially, a foundry.
The designer will modify the pieces, verify them, optimise them and manufacture them.
The hardware will still be physical.
But the process of creating it will increasingly resemble software development.
That is why the next four years deserve watching.
Because the most important semiconductor story of the late 2020s may not be the race from 5nm to 3nm to 2nm.
It may be the race to make serious silicon reusable.
And if Dholera becomes the place where that reusable silicon can increasingly become physical Indian hardware, its importance could ultimately extend far beyond the number of wafers it produces.
The future of computing may not belong exclusively to whoever owns the most advanced transistor.
It may increasingly belong to whoever can turn the largest ecosystem of reusable ideas into working silicon.
And in that future, the path from GitHub → RTL → GDSII → Dholera → silicon → Ubuntu could become one of the most important technology pipelines in India.
2030: Come back to this article
This is deliberately not written as a conventional technology prediction that will be forgotten after a news cycle.
September 2026 is the baseline.
The next four years are the experiment.
By 2030, we should be able to answer the question that today remains open:
Did the open-silicon ecosystem merely produce impressive research projects — or did it finally become a practical foundation for competitive computing?
If the answer is the latter, then the significance of Dholera will have to be measured in something much larger than wafers.
It will have helped turn software-defined hardware from an interesting idea into a manufacturing reality.
That would be a very different semiconductor story.
