Thursday, September 17, 2026

Build the Plinth, Not Every Statue: Why India Needs an Open Technology Consortium

India's next technology challenge is not simply designing more chips, writing more software or manufacturing more devices. It is making all of these pieces work together. An industry-funded, FLOSS-first technology consortium could provide the common software plumbing, APIs, standards, reference implementations and engineering infrastructure on which India's next generation of hardware and software companies can build.

The Missing Layer

India's technology conversation is increasingly moving beyond software services.

There is now serious discussion around semiconductors, RISC-V, electronics manufacturing, embedded systems, artificial intelligence, robotics, automotive electronics, IoT devices and sovereign computing.

But there is a layer between the semiconductor and the finished product that is easy to underestimate.

It is the enormous amount of software that makes hardware usable.

A processor is not a smartphone. A GPU is not a laptop. An NPU is not an AI product. A Wi-Fi chip is not a connected appliance.

Between the silicon and the application sits an enormous amount of engineering:

  • bootloaders
  • operating-system support
  • device drivers
  • hardware-abstraction layers
  • graphics frameworks
  • media frameworks
  • AI and NPU runtimes
  • networking
  • Bluetooth and Wi-Fi support
  • power management
  • security
  • secure boot
  • firmware updates
  • diagnostics
  • storage
  • developer tools
  • SDKs
  • testing infrastructure
  • documentation
  • hardware compatibility

Much of this work is not what makes a particular product special.

It is plumbing.

And India has an opportunity to build that plumbing as shared infrastructure.

The Plinth and the Statue

Imagine a giant statue.

The statue gets all the attention. It is what people see. It is what makes the structure distinctive.

But the statue needs a plinth.

The plinth does not compete with the statue. It makes the statue possible.

That is how India's open technology ecosystem should think about common software infrastructure.

The consortium should not attempt to build the next smartphone, refrigerator, automobile, robot vacuum cleaner or television.

It should build the plinth on which thousands of such products can stand.

The manufacturer builds the statue.

The startup creates the distinctive shape.

The semiconductor company builds the silicon.

The consortium makes the interfaces between them predictable, reusable and open.

This distinction is crucial.

Standardise the Plumbing, Not the Product

Consider a smart refrigerator.

Its manufacturer might have proprietary algorithms for compressor control, food preservation, energy management and temperature prediction.

Those things can remain proprietary.

But the refrigerator still needs:

  • network connectivity
  • secure boot
  • firmware updates
  • sensor interfaces
  • storage
  • power management
  • diagnostics
  • security
  • device management
  • AI acceleration, if used

There is little reason for every manufacturer to independently reinvent every one of these layers.

The same principle applies to washing machines, air conditioners, televisions, monitors, robot vacuums, industrial controllers, automobiles, smart watches, cameras and eventually smartphones.

The consortium could provide common APIs and reference implementations for the boring but essential parts.

Companies could then compete on the interesting parts.

Think of It as a Modular Stack

The architecture could look something like this:

                         PRODUCT
                           |
                 Company-specific software
                           |
                 ---------------------
                    COMMON APIs
                 ---------------------
                           |
          +----------------+----------------+
          |                |                |
       Graphics          AI/NPU          Camera
          |                |                |
       Media            Security        Sensors
          |                |                |
       Network         Storage          Power
          |                |                |
          +----------------+----------------+
                           |
                    Hardware HAL
                           |
                     Device Drivers
                           |
                Linux / RTOS / Firmware
                           |
                 RISC-V / Other CPU
                           |
                  GPU / NPU / VPU / I/O
                           |
                       SILICON

The important word is modular.

A company should be able to replace the underlying hardware without having to throw away its entire software investment.

Likewise, a semiconductor company should be able to offer a new chip without requiring every application developer to learn an entirely new software environment.

The AI Analogy Is Particularly Useful

Artificial intelligence provides an excellent analogy.

An application does not necessarily need to know every internal detail of an AI model.

It can communicate through defined interfaces.

The same principle can be applied to hardware.

An application might request an AI inference operation through a common NPU interface.

Underneath that interface could be an NPU from one semiconductor company or a completely different accelerator from another.

The application should not have to be rewritten from scratch every time the silicon changes.

The same idea can apply to:

  • GPU acceleration
  • video decoding
  • camera processing
  • audio processing
  • sensor access
  • cryptography
  • storage
  • networking
  • power management

The consortium therefore does not necessarily need to standardise the implementation.

It needs to standardise the interface.

Different companies can then compete underneath that interface.

RISC-V Needs This Layer

This becomes particularly important as India and other countries explore RISC-V.

The RISC-V instruction-set architecture provides an open foundation for processor design, but a processor ecosystem is much larger than an instruction set.

A successful hardware platform needs compilers, operating systems, drivers, debugging tools, graphics support, AI frameworks, security infrastructure, applications and developer documentation.

Without those layers, a technically impressive processor can remain a demonstration rather than becoming a mass-market platform.

India therefore should not define its RISC-V ambition merely as:

"We need an Indian RISC-V processor."

A more ambitious objective would be:

"We need an ecosystem in which RISC-V processors can become first-class computing platforms."

That requires software.

And software is where a consortium can create enormous leverage.

One Investment, Many Industries

Consider the number of industries that could potentially share portions of the same foundation.

Industry Common Infrastructure Product Differentiation
Smartphones Drivers, graphics, AI, connectivity, security, updates Camera, UI, industrial design, applications, AI features
Smart TVs Graphics, video, audio, networking, storage, OTA Display processing, UI, recommendations, brand features
Smart monitors Display, USB, networking, firmware, power management Panel features, productivity software, image processing
Automobiles Security, networking, middleware, OTA, compute abstraction ADAS, vehicle algorithms, infotainment, proprietary systems
Robot vacuums Sensors, motors, connectivity, AI runtime, device management Navigation, SLAM, cleaning algorithms and mapping
Refrigerators Connectivity, sensors, security, OTA, diagnostics Cooling, energy and food-management algorithms
Washing machines Motor interfaces, sensors, connectivity, security Wash algorithms, load detection and user experience
Air conditioners Sensors, networking, power management, OTA Thermal algorithms, energy optimisation and control
Industrial IoT Networking, security, device management, diagnostics Industrial applications and control algorithms
Robotics Motor control, sensors, compute and AI runtimes Robot intelligence, navigation and task-specific software

One common investment could therefore support many industries.

That is the economic logic behind a consortium.

It Could Lower the Barrier for Startups

This may ultimately be one of the consortium's greatest contributions.

Imagine a startup with twenty engineers wanting to build a new industrial robot.

It should not have to spend the first year writing its own basic infrastructure for networking, firmware updates, security, hardware abstraction, graphics, device management and accelerator support.

It should be able to start much higher up the stack.

Its question should be:

"What can our company do that nobody else does?"

rather than:

"How do we recreate the infrastructure that hundreds of companies have already recreated?"

This is particularly important in India because the country has an enormous base of engineers and startups but cannot afford to duplicate expensive engineering effort indefinitely.

A common open foundation allows the same engineering work to create value across many companies.

Build Once. Improve Together.

There is another advantage to the open model.

A proprietary solution maintained by one small company can become a liability if that company disappears.

An open project can potentially survive changes in individual companies because the code, documentation, issue history and technical knowledge remain available to a wider community.

That does not automatically make open-source software sustainable. Open projects still require maintainers, infrastructure, security work and funding.

That is precisely why the consortium needs to exist.

Open source without maintainers is an abandoned building.

Open source with sustained engineering investment becomes infrastructure.

The Apache and Eclipse Lessons

This idea would not need to be invented from scratch.

The Apache Software Foundation demonstrates one model in which individual projects retain substantial technical autonomy while operating within a common foundation and governance structure. Apache explicitly describes its projects as self-governing and driven by their communities, with Project Management Committees responsible for project governance.

The Eclipse Foundation provides another useful model. Its working groups allow companies and other participants to collaborate around shared industry problems while maintaining vendor-neutral governance. Eclipse currently operates industry collaborations across areas including automotive, IoT, edge computing, developer tooling and open hardware.

These examples suggest an important principle:

The foundation can provide the legal, financial, infrastructure and coordination layer without becoming the technical owner of everything.

That distinction should be fundamental to any Indian model.

The Indian Model: Fund the Commons

Imagine an Indian Open Technology Foundation.

It could be funded primarily by industry, with government acting as an enabler rather than the owner of the technology.

Potential members could include:

  • semiconductor companies
  • automobile manufacturers
  • electronics manufacturers
  • appliance companies
  • telecom companies
  • IT companies
  • cloud providers
  • startups
  • universities
  • research institutions
  • multinational companies operating significant engineering organisations in India

The government could support the ecosystem through appropriate incentives, research funding, procurement opportunities, testing infrastructure, university programmes and other mechanisms.

But the code should remain open and the technical governance should remain independent.

This leads to a simple division of responsibility:

  • Government: create favourable conditions.
  • Industry: provide funding and engineering resources.
  • Universities: provide research and talent.
  • Foundation: provide infrastructure, coordination and long-term stewardship.
  • Developers: build and maintain the technology.
  • Open-source communities: retain technical authority over projects.

Do Not Fork the World

This principle is particularly important.

India should not create an Indian copy of every major open-source project.

If the world already has an excellent project, India should contribute to it.

If an important project needs more maintainers, India can supply maintainers.

If it needs better documentation, India can provide documentation.

If it needs better hardware support, India can provide hardware support.

If it needs security work, India can fund security engineering.

If it needs testing infrastructure, India can build testing infrastructure.

The objective is not to create an Indian island.

The objective is to make India one of the major engineering centres of the global open technology commons.

That would be genuine technological participation rather than technological isolation.

The 10,000-Engineer Idea Looks Different in This Model

Earlier, the idea of a large publicly supported pool of software engineers might sound like an employment programme.

Within this model, it becomes something else.

It becomes strategic maintainership.

India could support a large engineering workforce dedicated to maintaining critical open infrastructure.

Some could work directly for the foundation.

Others could remain employees of member companies while contributing upstream.

Some could specialise in Linux and embedded systems.

Others could work on LLVM, graphics, AI runtimes, security, automotive software, networking, firmware, testing or documentation.

The important metric would not simply be how many lines of code they produce.

It would be:

  • how many important projects they maintain
  • how many hardware platforms they support
  • how many vulnerabilities they help resolve
  • how many companies can build on their work
  • how many Indian products become easier to develop
  • how much duplicated engineering effort disappears

Canonical India Could Become the Integration Layer

This is where the earlier idea of a hypothetical Canonical India becomes interesting.

It need not simply mean an Indian Linux distribution.

It could instead be conceived as a platform-engineering organisation responsible for making the pieces work together.

Its test laboratory could continuously test:

  • Linux
  • bootloaders
  • RISC-V processors
  • GPUs
  • NPUs
  • VPUs
  • Wi-Fi and Bluetooth
  • cameras
  • displays
  • audio
  • power management
  • storage
  • automotive hardware
  • embedded hardware

New hardware could enter the laboratory.

The platform could be tested against real workloads.

Problems could be reported upstream.

Drivers could be improved.

Documentation could be updated.

The next hardware generation could then be designed with real software experience in mind.

This creates a feedback loop between silicon and software.

Hardware Becomes a Testbed for Software

This is one of the strongest aspects of the model.

Suppose an Indian semiconductor company develops a new RISC-V SoC.

The consortium could put it through a common platform test suite.

It could measure:

  • boot time
  • power consumption
  • driver maturity
  • GPU performance
  • NPU performance
  • memory bandwidth
  • storage performance
  • video playback
  • browser performance
  • application compatibility
  • security
  • sleep and wake behaviour
  • thermal behaviour

The results could then feed back into both software and hardware engineering.

Hardware manufacturers learn what software actually needs.

Software developers learn what hardware actually does.

The ecosystem gradually becomes better at both.

Common Standards Could Create Hardware Competition

This is perhaps the most interesting economic consequence.

Imagine three companies producing different embedded SoCs.

If all three support the same open platform APIs, a product manufacturer can potentially evaluate them based on:

  • price
  • power
  • performance
  • AI capability
  • memory bandwidth
  • security
  • longevity

rather than being locked into a completely different software environment for every chip.

That makes the silicon market more contestable.

Competition shifts toward the things semiconductor companies should actually compete on.

The software layer becomes an ecosystem multiplier rather than a barrier to entry.

Open Does Not Mean Everything Must Be Open

This distinction should also be made clearly.

A company should be able to keep genuinely differentiating intellectual property proprietary.

A car manufacturer does not have to open-source its autonomous-driving algorithms simply because it uses an open operating system.

A refrigerator company can keep its energy-management algorithm proprietary.

A smartphone company can develop its own camera algorithms.

A robot manufacturer can maintain proprietary navigation technology.

The common platform should exist underneath them.

In simple terms:

Open the foundation. Compete on the innovation.

From RISC-V to the Mass Market

This is ultimately why the software consortium matters to the semiconductor programme.

A new processor does not become successful merely because it works in a laboratory.

It becomes successful when developers can build applications for it, manufacturers can integrate it, consumers can buy products using it and companies can support those products for years.

That requires an ecosystem.

And ecosystems are built through shared infrastructure.

The path could therefore look like:

Open ISA
   ↓
Open silicon
   ↓
Common drivers
   ↓
Common APIs
   ↓
Common SDKs
   ↓
Common testing
   ↓
Common security infrastructure
   ↓
Reference platforms
   ↓
Startups
   ↓
Products
   ↓
Consumers
   ↓
More hardware demand
   ↓
More semiconductor investment
   ↓
Better hardware
   ↓
Better software
   ↓
More products

This is a flywheel.

The Consortium Could Become India's Technology Pedestal

There is a temptation in national technology strategies to focus on visible objects.

The fab.

The processor.

The laptop.

The smartphone.

The robot.

The supercomputer.

Those are important.

But underneath all of them are thousands of invisible interfaces.

Those interfaces determine whether components can communicate, whether developers can reuse their work, whether hardware can be replaced, whether software survives a company disappearing and whether a new startup can enter the market without spending years rebuilding infrastructure.

That invisible layer may ultimately be one of the most strategically important parts of the ecosystem.

India does not need to build every statue.

It needs to build the plinth on which thousands of statues can stand.

A Different Definition of Technology Sovereignty

Technology sovereignty does not have to mean manufacturing everything domestically.

Nor does it mean rejecting technology developed elsewhere.

A more useful definition might be:

The ability to understand, integrate, maintain, modify and improve the technologies on which an economy depends.

Under that definition, contributing thousands of engineers to global open-source projects is itself a form of technological capability.

Maintaining critical drivers is capability.

Building open APIs is capability.

Creating compatibility test suites is capability.

Supporting RISC-V in Linux and development tools is capability.

Building NPU runtimes is capability.

Maintaining security infrastructure is capability.

Writing documentation is capability.

Making a new semiconductor usable by thousands of developers is capability.

The Bigger Vision

The most interesting outcome would not be an "Indian operating system."

It would not be an "Indian version" of every application.

It would not even necessarily be an exclusively Indian hardware stack.

It would be an ecosystem in which Indian engineers, companies, universities and startups become major contributors to the open technological infrastructure used by the world.

India could contribute silicon.

India could contribute software.

India could contribute standards.

India could contribute maintainers.

India could contribute testing infrastructure.

India could contribute documentation.

India could contribute reference designs.

And Indian companies could then build differentiated products on top of that commons.

That creates a virtuous cycle:

             FUND THE COMMONS
                    ↓
             MAINTAIN THE CODE
                    ↓
             DEFINE OPEN APIs
                    ↓
             SUPPORT HARDWARE
                    ↓
              ENABLE STARTUPS
                    ↓
             CREATE PRODUCTS
                    ↓
             REACH MASS MARKET
                    ↓
             GENERATE DEMAND
                    ↓
             FUND THE COMMONS

Build the Road, Not Every Car

India's technology ambition should not be measured by how many things it builds completely from scratch.

A mature technology ecosystem is one where thousands of companies can build on top of shared foundations without repeatedly solving the same problems.

That is what the proposed consortium could provide.

The foundation provides the conditions.

Industry provides the money.

Engineers provide the work.

Universities provide research and talent.

Open communities provide technical governance.

Startups build the differentiated products.

Consumers provide the ultimate test.

The objective is not to make every company identical.

It is precisely the opposite.

Make the underlying infrastructure common so that the products can become more different.

Make the plumbing reusable so that the innovation can become more ambitious.

Make the APIs open so that hardware can compete.

Make the software modular so that startups can enter.

Make the maintenance sustainable so that the ecosystem survives.

And make the whole thing FLOSS so that the investment does not stop at India's borders.

The Principle

India's next technology revolution may not require one giant company capable of doing everything.

It may require something more subtle:

A permanent institution capable of building and maintaining the common technological layer upon which thousands of companies can innovate.

Build the plinth.

Let the semiconductor companies build the silicon.

Let the software communities build the tools.

Let the startups build the products.

Let manufacturers build the machines.

Let consumers decide which products succeed.

And let the improvements flow back into the commons.

Fund the commons. Keep the governance open. Standardise the plumbing. Let industry compete on the product.

That could turn FLOSS from something India merely consumes into something India helps maintain as a global industrial resource.

And perhaps that is the real opportunity:

India does not have to build every statue. It can become one of the world's great builders of the plinth.

Wednesday, September 16, 2026

India Must Learn, Not Just Consume: A Pragmatic Doctrine for a Multipolar World

India has just hosted another BRICS summit. But perhaps the more important question is not which grouping India belongs to. The question is what India gains from every relationship it enters. A mature India should be pragmatic, not dogmatic: cooperate with everyone where useful, depend on no one where avoidable, and turn imported technology into domestic capability.

The Question Behind the BRICS Summit

India has just completed its 2026 BRICS presidency with the 18th BRICS Summit in New Delhi on September 12–13. The expanded grouping now brings together eleven countries and has become a significant platform for discussions on trade, finance, supply chains, technology, energy and the broader architecture of the global economy. The New Delhi Declaration runs to 140 points and reflects the enormous breadth of issues now sitting under the BRICS umbrella.

There is nothing inherently wrong with India being part of BRICS.

In fact, there are many reasons for India to participate.

BRICS gives India a platform in the Global South. It provides diplomatic leverage. It creates opportunities for trade, energy cooperation, investment and financial experimentation. It gives India another forum through which it can influence discussions about global governance.

But membership in a grouping should never become an ideology.

That is the larger lesson India should take from the summit.

India should be pragmatic about groupings rather than dogmatic about them.

A grouping is a tool.

It is not an identity.

It is not a marriage.

And it certainly should not determine with whom India is allowed to cooperate technologically.

India's Foreign Policy Should Have One Simple Question

Whenever India enters a major economic or technological relationship, there should be a question asked at the beginning, in the middle and at the end:

What capability will India have after this relationship that it did not have before?

This question changes everything.

Suppose India imports a finished product worth $100.

The transaction provides the Indian consumer with the product.

That is useful.

But suppose India instead imports a $100 piece of manufacturing equipment that allows an Indian factory to produce that product domestically.

Now India has acquired something more valuable than the product.

It has acquired productive capacity.

Now imagine that Indian engineers learn to maintain the machine.

Then Indian companies begin manufacturing some of its components.

Then Indian engineers modify it.

Then Indian companies design the next generation.

Eventually, India exports the machine.

The original $100 import has become the beginning of an industrial ecosystem.

This is the distinction between consumption and learning.

Import the Tool That Makes the Product

India does not need to stop importing.

It needs to become much more selective about what it imports.

There is a profound difference between importing a finished smartphone and importing the equipment, process technology and expertise required to manufacture smartphones.

There is a difference between buying an industrial robot and developing the ability to manufacture industrial robots.

There is a difference between buying an AI accelerator and learning how to design, package, program and manufacture accelerators.

There is a difference between subscribing forever to foreign software and participating in open-source ecosystems that allow Indian developers to understand, modify and eventually replace critical layers.

There is a difference between importing a semiconductor and importing semiconductor manufacturing equipment, process knowledge, PDKs, design expertise and packaging technology.

The strategic objective should therefore be:

Import the means of production before you import the means of consumption.

And when finished products must be imported, India should ask whether the same transaction can eventually lead to domestic manufacturing, design or technology development.

Trade Deficits Are Not the Real Problem

This distinction also changes how India should think about trade deficits.

A trade deficit is not automatically evidence of economic weakness.

If India imports sophisticated machinery that dramatically increases domestic productivity, the deficit may be part of a healthy industrialisation process.

The problem comes when imports remain permanently concentrated in finished goods, components and technologies that India has no pathway to manufacture or improve.

India's trade relationship with China illustrates why this distinction matters.

Official Indian data shows that India's merchandise trade deficit with China reached $63.97 billion during April–October 2025. Importantly, the government also noted that a substantial portion of these Chinese imports consisted of raw materials, intermediate goods and capital goods used in Indian production, including auto components, electronic parts and assemblies, mobile-phone parts and machinery.

That is a much more complicated picture than simply saying “Chinese imports are bad.”

Some imports feed Indian industry.

The strategic question is therefore not whether India should import these things tomorrow.

The question is whether India should still need to import them ten or twenty years from now.

That is the difference between dependence and industrial learning.

The Five-Stage Journey of an Import

India could think about strategic imports as moving through a ladder:

Stage 1 — Import
India buys the finished product.

Stage 2 — Assemble
India begins assembling the product domestically.

Stage 3 — Manufacture
Indian companies begin producing significant components.

Stage 4 — Engineer
Indian engineers modify, optimise and improve the technology.

Stage 5 — Design
India develops its own technology and eventually exports it.

This should become one of the fundamental metrics of Indian industrial policy.

Not simply:

“How many factories did we attract?”

But:

“How much technological capability did those factories leave behind?”

Be Friends With Everyone. Depend on Nobody.

This is where India's foreign policy needs to become genuinely pragmatic.

India does not need to decide that one country is permanently a friend and another is permanently an enemy.

International relations do not work that way.

A country can simultaneously cooperate with one nation on energy, another on semiconductors, another on defence, another on robotics and another on critical minerals.

There is no contradiction.

India should be willing to work with China where Chinese technology or manufacturing capability is useful.

It should work with Russia where Russian capabilities remain strategically valuable.

It should work with Europe where European industrial and technological capabilities complement India's requirements.

It should work with Japan on manufacturing and precision engineering.

It should work with South Korea on electronics and advanced manufacturing.

It should work with Taiwan on semiconductors.

It should work with the United States on advanced computing, AI, aerospace and other frontier technologies.

And it should simultaneously build Indian alternatives wherever dependence creates strategic vulnerability.

This is not inconsistency.

This is strategic diversification.

The Frenemy Principle

India should be comfortable with a concept that is uncomfortable for ideological foreign policy:

The frenemy.

A country can be a strategic competitor and still be a useful technology partner.

A country can be politically difficult and still provide valuable machinery.

A country can be an important trading partner without becoming India's technological foundation.

The objective is not to create permanent friendships.

The objective is to create permanent Indian capability.

That means India should be able to say:

“We will buy your machine today, learn how it works, build our own ecosystem around it, improve it tomorrow and perhaps compete with you the day after.”

There is nothing hostile about this.

It is how industrial civilisation works.

BRICS Should Be a Tool, Not a Destination

BRICS therefore has value.

But India should resist turning BRICS into an economic philosophy.

The expanded grouping is large and diverse. Its members have different political systems, different economic structures, different strategic interests and, in some cases, competing geopolitical objectives.

India should therefore ask of BRICS initiatives:

  • Does this increase Indian exports?
  • Does this reduce India's strategic vulnerability?
  • Does this create Indian manufacturing capability?
  • Does this bring useful technology into India?
  • Does this encourage joint research?
  • Does this create Indian intellectual property?
  • Does this create Indian companies capable of competing globally?

If the answer is yes, India should participate enthusiastically.

If the answer is no, India should participate diplomatically but avoid mistaking diplomatic participation for economic strategy.

India does not have to abandon a forum simply because it does not deliver everything India wants.

Nor should India remain emotionally attached to a forum simply because India helped build it.

Use the platform. Extract the value. Move on when necessary.

Europe May Be More Important Than the Acronym Suggests

This is where India's relationship with Europe becomes particularly interesting.

India does not need Europe because Europe is “Western.”

India needs Europe because Europe possesses many of the industrial capabilities India needs to build its next technological layer.

Europe has extraordinary strengths in precision machinery, industrial automation, semiconductor equipment, automotive technology, advanced materials, robotics, medical technology, aerospace and industrial software.

India has enormous strengths in software, engineering talent, manufacturing scale, digital infrastructure, entrepreneurship and a gigantic domestic market.

These strengths are complementary.

And this is no longer merely an abstract possibility.

In 2026, India and the European Union concluded negotiations for a Free Trade Agreement, while their Trade and Technology Council has expanded cooperation into semiconductors, high-performance computing, quantum technologies, artificial intelligence and 6G.

The EU and India have also agreed to deepen semiconductor cooperation, including chip design, heterogeneous integration, advanced-process PDK development, talent exchanges and resilient semiconductor production.

This is precisely the type of relationship India should cultivate.

Not simply:

“European company sells something to India.”

But:

“European technology and Indian engineering create something neither side could have created as efficiently alone.”

From European Machines to Indian Factories

Imagine a European company supplies advanced factory automation equipment to an Indian manufacturing cluster.

Initially, almost everything may be imported.

That is acceptable.

But the Indian engineers operating those factories learn the equipment.

Indian suppliers begin producing cables, motors, controllers, sensors and mechanical components.

Indian software companies develop factory-management software around the machinery.

Indian universities work on machine vision and industrial AI.

Indian startups develop cheaper alternatives.

Eventually, India is no longer merely the customer.

It becomes part of the technology ecosystem.

That is the model India should pursue across sectors.

Semiconductors Are the Perfect Example

India's semiconductor ambitions should be viewed in exactly this way.

A semiconductor ecosystem cannot be created simply by building a fab.

It requires:

  • process technology
  • semiconductor equipment
  • materials
  • chemicals
  • PDKs
  • design tools
  • IP
  • EDA capability
  • chip designers
  • packaging
  • testing
  • substrates
  • power electronics
  • controllers
  • software
  • customers

The first generation will inevitably contain foreign technology.

That is not failure.

The failure would be remaining dependent on the same foreign technology forever.

India's objective should be to climb the ladder.

Learn the process. Improve the process. Build the supply chain. Develop the IP. Design the chip. Manufacture the chip. Export the chip.

The Same Logic Applies to Open Source

There is another dimension to this strategy that is often overlooked.

India should not think about technological sovereignty only in terms of factories and physical products.

Software matters just as much.

Consider the difference between purchasing a proprietary software subscription indefinitely and participating in an open ecosystem that India can inspect, modify, maintain and develop.

India does not necessarily need to create an Indian replacement for every major foreign software product.

It can instead build around global open-source foundations.

Linux.

Open document formats.

Open-source office productivity.

Open databases.

Open-source cloud infrastructure.

RISC-V.

Open silicon.

Open AI models and tools.

Open standards.

Open developer ecosystems.

The objective is not isolation.

The objective is the ability to understand and control the critical layers.

If an Indian developer can inspect the system, modify it, improve it and build businesses around it, the technology creates a different kind of economic relationship.

India Should Become a Technology Student Again

There is an uncomfortable truth hidden inside all of this.

India has spent decades thinking about development primarily in terms of consumption.

More cars.

More phones.

More appliances.

More computers.

More imported technology.

Consumption is not inherently bad.

A growing middle class should consume.

But consumption cannot be the final destination of development.

At some point, the country must ask:

Who makes the thing we are consuming?

Then:

Who makes the machine that makes the thing?

Then:

Who makes the machine that makes that machine?

That is where genuine industrial power begins.

The Industrialisation Flywheel

Consider the following cycle:

Import technology

Learn technology

Manufacture locally

Develop suppliers

Improve technology

Develop Indian IP

Export technology

Use export revenue to acquire the next generation

Repeat

This is the flywheel India needs.

Foreign technology is not the enemy of self-reliance.

Permanent inability to learn from foreign technology is.

The Goal Is Not Autarky

India should also be careful with the phrase “self-sufficiency.”

Complete self-sufficiency is neither realistic nor necessarily desirable.

No modern economy efficiently manufactures everything it consumes.

India should instead aim for strategic sufficiency.

Strategic sufficiency means India possesses enough domestic capability that the denial of foreign technology does not bring the country to a standstill.

India can still import specialised components.

India can still purchase foreign products.

Indian companies can still use foreign technology.

But India should maintain domestic competence in the technologies that underpin its economic and national security.

The distinction is crucial.

Self-sufficiency says: “We must make everything.”

Strategic sufficiency says: “We must be capable of making what matters.”

A New Definition of Strategic Autonomy

This leads to a more useful definition of strategic autonomy.

Strategic autonomy does not mean refusing foreign technology.

It means refusing permanent technological helplessness.

India can buy a semiconductor manufacturing machine from Europe.

It can buy industrial robots from Japan.

It can use American AI technology.

It can purchase components from China.

It can continue defence cooperation with Russia.

It can participate in BRICS.

It can deepen relations with the European Union.

It can work with the United States.

It can cooperate with Japan and South Korea.

None of these relationships need to contradict each other.

The common denominator should be India.

Every relationship should make India more capable, not merely more comfortable.

The Indian Test for Every International Partnership

Perhaps India needs a simple strategic scorecard.

Before entering a major technology or industrial partnership, ask:

  1. What are we buying?
  2. What are we learning?
  3. What are we manufacturing?
  4. What intellectual property will India develop?
  5. What Indian companies will emerge?
  6. What components can eventually be localised?
  7. Can Indian engineers modify the technology?
  8. Can Indian universities participate?
  9. Can the technology eventually be exported?
  10. What happens if the foreign supplier disappears tomorrow?

The last question may be the most important.

If the answer is “India has no alternative,” the relationship has created dependence.

If the answer is:

“We have learned enough to build an alternative,”

then the relationship has created sovereignty.

India Should Be Pragmatic About Every Bloc

This philosophy applies to BRICS.

It applies to the European Union.

It applies to the United States.

It applies to the Indo-Pacific.

It applies to every future grouping that India joins.

India should never ask:

“Which bloc should we belong to?”

It should ask:

“Which relationship helps India become stronger?”

If BRICS provides useful markets, capital, energy relationships or diplomatic leverage, India should use it.

If Europe provides advanced industrial technology, semiconductor expertise, robotics, machinery and research partnerships, India should use it.

If America provides frontier AI, aerospace, computing and scientific capabilities, India should use it.

If Japan provides manufacturing expertise, precision engineering and robotics, India should use it.

If China provides components that India currently cannot economically manufacture, India can buy them while simultaneously building alternatives.

If Russia provides strategically useful technologies, India should use them where appropriate.

There is no ideological contradiction in any of this.

The Ultimate Objective: Learn and Grow

India's greatest opportunity over the next few decades is not to become the country that imports the most sophisticated technology.

It is to become the country that learns fastest from the technology it imports.

A foreign semiconductor fab should create Indian semiconductor engineers.

A European robot should create Indian roboticists.

A Japanese machine tool should create Indian machine-tool manufacturers.

An American AI system should create Indian AI researchers.

A Chinese component should eventually create an Indian component manufacturer.

An open-source project should create Indian developers who can improve it.

A foreign factory should eventually create an Indian industrial ecosystem.

And an imported technology should ideally create the capability to build the next generation locally.

India's Real Choice

India does not face a simple choice between East and West.

It faces a choice between two models of development.

The first is:

Consume → import → assemble → repeat.

The second is:

Import → learn → manufacture → improve → design → export.

The first model can create a large market.

The second can create a technological civilisation.

India should choose the second.

Own the Capability, Not Necessarily Every Component

Perhaps this is the most important lesson from India's current geopolitical moment.

India does not need to manufacture everything.

India does not need to leave every international grouping.

India does not need to choose permanently between China, Russia, Europe, America, Japan or anyone else.

India needs to become sufficiently capable that it can work with all of them without becoming subordinate to any of them.

That means being willing to cooperate with a friend.

It means being willing to transact with a competitor.

It means being willing to learn from a rival.

It means being willing to abandon an arrangement that no longer serves Indian interests.

And above all, it means understanding that the purpose of international economic engagement is not merely to obtain things.

It is to obtain knowledge, capability, scale, technology, markets and eventually independence of choice.

The Sovereign Principle

India's next phase of development should therefore be guided by a very simple principle:

Do not ask only what India can buy.

Ask what India can learn.

Do not ask only how many foreign companies are investing.

Ask how many Indian companies emerge around them.

Do not ask only how many products are manufactured in India.

Ask how much of the underlying technology is understood in India.

Do not ask only how large India's market becomes.

Ask how much of the technology serving that market India controls.

And do not ask whether India belongs to the East or the West.

Ask whether India is becoming stronger.

That is the real meaning of strategic autonomy.

India should trade with everyone.

Partner with everyone.

Learn from everyone.

Compete with everyone.

And depend permanently on as few as possible.

Because the ultimate objective is not isolation.

It is freedom of choice.

India does not need to build everything alone. It needs to become capable of building whatever matters.

Tuesday, September 15, 2026

The Indian Computer: Learn, Improve, Scale, Refine, Miniaturise, Mobile

From a modular 40nm-class learning machine to a 22nm-class ultrabook and eventually a smartphone: the real advantage may not be transistor density, but knowing exactly how to use every transistor.

Editor's Note: This article is a technical companion to the earlier essay, “The Indian Computing Ecosystem: Own the Everyday, Rent the Extraordinary.” It goes deeper into what would actually make such a system work: memory, accelerators, software, developers, modularity and continuous hardware-software refinement.

The real challenge begins after the processor is designed

It is easy to imagine an Indian computer.

Put an open RISC-V processor into a system. Add a GPU. Add an NPU. Add memory and storage. Install Linux. Put everything into a laptop.

But that is not really the difficult part.

The difficult part is making all those components work together efficiently.

A fast CPU can sit waiting for memory. A powerful GPU can sit waiting for data. An NPU can have thousands of operations available every cycle but spend much of its time fetching weights. A video engine can be technically capable while consuming unnecessary bandwidth. A perfectly good processor can feel slow because the compiler, drivers or operating system do not know how to exploit it.

The difference between a collection of silicon blocks and a real computer is therefore system engineering.

And this is where the Indian computing project could take a different path.

Instead of trying to build the ultimate integrated computer immediately, India could spend its first four or five years deliberately learning how every major component behaves.

The guiding philosophy would be:

Learn → Improve → Scale → Refine → Miniaturise → Mobile.

Learn: the first computer should be deliberately modular

The first generation should not try to be the thinnest laptop.

It should be a machine that engineers can understand.

CPU, GPU, NPU, VPU, memory, storage and I/O should be sufficiently modular that each can be measured, replaced and improved without redesigning the entire system.

+------------------------------------------------+
|              INDIAN COMPUTER GEN 1             |
+------------------------------------------------+
| Display | Keyboard | Power | USB | Networking |
+------------------------------------------------+
|              Modular Carrier Board             |
+------------------------------------------------+
| CPU Module | GPU | NPU | VPU | Memory | I/O   |
+------------------------------------------------+
|                NVMe / SSD Module               |
+------------------------------------------------+

This is not merely a repairability philosophy.

It is an engineering philosophy.

If the computer is slow, engineers should be able to determine whether the problem is the CPU, GPU, NPU, memory controller, storage, interconnect, driver or application.

The first generation should therefore contain unusually good instrumentation.

  • CPU performance counters
  • GPU utilisation counters
  • cache-miss counters
  • memory-bandwidth measurements
  • NPU utilisation
  • DMA statistics
  • thermal sensors
  • power measurements
  • VPU utilisation
  • storage latency measurements

The question should not simply be:

“Is this computer fast?”

It should be:

“Why is this computer slow?”

Improve: every component gets its own learning curve

The CPU team should improve the CPU.

The GPU team should improve the GPU.

The NPU team should improve the NPU.

The memory team should improve the memory controller.

The software team should improve the compiler and operating system.

These improvements should not have to wait for a five-year product cycle.

The physical hardware may remain stable for several years, while firmware, drivers, compilers and applications improve continuously.

A six-month platform release could therefore contain:

  • better RVV auto-vectorisation
  • better Vortex scheduling
  • improved Vulkan drivers
  • better NPU operators
  • better video acceleration
  • better memory scheduling
  • improved power management
  • better browser performance
  • new AI libraries
  • new developer documentation

The user does not need to buy a new computer every six months.

The computer simply becomes better.

The GPU should mature in parallel

This is where Vortex becomes particularly interesting.

Vortex 3.0 is already much more than an experimental GPGPU. Its 3.0 release includes a fixed-function graphics stack, texture units, output mergers, tensor-core structured sparsity, warpgroup matrix multiplication, global-to-local data-transfer acceleration, a hardware kernel scheduler, virtual memory support, Vulkan infrastructure, HIP support and ASIC synthesis flows.

But that does not mean Vortex 3.0 should immediately be turned into a giant discrete graphics card.

The better strategy is to use it as the iGPU learning platform.

A first configuration might deliberately target something like:

Parameter Illustrative Gen1 Target
GPU architecture Vortex 3.x
GPU cores 16–24
GPU clock 800 MHz–1 GHz
FP32 capability approximately 250–400 GFLOPS peak
GPU local/shared SRAM around 2 MB
GPU cache 2–4 MB
System cache around 8 MB
Memory dual-channel DDR5-class
Target bandwidth around 100 GB/s theoretical

These are proposed engineering targets, not specifications of the current Vortex project.

The important point is balance.

There is little value in building a 1 TFLOPS GPU if the memory system can feed only a fraction of its potential.

A smaller GPU that remains busy may produce a better computer than a much larger GPU that spends its time waiting.

The memory system may matter more than the process node

This is one of the most important lessons for the entire project.

Consider a hypothetical GPU capable of 400 GFLOPS.

If its workload constantly misses cache and waits for DDR5, its real performance may be far below that number.

Now imagine the same GPU with:

  • large L1 caches
  • 2–4 MB of GPU-side cache
  • 2 MB or more of software-managed local SRAM
  • an 8 MB system-level cache
  • efficient DMA
  • data compression
  • good memory coalescing
  • roughly 100 GB/s of external memory bandwidth

The theoretical GPU has not become faster.

But the percentage of time it spends doing useful work can increase dramatically.

That is system-level performance.

The NPU should be designed around data movement

The same principle applies to AI.

Google's Coral NPU is useful as a reference because its architecture is explicitly designed around efficient data movement and specialised ML computation. Google describes it as an open-source RISC-V-based NPU containing scalar, vector and matrix processing components.

A larger Indian implementation could provide considerably more local SRAM for weights and activations.

For example, an illustrative target might be:

  • 64–128 KB instruction memory
  • 512 KB–1 MB data SRAM
  • 2–4 MB weight/activation SRAM
  • dedicated DMA
  • double buffering
  • INT8 and INT16
  • FP16/BF16 where useful
  • sparse computation

The objective would be to keep the NPU busy without repeatedly travelling out to external DRAM.

In AI inference, moving data can sometimes cost more than performing the arithmetic.

Therefore:

The best NPU is not necessarily the one with the largest number of TOPS. It is the one that can sustain useful TOPS without drowning in memory traffic.

A dedicated VPU is not optional

Video should not be treated as a CPU workload.

Nor should the GPU have to perform every video operation.

A serious Indian SoC should have a dedicated video-processing block capable of handling workloads such as:

  • H.264 decode and encode
  • HEVC/H.265 decode and encode
  • AV1 decode
  • 4K video
  • high-efficiency display composition
  • scaling and colour conversion
  • 10-bit video and HDR where appropriate

Fixed-function hardware can perform these repetitive operations much more efficiently than asking a general-purpose CPU to do them.

This matters enormously for a 22nm design.

Every watt saved in video processing is a watt available elsewhere.

DDR5 should be treated as architecture, not a specification checkbox

It is not enough to write “supports DDR5” on a product sheet.

The actual question is:

How much memory bandwidth does the complete system need, and who gets it?

A hypothetical dual-channel 64-bit DDR5-6400 configuration would provide about 102.4 GB/s of theoretical peak bandwidth.

That bandwidth must be shared by:

  • CPU
  • GPU
  • NPU
  • VPU
  • ISP
  • storage DMA
  • networking

The memory controller therefore needs intelligent quality-of-service mechanisms.

A video stream should not stutter because the GPU is running a compute kernel.

A user interface should not freeze because an AI model is loading.

A background SSD operation should not steal bandwidth from an interactive application.

This is why the memory controller and interconnect should be considered first-class parts of the computer rather than invisible plumbing.

The SSD should also become part of the learning curve

Storage provides another opportunity for gradual localisation.

The first generation does not have to manufacture every NAND layer domestically.

It can begin by owning more of the controller, firmware, module design, qualification, encryption and system integration.

Over time, India could pursue deeper partnerships with Japanese semiconductor and equipment companies.

Canon's nanoimprint lithography technology is particularly interesting because Canon has positioned NIL for semiconductor manufacturing applications including memory, and has discussed its use in NAND-related manufacturing.

The realistic question is therefore not:

“Can Canon make an Indian SSD?”

It is:

“Can India and Japan eventually build a broader memory ecosystem in which Japanese process/equipment expertise and Indian manufacturing, controllers, packaging and product integration reinforce one another?”

That is a much more achievable strategic proposition.

Scale: the first computer needs users

None of this works if the machines remain in laboratories.

The first four or five years should deliberately create a substantial user base.

Government procurement could be one anchor market.

Education could be another.

Indian enterprises could become another.

Universities and engineering colleges should receive development platforms.

Manufacturers should be encouraged to produce different form factors using the same underlying compute platform.

The objective would be to create enough real-world usage that the engineers stop designing for theoretical benchmarks and start designing for actual behaviour.

And the end user developer is part of the architecture

This may be the most underestimated part of the entire strategy.

A 22nm processor cannot rely entirely on brute-force hardware to compete with a much newer process.

It needs developers who know how to exploit the hardware.

But ordinary developers should not be forced to write assembly.

The platform therefore needs a layered programming model.

Application
    ↓
Platform APIs
    ↓
Compiler / Runtime
    ↓
RVV / Vortex / NPU / VPU
    ↓
Hardware

A normal developer should be able to write C++, Rust, Python or another mainstream language and let the compiler and runtime handle most of the complexity.

A performance developer should be able to use RVV intrinsics.

A graphics developer should be able to use Vulkan.

An AI developer should be able to use an NPU runtime.

A specialist should be able to write GPU kernels, use DMA and explicitly manage local memory.

And a hardware researcher should ultimately be able to inspect the architecture, simulation environment and, where licensing permits, the RTL itself.

This creates a ladder:

Normal application
        ↓
Optimised library
        ↓
RVV / GPU / NPU API
        ↓
Intrinsics and kernels
        ↓
Hardware-level programming
        ↓
RTL / FPGA / silicon research

The point is not to force everyone to go down the ladder.

The point is to make sure nobody is prevented from going down it.

Documentation becomes national infrastructure

Every hardware capability should be continuously documented.

Not merely:

“This GPU supports feature X.”

But:

“Here is how to use feature X efficiently.”

For every subsystem, developers should know:

  • what it does
  • how fast it is
  • how much memory it has
  • what its bottlenecks are
  • what causes stalls
  • what operations are expensive
  • what operations are cheap
  • how to profile it
  • how to optimise for it

This should produce practical performance recipes:

  • RVV-optimised image processing
  • Vortex GPU matrix multiplication
  • NPU INT8 inference
  • CPU-to-NPU zero-copy pipelines
  • GPU local-memory optimisation
  • video-processing pipelines
  • fast cryptography using RVV
  • AI inference with minimal DRAM traffic

The expert developer effectively becomes a teacher for the platform.

Once an optimisation is understood, it can be incorporated into compilers, libraries and the operating system so that millions of ordinary users benefit without knowing the details.

Canonical India: the software side of the learning loop

The idea of a hypothetical “Canonical India” becomes much more interesting when viewed this way.

It should not simply be another Linux distribution.

It should be the software layer connecting applications to Indian hardware.

Its responsibilities could include:

  • Linux/RISC-V support
  • kernel optimisation
  • LLVM/GCC toolchains
  • RVV optimisation
  • Vulkan and GPU drivers
  • NPU runtime
  • VPU frameworks
  • power management
  • profiling tools
  • developer SDKs
  • performance libraries
  • hardware documentation
  • long-term security updates

The platform could then receive major improvements twice a year.

The hardware might remain unchanged, but its compiler could become better at RVV.

The GPU driver could become more efficient.

The NPU runtime could support more operators.

The browser could become better optimised.

AI libraries could learn to use the accelerator more effectively.

The result is a machine that becomes more capable over time without changing its silicon.

Refine: the interfaces become the next target

Once individual components are reasonably mature, the biggest performance gains may come from the interfaces between them.

Consider an AI application.

The CPU prepares data.

The GPU processes it.

The NPU performs inference.

The VPU processes video.

The result goes back to the CPU.

If every stage copies data through DDR5, enormous amounts of bandwidth are wasted.

The refined architecture should therefore increasingly support:

  • shared buffers
  • zero-copy transfers
  • coherent caches
  • direct DMA
  • shared system cache
  • hardware scheduling
  • efficient accelerator hand-off

The system becomes faster not because each component becomes dramatically faster, but because they spend less time waiting for one another.

What could an optimised 22nm system actually do?

This is where the comparison with a modern 4nm system becomes useful—but only if we define the comparison correctly.

A modern 4nm flagship system will generally have major advantages in transistor density, CPU performance, GPU capability and power efficiency at the transistor level.

It would be misleading to claim otherwise.

For example, even a relatively ordinary modern Core i5-14400 already has 10 cores, 16 threads, turbo frequencies up to 4.7GHz and up to 76.8GB/s of memory bandwidth.

The hypothetical Indian 22nm computer does not need to beat such a processor in every benchmark.

Instead, it needs to make the majority of everyday workloads feel sufficiently fast.

That is a different target.

A hypothetical 22nm mainstream system

Component Illustrative Target
CPU 8-core OoO RISC-V, RV64 + RVV
CPU frequency approximately 1.5–2.0 GHz target
GPU Vortex 3.x/4.x-class iGPU
GPU capability approximately 300–500 GFLOPS FP32 target
NPU Coral-derived / evolved Indian NPU
NPU local memory several MB
VPU dedicated H.264/HEVC/AV1-class engine
System cache 8–16 MB target
RAM 16 GB baseline, 32 GB premium
Memory dual-channel DDR5-class
Bandwidth approximately 100 GB/s or higher
Storage 128–512 GB NVMe/high-endurance SSD
OS Linux/RISC-V platform with continuous optimisation

This is a conceptual system specification, not a forecast of an actual product.

Could it handle 30 browser tabs?

Yes, potentially—and this is exactly the kind of workload where raw process-node comparisons become misleading.

Thirty browser tabs do not mean thirty tabs continuously consuming maximum CPU performance.

Many are idle.

Some are waiting for network data.

Some are rendering small amounts of JavaScript.

Some are displaying static documents.

Some may be playing video.

A well-designed 16–32GB system with good browser optimisation, fast storage and competent memory management should be capable of handling dozens of ordinary browser tabs.

The difficult case would be thirty simultaneously active, JavaScript-heavy, video-rich applications.

That is true even on much faster machines.

Office work should be almost trivial

Documents, spreadsheets, presentations, PDFs, email and web applications are exactly the workloads a mature 22nm system should be expected to handle comfortably.

In fact, this is the first place where the “own the everyday” strategy becomes convincing.

An employee writing reports does not need the CPU performance of a workstation processor.

A student preparing a presentation does not need a high-end GPU.

A government department processing forms does not need leading-edge silicon.

If the software is optimised and the machine has adequate memory, these workloads should feel normal.

Offline AI becomes the interesting differentiator

A properly designed NPU changes the equation.

Instead of sending every AI task to a cloud server, the local machine could handle many smaller models directly.

Potential workloads include:

  • speech-to-text
  • text-to-speech
  • live captions
  • document summarisation
  • translation
  • OCR
  • image enhancement
  • background removal
  • noise reduction
  • local chat assistants
  • school-learning assistants
  • classification and search

Some of these workloads could be genuinely excellent on a mature 22nm NPU because they are precisely the workloads specialised accelerators are intended to handle.

But generative AI needs a more careful distinction

Small local language models are a realistic target.

Medium models may be practical with sufficient RAM and aggressive quantisation.

Large models will remain constrained by memory capacity and bandwidth.

Image generation is possible locally with the right accelerator and model, but speed and image resolution will matter.

Video generation is substantially more demanding.

A 22nm mainstream computer should therefore not promise workstation-class local video generation.

It could, however, provide:

  • small local generative models
  • AI-assisted video editing
  • frame interpolation
  • upscaling
  • background replacement
  • short low-resolution generation
  • cloud-assisted high-end generation

This is where the “own the everyday, rent the extraordinary” model becomes extremely practical.

Image processing could be surprisingly strong

Image processing is an excellent example of why specialised hardware matters.

Resize an image.

Remove noise.

Sharpen it.

Convert colour spaces.

Run OCR.

Detect objects.

Apply an AI filter.

Much of this can be parallelised.

RVV, Vortex and the NPU can divide the work.

The CPU orchestrates the application.

The VPU or ISP handles media-specific operations.

The result can be a machine that is considerably more capable than its CPU benchmark suggests.

Coding should be comfortable

A mature Indian system should be able to run modern development tools, compilers, editors, Git, containers and local development environments.

Compilation of enormous projects would remain slower than on a high-end modern CPU.

But ordinary software development, web development, Android development, scripting, database work and system programming should be entirely practical.

And coding itself becomes one of the most important feedback mechanisms.

The developers building software for the machine are simultaneously improving the platform.

Gaming is possible—but should be defined carefully

The first integrated Vortex GPU should not be marketed as an NVIDIA replacement.

That would be premature.

Instead, target:

  • indie games
  • older AAA games
  • eSports titles
  • 1080p gaming
  • Linux-native games
  • emulation
  • GPU compute
  • educational graphics

If Vortex 3.x becomes mature enough, and later Vortex generations improve the graphics pipeline, memory system, drivers and Vulkan implementation, the ceiling rises.

Then the discrete GPU can emerge from the same technology family.

The 22nm versus 4nm comparison

It is tempting to create a table saying:

Capability 22nm Indian System Modern 4nm System
Raw CPU performance Likely lower Much higher
Peak GPU performance Likely lower Much higher
AI acceleration Potentially strong for targeted workloads Generally stronger overall
Web/office Potentially excellent Excellent
Local speech/AI Potentially excellent with NPU Excellent
Heavy rendering Behind Far ahead
High-end gaming Behind Far ahead
Everyday responsiveness Potentially comparable Excellent
Hardware openness Potentially very high Very low
Domestic control Potentially high Dependent on foreign supply chain

But this table misses the real point.

The objective is not to claim:

22nm = 4nm.

The objective is:

22nm + excellent architecture + accelerators + memory + software + optimisation can deliver a much larger fraction of the user experience than the process-node numbers suggest.

22nm FD-SOI could make this particularly interesting

22nm FD-SOI is not simply “old silicon.” GlobalFoundries developed 22FDX specifically around the balance between performance, power and cost, with adaptive body bias allowing designers to trade performance and power dynamically. GF has also continued developing its FDX platform for embedded AI and low-power applications.

That makes FD-SOI conceptually attractive for an Indian computing platform aimed at mainstream systems, edge devices and eventually mobile products.

But it is important to remain realistic.

A future Indian 22nm FD-SOI capability would require much more than simply obtaining a process recipe. It would require suitable SOI manufacturing, PDKs, standard-cell libraries, SRAM, analogue/RF IP, EDA support, packaging and qualification.

Therefore, 22nm FD-SOI should be treated as a strategic future possibility, not as an assumption about the current Dholera roadmap.

Miniaturise: only after the system is understood

This is why the ultrabook should come later.

The first machine can be thick.

The second can be better.

The third can be smaller.

By the time engineers reach the ultrabook stage, they should know:

  • how much SRAM the GPU really needs
  • how much SRAM the NPU really needs
  • how much memory bandwidth the CPU actually consumes
  • how much the GPU needs
  • how much video processing costs
  • where the interconnect becomes a bottleneck
  • how much power each block consumes
  • which blocks should be integrated
  • which should remain modular

Then integration becomes an informed engineering decision rather than a gamble.

Mobile comes last

A smartphone is the most unforgiving version of the problem.

There is little cooling capacity.

Battery energy is precious.

Memory bandwidth matters enormously.

Every milliwatt matters.

Camera, ISP, display, modem, RF, security, audio and AI all compete for the same power envelope.

That is precisely why the mobile platform should emerge from the lessons learned on larger machines.

The smartphone should be the miniaturised expression of a mature computing architecture, not the place where India first attempts to learn it.

The six-stage Indian computing roadmap

Stage Primary Objective
Learn Build the first modular computer and understand every subsystem.
Improve Refine CPU, GPU, NPU, VPU, memory, compiler and operating system.
Scale Deploy to government, education, enterprise and developers.
Refine Optimise interfaces, power, memory and SoC integration.
Miniaturise Move the mature architecture into thin, efficient 22nm-class systems.
Mobile Adapt the mature platform to smartphones and edge devices.

And these stages should not freeze the component roadmap.

Vortex 3.x can enter when ready.

Vortex 4.x can replace it when mature.

A better CPU can arrive independently.

A better NPU can arrive independently.

A better memory controller can arrive independently.

A better SSD controller can arrive independently.

The platform remains stable while its components evolve.

The parallel roadmap is the real secret

INDIAN COMPUTER PLATFORM
        │
        ├── CPU
        │    └── Gen1 → OoO → RVV → Gen2 → Gen3
        │
        ├── GPU
        │    └── Vortex 3 → 3.x → Vortex 4 → Vortex 5 → Discrete
        │
        ├── NPU
        │    └── Coral-derived → tuned → larger SRAM → Indian NPU
        │
        ├── VPU
        │    └── Basic → 4K → AV1 → advanced media engine
        │
        ├── Memory
        │    └── DDR5 → better controller → higher bandwidth
        │
        ├── Storage
        │    └── NVMe → controller → SSD module → deeper NAND ecosystem
        │
        └── Software
             └── Linux → platform SDK → optimisation → Canonical India*

*Canonical India is a proposed concept, not a currently announced organisation.

Every component advances when it is ready.

That means the platform never has to wait for the slowest component, and it never has to adopt immature technology simply because the product roadmap says it is time.

The real product is the parameterised Indian Computer

Over five years, the project should accumulate something more valuable than a collection of chips.

It should accumulate a deep quantitative understanding of the machine.

Engineers should know:

“If we add 1 MB of SRAM, what happens?”

“If we double GPU bandwidth, what happens?”

“If we increase CPU cache, which workloads improve?”

“If the NPU gets another 2 MB of local memory, how many more inferences per second do we obtain?”

“If Vortex gets another eight cores, does the system actually get faster?”

“If not, where is the bottleneck?”

This is what it means to master the basics.

It is not about knowing that the computer has a GPU.

It is about knowing precisely how the GPU behaves.

The first four or five years are therefore not a delay

They are the investment.

India would be building an engineering feedback loop:

Hardware
   ↓
Real users
   ↓
Measurements
   ↓
Documentation
   ↓
Developers
   ↓
Optimised software
   ↓
Performance data
   ↓
Better architecture
   ↓
New hardware
   ↓
More users

Every cycle makes the next cycle easier.

And this is where the distinction between a 22nm and 4nm machine becomes less important.

The 4nm system may always have an enormous raw-technology advantage.

But the Indian system can progressively become better at extracting useful work from its available silicon.

The ultimate objective

The objective should never be:

“India must make a 22nm chip that beats a 4nm chip.”

That is the wrong race.

The objective should be:

“India should build a computing platform where a mature process, intelligently designed hardware and highly optimised software can deliver excellent everyday computing at scale.”

If that platform can handle dozens of browser tabs, office work, coding, education, video conferencing, media consumption, local speech recognition, document summarisation, image processing and useful local AI—and provide reasonable gaming—then it has already achieved something important.

If demanding AI generation, scientific computing or high-end gaming exceeds the local machine's capability, the user can rent that capability from a data centre.

That is not failure.

That is the architecture.

Own the everyday. Rent the extraordinary.

The 22nm computer does not need to be the world's fastest computer.

It needs to be good enough, efficient enough, affordable enough and open enough that millions of people can use it.

The first generation teaches engineers.

The second generation improves the architecture.

The larger user base teaches the software ecosystem.

The software ecosystem teaches the hardware designers.

Vortex evolves.

The CPU evolves.

The NPU evolves.

The memory system evolves.

The storage system evolves.

The operating system evolves.

The developers evolve.

And eventually all those independently matured pieces can be compressed into a highly integrated ultrabook.

Then, when the engineering knowledge is deep enough, they can be compressed again into a smartphone.

That is the real meaning of:

Learn → Improve → Scale → Refine → Miniaturise → Mobile.

It is not simply a product roadmap.

It is a national engineering learning curve.

And perhaps the most important thing India could build during those first five years would not be a processor, GPU or laptop at all.

It would be the accumulated knowledge of exactly how its own computer works.

Because once you understand the parameters, you can improve the parameters.

And once you can improve them continuously, a 22nm computer no longer has to behave like what people expect from a 22nm computer.

That is where the real opportunity begins.

Own the everyday. Rent the extraordinary. Keep improving the silicon. And make every generation smarter than the one before it.

Friday, September 11, 2026

The Indian Computing Ecosystem: Own the Everyday, Rent the Extraordinary

How Dholera, RISC-V, 22nm FD-SOI, open hardware, Ubuntu and Indian data centres could combine to create a three-tier computing ecosystem — without India ever needing to win the race to the smallest transistor.

Note on the scenario: This article deliberately separates what exists today from what could be built over the next several years. Tata Electronics currently describes the Dholera fab as a planned 300mm facility with 50,000 wafers per month of capacity for analogue and logic products in the 28nm–110nm range. Tata has also described access to a broader PSMC technology portfolio including 28nm, 40nm, 55nm, 90nm and 110nm. The 22nm FD-SOI stage discussed later is therefore a future scenario, not a current Dholera commitment.

The question is no longer whether India can build a computer

Imagine looking back from 2032.

India has a domestic semiconductor industry. Dholera is producing chips. Indian companies design RISC-V processors and specialised accelerators. Linux runs on domestically designed silicon. Indian universities routinely tape out chips. Data centres across the country offer rented AI and high-performance computing capacity.

And there is something else that would have seemed improbable a decade earlier.

Millions of Indians are using computers whose most important silicon was designed and manufactured within an Indian-led ecosystem.

They are not necessarily the fastest computers in the world.

They do not need to be.

They are fast enough.

They are efficient.

They are inexpensive enough.

They run familiar software.

They are upgradeable.

And when their users occasionally need vastly more computing power, they connect to Indian data centres and rent it.

That is the idea behind what I would call the Indian Computing Ecosystem.

It is not an attempt to build an Indian equivalent of Apple, NVIDIA, Qualcomm, Microsoft and TSMC simultaneously.

It is something more pragmatic.

Build a domestic computing platform that is good enough for the majority, open enough to evolve, large enough to attract developers, and connected enough to outsource the workloads that genuinely require leading-edge computing.

And surprisingly, the foundation for such a strategy may not require India to manufacture the world's smallest transistor.

It may require something closer to a well-designed 22nm-class system.

The first principle: stop confusing transistor size with user experience

Much of the semiconductor industry is described as a race:

7nm.

5nm.

3nm.

2nm.

1.4nm.

And eventually whatever comes after that.

For semiconductor engineers, these advances are enormously important.

For the average user, however, the transistor node is almost irrelevant.

A user experiences:

  • how quickly an application opens;
  • how responsive the interface feels;
  • how smoothly video plays;
  • how long the battery lasts;
  • how quickly a webpage renders;
  • how well multitasking works;
  • how quickly a photograph is processed;
  • how good the AI assistant feels;
  • how quickly the computer wakes from sleep;
  • how quietly it operates.

None of those experiences is determined by transistor size alone.

Architecture matters.

Cache design matters.

Memory bandwidth matters.

Storage matters.

Software matters.

Compilers matter.

GPU architecture matters.

Dedicated video engines matter.

Neural accelerators matter.

Power management matters.

And perhaps most importantly, hardware and software have to be designed together.

This is where the Indian opportunity becomes interesting.

The Dholera starting point

The Dholera semiconductor fab being developed by Tata Electronics in partnership with Taiwan's Powerchip Semiconductor Manufacturing Corporation, or PSMC, is the physical anchor for this discussion.

Tata currently describes the facility as a 300mm fab with planned monthly capacity of 50,000 wafers, serving analogue and logic applications in the 28nm–110nm range. Tata says the chips are intended for markets including automotive, computing, communications, AI, IoT and data storage.

Tata's more recent description of its technology partnerships says PSMC provides access to a technology portfolio including 28nm, 40nm, 55nm, 90nm and 110nm.

This is important because it immediately changes the question India should be asking.

It does not have to begin by asking:

“How do we manufacture a 1.4nm processor?”

It can ask:

“What useful computers can we build with the processes we have?”

That is a much more productive question.

Generation One: build the computer before trying to build the perfect computer

Suppose the first commercially useful domestic logic platform available to Indian designers is around the 40nm-class level.

That should not be regarded as a failure.

It should be regarded as Generation One.

The first objective should be to create a functional, modular computer around domestic silicon.

Not an ultrabook.

Not a MacBook killer.

Not a flagship gaming machine.

A development computer.

A machine that can boot Linux, browse the web, run office applications, compile software, play video, connect to networks and serve as a platform on which thousands of engineers and students can develop the next generation of Indian silicon.

This is where the philosophy of MNT Reform becomes particularly relevant.

MNT has designed its Reform systems around modularity. Its processor is implemented as a replaceable System-on-Module connected to the motherboard through a 200-pin connector. MNT has produced multiple compatible processor modules and explicitly documents the hardware so that others can design replacement modules.

That is almost exactly the architecture India needs for an experimental domestic computing platform.

The laptop becomes a carrier for evolving silicon

Consider the traditional laptop.

Its CPU is soldered to the motherboard.

The memory is soldered or tightly integrated.

The GPU is integrated into the SoC.

When the processor generation changes, the entire computer usually changes.

The modular approach reverses that relationship.

The computer becomes the stable platform.

The compute module becomes the evolving component.

                 MODULAR INDIAN COMPUTER

       ┌─────────────────────────────────────┐
       │ Display                             │
       │ Keyboard                            │
       │ Battery                             │
       │ USB                                 │
       │ Audio                               │
       │ Storage                             │
       │ Networking                          │
       │ Power management                    │
       │                                     │
       │       ┌───────────────────┐         │
       │       │  COMPUTE MODULE   │         │
       │       │                   │         │
       │       │ RISC-V CPU        │         │
       │       │ GPU               │         │
       │       │ NPU               │         │
       │       │ Memory controller │         │
       │       │ Security          │         │
       │       └───────────────────┘         │
       │                                     │
       └─────────────────────────────────────┘

Generation One goes into the machine.

Generation Two replaces it.

Generation Three replaces it again.

The keyboard doesn't need to change.

The screen doesn't need to change.

The chassis doesn't need to change.

The storage doesn't necessarily need to change.

The software ecosystem largely survives.

The silicon improves.

That is a fundamentally different way of designing a computing ecosystem.

Why MNT Reform is such an important precedent

MNT's experience demonstrates that this isn't merely a theoretical architecture.

The company has already created multiple processor modules for Reform systems, including the RKX7 FPGA module. Its architecture allows different modules to contain very different SoCs or an FPGA while sharing a common motherboard.

The RKX7 is particularly relevant because it allowed an FPGA-based RISC-V system to become a real laptop computer rather than remaining an isolated laboratory development board.

That is an important distinction.

An FPGA development board tells an engineer whether the design works.

A laptop tells thousands of users whether the system works.

Those are very different tests.

The first Dholera computer should therefore be a learning machine

Imagine a first-generation Indian compute module based on an open RISC-V processor such as SHAKTI or CVA6, combined with open or licensable peripherals and accelerators.

A reasonable engineering target could look something like this:

Component Generation One target
Process 40nm-class, subject to actual Dholera/PSMC availability
CPU RISC-V, approximately 1GHz target
Memory 4–8GB baseline; higher-capacity modules where practical
Memory technology DDR3/DDR4-class, depending on available PHY/controller technology
GPU Modest integrated or adjacent accelerator
NPU Basic edge-AI accelerator
Storage 128GB or more, preferably modular
Operating system Linux/Ubuntu
Form factor Thicker, repairable, modular laptop

None of these numbers should be treated as a guaranteed consequence of a 40nm process.

A 40nm process does not automatically produce a 1GHz CPU, just as a 22nm process does not automatically produce a modern laptop processor.

Clock frequency depends on architecture, libraries, SRAM, physical implementation, voltage, thermal design and timing closure.

The point is to establish a credible target for a first-generation platform.

The first generation does not need to be competitive

This is perhaps the most important economic insight.

The first domestic computer does not have to beat Intel.

It does not have to beat AMD.

It does not have to beat Apple.

It does not have to beat Qualcomm.

It certainly does not need to beat NVIDIA.

It needs to teach India how to build the entire system.

That means discovering:

  • which RISC-V core is easiest to productise;
  • which memory architecture works;
  • how to integrate the GPU;
  • how to integrate the NPU;
  • how to bring up Linux;
  • how to write and upstream drivers;
  • how to handle power management;
  • how to debug PCIe;
  • how to build reliable storage interfaces;
  • how to qualify the package;
  • how to manufacture thousands of modules;
  • how to support customers.

That knowledge is the real product of Generation One.

Generation Two: 28nm changes the equation

Now imagine that the ecosystem has spent several years learning.

The second compute module is designed around a 28nm-class process.

The CPU gets more capable.

The cache gets larger.

The memory subsystem improves.

The GPU becomes more useful.

The NPU becomes a serious local AI engine.

Video encode/decode becomes hardware accelerated.

Power management improves.

The software stack is already mature.

Most importantly, the new module plugs into essentially the same computer.

This is where the original “development laptop” starts turning into a genuine mainstream computer.

The software investment compounds

Imagine spending three years getting the first generation of the platform to work properly.

By then, engineers have fixed:

  • boot firmware;
  • Linux kernel support;
  • memory initialisation;
  • USB;
  • PCIe;
  • NVMe;
  • Ethernet;
  • display;
  • audio;
  • GPU drivers;
  • power management;
  • suspend and resume;
  • firmware update mechanisms;
  • security infrastructure.

The second-generation CPU does not have to reinvent all of this.

The software stack moves forward with the hardware.

This is where RISC-V's use of standard profiles becomes particularly important.

Canonical has adopted RVA23 as the baseline for modern Ubuntu RISC-V support, creating a common hardware/software foundation intended to reduce fragmentation between different RISC-V implementations.

That is precisely what a multi-generation Indian hardware ecosystem would need.

We should not build one Indian CPU

This is another important conclusion.

India does not need to declare one RISC-V processor to be the Indian processor.

That would recreate the very centralisation that open hardware is supposed to avoid.

Instead, India could establish a common platform specification.

Something like:

  • RISC-V application profile;
  • standard memory model;
  • standard boot architecture;
  • standard interrupt mechanisms;
  • standard PCIe/NVMe interfaces;
  • standard security requirements;
  • standard graphics interfaces;
  • standard NPU runtime interfaces;
  • standard Linux support requirements.

Then multiple CPU designs could compete.

SHAKTI could compete with CVA6.

A future Indian out-of-order CPU could compete with both.

A startup could develop its own core.

A foreign company could participate.

The software platform would remain relatively stable.

The platform survives the processor.

That is where an “Indian Computing Platform” becomes possible

Think of it as a certification rather than a single chip.

Indian Computing Platform — hypothetical specification

  • ISA: RISC-V
  • Baseline: RVA23 or an appropriate future profile
  • OS: Linux/Ubuntu
  • Security: open or independently auditable Root of Trust
  • Storage: NVMe/SATA/standard removable interfaces
  • Networking: standard Ethernet and wireless modules
  • Graphics: standard Linux graphics stack
  • AI: standardised accelerator APIs
  • Firmware: open, documented interfaces wherever possible

The objective would not be to dictate the CPU.

The objective would be to dictate the contract between hardware and software.

RISC-V profiles are particularly important because common profiles provide a predictable baseline that software can target across different processor implementations while still allowing hardware vendors to innovate.

That is exactly the balance India would need:

standardise enough to preserve compatibility; remain open enough to preserve innovation.

Generation Three: the 22nm FD-SOI possibility

This is where the story becomes much more interesting.

Suppose that after the first generations of Dholera manufacturing and Indian design experience, India establishes a partnership with an experienced FD-SOI foundry ecosystem — potentially involving GlobalFoundries technology, licensing, process-development collaboration or another appropriate technology-transfer structure.

Again, this is a scenario, not a current announcement.

The important point is that India would no longer be approaching such a technology from a standing start.

It would have experience with:

  • domestic wafer manufacturing;
  • process bring-up;
  • PDKs;
  • standard cells;
  • SRAM;
  • physical design;
  • RISC-V silicon;
  • accelerator integration;
  • packaging;
  • Linux enablement;
  • real-world products.

That accumulated experience would make a future technology transition considerably more meaningful than simply saying “let's now build 22nm.”

Why 22nm FD-SOI is attractive

GlobalFoundries' 22FDX is a particularly interesting reference point.

22FDX is a 22nm fully depleted silicon-on-insulator technology designed around performance, power and integration rather than simply chasing maximum transistor density. GlobalFoundries has positioned the platform for applications including IoT, mobile, RF, automotive and edge AI.

That history matters.

It demonstrates that a 22nm-class FD-SOI technology can be commercially relevant at enormous scale.

It is not a theoretical laboratory process.

It is also interesting because FD-SOI provides designers with body-bias techniques that can be used to trade performance and power dynamically.

That makes it an intriguing technology for computers where efficiency matters as much as peak performance.

The 22nm computer should not try to be a 1.4nm computer

This is the central argument of the entire ecosystem.

Suppose a 22nm FD-SOI Indian SoC is substantially slower than the leading processor available from Apple, AMD, Intel or Qualcomm.

That does not automatically make it a bad computer.

Imagine instead that it provides:

  • 8 or more capable RISC-V cores;
  • vector processing;
  • a competent GPU;
  • a dedicated NPU;
  • hardware video encode/decode;
  • strong memory bandwidth;
  • fast NVMe storage;
  • 16–32GB of memory;
  • excellent power management;
  • well-optimised Linux drivers;
  • native applications.

For web browsing, office work, software development, education, video consumption, communications and ordinary AI-assisted workloads, the user may perceive the computer as fast.

The transistor node disappears from the user's consciousness.

They experience responsiveness.

That is the real target.

“Own the everyday. Rent the extraordinary.”

This leads to what may be the most useful phrase for the entire concept:

Own the everyday. Rent the extraordinary.

The mainstream Indian computer does not need to perform every imaginable workload locally.

It needs to perform the overwhelming majority of everyday tasks locally and efficiently.

When the user needs extraordinary computing power, that power can be rented from the cloud.

This produces a three-tier computing architecture.

Tier Technology Purpose
Tier 1 Domestic 22nm-class SoC Mainstream personal computing
Tier 2 Leading-edge foreign/advanced silicon Premium local computing
Tier 3 Indian data centres using advanced global compute Extreme and elastic workloads

These three tiers do not have to compete.

They complement each other.

Tier One: the Indian mainstream machine

This is the market that could become enormous.

The target could be a laptop costing perhaps ₹40,000–₹70,000 in today's purchasing-power terms, depending on memory, display and other components.

It would not necessarily have the fastest CPU.

It would not necessarily have the fastest GPU.

But it could have something more important:

a very high performance-to-cost ratio for ordinary workloads.

The machine might be slightly thicker than the latest ultrabook.

It might have replaceable modules.

It might have an unusually accessible service design.

And it could have a key feature almost completely absent from modern consumer laptops:

the ability to upgrade the computer by replacing the compute module.

The government can provide the anchor market

Here we move from technology into policy.

Suppose India eventually establishes a procurement rule requiring a substantial share of the hardware value of government and government-aided computing equipment to come from Indian-designed or Indian-manufactured components.

This is a hypothetical policy proposal, not an existing mandate.

Suppose further that the resulting addressable institutional base is approximately 20 million users.

The precise number should be treated as a scenario rather than a current official count. Government employment statistics are fragmented across the Union, states, public institutions and government-aided bodies.

But 20 million is useful as a planning assumption.

At 20 million machines:

20 million × ₹50,000 = ₹1 trillion.

That is approximately ₹1 lakh crore of hardware demand over a procurement cycle.

Even if replacement occurred over five years, that represents an average market of roughly four million systems per year.

That is not a niche.

It is an ecosystem anchor.

The government doesn't need to manufacture everything

This is another crucial distinction.

A “domestic hardware” requirement should not mean that every transistor, DRAM chip, display panel and Wi-Fi radio has to be manufactured in India.

That would be counterproductive.

A realistic rule could measure domestic contribution across the system.

A qualifying computer might contain:

  • Indian-designed CPU/SoC;
  • Indian motherboard;
  • Indian power-management electronics;
  • Indian security hardware;
  • Indian firmware;
  • domestically manufactured semiconductor content;
  • Indian assembly and testing.

It could still use imported:

  • DRAM;
  • NAND;
  • display panels;
  • wireless modules;
  • batteries;
  • specialised PHYs.

This is how a real industrial ecosystem develops.

Localise the strategic bottlenecks first.

The 20-million-device base becomes more powerful through household exposure

A government deployment of 20 million computers does not necessarily mean 20 million people are the only people who interact with them.

These machines enter homes.

Children use them.

Spouses use them.

Students encounter them.

Relatives encounter them.

Developers encounter them.

Schools and training institutions begin supporting them.

It is therefore reasonable to imagine a future institutional deployment producing an ecosystem exposure of perhaps 80–100 million people or more, depending on household size, secondary users and educational spillovers.

That is not a forecast.

It is a scenario illustrating the network effect.

The important point is that 20 million machines can create a much larger software market.

And software follows the users

Once tens of millions of people are using a common architecture, developers have a reason to support it.

Today, a developer might ask:

“Why should I optimise my application for Indian RISC-V hardware?”

In a 100-million-user ecosystem, the question changes to:

“How do I make my application run exceptionally well on Indian RISC-V hardware?”

That is how platforms become self-reinforcing.

The installed base creates the developer market.

The developer market creates better applications.

Better applications increase adoption.

More adoption increases hardware volumes.

Higher volumes lower costs.

Lower costs increase adoption again.

That is the flywheel India needs.

The role of Ubuntu — or the hypothetical “Canonical India” layer

This is where the software strategy becomes particularly interesting.

There is no current Canonical initiative called “Canonical India” of the kind imagined in this article.

The phrase is best understood as a shorthand for a hypothetical strategic partnership between Canonical, Indian semiconductor companies, OEMs, developers and government institutions.

But the technical foundations already exist.

Canonical has supported RISC-V in Ubuntu since 2021 and has adopted RVA23 as the baseline for modern Ubuntu RISC-V support. Canonical's stated objective is to make RISC-V practical, scalable and production-ready for silicon vendors, OEMs, ODMs and developers.

This is precisely the kind of software foundation the Indian platform would need.

India should not try to write an operating system from scratch.

It should take advantage of the enormous Linux ecosystem and contribute upstream where Indian hardware needs support.

The operating system should be common even when the CPU changes

Imagine:

Generation One: SHAKTI-based computer.

Generation Two: CVA6-based computer.

Generation Three: a new Indian out-of-order RISC-V processor.

If all three implement an appropriate common RISC-V profile and platform specification, the same Ubuntu ecosystem can continue across generations.

That is incredibly valuable.

The operating system becomes the stable layer.

The CPU becomes replaceable.

The GPU becomes replaceable.

The NPU becomes replaceable.

The compute module becomes a component rather than the identity of the computer.

RISC-V profiles are particularly valuable here because they provide a common feature baseline that software can target across different implementations while still allowing hardware vendors to innovate.

Native applications: the argument is stronger than “Android is virtualised”

There is an important technical correction here.

Android is not simply a Java virtual machine interpreting every application instruction at runtime. Modern Android uses the Android Runtime, or ART, with ahead-of-time and just-in-time compilation, and Android applications can also use native C/C++ code.

The stronger argument for an Indian Ubuntu/RISC-V ecosystem is different.

It is the possibility of having a relatively direct software path from:

application → native libraries → Linux → RISC-V → hardware accelerators.

Developers could build directly for the platform.

Compilers could target the processor.

Libraries could target the vector engine.

AI frameworks could target the NPU.

Graphics libraries could target the GPU.

Video frameworks could target dedicated codecs.

And the entire stack could be tuned together.

RISC-V also permits hardware-specific extensions, allowing specialised processors to expose additional capabilities without abandoning the broader architecture.

That is the real opportunity.

The smartphone becomes the second major battlefield

Once the laptop platform exists, the same philosophy can move into mobile devices.

A future Indian mobile SoC could combine:

  • RISC-V CPU cores;
  • vector processing;
  • GPU;
  • NPU;
  • ISP;
  • video engines;
  • security;
  • display processing;
  • memory controllers.

The difficult component is likely to remain cellular connectivity and some of the high-speed analogue/PHY infrastructure.

India does not need to solve every component simultaneously.

It can localise the processor and compute architecture first while continuing to use licensed or imported specialist IP where necessary.

That is not a failure of sovereignty.

It is rational engineering.

The smartphone does not need to contain the world's fastest processor either

A 22nm-class mobile SoC could potentially be perfectly adequate for:

  • messaging;
  • web browsing;
  • photography;
  • video;
  • social applications;
  • navigation;
  • office applications;
  • local AI assistance;
  • education;
  • communications.

The workloads that require massive compute can move elsewhere.

This creates a natural connection between the device and the data centre.

Tier Two: the premium foreign machine

Nothing in this model requires India to eliminate foreign hardware.

Quite the opposite.

There will always be users who want the fastest machine available.

A professional video editor may want the latest high-end GPU.

A game developer may want a cutting-edge graphics processor.

A researcher may want enormous local memory.

An AI engineer may want multiple high-end accelerators.

A workstation user may need maximum CPU performance.

Those users can buy:

  • Apple;
  • AMD;
  • Intel;
  • NVIDIA;
  • Qualcomm;
  • Lenovo;
  • Dell;
  • ASUS;
  • HP;
  • and other global products.

The domestic platform does not have to defeat them.

It simply needs to dominate — or become highly competitive in — the enormous middle.

That is a far more achievable ambition.

Tier Three: compute as a utility

Now comes the data-centre layer.

Suppose India develops a large domestic ecosystem of AI and high-performance computing facilities.

The precise processors and process nodes used by those facilities will evolve rapidly, so there is little value in predicting exactly which node will dominate a decade from now.

The strategic idea is simpler:

Indian users should be able to rent advanced computing from Indian infrastructure.

A user with a modest domestic laptop could connect to:

  • GPU clusters;
  • AI accelerators;
  • high-memory servers;
  • rendering infrastructure;
  • scientific-computing clusters;
  • large language models;
  • specialised enterprise compute.

The device becomes the local intelligence and interface.

The data centre becomes the elastic horsepower.

This is where the economics become attractive

Imagine a user who occasionally needs a machine worth ₹300,000.

They might need it for only a few hours a week.

Why should they own it?

They could instead own a ₹50,000–₹70,000 mainstream domestic computer and rent high-performance compute when required.

The same principle already operates in cloud computing.

The difference is that the local device remains powerful enough to provide an excellent everyday experience.

It isn't merely a thin client.

It is a genuine computer.

Own the everyday. Rent the extraordinary.

The cloud also creates an escape hatch for the 22nm platform

This is important because otherwise critics will quite reasonably ask:

“What happens when 22nm is no longer competitive?”

The answer is:

It doesn't have to be competitive with everything.

The 22nm computer handles the local workload.

The premium user buys leading-edge hardware.

The rest use cloud compute when necessary.

That means the domestic platform can remain economically viable even as the global semiconductor industry continues to advance.

India therefore doesn't have to win the transistor race

This is perhaps the most provocative proposition in the entire article.

India does not necessarily need to manufacture the smallest transistor in the world to create a sovereign computing ecosystem.

It needs to control enough of the stack.

It needs:

  • domestic semiconductor manufacturing;
  • domestic processor design;
  • domestic accelerator expertise;
  • domestic system design;
  • domestic packaging and testing;
  • domestic software engineering;
  • domestic cloud infrastructure;
  • access to global leading-edge technology where appropriate.

That is sovereignty through optionality, not isolation.

The Netherlands and ASML matter here

This is also why India's semiconductor strategy should not be framed as autarky.

India needs global partners.

Tata Electronics and ASML have announced a strategic partnership under which ASML will support the establishment and ramp-up of the Dholera fab with lithography tools, training, supply-chain development and R&D infrastructure.

This is exactly the kind of international collaboration an Indian computing ecosystem should encourage.

India doesn't need to reinvent lithography.

It needs to become exceptionally good at using lithography.

India-Netherlands collaboration could become part of the design loop

The emerging India-Netherlands semiconductor relationship makes this even more interesting.

The two countries have outlined semiconductor collaboration involving the Dutch semiconductor ecosystem, India's Semiconductor Mission, European universities and Indian technical institutes, with industry participation from companies including NXP, ASML and Tata.

That means the ecosystem can connect:

Indian universities → Dutch semiconductor expertise → ASML → Tata → Dholera → Indian startups → Indian products.

This is precisely the kind of network required to move from semiconductor assembly and fabrication into genuine design capability.

The open-silicon stack becomes the design commons

Now return to the open-hardware projects discussed in the earlier article.

They begin to make sense as components of the larger ecosystem.

Layer Possible open starting points Role
ISA RISC-V Common processor architecture
CPU SHAKTI, CVA6, BlackParrot, VexRiscv General-purpose compute
High-performance CPU XiangShan, BOOM, future Indian designs Advanced local compute
Vector Ara/PULP ecosystem SIMD and AI workloads
GPU Vortex and related projects Parallel compute/graphics research
NPU Coral NPU, NVDLA, Gemmini AI acceleration
ISP Infinite-ISP Camera processing
Video Fudan OpenASIC Video encode/decode
Storage IITM NVMe/OpenSSD ecosystem Storage controllers
Security OpenTitan Root of Trust
SoC infrastructure LiteX and related cores Integration and peripherals
Physical design OpenROAD/OpenLane RTL-to-GDS development
Operating system Linux/Ubuntu Software platform

The important change in perspective is this:

These projects aren't the product.

They are ingredients.

The product is the integrated platform.

The missing middle is system integration

This is where the earlier discussion about MNT Reform becomes crucial.

There are plenty of open CPU projects.

There are open GPUs.

There are open NPUs.

There are open ISPs.

There are open storage controllers.

There are open security architectures.

But putting all of them together is a separate engineering discipline.

The real chain is:

Open ISA
   ↓
CPU
   ↓
SoC integration
   ↓
Memory
   ↓
GPU / NPU / ISP / Video
   ↓
Security
   ↓
PCIe / USB / Ethernet / NVMe
   ↓
Firmware
   ↓
Linux
   ↓
Drivers
   ↓
Physical design
   ↓
Tapeout
   ↓
Dholera
   ↓
Package
   ↓
Compute module
   ↓
Laptop / desktop / phone
   ↓
Real users

That is the actual project.

Why the first laptop should be deliberately modular

A conventional semiconductor company might design the SoC, design the motherboard, solder everything together and launch the product.

That creates a giant single point of failure.

If the CPU is wrong, the product is wrong.

If the memory controller is wrong, the product is wrong.

If the GPU driver is poor, the product is poor.

The modular approach allows the problems to be isolated.

The motherboard can mature separately.

The compute module can mature separately.

The operating system can mature separately.

The storage can mature separately.

And when the silicon changes, the rest of the platform survives.

MNT's Reform architecture is a practical demonstration of this philosophy: the company's processor modules share a common motherboard interface, while different modules can contain very different SoCs or an FPGA.

Generation Four could finally become the ultrabook

This is where the roadmap comes full circle.

The first machine might be thick.

The second might be a conventional laptop.

The third might be genuinely competitive.

The fourth could be thin and light.

And by then, the industry would have accumulated years of experience.

Generation One Generation Two Generation Three
Process 40nm-class* 28nm-class 22nm-class FD-SOI*
CPU ~1GHz target Higher performance Advanced RISC-V/OoO
Memory 4–8GB DDR3/DDR4 8–16GB DDR4-class 16–32GB DDR5-class*
GPU Basic Useful Competitive mainstream
NPU Experimental Practical edge AI Integrated AI engine
Storage 128GB+ 256GB+ 512GB–1TB+
Form factor Development laptop Normal laptop Thin/light

*Illustrative engineering scenario, not a committed Dholera technology roadmap.

The important thing is that the generations are not independent.

They are cumulative.

The first generation creates the engineers who build the second

This is the real advantage.

Suppose 5,000 engineers work on Generation One.

They learn the process.

They learn the PDK.

They learn physical design.

They learn packaging.

They learn Linux.

They learn drivers.

They learn power management.

They learn what breaks in real computers.

Then those engineers move to Generation Two.

Some create startups.

Some join universities.

Some join Tata.

Some join Indian semiconductor design houses.

Some work on data centres.

The ecosystem becomes larger than the original project.

That is how semiconductor capability compounds.

The government should therefore fund the learning curve, not just the finished product

This is where public policy can be unusually powerful.

Instead of funding one “Indian processor” and declaring victory, government programmes could fund:

  • open IP development;
  • verification;
  • MPW shuttle runs;
  • university tapeouts;
  • PDK access;
  • shared EDA infrastructure;
  • open reference boards;
  • RISC-V software development;
  • Linux upstreaming;
  • compiler optimisation;
  • accelerator software;
  • packaging research;
  • system-level reference designs.

The government could effectively create a national semiconductor learning loop.

Every tapeout teaches something.

Every failed tapeout teaches something.

Every laptop sold generates another layer of feedback.

Every software bug becomes an engineering lesson.

Every generation gets better.

The 20-million-user government market can make that learning loop commercial

This is the crucial transition from government-funded research to industry.

If the government becomes an anchor customer, companies can justify building products around the platform.

A laptop manufacturer knows there is a market.

A semiconductor company knows there is a market.

A software company knows there is a market.

A developer knows there is a market.

A cloud provider knows there is a market.

The ecosystem begins to reinforce itself.

There should still be a premium foreign market

And this is where the proposal becomes much more realistic than nationalist technology programmes often are.

India should not ban high-end foreign computers.

It should not prevent Indian consumers from buying the best technology available.

If someone wants the world's fastest workstation, let them buy it.

If someone wants an expensive gaming laptop, let them buy it.

If a professional needs a specialised accelerator that India does not manufacture, let them import it.

The objective is not isolation.

The objective is to make sure that India has a domestic alternative in the mainstream market.

And the premium market can actually help the domestic ecosystem

Foreign companies would continue competing in India.

That competition would push the domestic ecosystem to improve.

Indian companies could learn from global products.

Premium users would have choices.

Domestic developers could benchmark against the world's best.

And when Indian silicon became good enough, it could compete internationally.

This is much healthier than trying to protect a domestic product from competition indefinitely.

Data centres complete the pyramid

The final layer is the data centre.

At the bottom is the mass-market domestic computer.

In the middle is the premium workstation.

At the top is elastic cloud computing.

That gives us:

                  INDIAN COMPUTING ECOSYSTEM

                     ┌───────────────┐
                     │ DATA CENTRES  │
                     │               │
                     │ AI / HPC      │
                     │ Advanced CPUs │
                     │ GPUs / NPU    │
                     │               │
                     └───────┬───────┘
                             │
                       Cloud services
                             │
        ┌────────────────────┴────────────────────┐
        │                                         │
┌───────▼────────┐                         ┌──────▼───────┐
│ PREMIUM LOCAL  │                         │ MAINSTREAM   │
│ COMPUTING      │                         │ DOMESTIC     │
│                │                         │ COMPUTING    │
│ Leading-edge   │                         │              │
│ foreign silicon│                         │ 22nm-class   │
│                │                         │ RISC-V       │
└────────────────┘                         └──────────────┘

The user can move between all three.

The mainstream machine handles everyday tasks.

The premium machine handles demanding local workloads.

The cloud handles extraordinary workloads.

There is no requirement that one device do everything.

This could also change the economics of AI

AI is often presented as a reason every device needs an enormous accelerator.

That isn't necessarily true.

A domestic NPU can handle:

  • speech recognition;
  • image enhancement;
  • background noise reduction;
  • translation;
  • small language models;
  • document classification;
  • local summarisation;
  • camera processing;
  • privacy-sensitive inference.

Large models can remain in the cloud.

This creates a useful division:

Local AI for privacy, latency and cost.

Cloud AI for scale.

A 22nm SoC with a well-designed NPU could therefore remain highly relevant even while the largest AI models run on much more advanced hardware elsewhere.

The same philosophy applies to graphics

An Indian mainstream GPU does not need to compete with the world's most powerful gaming GPUs.

It needs to provide:

  • smooth desktop graphics;
  • video playback;
  • hardware composition;
  • light 3D;
  • accelerated browsers;
  • developer graphics;
  • basic gaming.

Users who require professional rendering or high-end gaming can move to premium hardware or cloud GPU services.

That is a rational allocation of silicon.

The real competitive advantage becomes optimisation

This is where the 22nm thesis becomes strongest.

If India controls the CPU design, NPU design, operating system integration and application optimisation, it can compensate for some of the process disadvantage.

A workload that would normally require a powerful CPU can be moved to the NPU.

A video workload can be handled by dedicated hardware.

A vector workload can use vector extensions.

A graphics workload can use the GPU.

A repetitive workload can use a custom accelerator.

The CPU doesn't have to do everything.

The system does the work.

This is why the open-silicon strategy is more than a licensing strategy

It is tempting to think the attraction of open hardware is simply avoiding royalties.

That is too small a view.

The bigger advantage is control over architecture.

If an Indian company owns or can legally modify the CPU architecture, it can change the processor.

If it controls the NPU, it can change the accelerator.

If it controls the compiler, it can optimise the software.

If it controls the OS integration, it can tune the system.

If it controls the manufacturing relationship, it can optimise the design for the process.

That is where the economic value lies.

Dholera then becomes more than a fab

The ultimate strategic objective should not be to make Dholera a factory that manufactures chips designed elsewhere.

That would still be valuable.

But the larger prize is:

design → manufacture → package → deploy → learn → redesign.

That loop should happen increasingly within the Indian ecosystem.

Tata's existing partnerships point in this direction, with collaboration spanning process technology, PDK development, IP creation, design-technology co-optimisation, manufacturing equipment, training and R&D.

That is exactly the infrastructure required for a design-manufacturing feedback loop.

India-Netherlands collaboration could become part of the design loop

The emerging India-Netherlands semiconductor relationship makes this even more interesting.

The two countries have outlined semiconductor collaboration involving the Dutch semiconductor ecosystem, India's Semiconductor Mission, European universities and Indian technical institutes, with industry participation from companies including NXP, ASML and Tata.

That means the ecosystem can connect:

Indian universities → Dutch semiconductor expertise → ASML → Tata → Dholera → Indian startups → Indian products.

This is precisely the kind of network required to move from semiconductor assembly and fabrication into genuine design capability.

The long-term objective should be optionality

By the early 2030s, India does not need to say:

“We manufacture everything ourselves.”

That is neither realistic nor desirable.

It should be able to say:

“We have options.”

We can design our own CPU.

We can modify our own CPU.

We can manufacture selected chips domestically.

We can package them domestically.

We can run our own software.

We can build our own cloud.

We can buy leading-edge foreign hardware when it makes sense.

We can switch architectures when necessary.

We can develop alternatives when supply chains are disrupted.

That is technological sovereignty.

And this is where the 22nm idea becomes surprisingly powerful

A 22nm device does not need to beat a 1.4nm device.

It needs to be:

  • cheap enough;
  • efficient enough;
  • fast enough;
  • well supported;
  • available at scale;
  • upgradeable;
  • secure;
  • open enough to evolve.

If it can satisfy those conditions, it can become the foundation of a massive computing ecosystem.

The premium 1.4nm-class system can exist alongside it.

The data centre can sit above both.

The user can move between them without even thinking about transistor technology.

The Indian Computing Ecosystem is therefore not one chip

It is a hierarchy.

Layer Indian strategic objective
Open IP Create reusable CPU, GPU, NPU, ISP, security and peripheral building blocks
Domestic silicon Turn those blocks into manufacturable SoCs
Dholera Provide a domestic manufacturing anchor
Modular computers Provide real-world platforms for successive generations of silicon
Ubuntu/Linux Provide a common software foundation
Government demand Create an anchor market
Mass market Create scale and developer demand
Premium market Provide access to leading-edge foreign technology
Data centres Provide elastic high-performance computing
Global partnerships Keep India connected to leading technology ecosystems

The most important product might therefore be the platform

It is tempting to ask:

“Which Indian CPU will win?”

That may be the wrong question.

The better question is:

“Can India create a computing platform in which multiple CPUs, accelerators and generations of silicon can compete while the software and system ecosystem remains stable?”

If the answer becomes yes, then no single processor has to win.

Several can coexist.

Some will be embedded.

Some will be mobile.

Some will be laptop processors.

Some will be servers.

Some will be AI accelerators.

Some will fail.

Others will succeed.

The ecosystem survives all of them.

The ultimate roadmap

The entire strategy can be reduced to a surprisingly simple progression.

Stage One: use the currently accessible PSMC/Dholera process technology to build a modest domestic SoC.

Stage Two: put it into a modular, MNT Reform-style computer.

Stage Three: give those computers to developers, universities, government institutions and early adopters.

Stage Four: use real-world experience to improve the CPU, GPU, NPU, memory subsystem and software.

Stage Five: move to the next Dholera process generation.

Stage Six: repeat the process.

Stage Seven: collaborate internationally on more advanced technologies, potentially including FD-SOI if economically and technically appropriate.

Stage Eight: build a mature 22nm-class mainstream platform.

Stage Nine: deploy it across tens of millions of institutional and consumer systems.

Stage Ten: connect those devices to an Indian cloud/data-centre ecosystem for workloads that exceed local capability.

And eventually:

local device + domestic software + domestic manufacturing + domestic cloud.

The 2030 computer may therefore look very different from the 2026 computer

Not necessarily because the CPU is the fastest.

But because the architecture of computing has changed.

A mainstream Indian laptop could have a domestically designed RISC-V processor fabricated on a mature process.

It could have a powerful NPU that makes local AI feel instantaneous.

It could have an efficient GPU and dedicated video engines.

It could run Ubuntu.

Its applications could be compiled natively for RISC-V.

Its compute module could be replaced when a new generation arrives.

Its user could subscribe to a high-performance Indian cloud when needed.

And the same broad architecture could extend from laptops to desktops, workstations, education systems, government terminals and eventually smartphones.

The result would not be the world's most advanced computer.

It might be something more important:

a computer platform that India controls enough of to keep improving.

Conclusion: India does not have to win the transistor race

There is a seductive idea in technology policy that sovereignty means having the smallest transistor.

It does not.

Technological sovereignty is the ability to make meaningful choices.

India does not need every laptop to contain the world's most advanced processor.

It needs a domestic platform capable of serving the majority of users.

It needs a premium market where the best global hardware remains available.

It needs data centres capable of providing extraordinary computing power when local machines are insufficient.

And it needs the ability to move between those layers without losing control of the underlying ecosystem.

That is why the 22nm FD-SOI idea is interesting.

Not because 22nm is somehow equivalent to 1.4nm.

It isn't.

But because a mature, power-efficient 22nm-class platform may be good enough for an enormous fraction of everyday computing if the architecture, accelerators, memory system and software are designed intelligently.

India could then reserve the most expensive leading-edge computing for the workloads that actually need it.

The mainstream user would own an efficient domestic computer.

The professional could buy an advanced foreign workstation.

The researcher could rent a massive Indian AI cluster.

The student could develop on the same open platform used by the government.

The startup could design an accelerator and eventually put it into silicon.

The university could tape out a processor.

The fab could manufacture it.

The cloud could run it.

And the next generation could improve upon it.

That is the ecosystem.

And perhaps the most important part is that it begins not with a 1.4nm fab, but with something much more achievable:

a modular computer, an open processor, a domestic manufacturing process and enough users to make the entire system economically worthwhile.

The first machine may be thick.

The first processor may be slow.

The first GPU may be modest.

The first NPU may be experimental.

The first version of Ubuntu may have rough edges.

None of that matters.

Because the objective is not to build the perfect Indian computer in one generation.

It is to build a computer that can become better every time the silicon gets better.

And if India can create a 20-million-device institutional anchor, turn that into tens of millions of additional users, attract developers around a stable RISC-V/Linux platform, and connect the whole system to a domestic high-performance cloud, the country would have achieved something far more consequential than a home-grown laptop.

It would have created a national computing platform.

One in which:

the everyday is owned,

the extraordinary is rented,

the silicon keeps evolving,

and the ecosystem never has to start from zero again.

That may ultimately be the more realistic definition of Indian technological sovereignty.

Build the Plinth, Not Every Statue: Why India Needs an Open Technology Consortium

India's next technology challenge is not simply designing more chips, writing more software or manufacturing more devices. It is making ...