As the demand for fast computation and information transmission has increased dramatically in recent years, many designs have boards with signals operating in the multiple-Gbps range. Advanced memory designs are targeting over 10 Gbps data rates while the SERDES standard is moving toward 25-28 Gbps. With the signal speed changes come the new challenges of solving design issues never seen before. The electrical components of signal paths on boards and interconnects present problems, such as significant dielectric loss or impedance discontinuity from non-trace portion, which used to be ignored at lower signal speed. For a typical SERDES channel (Figure 1), the discontinuity contribution comes from the vias for signal switching layers, connectors enabling multi-board connections, and packages. To PCB designers, only via configurations are under their control in these discontinuity contributors.

To download this white paper, click here.

By Ann Steffora Mutschler
Since the dawn of EDA, the industry has largely operated under a traditional software distribution model whereby the customer would run the software it licensed on its own hardware equipment. With the sophistication of advanced IT management techniques as well as education surrounding “The Cloud,” it may be safe to predict that engineers in the not-to-distant future will be designing and verifying SoCs entirely in the cloud.

Right now, however, it’s a different story.

“As an industry, it’s pretty nascent for EDA applications,” observed Dave Desharnais, senior group director for product management in the silicon realization group at Cadence. “We ended up getting permission to use our tools in the cloud with constraints because there really was no formal way to do that in a third party cloud context. It’s really been large-scale companies that have been coming to us for about the last three years, on the tune of probably 10 to 12 a year, asking us because they are Cadence customers, ‘How do we use your tools in the cloud? We want to use your tools in the cloud.’

A frontrunner in this model, Cadence has offered its Hosted Design Solutions since 2007. It is a turnkey, private cloud offering born out of its design services. “It’s not a driver for our business but it’s certainly an option for a certain class of customers—mostly small and medium sized,” he said. With about 50 customers today, it has seen linear growth since the program began.

Desharnais is quick to point out, “This is really our entrance into the software as a service (SaaS) market because the customer owns the data but we want to provide that pathway in, all the compute resources, it’s turnkey and it’s beyond emulation, it’s everything: custom analog to digital ICs, all the physical and logic verification, emulation.”

Datacenter at Cadence Design Systems (Source: Cadence)

“It’s really no different from a business model in traditional EDA—you buy a license for a certain time. In this case you’d buy a set of licenses for a certain time with some bursting capabilities. That’s the SaaS model,” he said.

An even earlier player in the cloud arena is Sonics. Drew Wingard, co-founder and chief technology officer, said he feels like a grizzled veteran of this topic. He explained that way back in 2001, Sonics introduced a vehicle called SoCworks. Today it would be referred to as SoC- and IP-core-based design in the cloud.

“A challenge we were trying to address in those days, if you look at the basic business transaction model behind selecting IP cores to go onto an SoC, is that one of the big challenges is this horribly long dance that happens at the beginning before the customer can actually do the evaluation,” said Wingard. “It ends up being very messy, and in many cases it’s like six months to get through this process. The idea we had at the time was the reason for a lot of this protectiveness is around worries about the theft of the IP or worries about the pollution of the engineering, and that in the chip field we don’t worry about this as much because the chip that we distribute is pretty obscured. It’s buried inside a package, and you can’t really figure out what’s going on inside. The distributor can ship you a chip for evaluation purposes without all of this stuff. What if we could get to that same level of abstraction around IP cores?”

Sonics built a set of servers, in what would now be called the cloud, that ran the development environment that was part of its solutions. It still is, and it “allowed people to mix and match IP cores from who were then some of the major providers of IP cores—guys like MIPS and Tensilica, the inSilicon part of Synopsys—and actually plug and play them together around our interconnect fabrics, run some basic simulations so they could try before they had to go through all that legal stuff. We were way ahead of the curve on this clearly,” he added.

Mentor Graphics too is not new to the private cloud. Michael Buehler-Garcia, senior director of marketing for Calibre design solutions explained that as part of Calibre, there is a multi-thousand CPU farm in the floor of the building where the Calibre team is located, which is run as a private cloud to its different development teams around the world. “So are we doing cloud? Well, yes, and anybody who runs OPC accesses an SoC cloud because the size of designs requires multiple CPUs to run it.”

Datacenter at Mentor Graphics (Source: Mentor)

Today, the company expands its cloud play with its announcement (http://www.mentor.com/company/news/) of a cloud-based DFM Analysis Service based on the Calibre platform for TSMC 28nm and 40nm foundry customers, which analyzes the customer’s design database to meet the requirements for TSMC’s lithography process checking (LPC) flow. It delivers a results database containing hotspot locations and fixing hints that can be used by routers to perform corrections. Buehler-Garcia expects it to be attractive option for customers who tape out only a few advanced- node devices per year.

In addition, Synopsys has been offering verification-on-demand in the cloud for a few years.

IaaS Before SaaS
Before engineering teams embrace SaaS, Cadence’s Desharnais believes the infrastructure as a service (IaaS) model will take off as an interim step.

Interestingly, he said, customers are requesting permission to run Cadence software in the cloud…even if they don’t know what to do with it yet.

“What is shocking to me is very large sophisticated mobile telecom-type companies [like those] in the San Diego area—those guys aren’t doing it. Those guys are leading, bleeding edge, and they are the guys you would expect would have it. They want permission but they haven’t pulled the trigger on it yet because they are still trying to figure it out and how they are going to use it,” Desharnais continued.

“What I’m seeing the most, if you look at the semiconductor industry at large, it’s not so much a SaaS model, it’s more of an IaaS model. There’s a huge reluctance to put anything like an RTL on the Web or any sort of physical design that can be effectively pirated or moved so the security pieces scare them. As an EDA vendor, we’re actually not in a position to solve that. There are more systemic kind of things that are in the way. But we see companies taking a baby step in this direction, and this is where they are getting pressure from their CFO or their CIO or their CEO to start moving to more of an operational expense versus a capital expense model. And they say, ‘If we’re doing it for other things in our company (financials, HR) why not do it with EDA tools?’” he suggested.

In the long run, what probably makes the most sense is for EDA tools to be hosted by third party cloud providers such as Osmosix, Plunify and Xuropa, as opposed to private clouds hosted by the EDA vendors since customers won’t want a locked solution.

A newcomer to this scene is SiCAD, which comes out of stealth mode today. What’s different about this company is that it makes no tools of its own, but pulls together a cloud-based multivendor solution for a number of vendors’ products, including all of the Big 3 EDA companies and many point tools. As CEO Jai Iyer tells it, the key was to identify the pain points where utilization is extremely high but utilization over a year is low.

“The problem is that peak use for some of these tools last two to three months, and the rest of the time they’re sitting around idle,” said Iyer. “When you look at signoff tools for static timing analysis, extraction and DFM, they’ve all got low utilization and they’re expensive.”

It remains to be seen whether a multivendor complete solution will fare any better than previous attempts by established companies. At the end of the day, many will still argue that the business model is not working. But there are still those who believe that—at least someday—it will. The only question is when.

Customer IT Deployment Types (Source: Oracle)

By Ann Steffora Mutschler
Driven by high-speed interfaces, the demand for TSVs and the complexities that new process nodes bring, older packaging technologies like wirebonding can’t keep up.

The latest and greatest flip chip technologies offer much more flexibility, but at a cost. As such, the package plays a larger role than ever in determining system specifications because, depending on the packaging technology used, certain system parameters are either limited or not. For these reasons packaging is being considered up front in the design process—even at the very earliest planning stages. Moreover, the cost of packaging comprises a non-trivial portion of the total system cost. Throw 2.5D and 3D ICs into the mix and things get really interesting.

These issues are breaking down the brick walls between the IC designer and the packaging designer, observed Brad Griffin, product marketing director for Cadence’s Allegro product line. “I think we have hit a point where if you don’t at least consider some of the aspects simultaneously you’re going to end up with a system that either doesn’t perform like you would like it to or has additional cost than you would like it to have.”

Shafy Eltoukhy, vice president of manufacturing operations at Open-Silicon, agrees. “Essentially when we talk to the customer initially we try to understand from them what their thermal requirements are, like power, the footprint of the package, the thickness of the package and the cost. Also, if it’s a consumer part it will be different than if it’s a networking part. The cost has a big impact on the selling price. There are a lot of factors that come in at the very beginning, that being the power dissipation, signal integrity, form factor of the package and so on.”

There’s a complicated matrix to designing a package. “In some cases, at the very beginning, you don’t know exactly what the die size is going to be because customers keep adding functions and the die size keeps changing in the early stage. Having all the requirements from the mechanical to power to this and that, as well as the layout or the floorplan of the die, is also changing up front. The package has to be part of the very early stage of the design,” he said.

The company ties the package to the floor planning and the requirement as far as the speed and other considerations. Package design engineers get on board very early in the process—even before designing the die itself—to look at it from the floor planning point of view. That includes where to put high-speed interfaces, how fast these are going to be, packaging technology, i.e. flip chip or wirebond, power expectations, and so on. “It’s very complicated and people have started putting a very good interface between the packaging and floor planning engineers,” Eltoukhy added.

Broadcom recently detailed its experience making early tradeoffs during Cadence’s CDN Live event in March. The presentation can be viewed here (registration required).

In this case, using Cadence technology under development, Broadcom enabled its PCB designer to look at what the package footprint should be to best match the components on the board. From there it drives up from the package footprint to the bump matrix for the chip. They were able to determine the ideal bump matrix for the chip to be able to match the package footprint. Then from the bump matrix that drove the I/O pad ring to get the I/Os and chips placed properly.

Then, when it comes to 2.5D design, packaging issues are actually more complex than what they will be with true 3D ICs, according to John Park, methodology architect for IC packaging and pathfinding technologies in the Systems Design Division of Mentor Graphics. “I believe—and many of my customers believe—it is more complex because you have this intermediate substrate in which the die connect through these small microbumps, and there’s this die-to-die connectivity that happens on some unknown number.”

Engineering teams really want to save costs, or at least make the tradeoff of cost and thermal, etc., Park added. “They want some global routing technology that allows them to say, ‘What if, on the interposer, I limit it to three metal layers? Does that mean I need to add two more layers to my package substrate or does it mean that I have to add eight more layers to my package substrate?’ In that case, maybe they say, ‘I’m going to add one more metal layer to my silicon interposer so that I can reduce the layer count of the package.’ Now the costing gets very complex because you have this new intermediate routing structure that sits in between the traditional die to package connectivity that greatly impacts cost, routability, signal quality—all these types of things.”

Although some of these issues won’t be a problem with 3D, don’t expect a mass exodus from 2.5D when 3D becomes mainstream because it may be more expensive, noted Cadence’s Griffin. “You’re going to have to get to a certain quantity before you’re going to realize the value in going to 3D IC, so there’s going to be still a fair amount of chips in the lower to mid quantities for which they want to realize the performance gains of going to a silicon substrate to connect things together but they can’t necessarily go to the expensive TSMC to be able to connect all these things together properly. [Systems companies] will rely on less-expensive silicon interposer technology; it will have a little less performance but cost-wise, it will just be more efficient for them. I think you’re going to see both for quite some time, but i think you’re going to see the very-high-quantity things move to 3D IC as much as possible.”

By Ed Sperling
Synopsys’ Yaron Ilani talks about DVE and UVM while commuting to work in a video. It’s good info, but can you count the number of times he takes his eyes off the road to look at the camera? We lost count at 50, although admittedly he was stopped for some of those and this wasn’t the Autobahn. Still, is this legal in Israel?

Mentor’s Nazita Saye digs into the mechanical challenges at Bronswerk Heat Transfer, creator of the incredibly efficient “Whizz-Wheel” fan blade. If you want to see what a Whizz-Wheel looks like, check out the photo. This kind of design is long overdue, and it’s an interesting intersection of mechanical engineering and EDA.

Cadence’s Richard Goering interviews one of his colleagues, Ken Potts, about the GSA’s 3D IC working group. For an ecosystem to build technology this complex, we’re going to need lots of standards groups like this one.

DeepChip’s John Cooley raises questions about venture capitalist Jim Hogan’s SPICE rankings. Considering there isn’t much discussion about any of this stuff, and no official stats, it’s rather difficult to figure out who’s right.

Semico’s Rich Wawrzyniak examines Synopsys’ move into IP subsystems and why this trend is so important. Conclusion: Expect to see lots more of this kind of pre-integration.

No one enjoys home entertainment systems like engineers. But the truth is, most engineers don’t spend a lot of time playing games or watching movies. They do spend time deconstructing and improving the systems, though. Synopsys’ Navraj Nandra is in good company on this one.

Mentor’s Colin Walls recounts the activities at Nvidia’s recent GPU conference. Of particularly note is the programming for task and data parallelism, which may be easier with a GPU than a CPU. Nonetheless, it’s been a tough nut to crack for four decades.

Cadence’s Axel Scherer is stuck on the Saturday Night Live cowbell skit and has somehow tied it to UVMe. Call that loosely timed—or maybe just a loose thread.

Speaking of UVM, JL Gray is back with some tips on UVM drivers and monitors. Monitors are your friends. Use them wisely.

Synopsys’ Helene Thibieroz interviews one of her colleagues, Frank Lee, about FinFETs. Lee clearly has a very good grasp of this technology and what it means to SoC design.

Cadence’s Yuri Tsoglin offers some tips on writing macros in e. If you’re using the e language, this is the place to go.

By Ed Sperling
Cadence added in-circuit acceleration for the Incisive verification and Palladium emulation portions of its System Development Suite. This will reduce the time it takes to run tests on complex SoCs—for both hardware and software—allowing more time to make sure the chip actually works. Cadence also extended its Verification IP catalog for acceleration and emulation. The company also introduced an NVM Express subsystem with pre-integrated and tested IP.

Mentor Graphics won two deals. The first was from U.K.-based Professional Circuit Design, which standardized on Mentor’s PCB design through manufacturing technologies and consulting services.  The second involved Vestel Electronics, a set-top box manufacturer in Europe, which is using Mentor’s Inflexion user interface technology.

Synopsys won a deal with AMD, which will use Synopsys’ Discovery VIP involving everything from USB 3.0, ARM’s AXI, SATA 3.0, PCI Express 3 and Synopsys’ Protocol Analyzer. What makes this especially interesting is AMD’s play in the enterprise space.

MIPS rolled out a new generation of processor cores called Aptiv, with an emphasis on performance and energy efficiency. The cores are targeted at high-end mobile devices and smart home entertainment, squaring off against ARM’s big.LITTLE with what it claims is a much simpler power management scheme.

By Ed Sperling
Cavium’s Brian Hunter, writing for Synopsys’ Verification Martial Arts, resorts to a rather creative, if unusual, way of describing namespaces—a video of a chicken processing facility. This is the very free-range explanation.

Cadence’s Frank Schirrmeister offers a crash course on in-circuit acceleration. Get familiar with this concept because more and more will happen in-circuit at future process nodes.

Mentor’s Travis Mikjaniec questions why California law requires smokers to stand at least 25 feet away from doors and windows. How exactly did they arrive at that number? And which way was the wind blowing at the time?

IHS iSuppli’s Robert Braverman crosses concepts—value chains and supply chains—and explains why they’re so intertwined.

Synopsys’ Navraj Nandra expounds on how to test embedded IP—a serious problem when you’re using multiple IPs with different test access strategies, interfaces and descriptions.

Cadence’s Peter Heller looks into the role of verification IP in SoC verification and why it’s becoming so critical—not to mention why IP vendors are finally able to get paid for this stuff.

Mentor’s Nazita Saye has created a top-10 list of things she learned from engineers. You’ll like No. 4: Engineers are nice people. Funny, they never say that about writers.

DeepChip’s John Cooley goes searching for Samsung in the foundry rankings and finds them…well…all over the map. So much for consistency in math.

Synopsys’ Eric Huang questions the future of Thunderbolt vs. USB 3.0—while wearing a safari hat. That may not seem weird, unless you consider he was indoors.

And in case you missed the most recent Low-Power Engineering newsletter, here are some blogs worth noting:

—Synopsys’ Cary Chin tests the power efficiency of 4G and 3G phones and discovers, rather unexpectedly, the hidden cost of streaming data.

—Mentor Graphics’ Barry Pangrle digs under the covers of Intel’s new Tri-Gate processors and finds the real story is all about energy efficiency and reduced area.

—Cadence’s Luke Lang examines why there are different commands in CPF and UPF and how to navigate the macro models.

—Mimasic’s Bhanu Kapoor concludes that using all the features built into hardware will require some advances in software.

—Apache Design’s Aveek Sarkar looks at what’s needed to meet power, performance and price goals for stacked die and sub-20nm designs.

—Tensilica’s Chris Rowen cooks up the perfect SoC recipe with some advanced culinary techniques.

—Atrenta’s Kiran Vital charts the gap between a standard format for describing memory behavior and reducing dynamic power.

—And Docea Power’s Ghislain Kaiser points to a key problem in solving thermal problems. Blame it on a lack of training.

By Ed Sperling
A subtle but important shift is under way inside of EDA. While vendors are still focused on solving some thorny issues at the front end of Moore’s Law, much of the R&D effort lately has been targeted toward better and earlier integration of new or enhanced tools and toward combining IP blocks into subsystems.

To some extent this is simply good housekeeping—roughly EDA’s equivalent of making software backward compatible. Ensuring that that tools work with each other in a flow that now has to be concerned with hardware, software, power, electromigration, standards—and all the while making this work across a globally disaggregated supply chain—is an incredibly complex management challenge. But there is also at least an early indication, and one that apparently warrants big investments on the part of EDA vendors, hat at 28nm and beyond many of their customers’ in-house tools are running out of steam. Even better for EDA, there is far less money being appropriated to develop new internal tools.

This explains the rising clamor by customers for more standards. Chipmakers certainly don’t want to pay top dollar for EDA tools, and standards make it easier to chop costs—or at least to negotiate a deal. That’s partly what’s behind the increasing amount of noise about existing standards such as the dueling power formats, CPF and UPF/1801. It also explains why there is more collaboration under way between chipmakers and EDA vendors to develop complex solutions, because while chipmakers may experience a limited number of problems, EDA vendors deal with a much greater universe of the same or related issues and draw from a larger pool of chipmakers to offer advice.

All of the big EDA vendors recognize these changes, and their recent product releases clearly reflect it. Witness Cadence’s announcement today of tighter integration between its System Development Suite, with in-circuit acceleration, and its VIP catalog, which now has hooks for both acceleration and emulation. What that means, in a nutshell, is that simulation and emulation teams now can share a verification environment, and the VIP catalog is now compatible with the Accellera Co-Emulation and Modeling Interface (SCE-MI) standard.

“The goal is to push use models from NRE to automation,” said Michal Siwinski, group director for product marketing for Cadence’s System and Software Realization Group. “There are two elements to this. One is in-circuit acceleration to the System Development Suite. The second is a VIP catalog that has been expanded for acceleration and emulation.”

Both Mentor Graphics and Synopsys have been taking similar steps for their respective environments. Mentor, for instance, has been active in bridging a variety of its embedded software tools into a standard flow, and in making emulation far more attractive for software developers by adding a desktop virtualization layer. The company also has been working heavily on making it easier for chipmakers to develop and incorporate embedded software into their designs.

Synopsys has been integrating a number of pieces in other areas, most recently in the 2.5D/3D IC world where it has begun integrating test, IP, parasitic extraction, simulation, DFM and thermo-mechanical stress analysis into the same flow. It also has been working hard to integrate hardware and software.

“The interaction of components is much more important,” said Alan Gibbons, principal engineer at Synopsys. “A lot of this is not being modeled today, and if it is it’s happening on a spreadsheet. We need more intelligent algorithms to make this work.”

Along the same lines, but in different market, Cadence has launched an NVM Express memory subsystem for enterprise computing environments. “This will dramatically reduce the time it takes to integrate and optimize,” said Neil Hand, group production marketing director for Cadence’s SoC Realization Group. “NVMe was built on PCI Express. This is a natural move to a subsystem and it leverages a lot of expertise in storage and high-performance interfaces.”

This follows on the heels of similar moves by Synopsys in the audio subsystem arena (as well as its NVM Express VIP), and by companies such as Tensilica in the audio and video subsystem world.

Simon Butler, CEO of Methodics, said the move from IP to subsystems eliminates a lot of the “grunt work” by bundling in firmware and development tools.

“There’s a lot of history behind using the appropriate infrastructure with functional blocks,” said Butler. “The challenge is in trying to accommodate both of those. Generally speaking, the larger the block the more you need to remove the complexity, and the way you do that is to give it to the IP vendors and let them do it.”

Butler said that characterizing subsystems rather than just IP blocks is a big step forward. “The fact that programming and interacting can be done at a higher level means the use model is easier. How perfectly it behaves electrically is driven by the application. But if you see enough traffic going through a subsystem, you bring more to the table and are able to solve more problems. So basically your integration work as a customer is going down because the vendor is supplying the abstraction layer.”

With all of the big three EDA vendors on board, this focus on integration will likely establish the theme for the upcoming Design Automation Conference in San Francisco early next month. The big questions now are what else will be integrated, and by whom.

By Ed Sperling
System-Level Design sat down to discuss hardware-software co-design with Frank Schirrmeister, group marketing director for Cadence’s System and Software Realization Group; Shabtay Matalon, ESL market development manager at Mentor Graphics; Kurt Shuler, vice president of marketing at Arteris; Narendra Konda, director of hardware engineering at Nvdia; and Jack Greenbaum, director of engineering for advanced products at Green Hills Software. What follows are excerpts of that conversation.

SLD: How much does the business side enter into this equation?
Greenbaum: The cost of the models balanced with the benefits you get from having those models, and the lack of well-defined interfaces, conspire people to just build the chip and do as best as they can. Think about the effort to build drivers for the actual silicon. If you’re going to push real workloads through and connect to the actual Facebook servers, for example, you need a driver that can talk to the model. Did you define that interface between the CPU execution model and the approximately timed video codecs sitting on the other side of a bus in such a way that you can still write a driver quickly enough to derive a benefit from that? Will it result in fewer chip spins to get a design right? It’s a challenge to just bring a model together. Then you have to make it economically useful.
Shuler: It is starting to get better. There is more fixed-cost work to do this up front, but when you’re creating one of these chips you need to develop a platform because you have to amortize the cost over multiple chips. Companies build these chips and then make four or five derivatives that may go all over the world. For them, the cost of putting together the infrastructure up front is paid for in the end because they can get multiple chips predictably from that one. The whole SoC trend is helping the adoption of software-hardware co-design.

SLD: No matter how close we bring the hardware and software, they’re still out of sync. On the front end you’re working off something started by a hardware team, and on the back end you’re working off something that hasn’t been finished by the software team. How does that affect everything?
Schirrmeister: Things are out of sync. The question is whether a driver has been developed to push traffic to a server via the model rather than the actual hardware? I’m convinced we’ll get there, and we’ll know we’re there when the model generation becomes a natural byproduct of the mainstream design flow. So a company like Arteris creates the fabric and models for different needs. Then it’s up to the user to decide which one to use. Maybe they only need the LT model because they don’t need to plug in a more accurate model that will slow things down. But sometimes you don’t know what you don’t know. Your requirement may mean you’re producing more memory bandwidth than the hardware can handle. You might have seen that if you ran it against an AT model, and you certainly would have seen it if you ran it against an RTL model. It all goes back to having the models available. Sometimes it isn’t commercially feasible, but it is getting better. We are going in the right direction.
Matalon: I’m more optimistic on that. For model creation, we need companies to provide models at all levels of abstraction. People are working in isolation. Some of this is because it’s a natural thing of teams working in India and China and North America. But sometimes they need to see the solution. The solution is enabled by providers of models, but you cannot see how, for example, a network on chip will be utilized unless it’s put in the context of an overall platform. To do that, we need models for everything and we need automation to create the AT, the analysis tools to do power and performance, and all of this is something the EDA vendors can provide. There will be some groups that hold back on moving forward, but there are solutions there that are not coming from a single vendor. They’re coming from the collaboration of IP providers, tool providers, semiconductor companies and embedded software companies. Now we need to get users to accept them—to break the hardware-software barriers between engineers and architects and software teams.

SLD: Are the models being updated by everyone and in all places?
Schirrmeister: That goes back to making them a natural byproduct of the design flow. If they’re not, there is no way of synchronizing everything.
Shuler: You can’t do it manually.
Schirrmeister: In the past we had models for a certain platform, but in the next revision do you really go back and update the model to be in sync with it? Only when it’s absolutely necessary. But I do think it is becoming a more natural byproduct of the flow even though we’re not there yet.
Greenbaum: Yes, it is getting better. There are a number of open-source platforms for which you can download a QEMU (quick emulator) model. But it’s still the minority and the opportunities there are being squandered. If you look at a virtual prototype as just a development vehicle that is there pre-silicon and you get no more value out of it than the silicon, then you’re squandering the value from a software development virtual platform, which is visibility. With a virtual platform you don’t have pay the cost to pin out the ETM (Embedded Trace Macrocell) on your ARM core to get trace.
Shuler: The same kinds of problems the hardware guys discuss the software guys are discussing. The way I look at it is that hardware is no different from software. It just has to become fixed at a certain time. RTL is software. If you’re a chip vendor you’re in software development. It’s parallel code, but half of it becomes fixed.
Greenbaum: As long as you have timing closure you’re correct.
Konda: It was the case that the hardware and software teams were doing their own things. But what we see now, because of the market pressure and the increasing software content, is that the software team is taking a much more proactive approach. If we are designing a GPU and a CPU, the hardware team and the architecture team will be developing the C model and the functional model of this. But now the software team is knocking on the door and saying, ‘Hey, give us that model. We want to run our software code on it.’ We are seeing a lot more collaboration.
Schirrmeister: The reason that’s happening is that someone who owns both teams says that if they don’t do it, software will be too late.

SLD: But what happens if the models get out of sync?
Konda: If you look at an SD (secure digital) card, the specs are changing from 3.0 to 4.0. The focus of the hardware team—two or three engineers, one verification guy and two RTL guys—is to write the spec, look at RTL, verify it’s working and it’s done. They don’t care about software, system integration or anything else. But now you’re trying to realize an SoC and searching for ESD 4.0 model. Now you’re searching the globe to find models for these interfaces.
Greenbaum: And they still don’t match your RTL because the DMA (direct memory access) is not a standard part of that SD interface and you lose. Even for standard interfaces there are no models.
Konda: So yes, models do get out of sync. The C model probably doesn’t agree with RTL we are developing. The other problem is trying to find a valid model from somewhere. The audio guy with two engineers doesn’t have time to develop a fast model. It’s not his job description.
Greenbaum: And we haven’t reached the point where we can generate those models, either.
Matalon: In the past, the hardware engineers owned power and performance. Today, performance and power are controlled by software. The hardware can put in hooks to control voltage and scaling, but the hardware engineers have no clue when that will happen. The first big change is that co-design will be a bigger interest for the software guys because the top manager will start blaming the software team if a smartphone runs out of battery in four hours. It’s because the software guys have not used all the resources correctly. We’re seeing a shift of responsibility from the hardware guys to the software guys who have the overall system view. A second change involves the interoperability of models. You can no longer build a complex SoC based on proprietary models that are created ad hoc. They need to be TLM 2.0, they need to be standard, and they need to be re-usable in the next project. If you use standard models and make this investment, the payoff is huge. If you don’t do it, you’re stuck. A lot of software and hardware and architecture teams are aware of that. It’s happening.
Shuler: The dirty little secret is that hardware companies put all of this capability into a chip, but when they create the boards and packages they use a fraction of it. The end device manufacturers use even less. They’re using 10% to 20% of the capability.
Matalon: That’s why you can reduce 80% to 90% of your power if you evaluate power in the early stages of the architecture.

By Ed Sperling
Mentor’s Mike Jensen looks at the “Rooster Tail,” the giant fan of water released out of three dams in the Pacific Northwest. Check out the photos and you’ll know why they call it the Rooster Tail. This would certainly be a rude awakening in the morning.

Synopsys’ Navraj Nandra examines whether DDR3L will ever make its way into mobile DRAM. The answer, apparently, is no.

Cadence’s Richard Goering peers into the details of 20nm RTL to GDSII methodology. This is like looking over Niagara Falls where manufacturability, timing variability and design size and complexity are churning at the bottom. Better reinforce the barrel.

DeepChip’s John Cooley focuses in on the changes on Mentor’s board of directors, notably that two of Carl Icahn’s three choices for the board have been replaced. This gives new meaning to hot swapping.

NXP engineer Chris Hill, standing in for Mentor’s Robin Bornoff, looks at diminishing returns in thermal design of PCBs and how extra copper layers don’t always help. Given the price of copper these days, no one will argue.

Independent blogger Gaurav Jalan examines the list of challenges for verification teams, providing some insight into why it takes so long to get a chip out the door. Even more disturbing, though, is that confidence in the final product appears to be on the wane.

Synopsys’ Eric Huang had one of those “ah-hah” moments about the limits of family involvement in technical subjects. You do what for a living? Is that legal?

Cadence’s Jason Andrews looks at simulation performance on a Zynq virtual platform using VirtualBox compared with native Linux.

Si2’s Steve Schulz previews what his group is doing at DAC this year, which will include a rundown of all the standards efforts under way at the moment—or at least the ones they’re talking about in public.

Mentor’s Brooks Moses looks at the embedded software in a control cluster of an unmanned aircraft and how difficult it is to program to get maximum performance. In this case, “maximum performance” may mean different things to different people.

By Ed Sperling
System-Level Design sat down to discuss hardware-software co-design with Frank Schirrmeister, group marketing director for Cadence’s System and Software Realization Group; Shabtay Matalon, ESL market development manager at Mentor Graphics; Kurt Shuler, vice president of marketing at Arteris; Narendra Konda, director of hardware engineering at Nvdia; and Jack Greenbaum, director of engineering for advanced products at Green Hills Software. What follows are excerpts of that conversation.

SLD: How often is co-design really warranted?
Greenbaum: The case for power and performance may be more common than you think. Looking at the products from Nvidia, is a Tegra processor a standard product or an SoC? You put a Tegra in an automobile running an IVI (in-vehicle infotainment system and maybe an instrument cluster. That instrument cluster gets prototyped on a desktop. Then someone gets the idea of taking that high-polygon-count design and putting it in a car. Now you have a cost you have to optimize. If I can’t do it with today’s Tegra, can I do it with the next one? You’re not going to know. That’s one advantage of co-design. You can know before the sand gets melted. Even if your application can be implemented in software, co-design to let you know what price point you can do it at is very valuable.
Konda: We are delivering a solution today that is not just silicon. It used to be the case 10 years ago. But today it’s a complex piece of software and highly complex software. These two things have to come together. First and foremost, we have to make sure the design is in a semi-working condition before bringing in the software team to develop their code. To do that, we cannot wait for emulation or an FPGA. These bits and pieces of a design where we have multiple cores, multiple processors in that SoC—20 to 25 processors and components and interfaces—creates a very complex device. RTL is not available all the time. Some parts of the design are in RTL, some parts are in C models. As soon as we have a little bit of confidence we want to encourage the software team to come in. That’s very early in the design cycle.
Shuler: Why do you wait so long? Why don’t you do it as soon as you get the initial requirements?
Konda: We have been doing that for a number of years, but it’s still not a full-fledged solution. In our case, we have 30% to 40% of the design modeled at the very beginning and software teams are already working on that model. But it is not the entire SoC. They are working on the GPU or CPU portion of the SoC. How do we model all of these peripherals? That’s not there yet.

SLD: There are two trends unfolding in IC design. One involves a general-purpose processor, where you may leverage one or more cores and only a specific amount of memory. The second is a very specialized processor where you may run a specific application. How does co-design deal with these different approaches?
Matalon: One issue is really validating the spec. The earlier you can capture your specification using an executable specification where you don’t just generate UML diagrams but simulate it dynamically to represent the conditions upon which the specification is working is an ideal solution. This is a level above implementation. That’s very important. If you go one level down and start doing partitioning in LT mode, you can’t really evaluate the tradeoffs. It’s good to refine the specification, but you can’t validate the performance, bandwidth and power are there. In my view, the key is to first focus on architectural exploration to make sure you have the right performance and power. For that you need an approximately timed model that allows you to do an evaluation of performance and power for your standard processor, for your specialized processor, for multiple cores, for all the combinations and topologies. It cannot be too low-level so it can be used in a way where you can do power/performance evaluations, do a power budget, and if you need to, you can shut it off and run other parts very fast. That’s where I see the ideal solution. Some customers are using it and many customers are not. You can’t wait for the RTL. It’s too late. You can do co-design, co-validation through all the stages of implementation, but from a design perspective for these types of designs you have to start above RTL.
Shuler: When we’re talking co-design, it’s a people problem, not a technology problem. You don’t see kick-offs where there are hardware and software people in the same room—or even where the architects and verification people are in the same room. The semiconductor vendor is responsible now. When you think about it, the real customer of the semiconductor companies are the software vendors.
Greenbaum: Absolutely. And very few semiconductor companies recognize this.
Matalon: It’s not as bad as that, but it’s not yet the prevalent methodology. Co-validation is already quite entrenched, because emulation, acceleration and virtual prototypes are really co-validation. The co-design—evaluating the performance and power—is still at the early stages.
Greenbaum: The big difference is between code software drivers written for verification or validation vs. those written for real applications. The semiconductor vendors that are doing the worst job of delivering a full platform of silicon and software don’t understand the difference. They’re delivering verification code, but when you try to use it in a software environment it rolls over and dies very quickly. There is a spectrum of companies that get it, and if you look at the acquisitions in the embedded software arena—Cavium acquiring Montavista, Intel acquiring Wind River, the in-house Linux teams that are pervasive and Mentor with the Nucleus product—we’re seeing the recognition there. But only the top vendors are there today.
Schirrmeister: There is always the Yin and Yang in here. We have polar opposite trends. There is the generalization of the processor, which is meant to not shoot yourself in the foot. In the embedded space you have Java-based applications. Those development environments are built in a way that is very abstract. On the other hand there are highly specialized processors enabling highly specialized applications—highly specialized hardware with an abstraction layer and then the application development environment built on top of it. Now, going back to the models, if you had the model generator where you just talk to it and it creates the AT model, that would be the perfect environment. As a practical matter, what chipmakers are looking for is the ability to mix and match. The AT model is great to represent some of those effects, such as area, power and performance. But in the next version, the question might be slightly different. That makes it very hard to build those AT models.
Shuler: We have to do all three in addition to RTL. We have cycle-accurate, loosely timed and approximately timed. You never know what people will need.
Schirrmeister: As a practical matter, there are a lot of people using AT models. But in parallel people are taking the appropriate model for the system and hooking them together. So you have emulation or rapid prototyping for the pieces that are already stable, which is where IP re-use comes in. You may not have to rebuild them as an AT model. Having a processor model of the next big.LITTLE chip and execute the software, and for the subsystem that does more computing to be able to analyze the performance, allows you to create the right mix. Would the perfect environment be to have AT models for everything? Absolutely. Can you practically build AT models for everything? It may not be possible all the time.
Matalon: AT models are ideal because the other models are too slow or don’t have sufficient information. I disagree it is difficult to build them. We automate that from simple definitions. The challenge we see sometimes is that the functional model doesn’t exist. You have a design that is very complex and now you want to build a functional description that is equivalent to RTL. To wrap it with timing and power can be fully automated. Even the entire platform can be fully automated. But when you have a complex design and you want a functional abstract model, you have to write it yourself. If you put the RTL on an emulator and connect it to the rest of the models you are missing some of the capabilities of how you evaluate power or performance and you’re using RTL again, so what’s the point?
Konda: On the models front, it’s true you will not be in a position to provide models for the entire SoC. And to expect a functional model from an EDA vendor is not realistic. In an SoC environment, we have a number of interfaces and devices that get attached to the SoCs that are standard specs. At Nvidia we design our own CPUs. We also use ARM CPUs. We have a GPU. If you look at where these teams are, the CPU guys are in Santa Clara, the video guys are in Shanghai, and the simple interfaces like an SD card are in India. To realize the SoC model there is no common platform that pulls all these things together. The CPU and GPU guys are forced to develop a high-level C model. They start doing their work earlier in the cycle because they are forced to. Each team is doing whatever they have to do. But bringing all of these things together to create an SoC is the biggest missing piece. If you run a Facebook or a Twitter application, power and performance are key. So how do we estimate the power consumption? We cannot do this in one platform. With emulation it is too slow. With an FPGA, by the time the FPGA starts working the chip has already come back from the fab. It is a mix of parts of the design on an emulator or an FPGA, which is a real model, and then you hook up the rest of the design that gives a good approximation of the real system. It may not be highly accurate, but if you can estimate power and performance plus or minus 10% that’s still great.