VIA takes the wraps off Isaiah: Meet the Nano

VIA formally unveiled its Nano processor today, several months after first …

JOEL HRUSKA - 5/30/2008, 3:06 AM

WITHVIA has finally revealed final TDP specifications, model numbers, clock frequencies, and performance data on the "Isaiah" processor it announced last January. The processor will be marketed as the VIA "Nano," and it will compete primarily against Intel's Atom. Both processors are targeted at the Mobile Internet Device (MID)/ mini-notebook markets, though we'll likely see competition between the two products in the ultra-low-cost PC segment as well. Meet the Nano The Nano is VIA's next-generation processor, and will complete (though not replace) the older VIA C7-M. VIA intends to maintain the C7-M product line for the foreseeable future, as the company believes the two products will serve different markets and appeal to different types of buyers. The two processors are built on very different architectures. VIA's C7-M (codenamed Esther) is a simple, in-order microprocessor designed for low-power operation. The chip is built on 90nm technology, has 128K of L2 cache, and is 32-bit only. Nano, as we've stated, is an entirely different animal. ?

Unlike VIA's previous chip designs, the Nano is an out-of-order superscalar processor. Moving from an in-order to an out-of-order processor inevitably increases CPU power consumption and transistor count, but VIA claims to have carefully balanced Nano's performance against the low power requirements of devices in the MID/mini-notebook sector. Specifications on the new processor are shown below: The "L" and "U" designations in front of the VIA parts denote low voltage or ultra-low voltage respectively. VIA's naming system takes an odd jump within the "U" series—the U2300 runs at 1.0GHz, the U2400 is clocked at 1.3GHz, and the U2500, for a reason that escapes me, is clocked at 1.2GHz. When I contacted VIA to inquire as to whether this was a typo, I was assured that it was not.

Clock speedMHZ

FSB speedMHz

L2 cacheKB

SMT

TDPW

Avg powermW

Idle powermW

PriceDollars

Intel Atom

Z500

800

400

512

No

0.62

160

80

45

Z510

1100

400

512

No

2.00

220

100

45

Z520

1333

533

512

Yes

2.00

220

100

65

Z530

1600

533

512

Yes

2.00

220

100

95

Z540

1800

533

512

Yes

2.40

220

100

160

VIA Nano

U2300

1000

800

1024

No

5.00

n/a

100

n/a

U2500

1200

800

1024

No

6.80

n/a

100

n/a

U2400

1300

800

1024

No

8.00

n/a

100

n/a

L2100

1800

800

1024

No

25.00

n/a

500

n/a

L2200

1600

800

1024

No

17.00

n/a

100

n/a

Nano's power consumption is clearly higher than Atom's, but the exact difference isn't as clear as the numbers make it seem. VIA, like AMD, provides maximum possible TDP numbers, while Intel's TDP specifications "should be used to design the processor thermal solution." Intel also provides an "Average Power" value, defined as "measured CPU power whilst running BAPCo MobileMark'05 Office Productivity suite on Microsoft Windows XP for a period of 90min at 50°C." Despite the methodological differences, it's safe to assume that Atom consumes dramatically less power than Isaiah. The power consumption gap between the two could practically limit how much they directly compete with each other; Atom is capable of powering devices in situations where Isaiah, at least in its present incarnation, would appear to draw far too much power. We don't have any direct performance comparisons between Atom and Nano, but VIA did provide test results for Isaiah when compared against a C7 (and in one case, a Celeron M-520. These results may or may not reflect total Nano performance—these are manufacturer-provided benchmark numbers, after all—but they do provide some insight into what we can expect.

As expected, Isaiah stomps all over its predecessor in virtually every test. The rumors that Nano would be 2x-4x faster than C7 in certain scenarios appear to have been true. In Nano's case, this is of particular importance, as it allows the chip to perform certain tasks that the C7 was literally incapable of doing. Up until now, it's been impossible to build a VIA-based HTPC capable of HD DVD/Blu-ray playback; the C7 processor couldn't handle the task even when aided by the hardware decoding engine on a modern ATI or NVIDIA video card. Nano, however, changes this. One of the demos I saw on my trip to Centaur yesterday was of a 2GHz Nano flawlessly (and smoothly) playing the Blu-ray version of Blue Planet. CPU usage during playback varied between 39 percent and 75 percent, with an average rate of approximately 60 percent. Although the CPU in question was an as-yet-unreleased 2GHz processor, the 1.8GHz chip may also be capable of handling the load. VIA says we should start seeing Nano-equipped devices in the near future, and the chip is a drop-in replacement for any C7 board or product, provided that the CPU can be removed at all. Rumor has it that several companies, including HP, may refresh their current C7 products with Nano-based processors, and you can bet we'll get our hands on samples as soon as they're available. Per-unit pricing on the Nano isn't available at this time, but VIA processors have historically been very cheap. The company declined to specify what price ranges they were considering when asked, but VIA will almost certainly attempt to undercut Atom in product areas where the two might compete. Conclusion It's ironic that VIA and Intel each appear to have taken a page from the other when developing their new processors, but its a move that makes sense given each company's position in the market. Nano, meanwhile, is an exciting product in its own right. It's the first x86 processor not built by AMD or Intel that may be capable of taking on both companies within its target market space, and its capable of handling demanding multimedia tasks that put a significant load on its single core. There will be a dual-core Nano available at some point—possibly by the end of the year—but even the single-core flavor puts out some impressive performance numbers. If the chip lives up to its potential, it may go down in history as the processor that put VIA on the MID/mini-notebook map.

Isaiah revealed: VIA’s new low-power architecture VIA throws its hat into the coming x86 ultramobile battle with a brand new, 64 …JON STOKES - 1/24/2008, 1:01 PM0WITHAnd then there were three So much of the PC world's coverage is focused on the horse race between Intel and its archrival AMD that we often forget about the other x86 processor company out there, the one that's still well-known among the crowd of tweakers, hackers, and enthusiasts who build their own home firewall boxes and in-car PCs. I'm talking, of course, about VIA, maker of the low-power, low-cost, and also relatively low-performance x86 processors at the heart of many special-purpose DIY boxes. VIA's processors, designed by the company's Centaur subsidiary, focus on keeping costs and power down at the expense of performance.

VIA's newly launched processor architecture, known for the last three years by its codename, "Isaiah," will keep the company's focus on cost and power intact while taking things in a substantially different direction. In short, this year will see something truly odd happen on the low end of the x86 market: VIA and Intel will, architecturally speaking, switch places. Intel will take a giant step down the power/performance ladder with the debut of Silverthorne/Diamondville, its first in-order x86 processor design since the original Pentium, while VIA will attempt to move up into Intel's territory with its first-ever out-of-order, fully buzzword-compliant processor, codenamed Isaiah. In this brief article, I'll give an overview of Isaiah and of what VIA hopes to accomplish with this new design. Most of the high-level details of Isaiah have been known since at least 2004, when VIA began publicizing the forthcoming processor's general feature list (i.e., 64-bit support, out-of-order execution, vector processing, memory disambiguation, and others). So I'll focus here on a recap of those features and on a broader look at the market that VIA is headed into. Introducing Isaiah

Die plot of the Isaiah The Isaiah processor, which was first unveiled at the Fall Processor Forum in 2004, will start shipping in the spring of this year. The new-from-the-ground-up processor is fabricated on an unnamed 65nm process (VIA isn't ready to reveal who its foundry is) and at some point at a year or more out, it will shift to 45nm. As is typical of VIA, the company will use process shrinks to gain cost and power advantages, and not to increase performance by ramping up clockspeed. "Good enough" performance is the goal, and now that the company has made the leap to out-of-order execution (see below) it can focus on maturing the basic Isaiah design by eliminating bottlenecks when they do core revisions. (Note: Much of the language in VIA's architecture white paper stresses that this or that feature is characteristic of the "initial" Isaiah architecture, with "initial" in italics for extra stress in some cases. VIA has also said a number of times, both in the white paper and in my conversation with them, how much they've learned in designing and implementing Isaiah over the past few years. So we can expect parameters like decode width, issue width, buffer depth, and so on to change with the next core revision.) Isaiah is pin-compatible with existing C7 processors, and VIA is promising two to four times the performance of C7 while staying within the same power and thermal envelope. The company also says that Isaiah will sell for about the same price as existing C7 parts, which means that VIA parts will continue to be favorites with the small form factor crowd that builds Mini-, Nano-, and Pico-ITX systems. Though the current Isaiah parts are single-core, VIA assured me that it does have a dual-core variant in the works, but ?wouldn't say much more. Isaiah was designed with dual-core in mind, and Centaur's president, Glenn Henry, suggested that a dual-core part would probably happen at the 45nm node. Isaiah also brings to VIA's line-up support for the latest and greatest in the alphabet soup of x86 ISA extensions that AMD and Intel have introduced over the past few years. Intel's virtualization extensions are supported in the new processor, as are the various SSE flavors. The new processor also contains some added support for security features, like an on-board random number generator, hardware acceleration for popular crypto algorithms, and a "secure execution mode" that lets instructions access a private "volatile secure memory" (VSM) area on the chip. This added mode and special memory pool are both unique to VIA products, so I don't know enough about them to go into any detail on them. It's likely that they may find use in some application-specific embedded situations.

Isaiah's front end The shift to out-of-order execution means that Isaiah joins the rest of the modern x86 processors in breaking down long, variable-length x86 instructions into shorter, uniform micro-ops (or "uops"). This uop translation means that Isaiah's front-end pipeline is now fairly bulky and features the stages and hardware that readers of my book or my past processor articles will recognize from comparable Intel and AMD designs.

Isaiah's architecture. Image source: VIA Isaiah fetches instructions into a two-cycle decode phase that can take in three x86 instructions of any size or type per cycle. VIA claims that the decode phase can do both Conroe-style macro-fusion of some x86 instruction combinations, like compare and jump, and micro-ops fusion of instructions that use different issue ports. As is the case in Intel's Conroe (also known as the Core 2 Duo), these two types of fusion cut down on the amount of bookkeeping logic needed to track in-flight instructions.

Isaiah architecture branch prediction. Image source: VIA Recent years have shown that for more deeply pipelined out-of-order machines, branch prediction is one of the places where microarchitects get the best power/performance return-on-investment for transistors spent. So like its competition from Intel and AMD, Isaiah spends quite a few resources on branch prediction in both the fetch and decode phases of its pipeline. The processor has a total of eight branch predictors spread out over two of its fetch and translate/decode stages, each of which targets a different type of branch, and all of which vote to determine the prediction and branch target for speculative execution. Isaiah's back end Isaiah's decode phase passes instructions into a uop queue, where they fall into the processor's re-order buffer (ROB) for register renaming and allocation into reservation stations (RS). There's no word from VIA on how deep the ROB and RS buffers are, but if people are dying to know I can ask and I'm sure they will tell me. The ROB + RS hardware, which is the heart of the out-of-order engine, issues up to seven instructions per cycle to any of seven execution units:

• Two 64-bit integer units

• Two 128-bit vector/floating-point units

• Three load-store units (store-address, store-data, and load-data)

The FP/vector units, which VIA calls "media units," aren't symmetric; using a typical division of labor, one focuses on addition and the other on multiplication (and probably permutes). These FP/vector have fairly robust floating-point capabilities—more so than I would expect from a processor that mostly be used in embedded and low-power situations that typically see more integer-intensive, branchy code. In particular, the FP units can do any type of floating-point add (vector, scalar, double-precision, or single-precision) in only two clocks—at least one clock less than the Core 2 Duo's three- or four-clock latency. The FP multiply hardware is similarly speedy, and is capable of executing single-precision multiples in three clocks and double-precision multiplies in four. VIA attributes this low FP latency to a "completely new algorithm" for floating-point adds, but I have my suspicions that Isaiah may also be sacrificing some clockspeed scaling headroom in order to keep its pipelines short. Even if it is, this won't affect it much, since the point of Isaiah is low power and not high clockspeeds.

Data flow and cache hierarchy On the data-flow side of the processor, Isaiah can do the kind of memory disambiguation that Intel's Core 2 Duo uses to commit memory writes out-of-order. Isaiah also can do store merging, where smaller writes are combined with larger writes in the write buffer and sent out to memory as a group. Isaiah's cache hierarchy has some important differences from its competitors. Its 64K L1 instruction and data caches are twice as large as the typical 32K L1 caches of its competitors. The processor's L1 and 1MB L2 caches are also exclusive, meaning that data that resides in the L1 is not present in the L2, and vice versa. This exclusive design can have its drawbacks, but it makes the L1 + L2 function like a single, larger cache. Both the L1 and L2 caches are 16-way set associative. Isaiah also has a special data prefetch cache that should help it save space in the regular cache hierarchy. Data that's prefetched doesn't typically get accessed more than once, so there's no need to take up regular cache space with it. The data prefetch cache solves this problem putting prefetched data into a special 64-line cache. Conclusions

VIA is aiming Isaiah at the same segment that Intel, AMD, and ARM are targeting with their forthcoming processors: the so-called mobile Internet device (MID) and ultramobile PC (UMPC). Right now, the fate of the UMPC as a form factor has yet to be decided, so there's no guarantee that there will even be a market there for everyone to fight over. It's possible that the real action will be in the emerging flash-based laptop form factor (see the Asus Eee PC or Apple's new MacBook Air) or in the (increasingly ill-named) "smartphone" category. Regardless of what happens to the UMPC, though, 2008 will see a mix of low-power x86 devices, both in-order and out-of-order, from all three x86 players as they go head-to-head with the increasingly complex RISC processors from companies like ARM and MIPS that currently own the low-power space. ARM in particular will throw its hat into the out-of-order ring later this year with their forthcoming dual-core Cortex A9 processor. Whether any of the x86 contenders, whether they go out-of-order like VIA or in-order like Intel, can take on the reigning champ of the mobile and embedded space remains to be seen. But Isaiah looks like a worthy contender at the very least. Appendix: making the leap to out-of-order How could Isaiah possibly deliver on a two to four times performance increase over its predecessor in the same thermal and power envelope? Part of the answer is in the jump to 65nm, but tied up with that move is a change to the way that the processor executes instructions that's enabled by Isaiah's enlarged transistor budget. With its in-order design built on an aging but inexpensive 90nm process technology, the VIA C7 (codenamed Esther) and its predecessors have long lagged the x86 competition in terms of performance-enhancing microarchitectural features. Specifically, VIA's processors—even the ones launched as recently as 2005—have so far lacked the one crucial architectural feature that separates the Pentium from the Pentium Pro and that is the hallmark of almost all modern desktop- and server-oriented processor designs: an instruction window. In a nutshell, an instruction window is what enables modern processors to dynamically reorganize the sequential instruction stream so that instructions can execute inside the processor in an order other than the one in which they were placed by a programmer. On an in-order processor like the C7, an instruction that takes a long time to execute or that's waiting for data can stall the processor so that no other work gets done until that instruction finishes executing. In contrast, an out-of-order processor with an instruction window can allow instructions to flow around the problem instruction so that the processor continues to work; the instruction window's bookkeeping apparatus enables it to put the instructions back into their original order before writing their results out to programmer-visible memory. As you might imagine, an instruction window is fairly complex to implement, and the costs associated bookkeeping apparatus described above don't even tell the whole story. Because an out-of-order core can reorder and track only small, uniform instructions, the long, variable-length x86 instructions that come into the processor must be broken down into a series of uniform instructions called micro-ops. So the front end of the processor, which is the part that prepares the variable-length x86 instructions for execution, also balloons with extra translation and decoding hardware. All told, the transition from in-order to out-of-order is a massive leap in hardware complexity and size for an x86 processor, which is why it has taken the power-conscious VIA line so long to get here. Conversely, jettisoning all of that extra hardware can save tons of die space and power, which is why Intel's forthcoming mobile-oriented Silverthorne/Diamondville processor is an in-order design.