As with Nintendo's previous portable console, the system revolves around a big chip named CPU NTR. 'NTR' is shorthand for Nitro, the codename of the original Nintendo DS. This System-on-Chip (SoC) is also the continuation of a prosperous Nintendo-ARM partnership, which originally started with the Game Boy Advance.
Now, before we check out the new CPUs, let's look at how ARM evolved during the late 90s, as this impacted the technology ultimately found inside the Nintendo DS.
ARM's new territories
During the mid-90s, ARM was experiencing an influx of businesses from the mobile market (before cellphones became 'smart'). Yet, it struggled to please a particular sector: high-performance computing. The ARM7 was enjoyed by many mobile devices, but it didn't quite satisfy Apple (with its 'Newton' PDA line) and Acorn (with its RiscPC line), both of whom shipped software that could benefit from a faster CPU. Aside from the lack of a 64-bit solution (something MIPS was already commercialising), ARM was also unable to produce a CPU that operated faster than 40 MHz. Altogether, the bottlenecks were starting to pile up.
DEC's 'Digital Personal Workstation' model 433au (1997), carrying an Alpha 21164A CPU.
Nevertheless, during the commercialisation of the ARM7 line, ARM had already started work on a successor called ARM8, the first attempt into the high-performance market. Coincidentally, Digital Equipment Corporation (DEC), the American company historically renowned for their line of PDP and VAX machines (the so-called 'minicomputers') along with the sophisticated VMS operating system, was experiencing an opposite problem: They struggled to deliver a low-power CPU based on their high-performance solutions.
Well, it so happened that ARM's licensing model turned into an opportunity for DEC, who chose to develop a new CPU by borrowing materials from ARM (its instruction set and microarchitecture).
In the end, DEC grabbed the datapath design of their RISC-based Alpha processor and, with the help of ARM, mixed it with ARM's microarchitecture . This collaboration led to the StrongARM CPU, which was released in 1996 and targeted the performance sector.
A 233 MHz StrongARM CPU, part of the CPU upgrade card offered for the Acorn RiscPC.
StrongARM was a new ARM-based CPU that featured :
- The ARMv4 instruction set. If you want to know more about it, I've previously analysed it in the Game Boy Advance article.
- Up to 233 MHz of clock speed, roughly 583% faster than the beefiest ARM7 chip.
- 5-stage pipeline, an increment from the original 3-stage design.
- A new cache system implementing a Harvard architecture, where 16 KB are allocated to instructions and another 16 KB to data.
- This design helped alleviate memory bottlenecks (something the von Neumann/Princeton model suffered from).
It's worth mentioning that this chip still managed to work with a 3.3 V supply, like previous ARM chips. In fact, the StrongARM requires just 2 Volts and dissipates only 1 Watt . By contrast, Intel's 200 MHz Pentium chip draws 3.5 V and has a power dissipation of up to 15.5 W .
As expected, such was the impression on Acorn and Apple that both companies immediately shipped CPU upgrades and further Newton models, respectively, using DEC's invention.
In the same year, ARM also released their promised ARM8-based CPU, the ARM810. It was comparatively slower and offered no practical advantages over the StrongARM. So, too little and too late resulted in no commercial interest. Consequently, ARM shifted its focus to improving the ARM7 line for the mobile market. However, the potential of DEC's CPU was so disruptive that ARM Holdings absorbed StrongARM's design to produce their next line of CPUs, the ARM9 (which the Nintendo DS houses).
Turning points
Thanks to the StrongARM, ARM also cemented its position in the handheld market, completely displacing MIPS and SuperH as viable alternatives. From then on, ARM was en route to becoming the most widely adopted architecture for mobile devices .
Unfortunately for DEC, this CPU would be their last major achievement before being acquired by Compaq in 1998. The fate of StrongARM would then rest in the hands of Intel, who continued development under the new 'Intel XScale' line... until they liquidated the division to focus on 'low-power' x86 CPUs (i.e. the Intel Atom) . Fifteen years later, not only has Intel lost its chance in the mobile market, but it now finds itself competing head-to-head with ARM in the desktop arena.
Nintendo's debuting SoC
The silicon within the Nintendo DS is an interesting intersection between affordable and trailblazing technology. Aside from the aforementioned advancements, CPU NTR (the SoC) follows a multi-processor architecture that houses two different ARM CPUs: the ARM7TDMI and the ARM946E-S. This design was done before ARM Holdings officially released multi-processor solutions. So, their functioning may be considered a bit unorthodox (taking into account present technology).
The CPU NTR chip.
While this is not the first parallel system analysed in this series, its design differs significantly from the rest. For instance, we are not talking about the experimental master-slave configuration that the Saturn debuted, nor the co-processor approach found on the PS1 or N64. The Nintendo DS includes two largely independent computers that perform exclusive operations, each with its own dedicated bus. This design methodology is known as asymmetric multiprocessing, and the resulting inter-CPU dependency conditions the overall performance of this console.
Let's now take a look at the two CPUs.
ARM7TDMI
Structure and components of the ARM7 part.
Starting with the more familiar of the two, the ARM7TDMI is the same CPU found on the Game Boy Advance, but now running at ~34 MHz - twice its original speed. It still retains all of its original features (especially Thumb).
Now for the changes: because Nintendo's engineers placed the ARM7 next to most of the I/O ports, this CPU is tasked with arbitrating and assisting I/O operations. In fact, no other processor can directly connect to the I/O. As you can see, this is not the 'main' processor that will be in charge of the system, but rather the 'sub-processor' offloading the main CPU by passing data around many components.
ARM946E-S
Structure and components of the ARM9 part.
Here is the 'main' CPU of the Nintendo DS, the ARM946E-S. It runs at ~67 MHz, so not exactly 'StrongARM speed'. Yet, as part of the ARM9 series, this core not only inherits all the features of the ARM7TDMI and StrongARM, but also includes some additional bits you may find interesting :
- The ARMv5TE Instruction Set Architecture (ISA), an extension of the previous ARMv4 ISA and Thumb, offering more instructions and a faster multiplier.
- If you take a look at the core name, the letter 'E' means Enhanced DSP, indicating that many of these new instructions relate to signal-processing applications.
- The extended Thumb is sometimes called Thumb v2. It adds
BLXandBKPT, which assist with switching between ARM and Thumb mode; and facilitate debugging, respectively.
- A 5-stage Pipeline, like the StrongARM and ARM8 families.
- 12 KB of L1 Cache: Unlike the ARM7TDMI, the new core features cache and, akin to the Harvard-based StrongARM, allocates 8 KB for instructions and 4 KB for data.
- The cache employs a write-buffer mechanism, allowing RAM to be updated asynchronously, so the CPU can work on other tasks.
- 48 KB of Tightly-Coupled Memory (TCM): Similar to Scratchpad memory, although here is discriminated between instructions (32 KB) and data (16 KB).
- An integrated CP15 co-processor. It acts as a Memory Protection Unit (MPU), stipulating which memory ranges can be accessed, cached, or written to.
Nintendo also added the following components around the core:
- A divider and square root unit to speed up these operations, as the ARM9 by itself is not capable of performing this type of arithmetic.
- A Direct Memory Access (DMA) Controller: Accelerates memory transfers without depending on the CPU. When combined with caching, both CPU and DMA can potentially work concurrently.
- Cache and DMA can provide a lot of performance but also introduce new problems, such as data integrity and coherence. Programmers must therefore maintain memory consistency manually, for example, by flushing the write buffer before triggering DMA.
I guess with hardware like this, it's easy to figure out the real reason kids loved this console, eh?
Interconnection
So far I have discussed how the two CPUs operate individually. But to work as a whole, they are required to cooperate constantly. To accomplish this, both CPUs directly 'talk' to each other using a dedicated First In, First Out (FIFO) unit . This block holds two 64-byte queues (with up to 16 elements each) for bi-directional communication.
Representation of the FIFO unit.
The FIFO unit works as follows: the 'sender' CPU (the one that needs to transmit a message) places a 32-bit block of data in the queue, and the CPU acting as the 'receiver' can then pull that block from the queue and perform the required operations with it.
Whenever a value is written to the queue, either CPU can fetch it manually (polling). However, this involves repeatedly checking for new values, which can be expensive. Alternatively, an interrupt unit can be activated to notify the receiver whenever there's a new value in the queue.
Main memory
Just like its predecessor, Random-Access Memory (RAM) is spread across many different locations, enabling the system to prioritise data placement according to access speed. In summary, the following general-purpose memory is available :
The memory architecture of the Nintendo DS.
- 32 KB of Work RAM (WRAM) on a 32-bit bus: Used to hold fast data shared between the ARM7 and ARM9.
- Bear in mind that only one CPU may access it at a time.
- 64 KB of WRAM on a 32-bit bus: Also used for fast data, but accessible only by the ARM7.
- 4 MB of Pseudo-Static RAM (PSRAM) on a 16-bit bus: A slower type, available to both CPUs and arbitrated by a memory interface unit.
- PSRAM is a variant of Dynamic RAM (DRAM) that, by contrast, performs its refresh cycles internally. Thereby, behaving like SRAM (the faster but more expensive alternative to DRAM). This design reminds me of 1T-SRAM.
Backwards compatibility
Even though the Nintendo DS' architecture is a radical departure from its predecessor, this console still managed to retain the critical bits that enable native compatibility with Game Boy Advance games.
But for the DS to morph into a GBA, the console includes a set of software routines that place it in AGB Compatibility Mode. When activated, these routines halt the ARM9, disable most of the novel hardware, redirect the buses, put the ARM7 in charge, and slow its clock speed to 16.78 MHz. Finally, the ARM7 executes the original AGB Basic Input/Output System (BIOS), which bootstraps the GamePak cartridge (just like an original Game Boy Advance).
AGB mode also exhibits some features not present in the original console, such as displaying the game with black margins (as the new screen resolution happens to be larger). Moreover, since the DS has two screens, users can set which screen will be used to display the GBA game.
Finally, once in AGB mode, there's no going back. The console must be reset to reactivate the new hardware.
Unused Power
With so many sophisticated components fitted into a single, inexpensive chip, it's no mystery that some issues emerged because of the way they were forced to work together.
Let me start with the ARM9, this CPU runs at twice the speed of the ARM7, yet most (if not all) of the I/O is handled by the ARM7. Thus, the ARM9 is prone to excessive stalling while it waits for the ARM7 to respond to I/O requests.
Additionally, the PSRAM bus is only 16-bit wide (still following the Game Boy Advance's EWRAM model) and operates at half the ARM9's clock speed. Consequently, whenever either CPU needs to fetch a 32-bit word from memory, the interface stalls the CPU, introducing up to three 'wait cycles' while the full word is reconstructed.
The degree of stalling varies significantly depending on the transfer type (instruction or data fetch) and the transfer width (16-bit or 32-bit). The worst scenario occurs during non-sequential 32-bit data retrieval, where the ARM9 spends five cycles per transfer. This is alleviated when the data is sequential, reducing transfer times to a mere cycle. However, the ARM9 doesn't support sequential opcode fetching, so instruction retrieval gains no benefit. In other words, the same penalties apply regardless of whether instructions are adjacent.
All in all, this means that in the worst case, the ARM9's whopping 66 MHz horsepower is practically reduced to a mere ~8 MHz. That is, if the program makes an abysmal use of the cache and TCM. In situations like this, however, I wonder if Nintendo might have mitigated the issue simply by increasing the amount of internal fast RAM. I also question if this is just technical debt carried over for the sake of backwards compatibility.
Anyway, for a detailed report, I recommend checking out Martin Korth's documented timings .