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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

By Ed Sperling

Santa Clara, Calif.—Feb. 5, 2009—Cross-cultural communication has always had its challenges, but globalization is raising it from the level of nuisance to necessity.

Across the board, from systems companies to those that develop the tools to build the components that go into those systems, building international teams that can embrace a single corporate culture has emerged as one of the big business challenges.

“The main learning about having different sites around the globe is respecting the culture of where that site is,” Rich Goldman, vice president of strategic alliances at Synopsys, said during a panel at DesignCon. “Engineers are the same around the world, so there is a certain level of communication that always works. But at another level, cultures are very different. What you may think is the worst thing possible is a normal part of culture for another country. You have to go to that country to experience it. That’s the only way to overcome differences.”

And overcoming those differences is essential. Cisco’s vice president of engineering, Sri Hosakote, said globalization is a core competency of every company that does business in a global economy. “It’s a skill that is mandatory,” he said.

Hosakote said one of the keys is getting employees in other countries to understand the corporate mission the same way employees do in a place like Silicon Valley. That frequently requires bringing managers to the United States, letting them sit in on meetings and work in Silicon Valley and sometimes even enrolling them in executive courses at schools like Stanford. He said when that happens, “they get it.”

“It takes two to five years to get a culture of globalization,” he said. “Collaboration is the hardest piece. It’s particularly hard when it comes to multiple sites.

But there’s more to operating in a global environment than just a common vision. There also has to be an efficient structure everywhere. Brani Buric, executive vice president of marketing and sales at Virage Logic, said that for every situation—whether the operation is located in a place where labor is cheap or expensive—the office has to be optimized.

“What we’re seeing with globalization is just the first phase,” Buric said. “A couple of years from now this will go way beyond product engineering and R&D. New markets are opening and we will see good product specs for markets in places like China. There will be R&D, specs, marketing, implementation and a sales channel in these places.

One facet of globalization is outsourcing. While outsourcing continues to gain ground in markets such as IT services and support, many technology companies believe the cost differential is not enough to offset the benefits of having their own operation—whether it’s R&D or sales—in a foreign country.

“Sometimes running it ourselves is cheaper in some ways,” said Kirk Law, vice president of systems products engineering at NetApp. “There are a lot of different ways to measure value. It’s not just a spreadsheet decision.”