By Ed Sperling
Synopsys’ Karen Bartleson points to an important—and prematurely short—video from Colin Warwick, a signal integrity expert at Agilent. It’s required watching for anyone working in the SoC tools world—not to mention anyone attending DesignCon this week.

Mentor’s Thomas Bollaert looks at the impact of corporate cultures at Apple and Samsung and what happens when you add automated tools into the process. It’s an interesting idea, and one that deserves much more attention.

Apple seems to be on a lot of people’s mind this week. Cadence’s Jack Erickson looks at what went into Apple’s iPad. Details of this device keep leaking out, which is only fueling the interest over the iPad itself.

Daniel Nenni advocates a close partnership between EDA, foundries and IP providers at 28nm and beyond. He’s right on the need, but it doesn’t appear that all the players view themselves on an equal playing field.

Apparently not everyone sees the foundries equally, either. John Cooley’s blog looks at TSMC yield issues at 40nm. Are they real? It depends whom you ask and when you ask them.

Can there ever be a simple solution for mixing analog and digital on the same chip? Synopsys’ Navraj Nandra tackles that question with a look back at Henry Ford’s famous saying, “Any customer can have a car painted any color so long as it is black.” For anyone who’s been to Berkeley, Cheese Board Collective’s pizza seems to have followed Henry Ford’s model with a single flavor each day. It doesn’t seem to work in system-level design, though, where priorities are sometimes incompatible.

Mentor’s Colin Walls peels back the covers on one of the best-kept secrets in software programming—most of the time is spent in maintaining code, not in writing it. It’s a great look at why code needs to be written extremely clearly.

Cadence’s Steven Brown examines the entry points for companies using transaction-level modeling, which is a basic building block of ESL, and what are the likely phases for widespread adoption—in great detail. It’s an interesting perspective.

Synopsys’ Frank Schirrmeister looks back on a decade of technology change and the looming war clouds in 2000 between SystemC and System Verilog. Has much changed? Well, not really, but at least no one is calling it a war anymore. Who has time?

Mentor’s Steve Collis has discovered a major flaw in a device that was designed to monitor energy usage. Its batteries don’t last very long. So much for low-power engineering.

And finally, there seems to be an interesting crossover underway between blogging and cartoons. Check out this week’s entry from Synopsys’ Srivatsa Vasudevan. He may be onto something.

By Ann Steffora Mutschler
By now, semiconductor design abstraction is old hat to many engineers, but mention the term “semiconductor test abstraction” and expect a blank stare in return. Design complexity, enormous design size, and short market windows have put tremendous pressure on test to occur earlier rather than later.

Even at the RTL level, where hardware test typically has not touched, the name of the game is reliable predictability. If testing of circuitry doesn’t happen until the gate level when the final connections happen, big bottlenecks occur. For this reason, vendors in the hardware test equipment as well as in the EDA space are looking now at ways to connect design and test closer than ever.

While the term ‘abstraction’ is used with regard to both design and test, how it plays out in those spaces is very different. However, Robert Ruiz, senior product marketing manager for test automation products at Synopsys, pointed out there may be a few corollaries between the two.

“First of all, [test abstraction] is something that’s not done by the majority of users, and because of that the term isn’t interpreted by everybody equally,” Ruiz said. “For the design engineer, what the abstraction could refer to in terms of a specific flow is that there are models using the IEEE 1500 standard that can describe the test attributes and specifically the scan chain in a design. Abstraction of test for a designer who is implementing the design and focusing on its function, he just cares about having some way to carry over an abstraction of the DFT part, and that helps in multiple ways. One is that it hides all the unnecessary details to the designer. The second thing is that it helps with file management and tool performance so the tool doesn’t need to carry around larger netlists describing the scan chain and the other DFT information.”

Mark Chadwick, product marketing manager, for Mentor Graphics Corp.’s Silicon Test System products said that testing at different levels—be it the wafer level, the package level, when it’s in a circuit board, when it’s in a system, when it’s in the field—can all be thought of as different levels of abstraction. “However, unlike the term, the type of test we do is still down to a structural level, meaning, in terms of scan test or memory BIST, the function is not tested but by a process of testing every individual device/component/atom, we do test the whole chip.”

Ruiz noted there are certain things for test that can be done at the RTL level, but ultimately to generate high quality manufacturing test patterns that capture every single defect, the test generation program has to understand the structural connections—basically the gate-level view.

“There are a set of things that can be done at RTL, but not everything,” Ruiz said. “Nonetheless, it feels like we’re at a point where not most, but some, designers with very forward-looking glasses are thinking about what can be moved upwards beyond the gate level to the RTL level. In looking at that, there are a couple of different things. One is predicting what kinds of problems could occur if DFT is put in. Another, still in exploratory stages, is instead of going through the entire design flow and finding out what my fault coverage is and how much tester time and how much test data I have, what if I could do some prediction at RTL? Prediction at RTL is for a lot of these test engineers is abstracting test.”

Outside of EDA, abstraction also could be applied to test development and could mean that instead of looking at ones and zeros, and defined analog waveforms that are applied to the chip for test, what if this were abstracted?

“With this perspective, knowing my set of tests that just test the core, or a set of tests for the analog parts, I can therefore be more structured about the test development program,” Ruiz said. “Test development programs are an area where some of our largest customers invest a lot of resources, more than the investment in DFT/ATPG.”

Conversely, from the test hardware point of view, John Wiedemeier, product marketing manager at LeCroy, said that when his company started off 15 years ago things were very complicated and getting equipment to talk together was extremely painful. “We’ve changed quite a bit and introduced what we think is a standard for looking at protocols,” he said. “Our company is all about decoding protocols and understanding communication between devices and hosts. In the beginning, an engineer was looking at an oscilloscope screen full of ones and zeros. As things became more complex with digital design, the logic analyzer came out to solve certain problems and was a new interface. That was a monumental effort. Then someone thought, what if we could decode these ones and zeros, and so there were some rudimentary logic analyzer to decode the ones and zeros into numbers. They took it up a notch. But in the process, they were able to do some things but stepping aside and not doing what their core competency was.”

It was about that time that LeCroy came out with a protocol analyzer, a step above a logic analyzer. “We’re no longer just decoding ones and zeros into numbers but we’re now actually giving great detailed information about what a protocol looks like,” Wiedemeier said. He noted that if you read a book on the protocol, you were able to look at the pages and the tester screens and understand what was going on. There’s no longer the idea that you have to know anything about analog to do the software work and programming. It has gone a step above that to encompass putting the book into the tool and having the tool tell say what the book says, and now even to where a button can be pushed and the tool say what is wrong and how to fix it.

“It is much friendlier to the software engineer and gets away from only geniuses reading the waveform,” Wiedemeier said.

Connecting Test with the EDA Realm
While not an obvious connection at first glance, Frank Ditore, product manager of Agilent EEsof EDA in the Wireless Business Unit at Agilent Technologies, pointed out that the EEsof EDA tools do link with Agilent’s measurement hardware, and some recent work with software- defined radio (SDR) does apply here.

“First off, it’s not necessarily a well-known or well-documented fact, but Agilent (when it was Hewlett-Packard) was probably the pioneer in SDR architectures simply because we were developing instruments that needed to be scalable and reconfigurable. In fact, in the late ’80s and early ’90s we developed a new hardware measurement system that was called a vector signal analyzer—the first of its kind on the market. It literally was a software-defined radio. This allowed the engineer to take a firmware upgrade, which basically updated source code for embedded processors, so the instrument could be reconfigured to demodulate IS-95 CDMA or DECT or any of the digital communication protocols that were available at the time. Even before some of the more industry-notable names in software defined radio starting coining the term ‘software defined radio,’ we were actually already kind of doing it. Today, if you look at Agilent hardware measurement platforms, they are almost entirely software-defined instruments being that they are scalable, digital signal processing engines made up of FPGAs and embedded DSPs; they typically are built around a Windows PC framework (although that doesn’t cover every one of Agilent’s products) and the hardware is scalable so you can continue to increase the amount of horsepower you need for different applications by plugging in new application cards into the instruments,” he said.

Those are basically software-defined radio platforms because they allow Agilent to take an instrument and apply it to a number of different protocols without redeveloping the hardware.

“This fits into test abstraction in the context of standardized operating environments for SDRs,” Ditore said. “There are a number of operating environments, with the leading one being the Software Communication Architecture (SCA) Operating Environment (OE) standard, provided by a number of vendors for use in the armed forces Joint Tactical Radio Systems (JTRS) or commercial systems. In the radios that support SCA, the actual physical layer becomes transportable if it is also SCA-compliant. What we’ve been talking about internally is how to abstract test to create SCA-compliant test algorithms that would go into our instruments (assuming they were SCA-compliant) as well as user hardware that is also SCA-compliant so that you can actually build test right into your product.”

While not a commercial product, it fits well with how Agilent’s tools are architected, he said. For instance, SystemView, Agilent’s ESL tool, can be used to architect physical layer signal processing and analog RF algorithms either as arbitrary waveforms or an executable hardware description in VHDL, Verilog or C++ and export it into a piece of hardware.

As such, it can be used for design, or to define the test algorithms, and has the potential to save engineering teams a tremendous amount of time, he believes.

“If you look at traditional IF/RF designers, whether they are designing MMICs, RFICs or just standard RF boards, they typically design with continuous wave (CW) metrics in mind – what’s the gain, what’s the noise figure, what’s the output IP3 – but typically they don’t think about the higher level system metrics like what the error of vector magnitude is, what the ACPR is, what the co-domain power is, what the cross-domain leakage is between co-domain systems. They don’t necessarily think in high-level time domain metrics, so by providing these virtual test environments in a simulation environment you can actually connect your analog and RF processing to a test harness that actually does that. Typically the types of things you would do once you prototype hardware you’re actually doing in simulation while you are designing, while it is still cheap to make changes. A change is a tweak in a parameter, it’s not a respin of a mask,” he added.

What’s next?
For customers working intensely on I/O engineering for add-in cards and optimizing performance in the end system, industry sources believe there will be more integration of test tools with pre-silicon design engineering teams to allow feedback earlier in the design process. This is expected to materialize with tighter partnerships between EDA and traditional tester companies in the not-too-distant future. As the saying goes, stay tuned.

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.