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.
No comments:
Post a Comment