Currently, optical interconnect is dominated by Active Optical Cables (AOCs) and plug-in, front-panel optical modules called QSFPs (Quad Small Form-factor Pluggable). These modules contain high-speed Ethernet PHYs, an optical transmitter and receiver pair (or pairs), and optical connectors for the plugging in of the transmission fibers. According to Wikipedia, the optical modules for 40 and 100Gbps Ethernet “are not standardized by any official standards body but are in multi-source agreements (MSAs)” so there’s considerable leeway in developing new alternatives.

Luxtera is a silicon photonics company and its goal is to develop small optical components (receivers and transmitters) that can be located very near to the SoC receiving and generating the Ethernet data streams. When you’re running multiple streams at 10 to 100 Gbps, there are some big challenges in running the signals all over the place, so the closer you can get these optical components to the SoC, the better. What better way to do that than 2.5D assembly and silicon interposers?

And so you end up with an evolution of optical interconnect as show in this diagram:

40G and 100G Optical Interconnect Evolution

The current situation appears as a photo at the upper left. It shows a number of optical modules plugged into a 1U front panel in a server rack. There are both real-estate and power limitations with this approach. The next evolutionary step appears at the lower left of the image, which shows the continued use of MSAs for front-panel interconnect but the use of packaged optics mounted on the blade pcb for backplane and intra-rack interconnect. The final evolutionary stage is to incorporate these optics in the ASIC. How? 2.5D IC assembly using interposers, said Bergey as he showed this image taken from a Xilinx presentation.

Xilinx 2.5D Optical Assembly

In this image, imagine that the “Bridge Chip” is the Ethernet Switch SoC. The driver is a high-speed PHY built with somewhat different process technology (more on that in another blog post) than the logic-optimized process used to make the SoC. The PD and LD could be the integrated optics, built using yet another IC process technology.

This is another killer 2.5D assembly app in my opinion.

By the way, in case you missed it, Cadence just introduced IP blocks for implementing 40G and 100G Ethernet controllers and the digital portion of the PHYs at the same Ethernet Technology Summit.

The two PCS blocks implement the 40G and 100G physical coding layers respectively. The coding layers are the digital part of the Ethernet PHY and the Ethernet standards permit the formal separation of the PCS and SerDes to support multiple transmission media. The 40GBASE-R PCS block interfaces to four transmit and four receive 10G SerDes modules through eight separate, unidirectional 16/32-bit interfaces (four interfaces in each direction). The 100GBASE-R PCS block can interface with either ten 10G Ethernet SerDes blocks in each direction or four 25G SerDes interfaces in each direction.

The BEAN IP block implements the IEEE 802.3ap Clause 73 auto-negotiation function through the use of independent hardware state machines. Here is a block diagram showing how these four Ethernet 40/100G IP blocks relate to each other:

These IP blocks have already been licensed and taped out for high-volume production. Deliverables include the Verilog HDL code for the block, synthesis scripts for the Cadence Encounter RTL Compiler, a Verilog testbench, and documentation.

For Richard Goering’s take on 40/100G Ethernet, see his new blog post: “Who Needs 40/100 Gigabit Ethernet SoCs?“

“In the past, computing systems could rely on increasing computing performance with each processor generation. Following Moore’s Law, double the number of transistors was available with each processor generation. And according to Dennard’s Scaling, clock speed could increase 40% each generation without increasing power density. This allowed for increasing performance without the penalty of increased power. However, this free ride in processing performance increases is over. Increasing clock speeds would now result in unacceptably large power increases. As transistor operating voltages approach the logic threshold voltage, the device operating characteristics change dramatically: reliability and maximum operating frequency both decrease. Industry has only a limited ability to reduce operating voltage to avoid these clock frequency decreases, since reliability and operating frequency are critical to their user base. These factors have led to limitations on improvements in commercial processing power efficiency.

The goal of the Power Efficiency Revolution For Embedded Computing Technologies (PERFECT) program is to provide a power efficiency of 75 GFLOPS/w for embedded computing systems. The PERFECT program will achieve this goal by taking a revolutionary approach to processing power efficiency. This approach includes near threshold voltage operation and massive heterogeneous processing concurrency, combined with techniques to effectively utilize the resulting concurrency and tolerate the resulting increased rate of soft errors. The PERFECT program will leverage and incorporate anticipated industry fabrication geometry advances to 7 nm. Since no operational hardware is to be built in this program, a simulation capability will be developed to measure and demonstrate progress.

This program specifically addresses embedded systems processing power efficiencies and performance, and is not concerned with developments that focus on exascale processing issues.”

This is a 5-year project that starts this year.

Because Dave knows (and I know) that you don’t want to watch all the hours that go into a PCB design, he sped up the video by 10x, narrated it, and posted it on YouTube.

Now Dave used a PCB package from Altium to make this video, but his advice on PCB layout transcends any specific design package. If you’d like to try out a professional PCB layout package, you can download a free trial-sized version of OrCAD PCB Designer Lite. Just click here.

Dave Jones prepares to tear down a Motorola Dynatac phone

Teardowns are incredibly useful for learning what’s been tried before. Dave Jones is king of the teardowns in the sense that he not only takes a product apart, he also observes and explains the underlying importance of what we see during the teardown.

In this 30-minute video, Jones tears apart a vintage 1994 Motorola Ultra Sleek 9660 Dynatac analog mobile phone handset. During this process, he comments on a variety of evolving technologies including antennas, batteries, microphones and speakers, pcb layout, component selection, and so on. As the teardown progresses, you get a feel for how electronics design and packaging have changed over the last 18 years. You especially get that sort of perspective when Jones then tears down a Nokia GSM phone circa 2000—only six years newer—for comparison.

One thing to note here is that Jones cannot help but look at the Motorola design with 21^st century eyes. Back in 1994, there were at least two notable differences with today. First, the SoC had not yet arrived, so you bought your processors as separate ICs. The advent of the SoC has made a huge difference in system-level design.

Second, surface-mount technology and packaging was still fairly new. The Motorola 9660 Dynatac is completely based on surface-mount components, and we’ve become well used to seeing boards that are entirely based on surface-mount assembly, but the technology just was not as common back when the Dynatac was designed. It’s easy to forget this, but a good electronics archaeologist needs to keep these eras well in mind.

Enjoy the video:

There is also pizza involved for a nominal fee.

Click here.

Samsung Wide IO SDRAM die (Definitely NOT free!)

A recent email from Marc Greenberg, Director of Product Marketing for the Cadence Design IP Group, suggested that Wide I/O used in a 3D stack is free for the end user. In other words, there’s no incremental cost in the purchase price of an end product (such as a mobile phone or a tablet) that pairs Wide I/O SDRAM with a logic chip using 3D assembly techniques. Greenberg challenged me to check his math. I’m going to do just that in this blog post. See what you think.

We need to start with the incremental cost of adding TSVs (through silicon vias) to a multiprocessor SoC (MPSOC). To do that, we need to figure out much added cost there would be to add TSVs to an MPSoC die.

Well, how big is an SoC or MPSoC die that might use a Wide I/O SDRAM?

Without naming names, let’s look at a series of such SoCs from one vendor. This SoC family includes single- and multi-processor designs built with 65nm and 45nm process technology. Die sizes range from 40 to 110 mm². Marc then conjectures that a “representative” applications processor SoC measures 9x9mm, giving an area of 81mm². That’s right in the middle of the range for the existing application processor family described above.

You can fit approximately 800 such die on a 300mm wafer. (Marc provided a handy reference pointer for this computation.) Let’s suppose we get about 70% yield from this wafer (or pick your own yield number), resulting in 560 known good die per 300mm wafer.

Now all we need to do is figure out the incremental cost per wafer for adding the TSVs. Here, the numbers are all over the map. At the recent 3D Architectures for Semiconductor Integration and Packaging event held in Burlingame, California, I heard incremental cost numbers as high as $800 per wafer for adding TSVs. I’ve also read estimates of $150 (click here) and seen an estimate that the ultimate cost will be about $25 (click here) once we get the process nailed down.

What number should we use?

Let’s pick something between $150 and $800 that doesn’t require too much “hard” math. How about $560? That would make the incremental cost of adding TSVs to an SoC work out to exactly $1 per known good die. You can’t get much easier than that. If you prefer the $150 number, then it’s 27 cents per die. If you believe that eventually it will cost $25 per wafer to add TSVs, then the incremental cost is 4.5 cents per die.

In the end, you’ll see it doesn’t really matter which of those three per-die incremental costs you pick. You win in any case.

Why? Because, as Marc has been known to say, the power savings you get from using Wide I/O SDRAM permit you to shrink the battery powering the end product. You can save $1 to $3 in the battery alone from those power savings, not to mention the board-cost savings derived from reducing the IC real estate footprint when the SDRAM disappears from the board and climbs on top of the application processor.

Now, before you get all technical on me, let me acknowledge that there are a host of factors not included in this SWAG cost analysis. Neither Marc nor I compared the relative cost of compression bonding the Wide I/O SDRAM to the SoC versus wire bonding. We did not include the cost savings of entirely eliminating the packaging for the Wide I/O SDRAM nor the incremental cost of the more complex encapsulation for the 3D stack. Also, we did not factor in the cost savings resulting from the elimination of some 120 fewer pins on the SoC, which no longer needs an external SDRAM interface, and we also did not factor in the yield loss due to stack assembly.

So, is this a back-of-the-envelope calculation? You betcha! Is it a good engineering estimate for making a decision to look more seriously into 3D integration. I’d say so.

By the way, Cadence offers a Wide I/O SDRAM controller and PHY IP plus an appropriate memory model for your SoC verification efforts, just in case you feel the sudden, urgent need to design an SoC with TSVs to pair with a Wide I/O SDRAM. Feel free to check them out.

Dynasty Realization (a phrase I’ve just coined for this blog post) is usually only documented in business case studies. Such case studies are long on the business aspects and usually pretty short on the technical aspects, due to the nature of the authors. I’ve just spent two hours reading a different sort of case study, written by a friend named Chuck House. House is Chancellor of Cogswell College in Silicon Valley and he once worked for Intel but before that, he worked at Hewlett-Packard. Bill and Dave’s Hewlett-Packard. House has written a 45-page treatise on the invention of an entire HP division, the one that made logic analyzers and microprocessor development systems. It’s a really interesting story because it clearly demonstrates the seemingly random walk that leads to the creation of a dynasty.

The study starts with a very unusual situation. House and his fellow “HPite” (official HP nomenclature) Kent Hardage are standing in the Tektronix booth at the IEEE International Convention in New York City on March 23, 1970. They are conducting what’s supposed to be a covert operation to gather intelligence about the new Tektronix 7000 series mainframe oscilloscopes because House is running a development program called “Next Gen” (I wonder how many hundreds of projects have had that name) for HP’s Colorado Springs Division. That’s the division with the very unhappy task of trying to beat Tektronix at the ‘scope game.

The Next Gen project’s goal is to create an oscilloscope mainframe even better than the Tektronix 7000 series, so House has gone to NYC to find out more about the new Tektronix product family. Something amazing happens. House writes:

“… it took the Tektronix team less than three minutes to figure out who we were, what we were doing, and thus to develop a coping strategy. Oddly, they let us in. We knew the functionality better than most folk in their booth; surprisingly, we were invited to stay and exhibit their new ‘scope to potential customers.”

Now you might think that it was a supreme betrayal for House and Hardage to demo the Tek 7000 series ‘scope mainframe to prospects. Seems like it might have been, but it wasn’t. During the hours of demoing the Tek 7000 ‘scope to prospects, House learned what the prospects’ true problems related to ‘scopes were. These problems had nothing to do with the combined ‘scope and frequency analyzer that House’s team envisioned for the Next Gen project. Instead, the problems revolved around those newfangled integrated circuits—especially the digital ones—that wiggled so many signals simultaneously. Even a 4-channel scope was insufficient to troubleshoot such circuits. A different sort of test equipment was needed.

House’s foray into enemy territory—literally living in a competitor’s shoes for a few hours—put a stake into the heart of his Next Gen project. House learned that Tektronix had spent $34 million and seven years developing the Tektronix 7000 series. House’s team had spent $2 million and was at least two years away from a product. Dead end. Game over.

House’s narrative goes on to describe the initial, stumbling steps that his greatly reduced and restructured team made to envision what that next step after the current generation of HP scopes should be. It was a logic analyzer—something no one knew how to define or build. House’s 45-page document then explains in great detail how the first three generations of HP logic-analysis equipment was defined and built before it became truly usable and practical. Eventually, HP and its test-equipment spinout Agilent sold $5 billion worth of logic-analysis equipment. All because of a few hours spent on some spontaneous and opportunistic market research.

House’s story is one of Dynasty Realization. Creating a $5 billion dynasty isn’t a bad bit of work.

If you’d like to read more about this fascinating case study, you’ll find it on the HPmemory.org Web site. Click here.

Well, just look at the complexity that’s involved. In a recent interview with Industry Insights blogger Richard Goering, Pete Heller said “Today, PCI Express 3 and USB 3.0 are each thousand page specs. It’s not realistic or sensible for a development team to use its own resources to create VIP to verify a standard protocol that adds literally no differentiation to their end product.” (Heller is the senior product line manager for VIP at Cadence.)

Heller’s conclusion, in a nutshell, applies to both design and verification IP. If you cannot create sufficient product differentiation—whether SoC or system—by developing proprietary IP for a specific function block or verification task, then you really should purchase a proven, pre-verified IP offering because you will save time (critical) and you will likely save money (from the improved reusability). In the mad rush to tape out a chip, few in-house VIP teams end up being rated on the reusability of their work. As a consequence, the reusability of in-house IP often takes a back seat to simply getting the task at hand accomplished.

As Goering states in his article, if you look back ten years or so, most verification teams created their own verification IP. They went to that effort for several reasons. First, the protocols being verified weren’t as complex as they are today. (Re-refer to Heller’s statement above if your memory is short.) Second, the market for commercial VIP was not as mature and the players had neither the experience nor the track record that they enjoy today. Finally, whether or not VIP that’s written in-house differentiates the target product, there’s always an NIH (not invented here) factor to deal with. It takes a certain amount of ego to step forward and design a product and the NIH factor always comes hand-in-hand with ego.

Heller provides some guidelines to help you make the right make-versus-buy decision with respect to VIP. I’ve decided to bullet those recommendations to help bring out Heller’s key points about commercial VIP:

• Commercial VIP should have been exercised across a range of user implementations to ensure quality.
• Commercial VIP must provide protocol compliance checking and functional coverage metrics.
• Commercial VIP needs to be reusable between projects.
• Commercial VIP must support multiple simulators, languages and methodologies.
• Commercial VIP must work at all abstraction levels from block level to subsystem to full chip (SoC) to avoid re-creation of verification environments at different points in the project life cycle.

You can see Richard Goering’s original interview with Pete Heller here.