By Ed Sperling
System-Level Design sat down with Frank Schirrmeister, director of product development in Synopsys’ solutions group; Ghislain Kaiser CEO of DOCEA Power: John Sanguinetti, CTO at Forte Design Systems; Vincent Perrier, Cofluent Design co-founder and director of products and marketing.

SLD: Where do models fit into the standards world?
Perrier: Models are becoming the central things that engineers work with. But it goes much further than just translating the code into gates on the chip. There are power models, performance models and virtual platform models. It can be a custom-based approach by aggregating multiple IP blocks or a top-down approach starting from a functional or architectural description or a power model. These are very different approaches for designs.
Sanguinetti: There’s a lot more impetus to settle on a standard when you have models that people want to use from different sources.
Perrier: The whole point of models in ESL is to make sure those models work together.
Sanguinetti: Right, but those models are coming from different places.
Perrier: There also are a lot of them. Today you cannot find one model to represent all the different facets of a design. If you want a full picture of a system, you need to get all those models together, combine them, and simulate them so you can make your architectural tradeoff decisions on the basis of power. Power is becoming as important as everything.
Kaiser: The first goal for a system now is to improve interoperability because of all the complexity. You need to adapt that for every domain. That’s the case with power and timing.

SLD: Whenever a company turns over technology to a standards group, they have a jump on everyone else because they know the technology better. Is that window shrinking or growing?
Sanguinetti: It depends on the technology. If you need a standard to make models interoperate, no one has a big advantage.
Schirrmeister: It’s not a complexity issue. That’s solved according to how a design process is structured. The standards support that structure. If you look at the next big systems on chip, you have blocks in there and you need to be able to deal with those blocks. That includes development of the blocks, which is where high-level synthesis comes in. You need standards for a language that you can use to synthesize. You need to be able to deal with re-use of those blocks. That’s where SPIRIT comes in. You characterize those blocks and give them power formats. And then you need to integrate those blocks into the full chip. So you need the higher-level model for verification and for performance analysis, which is where TLM simulation comes in. It’s not that complexity influences the window. It’s that the complexity changes the design process, and for the different components you have individual windows on how to deal with this.

SLD: How far along are we with this?
Schirrmeister: With TLM 2.0, it’s like we’ve standardized on the VCR with VHS, but all the remotes don’t interoperate because everyone has different controls. That’s the next thing we’re trying to standardize on—the configuration and control of those TLM models. Those standards grow and build on each other.
Perrier: The EDA industry has a lot to learn from the software industry in this domain. They are way ahead of us in this area because they have been dealing with interoperability for a long time.
Schirrmeister: They have been dealing with this problem since 1968, and the last time I checked they still haven’t figured it out. But there is at least some interoperability in the software world. I assume you’re talking about UML (Unified Modeling Language).
Perrier: UML is one. There are also meta-model techniques. IP-XACT is an XML-based standard. In the software world you have Ecore, which an Eclipse implementation of the [Object Management Group] standard.

SLD: The software world has its own issues that have been going on for decades, most notably in operating systems, interfaces and parallelization.
Schirrmeister: And I’m not sure what we’ll actually learn from the software side. In the software world you have a company like Microsoft saying, ‘Here it is,’ and everyone has to deal with it. The same was true with UML for awhile, where Rational and Telelogic were dominating the market.

SLD: But isn’t this still a top-down definition?
Schirrmeister: Everything does need to fit into a top-down model, but the work is being done in two directions. The problem is that it’s like digging a tunnel from both sides where you don’t meet in the middle. You’re pushing down with high-levels of abstraction and UML is tunneling up, but they don’t quite meet. Now we are trying to figure out ways to see how UML will fit.
Kaiser: This is the challenge of the ESL domain. But if a new standard appears, there is a question of whether it will survive because it has to join these two worlds, from UML to hardware constraints.
Schirrmeister: When you talk about standardization, it’s always about restriction. You have this big item about what UML covers, and conceivably you can develop a profile of UML that may fit into something that will be able to synthesize down to RTL. That’s like a UML for hardware profiler. If this is SystemC, there is a subset that is synthesizable. The same happened with Verilog in the past.
Perrier: The software industry calls this domain-specific languages.

SLD: So is UML the answer?
Kaiser: I’m not sure that today UML can respond to the hardware constraints. We may have to modify UML because it was not created for hardware.
Schirrmeister: A standard never does something for itself. You always have to have a user need. Hardware developers are not that concerned if something is UML compliant. They have a very specific need to get to a virtualized model of the embedded hardware they’re developing as fast as possible so they can start software development. If my solution happens to be that I have a technology that takes UML, restrains it to a domain-specific subset and then allows a fast implementation, they will happily adopt it because it serves their need. But they won’t do it because it’s UML.
Sanguinetti: That’s a very relevant point to this discussion. Back when Synapse was working on a precursor to SystemC, I looked at UML. It was too far removed from the kinds of problems we were looking at.
Schirrmeister: I think we are getting closer. It’s just a question of how fast is the train going.

By Ed Sperling

What do you do when you can’t fit any more functionality on a chip without blowing your power budget?

That question is being debated inside IBM right now, and one of the more radical concepts is to actually have systems do fewer things.

“That trend will happen,” said Brad McCredie, chief architect of the Power6 chip and an IBM Fellow. “I think devices will become more specific. But there is great debate about this right now.”

McCredie said that if devices can do 80% of what’s now done on a desktop or by an existing device more efficiently than a device that does everything, then it can be a big winner in the market. “If it does 10%, no one will ever write a line of code.”

That may be the only way to actually stay on the Moore’s Law road map of delivering twice as many transistors on a piece of silicon coupled with the unwritten corollary to Moore’s Law, which is that performance will double as well. While companies such as Intel and IBM don’t trumpet their performance gains anymore, most customers still see performance as one of the main reasons to buy new equipment.

Exactly what process node this occurs at is unknown. With the number of challenges increasing at each node—engineers now must solve multiple problems instead of just one—solutions are coming at a systems level instead of a chip level. That means rethinking a device from the top down as well as the bottom up.

“At 22nm or 20nm, there will be a discontinuity,” McCredie said. “This will happen at both the transistor and the device level. The industry has been fueled by density. We integrate multiple chips into a single chip and multiple computers into a single computer. But at 20nm, you can’t do that anymore. You need everything from stacked dies to 3D transistors.”

By John Blyler

As multicore technology moves into the embedded systems, software developers face tool shortcomings, legacy code preservation and scalability challenges.

Max Domeika , an embedded tools consultant in the Software and Services Group at Intel, explained that one of the biggest challenges facing embedded system software developers is the growing number and types of multicore processors. “There are so many different cores with varying capabilities even within a given architectural family of processors, not to mention virtual enhancements like hyperthreading techniques, which enable a single core processor to look like two cores to the operating system.”

Hyperthreading is based on “out of order” scheduling of a processor in which the incoming code instructions are identified early enough so they can be executed in parallel. From a programmer’s viewpoint, it looks like you have two different processors, even though you are sharing many of the same resources, such as execution units and memory caches. It gives the programmer more options, but it is not the same as having two distinct cores as in a multicore environment.

Why are embedded designers upgrading to multicore technology? Many have found that the use of multiple processor cores reduces system latency or delay. “If you have latency sensitive applications – even something as simple as a user interface – you can spawn threads with reduced latency,” notes Domeika. Threads, or a collection of related code segments, are at the heart of multithreading paradigm, which allows programmers to design software applications whose threads can be executed concurrently.

Scalability is one of the biggest obstacles faced by embedded developers who want to or must use multicore systems. “You may ship with a two-core architecture, but the next revision of the product my have four cores. This means that you want to create your software in such a manner that it scales with as little effort as possible,” Domeika says. Many developers have found out the hard way that a system hard-coded for a two-core architecture must be completely rewritten to run on a four-core system. This translates to additional product cost and a longer time to market.

To accommodate the next product revision, a programmer has to look at all of their routines and figure out how to re-partition the executions among an increased number of processors.

At the heart of the scalability question is the balance between different types of available parallelism.  Besides multithreading, another means of providing for parallel execution is through the use of Single Instruction – Multiple Data processing.  Intel’s implementation of SIMD instruction is embodied by its Intel SSE instructions.  Another example of SIMD instruction set processing is AltiVec, used by the PowerPC community – namely IBM and Freescale.

"In many ways, it is still left up to the programmer to decide how best to balance the amount and type of parallelism to be used. Programmers must think about what happens at the tread level for a shared memory machine, the process level, and also the SIMD vector level. This is a very hard problem," notes Domeika.
Scalability and parallel implementation issues help to reinforce the need for better development tools and environments. One way to address these needs is through standards and automation. In the multicore space, several companies – including Intel – have worked on a standard called OpenMP which enables concurrency on shared memory machines. One challenge with using OpenMP in the past was balancing parallelization operating on multiple cores and parallelization available through use of SIMD instruction sets.To address this challenge, the Intel Compiler recently added support for automatic vectorization inside of OpenMP pragmas, which are used for compiler control. Automatic vectorization is a technique that transforms a series of sequential operations into operation performed in parallel. Hence, automatic vectorization analyzes the code to take advantage of SIMD instructions, while working within the OpenMP environment to balance different forms of parallelism.

All of these advances are great. However, for many embedded software developers, the main issue is how to preserve their legacy embedded C code while still upgrading to multicore technology. “Most customers that I talk with are interested in new technologies like multicore but are more interested in preserving their business, which means their 10 million lines of legacy C code,” explains Domeika. “That is why I’m one of the co-chairs—along with David Stewart, CEO at CriticalBlue —of the Multicore Programming Practices (MPP) Group. The charter of the group is to collect the best known methods of programming practices using today’s technology. For embedded developers, that means C/C++ and libraries, mainly POSIX threads.

Such cooperation among embedded software developers will be critical for the continued growth of multicore technology. As in the desktop world, embedded software is the last – but certainly not the least – component necessary for a successful system.

View the video interview with Max.

David Patterson, Professor of Computer Science at UC Berkeley, presented his views to the Naval Postgraduate School about the prospects for multicore programming success. This video was excerpted from his presentation.

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.

Independent investor Jim Hogan talks about where the real value is and what companies need to do to survive in a changing market.

By Cheryl Ajluni

Software as a Service (SaaS) is not a technology. It is a software deployment business model where an application is hosted as a service that is provided to customers across the Internet. Thanks to success stories from companies like Google, Salesforce.com, WebEx, and TurboTax, among others, this business model has become quite popular and is now even being looked at by some EDA vendors and system-level design engineers.

The central question is this: Can the SaaS business model ease the burden of chip design—especially for those designers at small to medium-sized companies faced with constrained budgets and resources? Let’s take a closer look.

Why SaaS, Why Now?

To better gauge the viability of the SaaS model for Web-based delivery of system-level design tools it is important to first understand why the model has been such a success. Why would customers prefer to use an application hosted as a service on someone else’s server, rather than use an application running on their own premise? The answer to that question is fairly straightforward and stems from the five key benefits often associated with SaaS, including:

• Low cost — Customers “pay as they go” for software and only for as much as they need.

• No required infrastructure — Because the customers’ information is stored in a central location hosted on the SaaS vendor’s server, no infrastructure is required at the customer premise. This reduces the up-front and ongoing expense of software deployment and alleviates the burden of ongoing operation, maintenance and support.

• Scalability — With its “pay-as-you-go” model, SaaS offers a scalable environment in which software applications can grow with the customer.

• Low investment risk — Because the applications are paid for as the customer uses them, financial risk is reduced. When the customer no longer needs the service they simply stop paying.

• Easy collaboration — Since Web-based applications allow customers to save their information on the Internet, it can be easily accessed anytime, anywhere—greatly easing collaboration between geographically disperse team members and increasing productivity.

While the benefits of SaaS are compelling, they would mean little to the design community were it not for a few relevant factors. To begin with, the Internet and security technologies (e.g., broadband access) necessary for making SaaS successful are now readily available. In addition, a changing market is driving designers to look at the design process in a new way. The current state of the economy, for example, is forcing many companies to reduce spending. Instead of buying “best-in-class” tools, some are opting to buy solutions that work “good enough.” Globalization of the design team is another way in which the market is changing. Design teams are today comprised of geographically dispersed members, making collaboration between team members a dicey proposition.

The cost savings and productivity benefits offered by the SaaS model now offer a viable means of addressing these challenges; especially for small to mid-sized design houses. Unlike large design companies with their well-established infrastructure and fully amortized system-level design tool purchases, smaller companies tend to have minimal infrastructure in place and are therefore more open to benefits of the SaaS model. Larger companies may also see its value, but typically not unless the situation warrants a re-examination of their existing infrastructure (e.g., when opening a new office or moving to a new geographic location).

SaaS In Action

Despite the challenges facing the design community and the benefits that SaaS offers, many wonder if the design community is really ready and willing to accept this model. One company that believes the answer is yes is Cadence Design Systems, which launched the Hosted Design Solutions) for just that reason (see Figure 1). As the first SaaS solution for semiconductor design, Hosted Design Solutions provides designers with IT infrastructure and design compute, storage and secure networking capabilities, as well as access to the design capability, including the software encapsulated in packaged design environments. Leveraging the SaaS delivery model, the Cadence offering delivers location-independent support, access to worldwide Cadence expertise and a secure collaboration infrastructure.

Figure 1. Cadence Hosted Design Solutions came about as a natural evolution to its advanced collaboration infrastructure—a solution deployed more than seven years ago to help its services clients leverage Cadence expertise and decrease risk on their production designs. Hosted Design Solutions combines this service with the SaaS infrastructure.

Cadence’s Hosted Design Solutions is not the only foray into Web-based services for the design community. Virage Logic also is making good use of the Internet by allowing customers to evaluate its Intellectual Property (IP) online and by providing them access to the Integrator Online product. Integrator Online provides customers with all the information they need to understand, for example, what types of memories will be required to achieve a specific system performance or area, all before any memory has even been purchased.

Synopsys also offers Web-based functionality to its customers to ease collaboration among geographically-dispersed team members. Its transaction-level models, for example, are available in Internet-accessible libraries. Customers simply purchase tokens, which can be used to check out specific models as needed. Additionally, the company’s combination of virtualization and hardware prototyping tools provide customers with remote access (see Figure 2). A virtual platform executes embedded software on the virtualized target’s embedded hardware as a fully functional model on the developer’s workstation 9 to 12 months before silicon is available. Once RTL becomes available and is stable, the virtual model is connected using transaction-level interfaces with a hardware prototype. Since the connection can be made using networks, the software developer need not be in the lab where the hardware prototype resides. The developer can also attach devices like USB memory sticks to the virtual platform, which can be remotely accessed by the target hardware prototypes behind the network.

Figure 2. This graphic illustrates how the combination of Synopsys’ virtualization and hardware prototyping solutions enable remote access.

The Other Side of The Story

While there is no denying the cost and productivity benefits of SaaS-based applications, there remains no firm agreement in the EDA community on the value of using this model to deliver sophisticated design flows. According to Mentor Graphics, one reason for this is that despite a changing design market a fundamental issue remains: Is design a core competency? As a company spokesman put it: “If design is a company’s core competency (whether large or small), they want to control the design environment. Customers who care about design care a lot about the tools they use. If design is not a core competency, then why design at all? Instead designers could simply take off-the-shelf components and add their value at the application level.”

Another challenge for SaaS in system-level design may be convincing system houses to give up control of their information. This challenge may prove formidable as some years ago vendors tried unsuccessfully to offer design tools over the Web. One reason for this failure was that designers simply did not want to give up control of their design information by storing it on a server that might be susceptible to security breaches.

Cadence agrees that security remains a key issue these days, but it also points out that security solutions have improved dramatically over the years. For that reason, its Hosted Design Solutions is a Class 3, ultra-reliable and redundant solution. In some cases, that level of security is higher than what some of its customers have in house. Cadence also adds that when customers are looking to reduce risk and cost, outsourcing the elements of the design environment that are non-differentiating but critical is a key place to start.

The Final Word

The SaaS model, bolstered by offerings like the Cadence Hosted Design Solutions, is now making its move on chip design. With the technology ripe and the design community facing a changing market, this model may finally have found a compelling enough reason to make it acceptable to designers. There is obviously no way to ascertain how the design community as a whole will greet this business model, but one thing is certain, the changing market is forcing the design community to consider lower cost, higher productivity design tools—two areas where SaaS has proven itself strongest.

By Ed Sperling

Most of our weather predictions are developed from about 150 stationary government radar systems, which interlock and occasionally overlap to create a cohesive picture. The picture isn’t perfect—in fact, it’s probably the equivalent of looking at a large, grainy satellite photo—which creates plenty of wrong forecasts. But the system can track large storms across state borders and, in many cases, well into the ocean.

Getting insights into the inner workings of storms and how they are affected by a number of variables is generally left to amateurs, who have devised their own technology—sometimes crude, often innovative—to look into the center of hurricanes and tornadoes. But getting an up-close, crystal-clear look into the center of the beast, and being able to repeat that experience with consistency, has been impossible.

At least it was impossible until a piece of government radar fell into the hands of the Naval Postgraduate School in Monterey, Calif. The radar originally belonged to the U.S. Army and was being used for mobile air defense. While it was considered outdated for military purposes, it proved to be incredibly advanced for scientific research. Weather researchers don’t typically acquire a $2 million piece of military radar for chasing storms.

“What we’ve been doing is casting versus forecasting,” said Jeffrey Knorr, professor and chairman of the Naval Postgraduate School’s department of electrical and computer engineering. “We thought we could use this for atmospheric science. This is a phased array, and it’s the only mobile phased array in existence.”

It became mobile when Knorr and his team mounted it on the back of a flatbed truck, added a diesel generator and developed some software programs to take advantage of the radar in real time.

“The National Weather System radar is a high-power S-band system, which is a parabolic antenna that basically can scan 360 degrees. There’s a clear-air mode and a precipitation mode, but it takes time to develop an image in 360 degrees. It’s about 5 to 6 minutes for a precipitation scan and about 10 minutes for a clear-air scan. With mobile radar, you can get the same data but you don’t have to scan 360 degrees. It’s all programmable from a laptop, so you can take a phased area and make it frequency agile,” he said.

The shape of things to come?

Weather radar can measure how hard it is raining through reflectivity, which includes the number of raindrops and the average velocity. It also can measure spectral spread of the precipitation, which includes turbulence and wind sheer, which is useful in measuring rainfall rates and predicting flash floods. But the speed of updates is a problem for making fast and accurate predictions.

Knorr’s system allows updates every 5 to 10 seconds through the addition of a high-speed digital signal processor. But it does more than that. Most radar is horizontally or vertically polarized. His team added a third axis, so instead of just seeing how hard it is raining and how many raindrops there are, it can measure the size of the raindrops. The larger they are, the flatter they are, which makes it impossible to pick up using ordinary polarization.

“What we’re able to measure now is the storm velocity, reflectivity, motion toward or away from the radar, and the gray area, which is zero radio velocity,” he said. “We also get a higher-resolution picture. Radar spreads as it goes out, so a 1 degree beam width has a certain cross-range resolution at 1 mile. Shorter-range radar has higher resolution.”

This is particularly important in tracking the path of tornadoes, which have a signature characteristic on weather radar. When weather experts look at a radar image, they can identify this signature and predict that tornadoes will form. What they can’t do is refresh the image frequently enough and look inside with a better image. That requires radar to be much more mobile, quicker and much more accurate.

Just imagine what happens when the guidance system on the International Space Station goes on the fritz and the entire lab begins doing somersaults through outer space. Then the solar panels no longer work and the communication system fails, and suddenly you understand how serious system-level design problems can become. Ret. Capt. Daniel Bursch recounts the incident from the safety of the Naval Postgraduate School in Monterey, Calif.