It was the best of times, it was the worst of times—depending upon who was writing your paycheck last week.

The EU slapped Intel with a $1.45 billion fine for anticompetitive behavior. Bad Intel. Bad, bad Intel. Even for Intel, that’s a lot of dough, and it may be enough to change what have proven to be highly effective business practices in overseas markets. But does anyone else find it unusual that the EU is regulating behavior of U.S. companies against U.S. companies within its borders?

The bigger question—and one that no one is talking about—is what effect this will have on the looming battle between Intel and ARM in the low-power portable market. ARM is moving up into netbooks and other mobile Internet devices, and Intel is moving down into the same space. For ARM, this could serve as a body of case law, while Intel will be forced to check its step before proceeding. And then again, how much can Intel actually change?

Rambus, meanwhile, is either in celebration mode or a state of shock. The Federal Trade Commission dismissed its latest case against the company, hopefully ending what has been a multi-year, multi-headed assault on the company’s memory IP. And all of this from an industry that has seen multiple convictions for price collusion, including jail time for some, endless lawsuits and perpetually falling average selling prices run ragged by competition at the bleeding edge of Moore’s Law.

Most electronics is pointed downward, as in shrinking line widths and smaller, faster, cheaper. But some of the same tools being used on a nano level are being used on a macro level, as in Mentor Graphics’ simulator being used to design data center cooling systems. Considering the number of ASIC starts is way down, you can expect to see more of these applications of chip technology in broader markets.

You also can expect to see a lot more tools rollouts over the next six months as the economy begins heating up. Synopsys’ IC Validator, which is focused on physical verification before tapeout, is this week’s example. There are plenty more in the pipeline from all the major EDA companies, all of which are racing to get those tools out before the next design cycle. This should be an interesting DAC.

You also can expect to see a lot more acquisitions. TI acquired Luminary Micro this week, which makes ARM Cortex 3-based microcontrollers. That should make for an interesting arrangement between ARM and TI, which already are collaborating in the DaVinci processor. 

And finally, a word of note about the jobs market and the economy in general. Job postings are starting to pop up on discussion boards for the first time in many months, even as more cuts are happening in the general economy. We expect that to continue in the design world, which is months ahead of the rest of the economy. And as the fabs begin ramping up their volume again, you may long again for the days when you had less to do.

–Ed Sperling

It was a good week for globalization, but a bad week for the global economy.

ARM made a “strategic” investment in eSOL, a Japanese embedded software vendor. The real way to read this announcement is that ARM has bought its way into the Japanese car market, which is about the only way you can actually get into that market if you’re an outsider. Despite its prowess around the globe in many markets, Japan’s domestic market remains impossible for non-Japanese companies to crack. But the downturn is hurting Japanese companies, too. Remember when Japanese firms were buying up U.S. real estate in the 1980s?

The economy may be down, but that isn’t stopping Moore’s Law. Mentor Graphics issued an announcement that STMicro is using its Eldo simulator to characterize 32nm cell libraries. Seems like the folks in Europe are staying busy to keep from freezing (or at least to justify their jobs.) Get ready for more power islands, really complex verification—as if it wasn’t complex enough before—and lots of complaints about tools not doing enough because there’s now lots more to do. 

That’s only part of the shift, though. While companies like ST, TI and Intel push to the next process node, others are jumping a half node. TSMC is looking at half-node increments to stay ahead of the pack, which may explain why NEC has partnered with Virage Logic at 40nm.

Speaking of TSMC, did anyone notice that Intel is pushing its Atom chip into the commercial foundry world? The two companies inked a deal to collaborate on IP, platform and SoC solutions involving Atom. There are two ways to read this. One is that, in light of Intel’s $7 billion investment to upgrade its fabs, Intel doesn’t see Atom as a core part of its chip lineup. The other way is that Intel believes it can further reduce costs on its core platform by outsourcing some of the manufacturing. Our guess is there’s a little bit of both involved, meaning Intel is hedging its bets on whether Atom will really pay off while simultaneously giving it a chance to compete with ARM.

The competitive stakes for Intel are growing from a different side, as well. Intel has always been proud of its ability to maintain its own fabs. The spinoff of AMD’s fab business and a subsequent investment into that business by Abu Dhabi-based Advanced Technology Investment Co.—read huge oil company profits looking for a new market opportunity—could make even Intel question its go-it-alone strategy. AMD’s ploy is to open its fab to outsiders while reaping the same unbridled flow of information back and forth between fab and design team—while utilizing capacity from outside companies the way IBM has done with its fab in East Fishkill, N.Y.

And if that doesn’t make chip manufacturing interesting enough, Shanghai-based SMIC received approval from the U.S. government to export its 32nm technology to the United States. That SMIC has gone from 65nm to 32nm and is now talking about success at 45nm is rather surprising, considering the bulk of its work has been at 180nm. That the U.S. government isn’t putting up any roadblocks is less surprising—at least when you think about all those U.S. bonds being held by the Chinese government. The last thing the U.S. can afford right now is a trade war with China, and SMIC is one of China’s most important companies.

–Ed Sperling

By Ed Sperling

The network on a chip (NoC) approach is gaining ground as an essential part of a system on a chip (SoC), providing the same kind of time-to-market advantage that well-tested intellectual property blocks provide.

This follows almost eight years of hype about NoCs potential with little to show for it. Times have changed and there appear to be two main drivers, one technological and the other business-related. From a technology standpoint, the real key is that chip designs are becoming far too complex to create all the interconnects necessary to get an SoC out the door on time and on budget. From a business perspective, the downturn has cut into staffing of design teams so severely that most companies don’t have the manpower left to develop complex interconnects on a chip that also has multiple cores, multiple power islands, as well as shared busses and memory.

“The key trend that makes such technologies more important is simply the increasing levels of integration, which significantly increase the amount and complexity of the on-chip communication—particularly in the sharing of key resources such as external DRAM,” said Jim Hogan, a venture capitalist familiar with this market. “This complexity permeates every part of the SoC design, from the increasing fraction of circuit delay due to wiring at deeper process nodes up through the massively deeper pipelining required to keep modern DRAMs operating at high efficiency, to the QoS scheduling required to ensure that general purpose software on CPUs can co-exist with real-time communications and multimedia traffic. NoCs provide a structured framework for managing these growing complexities and will therefore become the dominant approach for complex SoCs.”

But structured does not mean standardized. Far from it, in fact. While NoCs fit into standardized EDA flows and work with standards, they are one of the key components that must radically change from design to design.

“At 45nm, and with some designs at 65nm, companies have started to see issues with interconnects” said Charlie Janac, CEO of Arteris. “Projects cost more, they last longer, or they’re being canceled. There’s more problem solving, and the interconnect is more important. When we had single-core chips, it was a choice between a mainframe versus distributed network computing. Now we’re dealing with four to six cores, algorithmic engines, graphics, peripherals and on-chip/off-chip memory. All of this requires more communication on a chip.”

Defining NoC

So what exactly is a NoC? Definitions vary, and likely will evolve as NoCs become both more necessary and more widely deployed. And some of the standard definitions are fuzzy at best. Wikipedia, for example, defines a NoC as “an emerging paradigm for communications within large VLSI systems implemented on a single silicon chip.”

Most chip architects view NoCs as more of an evolutionary step than a radically new concept, though, with the difference being that a NoC is now a discrete part of the development process instead of including it as a piece of something else.

“I like to use the phrase ‘network on chip’ to describe what we do and have been doing for a few years,” said James Aldis, SoC architect at Texas Instruments. “My definition is based around the idea of the NoC being a separate component in the top-level assembly, with a point-to-point interface to each other top-level component. This is distinct from a traditional ‘bus’ where the bus is the top-level assembly. The alternative view is that a NoC is really something with a network-style architecture, where you send out bus requests and responses on the same wires. This alternative view means that the external interfaces of the NoC are not traditional ‘bus-style’ but rather ‘network-style.’ Transactions are captured in packets rather than being represented by separate address, data and command busses. This alternative view is not yet real in the IP industry. You can’t buy IP with this sort of interface on its boundary. It may be used internally in some companies.”

The NoC is particularly attractive at advanced process nodes because of the increasingly complexity and the ability to isolate some of that complexity in the network.

“With the advent of SOCs, a lot of complexity has moved into the interconnect. No one building such chips is really using the old “bus” paradigm anymore,” said Geert Rosseel, senior director at Pixelworks. “The interconnect now has to manage communication between IP blocks having very heterogeneous bandwidth and latency requirements and possibly living on different clock and power domains. The interconnect is now managing CPU-type requests with networking and real-time media (video and audio) traffic, usually all directed to shared resources such as memory. In my opinion, everyone building an SOC is already implementing some kind of complex on-chip communication system.”

But the NoC takes that one step further.

“What sets the concept of a NoC apart is the idea of developing an architecturally clean and unified approach to solving this problem,” Rosseel said. “You put all communication complexity in the network with the IP conforming to some simple interface standard. Once you have this ‘clean’ separation, you can develop an interconnect based on internal protocols that are optimized to meet the performance, area and power requirements.”

Looking forward and backward

The final caveat for most NoCs is that they have to embrace both new and existing technology. That includes a number of existing on-chip protocols, the Open Core Protocol (OCP), ARM’s Advanced extensible Interface (AXI) and AMBA High-Performance Bus (AHB), as well as an alphabet soup of proprietary and lesser-known acronyms.

Ian Mackintosh, chairman of OCP-IP, said the real key is to maintain openness, while embracing existing standards. “The world is heterogeneous,” Mackintosh said. “People have worked up from single bus generators to intelligent networks on chips where you need predictive performance of the NoC.”

OCP-IP has been working on a way to standardize NoC benchmarking to help sort through years of attempts to get this right. For further reading on this subject, check out the white paper entitled: “An Iniative Towards Open Network-on-Chip Benchmarks.”

Making all the pieces work together in a multicore system requires a deep understanding of the technology, lots of different layers of synthesis, and some incredibly complex testing strategies.

System-Level Design sat down with James Aldis, system on chip architect for Texas Instruments wireless business unit; Charles Janac, president and CEO of Arteris, Drew Wingard, CTO of Sonics, and Dave Gwilt, product manager for ARM interconnect products. What follows are excerpts of that conversation.

SLD: It’s hard to synthesize software now. Is it possible to synthesize the interconnect?

Gwilt: You have to look at techniques for traffic generation rather than software to bring these platforms up for testing the interconnect’s properties. Other techniques are needed to put the interconnect through its paces.

Wingard: The high-level design modeling often breaks down into function versus performance. In the functional domain, you have to have the software, but in many cases you can abstract away the interconnect and the memory system. It’s just bits and bytes at that level of the model. The virtual model stuff done by Virtio, which has been bought by Synopsys, were really more focused on trying to get a functionally accurate model into the hands of the software folks as early as possible without worrying about performance. We’re more worried about the performance, and for many of the accelerators it’s pretty easy to abstract away their communication behavior. The System C or TLM (transaction-level modeling) models can be living objects that the architect uses early for provisioning design, but as the design is integrated and I have the real stuff to play with I can compare what I’m seeing versus what I predicted. If they’re different, I can re-tune and re-optimize that part of the design—and I still haven’t built the chip yet.

Janac: There are different levels of abstraction. There is tremendous benefit in doing architectural exploration using traffic to model what the SoC is going to look like even before the IP is there so you can identify latency and make estimations of performance. But as you get onto the next level, which would be the RTL level, then you can use cycle-accurate System C models, which are much closer to the real performance of the system and ultimately you get the results from the FPGA and simulation. You’re looking at three or four hierarchies of modeling accuracy. The benefit is you’re likely to come out with something that’s going to work.

SLD: Does that make it harder to scale a platform into derivative systems?

Wingard: There are different strategies for scaling these platforms. Some companies go after the ‘Super Chip.’ They build the most complex platform they ever want to make. It’s a very expensive way to do it, but you get an ideal software vehicle and whatever chips you build are going to be subsets of that chip. It’s very easy to turn off the hardware and software. You tend to come up with a piece of silicon that’s harder to sell because it’s more expensive and bigger than it has to be. A lot of people can’t afford to build a throwaway chip, and the Super Chip approach requires you to understand what the market is going to look like several years from now. The alternative approach is to be in continuous refinement phase. The architects’ models, which normally would be thrown away, need to be kept alive. If something changes, how does it affect the previous model? And maybe you don’t have to do all the detailed analysis work again. The last thing you want to do is figure this out at the polygon level.

Gwilt: It also helps to have debug and trace hardware built into your core, so you can understand where it’s performing well and where the inefficiencies are. Having debug features may make the difference between being able to extend the platform another generation in software versus having to rebuild the hardware platform. That can be the make or break for a platform.

Wingard: I completely agree. One of our customers shared 30 milliseconds of trace data off one of their production high-definition TV designs. We used that for optimizing the next generation of our interconnect. That kind of visibility and trace data can be invaluable for the IP provider as well as the system architect.

SLD: What are the problems TI is seeing with this kind of technology?

Aldis: We’re probably like the first type of customer. Our flagship OMAP product looks more like the Super Chip, and then we go through derivatives—although they would have other things on them, as well. It’s essential for us to maintain models of interconnect technology, the different cores we’re using and the applications. Traffic models give you some idea of what the system looks like when it’s running, and how much the system suffers if you increase latency. We spend a very large proportion of our time trying to recalibrate the kind of model libraries we have for our SoC platforms against the results. When the software people tell you three years in advance that they expect it to need this number of instructions and this kind of cache footprint and you come back three years later and they have the codecs running, but not necessarily with the same numbers, it takes constant work to keep these things alive.

SLD: How do you optimize utilization of the individual cores on the chip?

Janac: You get different levels of detail as you progress down the design path. Initially you’re working with TLM 2.0 models, which are fully untimed and which give you the function. Performance is an estimate. Then you go to cycle-accurate System C, where you get within the range of performance. Then you have FPGA data. You get more and more detail. That’s very important, because you can make all sorts of analysis and tradeoffs and estimates. Then, on your derivative, you can look at how that stacks up.

Aldis: Derivatives are easier because you have a lot more information when you build the derivative than when you build a new platform. Whenever you’re doing early architectural decisions for a major new generation, you use whatever information you’ve got. That’s often very little information, but there’s a huge time pressure to make decisions, decide what the thing is going to be like, whether it’s green or brown, 32-bit or 64-bit or 128-bit. If you don’t have a working model and the project needs to make a decision and someone’s gut instinct is strong enough that it will be okay, you go with that. With a derivative, you have a chance to put model data together and measure data off the platform, so you can make more informed decisions.

SLD: Is complexity getting to the point where it’s affecting business decisions about what gets developed?

Gwilt: Our customers’ systems are growing dramatically. Whether they will be able to over-engineer platforms, I don’t think so. Unless you’ve got a very significant parent company that can afford to take a few more square millimeters of silicon than they might need, there will be a lot of pressure on area, gate count, the ability to implement it both in processors and cores.

Aldis: There is no doubt it’s getting more complicated. The number of engineers we need to build a big SoC these days is huge.

SLD: Is the number of engineers going up, and are automation tools helping?

Aldis: It is going up. The tools are obviously helping a lot. Four generations ago, for example, we did the interconnect by hand. Now we couldn’t imagine doing that. What’s happening now is the level of modularity on the chip—the number of subsystems containing their own interconnect—is going up. We used to have a team of five or six people building the interconnect. Now we have five or six people that are responsible for 20 interconnects on one device. That could be a break-even case. In other areas there could be less tool support. When you’re doing video processing, you don’t have the level of specialist tools that you have in the interconnect space. There are a lot of interesting tools that enable you to synthesize in C code, but there’s still a lot of hard work running those things or putting those together.

Wingard: One of the approaches we see companies take, which is what TI is doing, is building subsystems. They’re building larger collections of IP into an object that is more application-domain focused, like a video processor with a lot of local memory and a collection of IP cores that is potentially re-usable. All of the software assets needed to make that thing do its job are considered part of that object. That’s a much lower-cost way of re-using that component than if it’s a bunch of separate building blocks. That’s a positive trend we see coming.

If you think designing a single-core system is hard, designing multicore systems is multiple times harder. Connecting all the pieces together and making them work properly, if not together, is one of the hardest tasks design engineers and architects will ever face.

System-Level Design tracked down some of the experts in this field and sat them down around a table to discuss what’s going on. Included in the discussion were

James Aldis, system on chip architect for Texas Instruments wireless business unit; Charles Janac, president and CEO of Arteris, Drew Wingard, CTO of Sonics, and Dave Gwilt, product manager for ARM interconnect products. What follows are excerpts of that conversation.

SLD: Let’s start with a really basic question. How do you define multicore?

Gwilt: We’ve been doing multiprocessing heterogeneous stuff for a very long time and in many different markets. Multicore is running a single software image across multiple processing elements.

Wingard: That doesn’t match what we see in practical systems.

Aldis: TI has been producing multicore chips for multiple generations now. We split the software into the piece that’s going to run on the RISC and the piece that’s going to run on the DSP and the piece of application processing that’s going to be offloaded onto a hardware accelerator. That’s all a very manual process. When I think of multicore these days I tend to think of what’s coming up in the wireless space where you have a single software image and it’s magically distributed over identical cores on the same device. But multicore means more than that.

Janac: There are a number of people who have tried to do the homogeneous multiprocessor kind of approach—similar to an FPGA. That works in some applications like defense and aerospace and networking, but it doesn’t work in cost-sensitive applications like wireless and consumer. As a result, we wind up with the majority of the market being heterogeneous multiprocessor SoC’s. Those are getting increasingly complex because the wireless carriers are constantly trying to deploy new applications and handset guys are trying to approximate the function of a PC. That’s putting increasing pressure on the hardware.

SLD: What do you actually gain integrating multiple cores, which share memory and busses, versus single-core chips?

Wingard: We’re doing these high levels of integration because we’re trying to get a certain amount of function at the lowest system cost and power and with the right amount of performance. We integrate not because we want to, but because Moore’s Law says we have so many transistors. It’s the job of the system architect to figure out how to make it work. In many cases, the thing that throttles these chips is that they have to share memory, but if you don’t share memory you don’t save costs. The personal computer space is driving DRAM road maps to give us increasing bandwidth per pin. Then we want to put the right amount of processing and bandwidth on the SoC so we can maximize utilization of that extra DRAM bandwidth. Some of this is also driven by form factor. You can’t do a multichip iPhone because there isn’t enough space inside the package.

SLD: Is the heterogeneous approach because each function requires different processing power?

Gwilt: Absolutely.

Janac: I was at a presentation where one gentleman said he was proud that his company was only using 7 percent of the ARM processor and that the rest of the system was running on these proprietary algorithmic engines. I wouldn’t be very proud of that.

SLD: So that’s 7 percent utilization?

Janac: Yes. They should be adding some intelligence that makes use of that resource and reduces the cost. One of the issues is how do you route the traffic to the cores that are available. What is the idle core doing? If it is idle, can you utilize it better?

Wingard: Today, in the battery-powered domains, they’re shutting off regions of the chip and turning off the power supply to several of the cores. If they don’t have anything to do, they’re shutting them off.

Janac: Or they’re putting them in a lower operating mode.

Wingard: All these games get played, but there’s an inefficiency associated with that. If you use heterogeneous cores, you can get better results. Your battery lasts longer. You can get higher performance. And you are much more able to support these multi-mode devices, which are still not general-purpose computers. PCs don’t do it this way because economics demand that you have a single software platform and you can run anything you want to pretty well. Application flexibility is much more limited. That doesn’t mean we don’t see clustered processors like the ARM MP core being useful for these applications. It’s still valuable to span a wider range of performance points by using some number of identical cores that you can schedule software across. ARM can scale an application, and the power associated with running that application, when you play with the voltage and the number of cores that are turned on.

Gwilt: That’s the key—using that to get power scaling across a broader dynamic range.

SLD: Didn’t TI do this with its DaVinci platform?

Aldis: Yes, we did. But there’s another aspect to all of this, too. The more open you make your platform, the more you end up in the PC world that Drew described. One thing we’re seeing in the wireless space with the advent of the iPhone and the mobile Internet devices that are coming through now is an emphasis on getting raw power out of the main processor and software portability. The wireless world, particularly at the high end, is becoming more and more like the PC world. This presents a challenge because just throwing gigahertz at something isn’t going to fly in the wireless world because of the constraints of power and form factor.

SLD: More and more, chip developers are trying to get multiple generations out of chips because of the cost of creating one. Is it harder to do with heterogeneous cores?

Janac: No, that’s where the interconnect comes in. If you have the right structure for the interconnect, you’re actually able to add in and back out IP in a much more cost- and time-efficient manner to get multiple derivatives.

Gwilt: That’s absolutely correct. Nowadays, with the type of interconnect technology that’s available, we’re able to build chips with very large numbers of cores and use the content of the cores that we require. We can choose those cores dynamically and maintain a highly optimized solution.

Wingard: There are some interesting examples where they take a subsystem, and within the context of a platform they implement that function in dedicated hardware or an optimized programmable processor. They get to higher performance and lower power that way. But in other versions of the same platform they move that same function into software. From the perspective of the application, the platform is the same. They’ve put in a layer of middleware that allows them to be agnostic. That makes it much easier to take this common platform definition and build different variants.

SLD: Your definition of interconnect is different than the historical one. This version seems to have logic built into it so you can optimize performance in multiple products.

Wingard: We want to put enough intelligence into the interconnect so that some part of the platform definition relies upon logic within the interconnect. What’s different about each chip is the set of IP cores, but there’s a set of common functions that are part of the platform definition. Some of those functions live within the interconnect—things like how do we enforce security and how do we manage to recover from errors. What scares me most about phones becoming more like computers is I really don’t like getting blue screens when I’m in the middle of a call. We expect stability in our appliances.

Gwilt: That same requirement for stability is also being driven by the need for integration. Our customers all want to pull together very significant platforms in very short periods of time. Having the ability to manage that stability through the interconnect is a valuable function.

Janac: If you use the interconnect to assemble these kinds of platform applications, you also need some automated and sophisticated tools for the design of the interconnect and for verification. It’s a matter of both the IP and the tools that come with it that are required for rapid time to market.

Wingard: The total amount of communication that we have to manage in the interconnect grows with the total number of components that have to be connected. But historically the fraction of the chip that’s dedicated to the interconnect and the main memory controllers has been remarkably constant across a wide variety of applications and design styles. Typically, between 8% and 12% of the die are interconnect and memory system components. As the chips get bigger, this is the part of the system that must change for each design. I can mix and match components, but the interconnect is going to be different every time. It is the most chip-specific IP, even in a platform definition. That’s why the automated tooling for this part of the design is so important.

SLD: But interconnects traditionally have been several steps after the initial architectural design. Has that changed?

Aldis: We’re now in our third generation of SoC platforms where we’ve known what our interconnects are going to look like—maybe not all the dots on the ‘I’s’ and crosses on the ‘T’s’ but we’ve known at a very early stage what we’re going to be using. We also know all the requirements we’re going to put on the different cores in the chip so they can plug into our interconnect environment. Nowadays, when we build a chip the interconnects are enabled before any of the cores. We have legacy cores, of course. But for any new cores, before we have working RTL we have an interconnect. This makes a huge difference between the time it takes to kick off a project and see the test cases running and starting to debug and analyze. We also have a System C model for the interconnect technology we’re using, as well. That’s part of the very initial architectural studies.

Wingard: This has a lot to do with the application domain that’s being targeted.

In those places where you put multiple cores together, you have to worry about the sharing behavior and performance. You quickly get the point that until you have a model of that system and you need to understand the implications of a shared memory and the interconnect that feeds it, you don’t know if you have an architecture that works. For those domains where it’s not, ‘Slap it together and we don’t care about performance,’ you absolutely have to have the interconnect technology and it has to be available very early in the architectural phase of the chip. There are many designers from ASIC background who aren’t used to that.

By Ed Sperling

Jan. 22, 2008—Vendor news releases are far more interesting in context of other releases than they are by themselves because they reveal both a strategy and execution of that strategy.

It’s no secret that many companies in the design space are extending themselves beyond their traditional borders because their customers are doing their own retreat into a very narrow space and relying on tools developers to do much more. It’s how the pieces go together, though, that gets interesting.

Consider, for example, Mentor Graphics release this week of a Scalable Design Methodology based upon TLM 2.0. While the announcement is interesting enough in itself, bringing Vista and Catapult C into the TLM 2.0 world means Mentor is making a broader play for a new class of designer—one that is worried about complex ESL problems but less able to marshal the resources and expertise in-house to understand all the pieces and how they need to fit together. TLM 2.0 is something of a black box technology that requires a leap of faith, and Mentor is piling its tools on top of the OSCI standard.

Likewise, Synopsys, which has been reaching out farther into the IP world, added support in its Ethernet IP for ARM’s AMBA on-chip interconnect standard. Considering AMBA is one of the resident standards in the wireless world, this allows plug-in extensions to the ARM environment. When you think about the hybrid device that is part portable, part plug-in, part PC replacement, this is a potentially enormous market.

The last of the big three EDA companies, Cadence, pushed into the FPGA synthesis world, in part because both of its top rivals already have a strong position there and in part because FPGAs seem to be gaining ground in new markets. Genomic sequencing, for one, relies heavily on FPGAs with software written in RTL to directly interface with the chip. This is potentially a huge market, as well, given the aging population and the growing recognition that people will money will part with huge quantities for personalized medicine.

That’s just on the tools side, too. The end markets are beginning to expand, as well, in areas that should come as no surprise. Texas Instruments introduced a solar energy harvesting development kit and high-temperature transceivers for oil exploration.

Broadcom added Bluetooth to digital televisions with Sharp while its arch-rival, Qualcomm, bought AMD’s handheld graphics and multimedia assets.And Intel is working with virtualization software maker Citrix to figure out ways to take advantage of all those cores it plans to release in future versions of its x86 processor.

Put it all together and the picture is broader than just a new product release. It’s an industry in transition to expand beyond traditional borders, or figure out ways to do more within the traditional limits.