By Ed Sperling
System-Level Design moderated a discussion about the future of SystemC with Thomas Alsop, corporate design solution expert at Intel; Ambar Sarkar, chief verification technologist at Paradigm Works; Mike Meredith, vice president of technical marketing at Forte Design systems; David Black, certified training instructor at Doulos. Here are some of the key outtakes of that discussion.

SLD: What’s going on with SystemC behind the scenes?
Black: The SystemC working group is starting back up. Quite a few companies are interested in making it more compatible with modern platforms. There is also interest in UVM and other areas of coverage.
Meredith: There isn’t activity yet in the working groups, but people are starting to bring information to address coverage in verification. There is certainly an appetite for a UVM-like methodology inside the SystemC verification framework. That’s an area where we will see some activity in the future.
Sarkar: What people would like is better coverage, along with UVM.
Alsop: I’m on the committee at Intel that’s looking at high-level synthesis capabilities. New capabilities we want to see over the next year are things directed at HLS. Some of the verification methodologies we’re implementing in relationship to HLS involve better coverage. We’re working with EDA vendors on better constraint solvers and better random generators. We have a very vested interest in UVM and maybe we could create a UVM environment around SystemC, as well.

SLD: There have been rumblings about a SystemC verification group. Is it really happening?
Meredith: There was a SystemC working group in OSCI some years ago. The activity died down for a few years, but last fall there was a new call for membership. It is starting up again.

SLD: Any idea when something will come out of this group and what it might be?
Meredith: When is a crystal-ball question. But in terms of what’s going to come out of it, initially they’re looking at updating the existing library to work within the context of the new standard as a first obvious step. From there it could include better coverage.

SLD: We’ve all seen what happens when standards efforts go wrong. Will there be multi-language support out of SystemC.
Alsop: Intel, and even some of the other companies working with the UVM committee, really want to see multilingual support for SystemC. There are some behind-the-scenes efforts where we’re trying to get end users to look at the spec and what kind of infrastructure or framework we want to place around this. We’re still trying to get our hands around what the spec will look like. The good news about the merger between Accellera and the Open SystemC Initiative is that it will help a lot with collaboration across different committees. We’re not sure if this will enable work on a new subcommittee that will work on ML and bring in numbers and help from across different committees, or whether it will do this under one of the existing committees. But it is definitely one of the things being investigated.
Black: A lot of EDA companies have their own private interfaces across the boundaries. For example, with TLM 2.0 there are some proprietary implementations. It seems to me that the boundary between SystemC and System Verilog has to be crossed and standardized.
Meredith: Another area where the multilanguage issue is prevalent is in the analog space. With the Accellera systems initiative there is SystemC AMS and Verilog activity. There is definitely some movement, not toward a single language solution, but toward getting these languages to work together.
Sarkar: A similar problem to UPF/CPF came up with the coverage stuff. There are so many domains of coverage that there is a problem of how you deal with it in the first place, and then how do you get access to the data afterward. We have to define a common coverage data model and then choose an API. In this case, it may be C, which is the lowest common denominator. That approach may not work for everyone, though.

SLD: What’s the relationship between SystemC and UVM?
Alsop: I’ve had lots of discussions with vendors about this. The issue right now is there is no standard mechanism for interaction. One of the things we want to enable is IP re-use. That requires any connections—whether it’s TLM connections or other communication protocols across languages that need to happen—it has to happen in a standardized way. If you have IP that’s communicating with some other block, we want the industry to provide IP that already has the communications embedded into it. When you acquire IP you want it to just automatically start communicating with other IPs. So how does SystemC interact with UVM? Long-term we want to set up a framework that enables that.
Sarkar: The fact that we’re using TLM is a big step toward that. System Verilog now works with TLM and SystemC works with TLM. That means both communities need to come together and help out. That’s one area.
Alsop: We have different data types to support. How do you do that? What subset of TLM has evolved and how do you support it? That has to be dealt with.

SLD: There’s another standard out there called the Unified Coverage Interoperability Standard (UCIS). How does that fit into SystemC?
Sarkar: There needs to be something common across both. The good news is there are a lot of common goals. We don’t want to solve the problem two different ways and then try to bring it back together. We are coming up with a standard, and it has a very good start. But we have to be able to capture coverage and use it with the same content. That’s what this enables.
Meredith: Do you anticipate people building environments where some of the verification is done in System Verilog and some is done in SystemC and then you try to accumulate coverage across all of that?
Sarkar: Sometimes you don’t have a choice. Whether you want to do it in one environment or another, you have to deal with different methodologies when you’re talking about emulation or formal verification. But we have tools to make sure you are covered, regardless of which one you’re using.
Alsop: There are a lot of religious wars among designers. At Intel we see a growing use of SystemC. We think we’re still in the infancy here. SystemC has been around for a while for verification, but now designers are moving to a higher abstraction language. That’s still in its infancy. But once designers get hooked into a language and know how to use it, they stay with it. Then there’s also performance. When you’re trying to do certain things in System Verilog it’s slower than SystemC.
Black: There’s another effort going on. A lot of folks are interested in parallelization of SystemC. It’s a matter of distributing your simulation across machines, which is not a trivial task. It doesn’t matter whether it’s System Verilog or SystemC. Both languages need to do that. There are a lot of people talking about that right now.

By Ed Sperling
Apache Design uncorked the next release of its RedHawk power signoff environment, this one geared for sub-20nm and stacked die for designs with more than 3GHz performance and billions of gates. The fact that tools are starting to roll out for 3D ICs is key for moving this design, packaging and re-use scheme forward.

Cadence introduced TripleCheck IP Validator, the latest addition to its verification IP catalog for compliance testing of interface IP. The company also announced availability of its OrCAD Capture Marketplace for its OrCAD and Allegro PCB community through a desktop browser.

Samsung rolled the industry’s first hardened ARM Cortex A-15 SoC utilizing Synopsys’ IC compiler for place and route of the 32nm chip. The chip is based on Samsung’s LP process using high-k/metal gate technology. ARM’s A-15 is its most power processor core yet, and one that it has positioned squarely against Intel.

By Ed Sperling
Cadence rolled out a low-power reference flow for SMIC’s 40nm process, from RTL to GDSII. What’s particularly noteworthy is just how fast SMIC moved ahead in process technology.

Arteris won a deal with MtekVision, which licensed its MIPI Low Latency Interface inter-chip link IP for multiple SoCs. The big selling point on LLI is it reduces the bill of materials by an entire memory chip.

TSMC’s net sales increased 9% in March compared with February, while revenue for Q1 increased 1.7% over the same period in 2011.

Intel inked a joint development agreement with the Beijing municipal government and the Chinese Academy of Sciences for research into a Chinese “Internet of Things.”

By Pallab Chatterjee
With the rise of mobile appliances, smart phones and tablets, there has been a lot of discussion about the place for PCs, servers, embedded processors and networks. A number of companies have claimed they will rule the world of computing and there will no room for others.

Reality seems to be somewhat different, however. The mobile end point devices—smart phones, tablets, and netbooks, are content-consumption devices. They playback content—video, music, still images, business data—that already exist.

The majority of business data is created on desktop/laptop PCs that use an x86 processor from Intel or AMD. These have been the dominant platform since the early ’80s and still are the workhorses inside most offices. Tablets are starting to be brought in to supplement the PCs and extend their lifecycle, but they are not displacing the existing machines. The computing power of these larger systems allows them to be used for presentation creation, as opposed to viewing, graphics creation, report writing and calculation. These are in addition to the engineering and scientific uses, which are also compute-intensive.

A common misunderstanding is that the multi-core microcontrollers that are in the tablets and smartphones can perform equivalent computational tasks to microprocessors. The applications on these devices (power optimized in-order-execution controllers with direct mapped memory) are created on machines using out-of-order execution featured microprocessors, which also provide deep, virtualized memory, large data stores and the true multi-user and multi-tasking. This allows for the creation of memory and runtime-optimized applications (i.e. Web browsing and games with multiple pre-defined playing levels and performance metrics) that have both known and minimized data and resource extents for the micro-controller based players.

As a result, standard development environments on Windows/Linux/Mac OSX using x86 machines are the default basis for the application and content creation for the mobile appliances. These are not just created on workstations. They also are created on a server base. Depending on who is quoted, the ratio of server cores per end point device is in the range of 1:8 to 1:20. This means worst case for servers, at the 1:20 ratio, it would require 2.5 billion x86 cores to address the 50 billion end-point devices forecast for the Internet of Things. Rather than spelling the death of big iron devices, it means massive sales in this market. Based on real applications, the ratio will average out to something closer to 1:12, which brings the number of cores close to 5 billion.

The advantage of these machines is the ability to support virtual users (multi-simultaneous clients) using products from Microsoft, IBM, VMware and Citrix, as well as full virtual machines. A virtual machine differs from multi-user approaches in that the I/Os, storage, security and CPU/GPU interaction are also virtualized for each user. This allows for mapping direct-attached and tiered storage, including a storage-area network, to be virtualized for access from the virtual machines.

Currently, the virtualization support for the microcontrollers and their associated hypervisors do not support full virtual machine capabilities. In discussions with more than 75 enterprise and data center administrators, this need for full storage and memory access, as well as out-of-order execution to support multi-applications from multi-users at once, are preventing microcontrollers from gaining ground in the server space. They have made only limited gains, mostly for targeted applications at the edge of the network for running Web servers and fixed fill-in-form applications that can be crafted the same way that end point code is created.
This accounts for, at most, 1% of the server environment at a ratio of one core for four users. It also brings with it a cost of development and support that is about four to five times the cost of general-purpose code that has single release capabilities and does not need multiple operating variants to be deployed for support of multiple device platforms and OSes.

By Ed Sperling
As complexity increases and the industry increasingly shifts away from ASICs to SoCs, the concept of coherency is beginning to look more like a stack of issues than a discrete piece of the design.

There are at least five levels of coherency that need to be considered already, with more likely to surface as stacked die become mainstream over the next few years. Perhaps even more mind-numbing, this stack itself will have to take on a level of coherency over the couple generations of chips.

Let’s take a closer look.

Cache coherency
The concept of keeping data coherent historically was relegated to processor makers such as IBM, Intel and AMD, which have focused on improving performance through faster access to data. One solution to that improved performance has been multithreading and multiprocessing. Along with that, these vendors have added in various levels of cache memory for faster recall of important data.

More cores also makes it harder to effectively use these caches. Data has to be kept consistent, which requires more system overhead in terms of processing and power just to maintain that coherency. And it gets even harder as more cores are added into an SoC, which increasingly are not same size, do not run at the same frequency, and sometimes do not even connect directly to the main CPU.

“With cache coherency, some of the traffic may be serviced by the cache on another GPU,” said Drew Wingard, CTO at Sonics. “If you’re just using an ARM core, the CPU coherence is sufficient. But the GPU uses its own local memory. You really want it to be fully cache coherent across all of those.”

But even finding the data to maintain consistency may be a problem in a complex SoC.

“You can view what’s in memory, or view it and be able to change what’s in memory, but first you have to find it,” said Kurt Shuler, vice president of marketing at Arteris. “If you have four cores, the most efficient way to hook them up is for each core to have its own cache and graphics to have its own cache. If you change something, you have to snoop in all the caches to make sure it’s consistent.”

But there is also a move in the completely opposite direction—sharing memories among multiple cores—because it reduces the number of components on the bill of materials. The Low-Latency Interface specification from the MIPI Alliance is a case in point, where a memory can be shared between a modem and an applications processor. Intel, meanwhile, has added on-chip graphics that share memory with the CPU.

“The whole design gets more complex,” said Shuler. “You have more traffic beyond the cores, and from a power standpoint the overhead goes up.”

Still, cache coherency is one of the better-understood pieces of this stack. It has been an issue ever since multiprocessing was first employed in the 1960s. “Snooping” has been widely used since that time.

Software coherency
A newer facet of coherency involves embedded software. Because SoCs now include an increasing amount of software in the design, engineering teams now have to wrestle with coherency issues that previously were dealt with by the operating system.

“Fundamentally you’ve got two combined issues here,” said Andy Meyer, verification architect for Mentor Graphics’ Design Verification Technology Division. “You’ve got cache coherency, where the same data is being viewed in a couple places. And then you’ve got an issue with consistency in the simple code in a uniprocessor that now has to run on a second processor. The ordering of events can change in multiprocessing.”

Those problems crop up regularly in verification, but not always with the expected results. It’s difficult to effectively write the stimulus in a testbench for coherency. What happens, for example, when a core is shut down to save power?

“The scariest part is when there is no OS support,” said Meyer. “There’s also a big problem with heterogeneous cache, such as when you have a CPU working with a GPU.”

Another issue has to do with effective coverage in verification, already a problem for complex SoCs. States frequently are distributed across multiple chips and multiple boards. Timing varies from one state to another, and can be particularly problematic if snooping functions are tied to a state. And parallelism continues to baffle even the most advanced teams.

“Standard coverage methods don’t work well here,” said Meyer. “You have to query in ways you traditionally didn’t have the power to query and ask questions across months of regressions. For instance, ‘Have we been here ever—or in the last two months.’ Until coverage steps up, people with deep knowledge of verification running hundreds of full-time emulator systems are finding out at the last minute that it’s not okay to ship.”

I/O coherency
Tied in with both cache coherency and software coherency is I/O coherency. Increased communication on a chip, between chips, and between a chip and the outside world, have turned what used to be a relatively straightforward networking issue into a complex jumble of prioritization and synchronization.

“You have to deal with this even in single processors,” said Sonics’ Wingard. “You may have a PCI core streaming data into memory. Today, without I/O coherence, it’s difficult to determine what is coming in. The CPU has no way of knowing what was transferred when it dos a copy from non-cache to cache.”

He noted that personal computers had I/O coherency for a long time, particularly with direct memory access. DMA was developed initially to help solve the bottleneck that occurred when a CPU was involved in an I/O transfer. Rather than tie up the CPU with that transfer, the CPU continued running, then accepted an interrupt when the transfer was completed.

But with more of this being moved onto a chip, keeping coherency while moving data back and forth from more places is becoming much more difficult.

Ecosystem coherency
One of the least addressed facets of the coherency stack involves business and communication issues across a supply chain for a particular SoC rather than the actually technology itself. Even where competitive suspicions can be overcome, the very different approaches taken for designing components, IP and software, as well as language barriers, create one of the more difficult and less tangible challenges in the coherency stack.

“The challenge going forward is that you have a bunch of people who may not be that skilled in system development driving the chip and spec for one design, and other supplier trying to orchestrate things,” said Mike Gianfagna, vice president of marketing at Atrenta. “So you bring them together to solve a problem for one customer in 12 weeks and then they move on. You’ve got corporations coming together and bringing all these pieces together almost like the way a movie is done. But is there a coherent way to communicate data and information risks and still provide good visibility from a power/performance/area point of view?”

For decades this task has been handled by IDMs, but in the SoC world there are far fewer IDMs these days. Many of these chips are built using third-party IP such as cores from ARM or MIPS, DSPs from companies such as Tensilica, and standard IP from the Big Three EDA vendors.

Coherency in stacked die
It’s uncertain whether stacking of die, either in 2.5D or 3D configurations will make coherency easier or harder. The answer is likely to be a little of both.

“With 2.5D and 3D, you’re looking at low-power memory access,” said Arteris’ Shuler. “You put the DRAM closer to the CPU, the addressing is wider and you get rid of some of the latency. But you also need coherency across all of this.”

No one is sure yet how multiple high-speed communication channels between die will affect coherency. If the channel between the core is wider and shorter that will improve data speed, but if processors and DRAM are scattered on multiple die, with some of them shut down, some partially shut down, and others fully active, it may make it harder to keep track of data and make sure it is all synchronized.

By Ed Sperling
System-Level Design sat down to discuss the future of stacked die with Riko Radojcic, director of engineering at Qualcomm; Prasad Subramaniam, vice president of design technology at eSilicon; Mike Gianfagna, vice president of marketing at Atrenta; and Herb Reiter, 3D/TSV working group chair for the GSA. What follows are excerpts of that conversation.

SLD: Where are we with 2.5D and 3D?
Radojcic: I think 2.5D was a misnomer, because that implies they are sequential. It’s clear that what we call 2.5D and 3D are going to co-exist for a long time. Some things make sense with an interposer and some make sense to be 3D.
Reiter: I agree—2.5D is a parallel effort to 3D. Lots of things will not use 3D because it’s too expensive. In 2.5D we will see production this year. With 3D it will take until next year for the first ones. I would guess computing or networking would be the first.
Radojcic: I would think those guys will pursue 2.5D.
Subramaniam: Memory makers are already offering 3D solutions today. If you look at just the memory chip, to increase the size of the memory rather than the die they’re stacking it vertically. That kind of 3D is already in production. It’s the question of co-mingling logic and memory that will take time. The advantage of 2.5D is that it allows afterthought. It allows you to take an existing design and to create a new set of I/Os and put in a 3D type of application.
Radojcic: I see no value in doing that. You’re creating an expensive solution to something you can do more cheaply. If you add the 3D interposer you’re adding another wafer. That’s cost. We can solve that problem with a flip chip. It’s cheaper.
Subramaniam: I disagree. We’ve done the analysis. It allows us to take an existing design, like an ARM subsystem in 28nm, even though surrounding logic doesn’t have to be at that 28nm process node. It can be 40nm or 65nm. Rather than building a new chip at 28nm, I can take my existing design, use it as one component of my 3D IC, and build a second chip in a cheaper, older technology.
Radojcic: Yes, as long as you’ve architected your chip like that, such that you can partition it.
Subramaniam: You can’t take any design, no. There has to be some partitioning in the architecture and some forethought. It’s not 100% an afterthought, but there is still some afterthought there.
Radojcic: You have to architect for it. If you haven’t done that, taking an existing chip will just cost you more. If you have done that, of course there is an avenue to doing things better and more flexibly.
Subramaniam: There is enough flexibility in designs that allow you to partition it in some manner.
Radojcic: True, but before 3D came along most of us wouldn’t have partitioned. We wouldn’t have architected it that way. To be able to leverage that value proposition, you must have 3D in mind.
Gianfagna: That’s true. It’s a premeditated act. If you don’t think it through way up front it doesn’t work.
Subramaniam: Because the SoC has a well-defined architecture, it lends itself to this type of application.
Radojcic: But only if you plan for it ahead of time.

SLD: Is this true in all cases?
Reiter: That’s the view of a high-volume supplier. I see low-volume solutions where they use an existing die, put it face down on an interposer, and connect memory to it. So for low to medium volume, 2.5D works. You call it an afterthought. I call it a customized solution.
Radojcic: Why wouldn’t you do that in a traditional multichip package?
Subramaniam: Because you don’t get the interconnectivity. The advantage of a silicon interposer is that you get thousands of interconnects.
Radojcic: But you have to design it sufficiently so you can leverage the interconnects from die to die. If you had designed for a traditional design, though, you would say, ‘I can’t have thousands of interconnects so I’m going to make a serial interface with 100 pins.’ If you take that design for a 100-pin interconnect and stick in an interposer it’s an expensive way of doing things.
Subramaniam: You may be able to take some internal signals out, which you are not able to do with a traditional MCM (multi-chip module) approach.

SLD: Let’s do a reality check. How far along are we toward stacking?
Gianfagna: Last year we had a hot-wired 3D system that was 2D with a bunch of scripts and manual effort. The customer base had strange, contrived designs and they were trying to see what they could and couldn’t do, and the foundries didn’t know what they wanted to do. A year later we have native 3D planning capability, the customer base has specific designs for implementation this year and next, and the foundries have a laser-sharp focus on process learning, mostly around 2.5D initially. If that’s a metric, things are clearer this year than last year. From an EDA perspective, I still think the market is two years away. But we still think this is big.
Reiter: If you look at the Atom chip with the FPGA from Altera, that’s basically a 2.5D solution. The FPGA is for customizing things. The Atom chip was not designed for this application.
Radojcic: But why use an interposer? Why not use a substrate and a multichip package?
Reiter: You could do that.

SLD: What’s missing from the tools side to make all this work?
Reiter: The ability to demonstrate what this technology can do is the most important capability. If you look at big corporations, top management is still hesitant to invest in this technology. If we could demonstrate in a credible way what it can do, people will be more successful in getting money to start programs using this technology.
Gianfagna: The way that happens is the early adopters blaze the trail, everyone tries to follow and the market heats up. What’s needed are commercial drivers. The tools aren’t there, but they’re close enough.
Subramaniam: The tools are not the issue. The development needed to support 3D is incremental. It can be done with the existing infrastructure. It’s really the end application.
Radojcic: Other than path-finding, which is hard to do with traditional tools. And the analysis.
Gianfagna: The complexity is higher. We’ve discovered that, too. RTL prototyping for a single chip has a certain set of challenges. When you go to 3D the modeling requirements are much greater, the constraint generation is more complicated. And we need standards. We can generate all the constraints, but we don’t know where to put them and how to express them because there is no agreed upon way to do that.

SLD: Do the standards organizations know where to start with all of this?
Radojcic: Standards are on a good track. We’ve worked with Si2 and Sematech to propose initials blasts for standards so we can feed them into Si2 and the EDA community and accelerate the process. The bits and pieces are moving, and we are on track to have a set of design exchange format standards by early next year.
Reiter: And Wide I/O.
Radojcic: Yes. The standards are channeled and the engine is revving.
Reiter: We have a bunch of players in a 3D enablement center participating. There are 15 companies listed, including Intel, IBM, TSMC, GlobalFoundries, and so on.
Radojcic: The way this was set up was Sematech said we are going to start a 3D enablement center initiative driven by the SIA. All the members of Sematech were mapped into this. Then a number of companies like Qualcomm, LSI and ASE joined.

By John Blyler
Interconnect technologies are nothing new at Intel. During the recent Intel Developers Forum (IDF) 2011, several processor-centric interconnect technologies were on display in the company’s Labs Pavilion. Most noticeable of these were Many Core Application Research Community (MARC) and its derivative called the Many Integrated Cores (MIC) projects.

In terms of interconnect fabric, the MARC platform relies on an open standard “Message Parsing Interface” (MPI) to communicate between as many as 48 Pentium cores within a single die. The goal of this research is to develop the interconnect hardware and parallel software applications that would support the “millions of processor” program. In this activity, Intel has been working with the U.S. government on a project called Ubiquitous High-Performance Computing (UHPC).

Interconnect strategies change as vendors move from processor-centric to SoC third-party IP-based designs. While Intel laid out its SoC development strategy years ago, few details concerning the interconnect fabric have been made public. Bill Leszinske, the company’s general manager of technical planning and business development at the Atom processor SoC development group, recently revealed that the Intel interconnect fabric will serve as a “chassis” within which a variety Intel and third-party IP can be swapped in and out for different applications. The company calls this proprietary chassis the Intel On-Chip System Fabric (IOSF). It is analogous to the ARM community’s Advanced Microcontroller Bus Architecture (AMBA) interconnect platform. Other proprietary on-chip bus structures include MIPS SoC-it and IBM’s CoreConnect, to mention a few. These buses have bridging capabilities to ARM’s AMBA bus or the Open Core Protocol (OCP) standard for IP cores (OCP-IP) socket technology.

Leszinske is quoted as saying that the IOSF is a scalable fabric that supports multicore operation and maintains the PCI-bus order. This last item is critical because Intel’s Atom processor uses the PCI bus to connect to the outside world, for example, to provide embedded programmability via Altera’s FPGA core (see, “Intel Teams Up with Altera.”) The popular PCI bus is also an important interface between ARM processors of Xilinx FPGA fabric (see, “FPGAs Move to IP through Processor Interface”).

NoC vs. internal buses
The growing demand for low power and high performance chips is putting new demands on the on-chip IP interconnect architecture. Perhaps that is why many chip companies have migrated from internal interconnect technology to on-chip networks. This approach allows them to protect their legacy IP cores and any proprietary communication features while providing access to third party IP vendors. But how do overall SoC networks, such as a network-on-chip, relate to proprietary buses like Intel’s IOSF or ARM’s AMBA?

Drew Wingard, Sonics’ CTO, puts it this way: “Our principal competitor is internal technology, which is typically derived from either legacy computer buses or the various flavors of ARM’s AMBA specifications. Intel’s IOSF represents such an internal technology, and their press interviews about IOSF make it clear that supporting the ordering requirements of PCI is crucial to them for supporting their large, existing software base.”

Figure: Intel’s hierarchical approach to SoC integration, with separate interconnection fabrics (networks) for Intel IP and most third- party IP.

Processor-centric companies like ARM and Intel need interconnect architectures to grow an ecosystem of third party IP providers. But these providers have widely varying communication requirements that are difficult to manage.

Here is where NoCs can be of great value. As chief architect and co-founder of Arteris, Phillippe Boucard explains that before NoC technology was available IDMs would use hybrid-bus technology to connect IPs to a centralized crossbar, which would then route the traffic throughout the chip. In the past five years, NoC on-chip interconnect architectures began to replace proprietary hybrid bus technology.

“Our NoC IP uses Network Interface Units to convert the ARM protocol into a packetized protocol format. Instead of having a centralized crossbar, the NoC interconnects are distributed throughout the SoC. On top of that, the NoC provides several services, such as security, quality of service, software bring-up, power management, domain management, and so forth.”

There are multiple challenge facing today’s SoC designers. Chips must meet the often-conflicting requirements of low power, high performance, small die size, low cost, low heat generation and development in a very tight time-to-market period. The problem with traditional, proprietary hybrid-bus interconnects is that any change in the IP requires a physical change in the overall system topology, including the buses. With a NoC architecture, only the interconnect needs to be reconfigured.

Complex designs have spurred the growth of design re-use via semiconductor IP. To handle all of this IP, on-chip interconnects had to become more complex. Proprietary internal buses have been giving way to more open on-chip interconnect specifications. NoCs further reduce chip complexity by providing a easily reconfigured communication subsystem between the majority of IP cores on an SoC.

By Ed Sperling
Cadence won a deal with Taiwan-based Sunplus Technology, which has adopted Cadence’s TLM flow for its next-gen SoCs. Sunplus makes chips for TVs, set-top boxes and DVD players.

MIPS won a deal with Loongson Technology Corp.—a Beijing-based company formed through the Beijing Municipal Government, the Institute of Computing of the Chinese Academy of Sciences and the Loongson development team—to use its cores for everything from high-end computing, cloud servers to embedded applications in the industrial control, smart meter, automotive, GPS and mobile markets.

TSMC’s net sales were down slightly again in July—2.9% compared with June and 3.4% compared with July 2010. Of that amount, about 0.4% can be accounted for by Global Unichip, which is no longer included in TSMC’s numbers.

Processor sales appear to be booming. Intel declared a quarterly cash dividend of 21 cents per share. Given that Intel’s stock is trading at about $20 per share, that’s a hefty dividend.

By Ed Sperling
Mentor Graphics rolled out its Pyxis custom IC design platform, signaling that it has fully digested and integrated its acquisition last year of Pyxis, which made AMS routing tools. What’s particularly interesting is that Mentor says the new platform is tightly integrated with 2.5D interconnect parasitic extraction, taking yet another step alongside its role in test to position itself in the stacked die world.  Mentor also unveiled a new program for embedded software development that includes both professional services and a suite of tools for Linux, Android, open-source toochains and user interface product and design services.

Synopsys uncorked the next version of its LightTools for illumination analysis for the lighting industry. The focus will be on lighting and solar designs, which are both rapidly growing markets. Being able to apply advanced CAD tools to these sectors should produce some interesting results.

A standard for sharing memory between two chips, which was jointly developed by Arteris and Texas Instruments, has been licensed by 10 SoC vendors in the mobile and wireless markets. You might recognize some of these names: Intel, Samsung, LG, ST-Ericsson, HiSilicon and VIA Telecom.

Ansys’ proposed acquisition of Apache Design Solutions got a boost when the U.S. Justice Department and the Federal Trade Commission reduced the waiting period for the deal. The acquisition is expected to close next quarter.

TSMC issued its Q2 earnings report. Revenue was up 6.5% from Q1 and 16% year over year (in U.S. dollars). Net income was down 0.9% from last quarter. What’s most interesting in the earnings report, though, is the outlook. The company says the “global economic condition has weakened in the last few months,” adding volatility into the supply chain and impacting the demand for wafers next quarter. Consumer and computer sements are expected to decline while the industrial/standard segment will increase.

By Ed Sperling
MIPS has positioned itself head-to-head with ARM in the Android world, adding yet another competitor. The other one is Intel’s Atom, of course. MIPS stake on this one involves a smartphone that passed the Android Compatibility Test Suite.

Moortec Semiconductor taped out its embedded temperature sensor IP using TSMC’s 40LP and 28HP processes and Synopsys’ custom design solution. Who says analog isn’t migrating down the process curve? Moortec is based in Plymouth, U.K. 8

TSMC’s net sales, which are a good indication of how the semiconductor industry is faring, were down 0.7% from April to May—basically flat—but they are still up 6.3% from last May, which was well into the recovery period. Revenue was up 12.2% in the same period compared with 2010.

GlobalFoundries, meanwhile, swapped out its top leadership team. Ajit Manocha will replace Doug Grose as acting CEO. James Norling will become executive chairman and Ibrahaim Ajami the vice chairman, while COO Chia Song Hwee—former CEO of Chartered Semiconductor, which was acquired by GlobalFoundries—will leave the company in August.