By John Blyler
When most people think of wireless audio applications, they think of a Bluetooth headset that connects to their mobile phone. But a growing segment of the wireless audio market is occurring in the whole home connectivity space, where audio is CD rather than MP3 listening quality. How will this more stringent audio requirement play out in the whole home environment?

Today’s home multimedia systems consist mostly of stationary, line-power, and wired devices – from CD and DVD players to PCs and iPods – and require both devices and listeners stay in the same room. As wireless connectivity spreads to home multimedia system, will the existing wireless technology, namely Bluetooth and Wi-Fi, meet the high performance needs of the stationary devices?

Probably not. “With CD quality audio available in the home, the performance bar for mobile, wireless connectivity has been set higher,” says Ralph Mason, CTO of Kleer.

CD quality audio streams at 1.4 Mbits/sec, while Bluetooth streams at only 350 Kbits/sec, which means a CD quality audio stream must be compressed before it can be transmitted from a Bluetooth radio. Bluetooth uses lossy compression algorithms that discard certain portions of the signal to make meet the streaming bandwidth limitations.

Conversely, Wi-Fi supports fully lossless audio, so it has the prerequisite throughput bandwidth for CD-quality data. Unfortunately, Wi-Fi has a high rate of power consumption. Wi-Fi is being used satisfactorily in mobile smart phone devices, but mobile phone users are accustomed to charging their devices on a daily basis, where home multimedia users are not.

“Power consumption for a typical Bluetooth headphone audio receiver system is 110 millwatts, whereas a similar Wi-Fi device is about 200 mW,” says Mason. “Our Kleer device requires under 30mW of power.” Why so little power? It’s the optimization of the radio, which uses a proprietary wireless design.

Beyond power
Latency is another challenge for mobile audio. Wi-Fi was designed for data networking, which today means primarily web browsing and email applications. However, streaming live audio, especially if that audio is part of a video streams, requires a very small latency. For example, traditional TV video streaming requires 45ms of latency. Above that threshold, TV viewers can perceive the mismatch between the video-video and video-audio streams. Both Bluetooth and Wi-Fi fall short of the latency bar, says Mason.

One of the biggest challenges with wireless connectivity is co-existence. Kleer operates in the popular 2.4 GHz spectrum, which is also home to Bluetooth, Wi-Fi, microwave ovens, cordless phones and other transmitters. How do all these competing transceivers co-exist with one another? Not all that well.

With the largest power transmitter, Wi-Fi chipsets tend to ignore co-existence problems. Bluetooth, with a smaller power signature, uses adaptive frequency hopping (AFH) to detect and avoid competing Wi-Fi signals by “hopping” to a different channel. According to Mason, Bluetooth has 79 1MHz channels. “But if a Wi-Fi transmission is detected, then Bluetooth can shrink down to 20 channels or 20 MHz of bandwidth. Typically, Bluetooth likes to occupy about 20 MHz.”

In contrast, Kleer operates in a very narrow channel of 3MHz. This narrow channel can easily co-exist between three Wi-Fi transmitters operating simultaneously on three different channels. Additionally, Kleer uses dynamic channel switching to quickly move off any channel that is being occupied by a competing Bluetooth or Wi-Fi signal.

Taken together, these interdependent technical features of low power, lossless CD-quality audio performance, and manageable co-existence with other competing devices make this a good example of how system-level design is being used for competitive advantage. Kleer technology an attractive alternative to Bluetooth and Wi-Fi, and it offers pairing and connectivity management; music playback control & music file meta-data forwarding; and a distributed controller function including iPhone/iPod Touch application.

Will these attractive feature sets be enough to win Kleer a significant slice of the whole home audio market? As we have seen in past wireless innovation, good enough often wins out over the better technology. The Kleer “advantage” will depend as much upon market penetration and cost as upon technical performance. Still, having a compelling design can only improve the odds of success.

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 Cheryl Ajluni

In spite of all of its hype, WiMAX is not the only standard causing a stir these days or being called a “killer app.” Another technology that has achieved this illustrious title is Long Term Evolution (LTE), the Third Generation Partnership Project’s (3GPP’s) air interface for wireless access.

Granted, WiMAX does have the advantage of a head start in development, testing and deployment, but LTE is gaining momentum. According to a new ABI Research report, more than 18 operators globally have announced LTE deployment plans, and the tough economy seems to have done little to dampen their enthusiasm. Verizon accelerated its LTE deployment timetable, moving its launch forward from 2010 to 2009. NTT also is likely to deploy LTE in Japan in 2009. By 2013, operators are expected to spend over $8.6 billion on LTE base station infrastructure alone.

The difficulty with these projections is that LTE is an evolving technology (e.g., its MAC and upper layers are still be finalized) and therefore subject to change and interpretation. Specifications for the LTE radio interface are stabilizing, but this uncertainty leaves room for error and further complicates an already challenging design and test process. Nevertheless, chipsets, infrastructure and devices currently are being developed for commercial launch. Much of the pressure for successful development falls to the system-level engineer, who must accurately and cost-effectively design and test for the moving target that is LTE. How can this goal be achieved? Let’s take a closer look.

Understanding the Options

While LTE is expected to offer both consumers and operators a number of key benefits (e.g., lower costs, better services and an increase in data rate with lower latency), the complexity resulting from its use of technologies like SC-FDMA in the uplink, multiple antenna configurations and OFDMA, presents a host of engineering challenges to the engineer. LTE’s variable channel bandwidths further add to this complexity. Challenges also stem from the dependence of LTE system performance on its baseband and RF subsystems, both of which are subject to impairments like nonlinearities, multi-path and fading.

Dealing with this complexity and the resulting challenges is no easy task. As Frank Ditore, product marketing manager at Agilent Technologies points out, “For the system-level engineer working with LTE, or any emerging technology for that matter, there is simply nothing to validate their designs against. There is no LTE base station against which a designer can test their handset design. So, right from the very beginning the engineer faces uncertainty.”

Anritsu offers a solution to this dilemma. Its new MD8430A Signalling Tester is intended for developers who want to verify the operation of a new LTE terminal, but are unable to connect to an actual base station. As a base station simulator, this solution offers the functions needed to test the performance of 3.9G mobile terminals supporting the LTE standard.

What are some of the designer’s other options? The first alternative is to guess. In this case, the engineer builds a device with LTE functionality and hopes the design is correct. If the device was not designed properly, the engineer would unfortunately not realize this until after the design was fabricated. The design would then need to be fixed and fabricated again—a costly and time consuming process and one that’s not likely to receive much support given the current economic situation.

The other alternative is to use early design solutions with algorithms created by a company that’s closely involved with the LTE specification. Granted these solutions and the algorithms on which they are based will not be perfect as LTE is not yet finalized, but they do increase the engineer’s confidence that his/her design is correct. Over time these algorithms will become more mature and the design solutions that employ them will likewise mature, further raising the engineer’s confidence. And, since algorithms used in early design solutions ultimately find their way into measurement solutions, test equipment like signal analyzers, signal generators and network emulators that employ these algorithms also will be mature. Using design tools and measurement solutions from the same company is one way to ensure access to the most mature algorithms.

Agilent Technologies is one company offering solutions that span the entire LTE development lifecycle. In addition to its Advanced Design System (ADS) and the ADS Wireless LTE Library for design simulation and verification, the company also offers a range of pattern generators, logic analyzers, signal generators, signal analyzers, and network emulation and protocol development tools—all of which support early R&D in components, base station equipment and user equipment.

Successful Design And Test

Regardless of which company’s design and test solutions that are used, there are a few key tips for the engineer to keep in mind:

1. Design simulation can be a valuable ally in addressing LTE development challenges and in verifying the engineer’s interpretation of the LTE standard. Its uses are multi-purpose: enabling the engineer to perform system-level trade-offs early in the design cycle to determine design requirements and specifications, and enabling evaluation of the system’s RF/mixed-signal performance by simulating RF and baseband designs together in one simulation environment. Additionally, combining design simulation with test equipment provides added flexibility in addressing testing needs for LTE.

   One solution capable of enabling such functionality is Agilent’s SystemVue 2008 (see Figure 2). This new electronic design automation platform provides an easy-to-use environment with simulator and modeling technologies, along with links to hardware implementation and test. It allows algorithm creation and prototyping for challenging communications system architectures at the physical layer. It also bridges the design flow gap between algorithm developers and the mainstream design community and lowers the cost of ownership by unifying a disjointed flow at an affordable price.

2. For design and test accuracy, select tools from a company with known good algorithms and models.

3. Consider purchasing design automation tools and measurement solutions from the same company, as its algorithms will become much more mature as they trickle down from design automation tool to measurement solution.

4. Foster a close working relationship with the company from whom you purchase design tools and/or measurement solutions. You want to know what your vendor is doing to address changes in the LTE specification and that they are fully committed to making updates to their solutions, as necessary, in a quick and efficient manner.

5. According to Andrew Kodarin, business development manager, Anritsu, another key tip is to “verify that the solutions you purchase are future proof and will preserve your investment.” In other words, ensure that the tools can be expanded to support future developments in the standard and that you won’t have to buy a new solution every time the specification changes.

Summary

There is no denying the current buzz surrounding LTE. Despite this, its true test will come on the first day of its commercial launch, when user’s expectations will be at the highest. How well LTE can meet those expectations will ultimately determine its long-term success. Much of this burden will fall to the system-level engineer tasked with designing and testing LTE devices. While some uncertainty in this process is inevitable given the changing nature of the standard, some tips (e.g., using design simulation with known, good algorithms and models) can prove especially useful in helping the engineer achieve a successful design.

By John Blyler

Chips continue to grow in complexity. This is nothing new. But even at the existing process nodes of 180nm and 130nm, complexity is increasing as designers attempt to squeeze in more feature sets while shrinking the power budget and chip size. This growing complexity, married with the shift to time sensitive consumer product markets has led to an increase in the use of prototypes to verify these chips prior to production.

But what do users really seek in prototyping tools? The report that follows contains the summary and analysis of a survey conducted with more than 270 qualified respondents in the ASIC and related markets. The results track well with similar surveys in this space, but the details present some surprising implications.

Application Markets

Most responders listed the communication market as their primary product area, followed closely by the Consumer, Computer and Other markets (see Figure 1). Most prevalent “Other” markets were Industrial, followed Mil/Aero, Automotive and Medical.

Figure 1

In the category of communications, most respondents listed wireless handsets and wireless and wired networking as their chief application areas, followed closely by wireless base station design, telephony/VOIP and wireless Metro Area Networks (MANs). A small percent listed research, remote controllers, CDMA networks, fixed networks, telemetry and military as other areas of focus within communication category.

In the consumer market most respondents list multimedia designs – involving both video and audio subsystem – as their primary area for developing ASIC prototypes. Multimedia design concerns will be reflected proportionately in other parts of this survey, i.e., processor types, interfaces, etc. Interestingly, several designers listed games as their chief concern. That’s a trend we will watch in future surveys.

Computer design issues were most closely tied to peripherals such as storage, printers and the like. PC and workstation systems came next, with others including prototyping systems, servers, data acquisition modules, and instrumentation and software/firmware design issues.

Job Function

Most of the respondents identified themselves as ASIC or ASSP designers, followed by engineering management, corporate management, verification engineers, system architects and software designers. A small percent of users listed their function as applications engineers, business development, academia and sales/marketing.

Figure 2

ASIC/ASSP/SOC Design Details

When asked to describe their current ASIC/ASSP/SoC design, more than half of the respondents indicated a design size of less than 5M gates, with that majority below 2M gates.

In terms of memory, most designers focus on SRAM memory, suggesting the strength of on-chip memory prototyping. Still, DDR and Flash memory account for about 22% each of memory usages.

Embedded processors usage is led by the MIPS processor, which matches up with the respondents’ applications markets. ARM, Tensilica and Intel comprised roughly 16% each of the remaining usage. Other processors used for ASIC prototyping ran the gamut from microcontrollers like the 8051, Microchip’s PIC and Xilinc’s MicroBlaze to proprietary cores. A large number of DSP cores also were cited, including Ceva Teak Lite, TI and in-house multimedia DSPs.

To the question concerning the types of external interfaces used in ASIC prototyping projects, the top three busses were PCI, USB and Ethernet. SPI, SATA, XAUI and HDMI finish up the lower quadrant. Though not listed in the survey, questions have arisen about the use of the PC-104 bus. Several experts believe PCI Express represents the path forward for PC-104. This projected growth will be the subject of a future survey.

The majority of users listed Serial RapidIO (sRIO) as the main external bus of choice under the “other interface” category. This is no surprise, since the sRIO interface is commonly used to connect multiprocessor designs, especially for DSPs. This tracks well with the use of DSPs highlight in the “Processor” usage category cited earlier. Other interfaces include I2C – a low-speed serial bus used to attached peripherals to a motherboard, embedded system, or cellphone; DVI, RS-232, parallel bus, CAN – automotive bus, DigRF – digital serial interface for 3G air standards; and even UART.

Re-spins

A little over half of the respondents indicated their previous design project required no re-spin. Of those acknowledging re-spins were necessary, 50 percent stated that only one re-spin was needed. About half as many reported by two re-spins were required and slightly less than 10 percent admitted to three re-spins.

The main reason for chip re-spins was the presence of logical and functional errors. This result tracks well with other recent studies that indicate more than 60 percent of re-spun ASICs fail due to logical/functional errors, not because of timing or power issues. This means that functional verification is now the most critical phase of the chip development cycle.

Figure 3

Verification Environments

When asked what type of verification was used for a current project and planned for future work, the largest groups of respondents selected Mentor’s ModelSim/Questa. This was followed by Cadence NC Simulator and Synopsys VCS.

Figure 4

Other software simulation environments consisted of tools from IBM, Altera’s QuartusII and Xilinx’s ISE, Synplicity’s Synplify, Dolphin’s SMASH and Catena’s Analog and Mixed Signal (AMS) Simulators, Aldec’s Active-HDL Simulator and homegrown systems.

In terms of emulators, most users listed Cadence systems, followed by Mentor and Eve. An interesting side note is that only Eve emulators saw a planned increase for future projects. Formal verification favorite was Formality, followed distantly by OneSpin, Real Intent and Certess. System Verilog lead the way in Assertion-based tools, followed by OVL and PSL.

Here’s where the results get interesting. When asked what type of virtual prototyping environments were currently being used, ARM was the favorite – but by a decreasing margin for future projects. Synopsys’s Virtio was the second most popular choice, showing projected growth along with CoWare, VaST and Virtutech. One should exercise caution when interpreting these results, since the slower pace in usage of ARM tools may simply reflect the growth of virtual prototypes in non-telecom related industries.

Figure 5

Looking at the other end of the prototyping spectrum revealed that Synplicity was used more often for ASIC prototyping with FGPA-based systems – at least in the market areas highlighted by this study. ProDesign followed second, then came Dini and Gidel. It must be noted, however, that 36 percent of respondents still used custom-built FPGA-based prototyping, though the percentage was on the decline for future projects. This marked decrease in custom-built systems may attest to the growing complexity of ASIC designs and hence the corresponding complexity of FPGA prototypes.

Conclusions

This survey points to the changing dynamics in ASIC prototyping tools and methodologies. Prototyping of specific blocks on an ASIC core now seems mandatory, especially since ASICs continue to increase in design complexity. This complexity is manifested by an increase in logical and functional errors in the chips, which has resulted in a need for more complete verification tools and methodologies.

But prototyping itself has taken on a new dimension with the advent of virtual prototypes – used more often by software designers – and FPGA-based prototypes used by chip hardware engineers.

These trends have been confirmed by other studies. For example, Aberdeen’s “Best in Class” study cites verification as one of the most prevalent concerns in chip companies. Chip Design Trends reports, which tracks ASIC pre-silicon architectural trends, confirms the growing complexity of ASIC chips – at all levels of design metrics. Contrasting this complexity with the continued decrease in ASIC starts suggest that ASICs may be getting larger in size though less numerous in unique projects. All of these trends support the growth of prototyping as a key element in future chip designs.

On the business side of the equation, one should note the shift away from corporate electronic expenditures to the rapid increase in consumer’s consumption of electronic products. The consumer world is outpacing the corporate world in the purchase of electronic goods, but there is a caveat: Consumer electronics have a shorter time to market, high product volume but lower cost per unit that corporate electronics. What does this mean to chip designer? It means that they must find a way to reduce ASIC re-spins, such as with ASIC prototyping.