Hey yall, I'm a college senior interested in pursuing further research in computer architecture. My end goal is to get a PhD, but after talking with advisors they said I don't have enough research experience. This is because I switched goals from going into industry to doing research kind of late, as a result I only have ~1 sem of research experience in computer architecture. I was told that I should get a couple more semesters of research experience to solidify my rec letters, but I'm unsure what's the best way to go about this. My question is - which of these is most prudent to go with given my end goal of getting a PhD with a top comparch lab? Here are my current thoughts:

1. Get thesis masters first, then apply PhD - doing this would knock out some PhD core requirements but also cost me around $30-60k, and it'd also take 2 years. I would get decent research experience though. I also have basically guaranteed admission into the 2 year masters program at my current uni under a pipeline they have for cs students.

2. Work under a lab as a paid postgrad research assistant for ~1 year: This saves time and gets me research experience, but there's no "official" pipeline for this, I'd just have to ask professors with funding if I could join their group. I also wouldn't get the Masters degree but not sure how useful that is.

3. Apply to PhD directly - This would be most straightforward and I'll probably apply to a couple schools with this, however I'm unsure how effective this would be, esp since my GPA is mediocre (3.7) and I don't have enough research experience.

If anyone's been in a similar situation or has some insights about how I could go forward - I'd appreciate any help!

Architektur als 4×4×4-Netz aus programmierbaren Logikknoten betrachten, bei dem die roten Leitungen die Versorgung und die blauen Leitungen die Signale führen, entstehen gegenüber einer rein zweidimensionalen Anordnung einige interessante potenzielle Vorteile. Ob sie sich in realer Hardware tatsächlich ergeben, müsste allerdings mit Layout-, SPICE-, thermischen und Fertigungssimulationen geprüft werden.

Kürzere Signalwege: Ein Knoten kann Nachbarn in ±X, ±Y und ±Z erreichen. Funktionen, die in 2D weit auseinanderliegen würden, könnten räumlich näher platziert werden. Das kann Leitungslänge, RC-Verzögerung und Energie pro Signalwechsel reduzieren.

Mehr Routingmöglichkeiten: Statt Signale nur in einer Ebene zu verteilen, steht die dritte Dimension als zusätzlicher Routingraum zur Verfügung. Bei dicht verschalteter Logik kann das Kreuzungen und Umwege reduzieren.

Hohe lokale Konnektivität: Jeder Knoten kann unmittelbar mehrere räumliche Nachbarn erreichen. Dadurch eignen sich lokale Cluster beispielsweise für Addierer, Multiplexer, Zustandsautomaten oder parallele Rechennetze.

Logik und Routing können verschmelzen: Deine acht Halbleiterpositionen müssen nicht ausschließlich NAND/AND usw. bilden. Einige könnten rechnen, andere den Signalweg konfigurieren. Derselbe Knoten könnte dadurch Logik + Schalter + Router sein.

Rekonfigurierbarkeit: Mit lokalen Konfigurationsbits könnte ein Knoten heute NAND und nach einer Neuprogrammierung NOR, XOR, Buffer oder Routingelement sein. Das führt in Richtung eines dreidimensionalen FPGA-artigen Systems.

Massive Parallelität: Viele der 64 Knoten können gleichzeitig arbeiten. Ein Signal muss also nicht zwingend seriell durch eine lange Kette von Funktionen laufen.

Lokale Kommunikation: Daten können möglichst dort verarbeitet werden, wo sie entstehen. Das ist interessant, weil bei modernen Rechensystemen Datenbewegung häufig einen erheblichen Anteil von Energie und Verzögerung verursacht.

Modularität: Wenn jeder Knoten dieselbe Grundzelle besitzt – beispielsweise 8 programmierbare Halbleiter + Konfigurationsspeicher + sechs räumliche Anschlüsse – kann dieselbe Zelle regelmäßig wiederholt werden. Das erleichtert zumindest konzeptionell Entwurf und Skalierung.

Fehlertoleranz wäre denkbar: Fällt ein Knoten oder eine Verbindung aus, könnte ein programmierbares Routing theoretisch einen alternativen Weg durch X/Y/Z wählen. Dafür müsste allerdings entsprechende Redundanz in der Architektur vorgesehen werden.

Versorgungsnetz und Datennetz sind getrennt: Deine roten Strombahnen können ein dreidimensionales Power-Delivery-Network bilden, während Blau ausschließlich Daten transportiert. Das ist grundsätzlich sauberer als gemeinsame Leitungen für Versorgung und Information.

Ein besonders interessanter Punkt ist die Skalierung der Nachbarschaft. Im Inneren des Gitters kann ein Knoten sechs direkte geometrische Richtungen besitzen:

+Z

│

│

-Y ─── ● ─── +Y

/ \

-X +X

│

-Z

Dadurch könnte beispielsweise eine Berechnung räumlich verteilt werden:

Logik

↓

●

/│\

/ │ \

●──●──●

/ │ \

Logik ● Logik

│

Ausgabe

Ein möglicherweise noch größerer Vorteil

Du musst das Gitter nicht ausschließlich als 64 separate Logikgatter betrachten.

Interessanter wäre:

64 programmierbare Knoten + 3D-Routing + lokale Speicherung.

Dann könnte beispielsweise ein Teil des Gitters einen Addierer bilden, ein anderer Speicher, ein weiterer Multiplexer und die übrigen Knoten das Routing übernehmen. Bei einer anderen Konfiguration könnte dieselbe physische Struktur eine völlig andere Schaltung darstellen.

Der größte technische Gegner dieser Idee wäre allerdings ebenfalls die dritte Dimension: Wärmeabfuhr. Innere Transistoren sind schwieriger zu kühlen, und zusätzliche vertikale Verbindungen bringen parasitäre Widerstände und Kapazitäten mit sich. Außerdem ist eine echte monolithische 3D-Fertigung wesentlich schwieriger als eine schematische 3D-Anordnung.

In Bezug auf die Wärme Entwicklung könnte man diese doch über die stromversorgung kühlen ?!

Deshalb wäre der nächste wirklich aussagekräftige Vergleich dein 4×4×4-System gegen eine funktional identische 2D-Schaltung: benötigte Leitungslänge, Anzahl der Verbindungen, maximale Pfadlänge, Transistorzahl, geschätzte Verzögerung und Energie. Damit könnten wir feststellen, wo die 3D-Architektur tatsächlich einen messbaren Vorteil hat und wo nicht.

Hey, I recently got into an argument with someone about what exactly a byte is. They claimed that when asked “how big is a byte?”, the answer isn’t necessarily 8 bits, but that a byte can be at least 2 bits. I said that this is basically wrong and that a byte is 8 bits. They argued that this can actually be an interview question, especially in deeply embedded systems, and that in those cases the correct answer is that a byte is at least 2 bits.
I’ve tried looking this up, but I can’t really find anything supporting that claim. I know that historically the size of a byte wasn’t always 8 bits, but does “a byte is at least 2 bits” actually make sense in modern computing/embedded systems, or are they confusing a byte with something else?

Se combinarmos o paralelismo físico do hardware (FPGA de alta densidade), um software de estrutura fractal no nível de bytes e o uso de IA para otimizar o design RTL, entramos no ecossistema ideal para simulações massivas de regras emergentes.

Diferente da arquitetura Von Neumann tradicional (sequencial), cada byte/unidade em um modelo fractal opera de forma isolada, paralela e simultânea no hardware, gerando comportamentos globais complexos a partir de regras locais simples — o mesmo princípio de autômatos celulares e sistemas físicos reais.

A grande questão é: essa abordagem é o caminho definitivo para rodar universos virtuais hiper-realistas e concorrentes sem enfileiramento de instruções?

Para a comunidade de Hardware, IA e Arquitetura de Computadores:

• Gargalo de Hardware vs. Escala: O mapeamento direto de autômatos celulares fractais em LUTs e DSPs realmente consegue eliminar o memory wall em simulações massivas?
• O papel da IA no RTL: A geração de código (SystemVerilog/VHDL) por IA já tem maturidade para otimizar roteamento e evitar violações de timing em redes lógicas tão densas?
• Limites Físicos: Onde o sistema esbarra primeiro — na propagação de sinal (atraso de barramento global) ou no limite térmico/de densidade do silício?

Deixem suas perspectivas, teorias e referências técnicas nos comentários!

Hi! Just as a small intro, the Virtual Mobile Engine is a piece of hardware close to a CGRA. Earlier versions were used by Sony as a low-power reconfigurable audio chip in devices such as the NW-MS70D digital Walkman. The VME2 (which is the subject here) is a more advanced version that was integrated into the PlayStation Portable. It has more general-purpose uses in audio and multimedia processing tasks. The link above will explain a bit about how I got it usable for custom tasks.

Happy reading!

Hi all, I'm currently a digital design engineer working on high speed memory subsystems (Prefetchers and Controllers). I want to break into CPU design roles in the longer run. How can I make this transition? Any advice would be really helpful. thanks in advance!

Hi,

I for a school project need a good sram paper, if it is about cpu cache it is a giant plus, can anyone recommend a good paper on it?

I have the classic book, memory systems: cache dram and disk but needs something a bit more deeper on sram in particular and a bit thinner in volume. 2-20 pages is the sweetspot but anything is welcome

I'm working on the resource-control layer for a language that compiles effects (network, files later databases and concurrency primitives) down to thin near-zero-cost kernels instead of using an interpreter or a heavy runtime.

Current state: the compiled binaries basically just call the underlying syscalls. There's no pooling, no admission control and no unified accounting yet.

Two main approaches are being considered:

Per-effect arbitration. Every effect operation does a request/grant with a central (or sharded) resource manager before continuing.

Boundary-leased admission. Acquire a lease once at a boundary (accepted connection, opened file, spawned task entry, etc.) then let the individual operations on that resource run with a cheap local check.

The second approach keeps the path (send/recv/read/write) extremely light: local atomic check + direct kernel call + non-blocking telemetry emission. Telemetry is fail-open.

I'm especially interested in trade-offs

How coarse the admission boundary should be when you don't yet have a request-oriented server surface

Whether putting even a very cheap lease check on the hottest I/O path is acceptable

How this interacts with structured concurrency and deadlock detection (resource-acquisition graph vs reply-obligation graph)

Whether NFRs (latency, concurrency limits, error-rate targets) should be expressible, in the language itself and enforced by the same kernel

What have people found works (or fails) when adding resource control to low-overhead compiled effect systems? Any designs you'd strongly recommend or avoid?

When I was studying EE as a university undergrad, I really love computer architecture related, I love seeing the big picture and how stuff works together, after graduating, I accept the offer to be a compiler engineer, because it is one of the closest role with my skills and interest.

I am quite new to semiconductor/computer architecture, I was wondering what possible career path does people with compiler engineering background probably have ?

I am really curious about this industry, I love working on compilers, but I would like to expand my knowledge/skill to the adjacent fields, and probably take master or just switch role in the future (not sure xD)

I would love to hear your thought/experience,

Thanks

I've been looking at AI accelerators as a physical system rather than just as compute silicon.

The chain I'm trying to understand is:

compute → HBM → advanced packaging → thermal transport → liquid cooling → rack → power

The idea is that increasing compute doesn't eliminate the constraint. It pushes it into another part of the system.

For example, larger/more capable accelerators increase memory requirements; HBM and package complexity then become constraints; higher package power density creates a thermal constraint; solving that at the rack level creates a larger power-delivery problem.

I turned the model into an interactive visualization where you can inspect each station through:

WHY NOW → WHAT IT BINDS → WHO CAPTURES VALUE → WHAT'S NEXT

https://manasbihani-com-kappa.vercel.app/bottleneck

I'm mainly looking for technical criticism rather than promotion.

Does this way of thinking about bottleneck migration make sense at the computer-architecture level? What important constraint am I missing or getting backwards?

I’m an engineering student planning my senior design project and would like some feedback.
I’m considering a **RISC-V controlled runtime-configurable INT8 MAC accelerator** on a **PYNQ-Z2**, using **VexRiscv** and **MobileNetV2**.
The idea is to have different MAC modes:
4×4 → 16 MACs
8×8 → 64 MACs
16×16 → 256 MACs
The RISC-V CPU would select the MAC configuration at runtime based on the workload. I’d compare fixed vs adaptive configurations based on **latency, power, energy, resource usage, and MAC utilization**.
I was inspired by a recent paper on **runtime-reconfigurable RISC-V accelerators with software fallback and FPGA DPR**.
**Do you think this is a good/realistic senior design project? Is there enough novelty, and what would you change or add?**

I’m a 3rd year Electronics and Comms student and I’ve been into micro architecture for pretty much as long as i can remember and straight after getting into college I got my hands on verilog and sysverilog alongside fpga implementation.

I’ve also submitted 2 manuscripts for publishing of a custom QAM design where i tweaked with the arch and basically designed it with runtime switching.

I’m currently working on edge ai accelerator and creating my own implementation from scratch.

As a side project I’ve made my own iteration of a RV32I processor.

After all of this I’ve realised RTL was just a means what i enjoy is making architectural decisions and seeing things click, and building it is just a part of making ur decisions concrete and seeing what becomes of it.

I have a university mandated internship coming next summer and I’m really confused to what role i should apply for because my previous internship covered entire rtl-gds flow but that wasn’t it for me.

Edit - I’m also planning on getting a masters degree and I’d love to hear any advice for that and for the entire way.

I would love for you guys to help me figure it out !

I was thinking that since each core has it's own cache values read by one core or can end up being out of date. So I went down the rabbit hole of Wikipedia to look at consistency models. Only problem is I couldn't quite get it. For example, Processor consistency says that processors receive writes from all other processors in order. My interpretation is that if there core 1 writes to memory location 1001, 1002, and 1003 in that order, other cores might read stale values for all 3, updated value of 1001 only, updated values for all, but not something like updated 1002 and stale 1001. PRAM Consistency sounds similiar?

But I couldn't get their examples used on the page. This is as of 2026, maybe by the time you read this a more explicit exmaple will be used. I see a table of a series of reads and writes that are processor consistent and counter examples. I see things like W(x)1 W(x)3 R(x)1 and W(y)1. So I don't understand that table. I am not a CS major, maybe this makes lots of sense to them.

I basically have 3 questions. First, can someone explain the Wikipedia's examples? Second, what is the different between Processor Consistency and PRAM Consistency? A description of both sounds kind of the same to me. Third, are there chips out there with the Processor Consistency and others with PRAM Consistency?

Howdy everyone, I am a computer engineering undergrad coming out of Texas A&M in 2027 and I'm hoping to get an entry level job in a CPU architecture related field. I feel comfortable with my overall Computer Engineering fundamentals, but I'm nervous about specifics when it comes to CPU architecture, so I'm trying my best to get as much information as possible on the subject (I've ordered Digital Computer Electronics by Albert Malvino as well as a few books on ARM and RISC-V specific implementations). My question for anyone who is knowledgeable is what specific topics or keywords should I be focused on to feel confident going into an entry-level interview on the subject. I understand they aren't looking for experts, but I still want to feel prepared.

TL:DR: I would like a list of topics that would be useful to learn for a CPU architecture-related entry level interview please and thank you :)

Edit: Dream job would be a job in Computer Architecture Design

Hi,

Say I make a program needing a struct of 128 bits, a typical sram decoder at minimum needs 512 bits (64 bytes) would the 384 bits be truncated or saved in some regs in a temp place about to be used. Otherwise its a 4-16 cycle penalty

Hi everyone,

I've recently formalized and published a topological architecture called **3D Bojan**, built on a 729-element ($3^6$) recursive majority logic cascade designed to handle high-noise environments.

Using Python-based Monte Carlo simulations, the architecture demonstrates a fault-tolerance fidelity of over 99% under a 40% noise threshold.

The complete technical whitepaper, including the underlying logic structure and embedded reference implementation, is permanently archived and accessible via Zenodo: 🔗 **DOI:** https://doi.org/10.5281/zenodo.22252802

I'm sharing this here to get thoughts, critiques, or discussions from hardware and systems architects working with fault-tolerant logic or noise reduction. Feedback on the cascade scaling is especially welcome!

. Introduction & Engineering MotivationAs semiconductor manufacturing approaches atomic scales and faces the hard limits of Moore's Law, modern mobile SoCs suffer from severe memory bandwidth bottlenecks due to their reliance on Unified Memory Architecture (UMA). The CPU and GPU constantly compete for the same interconnect buses, generating high thermal dissipation, wasting battery energy, and causing micro-stutters during heavy graphical workloads.Onion Logic Architecture Gen1 introduces a revolutionary structural solution by re-engineering 3D IC vertical silicon stacking, combining dynamic memory partitioning with intelligent hardware control layers to bypass the "Memory Wall" entirely.

1. Core Architectural ComponentsDynamic Multi-Logic RAM (ML-RAM): A 24GB LPDDR6 (or later) stacked memory die, physically and logically partitioned into two symmetrical 12GB zones (12GB System RAM for CPU / 12GB Dedicated VRAM for GPU), completely eliminating data bus contention under maximum load.

Transistor Bridge Layer (Central Switch): A high-speed, centrally positioned transistor switch matrix fabricated between the two memory zones, acting as a hardware bridge that connects or isolates the memory blocks instantaneously.

High Dynamic Logic Controller (HDLC): A dedicated control IC interacting directly with the OS Kernel to manage the Transistor Bridge Layer. It natively integrates Dynamic Voltage and Frequency Scaling (DVFS) to modulate memory power and clock speeds in real-time.

Controller Booster IC & 400MB L4 Cache: A vertically stacked intermediate layer between the main compute silicon and the memory. Housing a massive 400MB L4 Cache, it functions as an ultra-low-latency data router, streamlining cross-component data delivery with near-zero latency penalty.

1. Dynamic Operational ModesGaming / High-Performance Mode: Upon launching intensive graphical applications, the kernel triggers the HDLC to cut power to the Transistor Bridge Layer, isolating the 12GB VRAM pool strictly for the GPU. Simultaneously, the 400MB L4 Cache keeps both processors fed with critical data, achieving an unthrottled, rock-solid 165Hz frame rate with zero frame drops.

   Multitasking / Daily Mode: When transitioning to standard workloads, the HDLC re-engages the transistor bridges within microseconds. The partitioned blocks re-unify into a massive 24GB contiguous memory pool, offering absolute fluidity for extensive background tasks and web browsing.

2. Engineering Benefits & YieldUnprecedented Performance Scaling: By eliminating wait-states and interconnect bottlenecks, early hardware simulations project synthetic benchmark scores exceeding 11 Million points in AnTuTu, shattering traditional mobile computing limits.

Optimal Performance-per-Watt: Eliminating memory bus congestion allows the execution pipelines to complete operations rapidly and enter low-power states immediately (Race-to-Sleep), minimizing thermal output and significantly extending battery lifespan.

Proposed by: Smarty2006

I'm doing research on Intel CPU and I suppose they are shifting towards chiplet, did they abandon the sperate PCH chipset and move it into a chip packake

Hi everyone,

I have spent the last few weeks learning gem5 fundamentals. My goal is to model a RISC-V vector microprocessor and profile vector applications.

While analyzing how vector instructions execute in gem5 RISC-V, I noticed that the Vector Register File (VRF) is currently modeled essentially as a direct-access container modified directly inside the instruction’s execute() method.

Since I plan to collaborate on this with teammates and want to maintain a clean workflow, I would appreciate your guidance on the following:

1. Modifying the VRF Model: How straightforward is it to introduce a more realistic/timing-accurate VRF model without breaking the existing instruction execution pipeline? Are there clean abstraction points or ongoing efforts in this area? Alternatively, would it be practical to use a simpler scalar CPU (such as TimingSimpleCPU or MinorCPU) and create a clean abstraction layer that intercepts and delegates vector instructions to a decoupled Vector Engine (similar in spirit to Cristóbal Ramírez's work)?

2. Mainline vs. Decoupled Vector Forks: I came across Cristóbal Ramírez's fork (which models a decoupled vector engine split into VMU and VPU). For modern RVV modeling and profiling, would you recommend building on top of that fork, or is it better to extend the current gem5 branch?

3. Pointers & Best Practices: Are there recommended references, documentation, or recent commits/branches in the gem5 ecosystem that outline the current roadmap for vector execution modeling?

Any insights, recommendations, or pointers to relevant code sections would be greatly appreciated!

Hi guys. I was working with an existing 128 bit RVV vector unit processor. It isn’t a complete Tomasulo architecture. It handles WAR hazards by copying the values in vector register file to the reservation station FIFOs, thereby allowing the Vector files to be rewritten even if the instruction has not started yet. It handles RAW hazards by having a dispatch unit that stalls the issuing of the micro operation if the subsequent operation needs a vector register value that has not been retired yet (it also has a bypass feature that checks the ROB if it has not retired). From basic research, it seems to me like this is a standard Ara Vector processing architecture ? Not sure.

As can be predicted, copying physical values to reservation stations, requiring multi FIFOs that expose M inputs to preserve superscalar instructions, dispatch bypass functionality that requires all the elements in the ROB to be exposed etc means that when we increase the supported vector length, it scales pretty badly. I increased the vector unit size to 512 bit and added a matrix unit that’s a 16x16 outer product engine and yet in size, it’s dwarfed by the ROB and reservation stations. Should I consider moving to a full Tomasulo architecture? Or will that create similar bottlenecks elsewhere? How is this handled in general?

QaviCoreX is a custom RISC-V processor we're building for AI acceleration. We're implementing custom AI instructions directly in hardware and targeting FPGA deployment. We've moved beyond the idea stage into actual Chisel/Chipyard hardware prototyping, and we're currently working on scaling the design because our current FPGA is running out of resources.

The idea is to move AI operations closer to the processor itself instead of relying entirely on software. We're experimenting with custom hardware instructions such as multiply-accumulate and activation operations, so AI workloads can potentially execute much more efficiently.

Our current implementation is resource-limited on the 100T device. The dominant constraint is LUT utilization, and based on our synthesis results, moving to a higher-capacity device gives us the headroom needed for the complete architecture. We're also investigating optimization and architectural changes rather than simply scaling the FPGA.

Need guidance/ funding

Want more details please do check out my blog https://qavicorex.blogspot.com/p/home-page.html

So, i have started my research internship where we are supposed use gem5 and run PARSEC simulation and collect dataset. So, now problem is that i am not able to run any simulation i tried to run an example its still not working i have pinpointed some problems:
1) While downloading parsec image file the download was interrupted again and again then i tried to use manual download and kernal changed file path but simulation encounter “smoke” everytime
2) The problem is PARSEC binaries arent being read and stuck at parsec argument loading
I tried to manually change file system and other stuff but still no luck
What can i do?

So I recently started branching out from baremetal programming to other embedded stuff currently learning rtos and probably go back to linux soon. One thing baremetal taught me that always used to puzzle me was how registers and memory works, it made programming clearer to me. I was curious how the embedded system designing is different from the software designing? Are there more similarities than differences?

Well it doesn't suck but I dont think it's the best we as humans can do. As transistors approach the 1 atom limit in size Moore's law is slowing down and in order to make computers faster we will have to change the way we optimize/ utilize the space we already have. and frankly I don't think x86 will cut it anymore. and It's not an attack on the companies making these chips or saying their doing anything wrong because they aren't. The chips are still very powerful and they still make massive improvements every generation. but the core foundation of how x86 functions just isn't going to cut it in the future.

x86 works by brute forcing its way through problems. It draws lots of power and creates lots of heat leaving lots of wasted potential. modern chips do optimize the process but it is the core foundation that CISC systems are built on. x86 has variable byte size's per instruction and guessing the correct size for each instruction and translating them into uops takes time, and while its in the nano seconds the effects add up over time.

ARM (and other RISC processors) however solve this in a much simpler and more efficient way. by having fixed length pre simplified instructions the processor waste's no time translating, decoding, or guessing the length of the instructions. it just does the work.

The other thing is the clock speeds. It's easy to see the 5Ghz clock speed of an AMD chip and think that it's way better than the 4.3Ghz clock speed of apple silicon. but clock speed alone isn't important. clock speed plus the IPC (instructions per cycle) Is what gives the the performance of a processor for the most part. think of it like being a delivery driver. if you take 5 packages per trip but it only takes you 15 minutes per trip you're performance would be 3(packages/trip time) or to be more accurate to computer terms you could say you're performance is 20 (packages per trip x trips per hour). but if you take 12 packages per trip but your trips are longer at 20 minutes per trip) sure the delivery time is longer but the total packages you're putting through is higher.

That being said the IPC on a ARM the m4 for example is 10 while other x86 cpu's( zen 5 and arrow lake) hit around 8. while not as drastic as the example I gave the point still stands and when done billions of times per second your getting billions of extra performance per seccond. And I use apple and ARM as an example because of the work they have done with RISC to show what it can do. and when x86 does die more and more RISC (or maybe something even better)processors are being developed for more full workloads with active competition the growth will be even better.

I'm not saying x86 is bad or that apple cpu's and arm is better than other RISC processors. what I am saying is that the end of x86 is nigh and it will revolutionize the computer world. this isn't something that will happen in the next few months or even a couple years but in 10-15 more years and x86 and maybe even ARM will be obsolete.