By Ed Sperling
System-Level Design sat down to discuss ESL modeling with Anmol Mathur, CTO of Calypto; Steve Frank, CEO of Paneve; Fabian Clermidy, senior architect at Leti, and Sylvian Kaiser, CTO of Docea Power. What follows are excerpts of that conversation.

SLD: How important is speed in ESL?
Mathur: To get verification productivity out of an increased level of abstraction you really need to be able to quickly validate your implementation models and push the correctness of that through, whether you’re using high-level synthesis or whatever else to get to RTL and down. If you have to re-validate another model at the RTL level you’ve lost that.

SLD: What happens now that we have software in the mix? Does this complicate everything?
Frank: Absolutely. Our mantra is all about software, and we care about how efficiently the software runs on the hardware. It’s not about whether the hardware matches the architectural model. That forces us to do things early on. We develop a prototype compiler so we can take strategic samples of code and we take a real compiler and run it on the architectural model to validate that we’re actually getting the performance we’re looking for. A big part of what we’ve done is validate and automate that tool chain. In our case, that’s a big part of our design.
Mathur: One of the key motivators of people to have these high-level models is to have platforms for early development. That’s definitely one of the key drivers. People cannot wait until they have RTL or silicon to do software development.
Frank: Architectures you pick don’t just have implications for power, area and timing. They also have implications for how easy it is to write the software and to integrate it. You need to take that into account early in the design, just like power, area and performance. You have to understand when you can write the software, whether you can write it at all, and what the use cases will be. There’s more emphasis many times on just looking at the hardware metrics and not looking at the software metrics. The use cases when you design a chip aren’t necessarily the same ones when you get in front of customers. As designers, just like we wouldn’t pick a methodology that leaves us blind to timing and power, we need to pick strategies that don’t leave us blind to the software piece. Some strategies are better than others, and that’s just starting to be understood. No one really formalizes it yet, but it is an issue.
Clermidy: We have an issue with software development. On one hand, what the software people are asking for is something that is very fast. On the other side we have power management. We have software running and it has an impact on the hardware. So we need something that is very fast in terms of simulation. But we also need information on power and the circuit, so it has to be very accurate. We need something very high level but very accurate. That is very difficult.
Frank: They’re almost mutually exclusive.
Clermidy: We use different types of models that can be accurate enough, but which are not functional. They need to be running with high-level simulation and in parallel.
Frank: But the power of SystemC is you can have one model doing that with the power on an FPGA. Running SystemC at the instruction level is 100 instructions per second. An ISS is thousands, and you get 50 million to 100 million in an FPGA. We built our software platform first on an FPGA and then we retargeted to the SoC. But while we retargeted it, we had a software platform. And we could run real applications. That was more information that we could get from all of our simulation models.

SLD: And power models, right?
Frank: One of the big benefits of SystemC is the ability to re-target and get the best of both worlds. Clearly there is additional effort to do that. But most of that effort is additive. Most of the refinement you would have to do anyway.
Kaiser: There is no doubt that the possibility to write to hardware early in the design is one of the biggest benefits of system-level design. This is a real achievement of SystemC. Our customers say they need both. They can develop the software before the hardware and have a virtual product that they can show to their customers, and then take that feedback to the engineering team.

SLD: One of the whole ideas behind ESL was that it was supposed to make things simpler. The reality is that only the most advanced companies can work with this stuff. Will it ever go mainstream?
Frank: Another way of looking at the benefit of ESL is you now can have a small team of the best of the best doing what a big team could do. You could never have a big team with the best of the best.

SLD: But where are those small teams? Are they only in the most advanced companies?
Frank: It takes enough vision to go in this kind of direction. Many large companies aren’t comfortable taking what is perceived of as a technical and a business risk.
Mathur: It’s the standard adoption curve. These companies might be small. They might be big. I see many companies that are fairly small in size that need that productivity just to survive. But once the methodology is in place and once the food chain can use plug and play and swap things out, that’s when the risk-averse companies will start adopting it. We’re starting to see that. There are standards in place.
Clermidy: It’s about productivity. It’s a reality for small companies and it will be a reality for large companies. ESL will push even into large companies. It will take longer because they have established flows.
Mathur: The biggest companies are now looking at system-level modeling.
Kaiser: There is legacy in every company, but ESL will promote a seamless adoption of SystemC.
Frank: The skill level isn’t less. It’s more. It’s like a fighter jet versus a small plane. But the leverage and the power are extraordinary.

By Ed Sperling
System-Level Design sat down to discuss ESL modeling with Anmol Mathur, CTO of Calypto; Steve Frank, CEO of Paneve; Fabian Clermidy, senior architect at Leti, and Sylvian Kaiser, CTO of Docea Power. What follows are excerpts of that conversation.

SLD: How critical is it to keep models synchronized?
Kaiser: Keeping the synchronization between the models is a key for success. With ESL, there is another step in the chain. You can add another stage to your implementation flow. It is SystemC to GDS, but with ESL you also can have representation of your whole system at a very high level. You need to keep those models synchronized with your implementation. This is not only a concern for ESL. Every time you want to deal with anything that is not functionality, whether it’s a classical flow of RTL to GDS, or SystemC to GDS, it’s driven by functionality implementation. But people do not want to include other estimates, and they need to keep control in the flow of other non-functional properties. For these they need models, and they have to keep these models synchronized. This is true for ESL, for UPF or CPF, and they have to keep UPF and CPF synchronized. This is key to keeping interoperability in the flow.

SLD: Another piece that needs to be included is architectural exploration. What happens when you have loosely timed, cycle accurate, measurements to the microwatt?
Frank: Part of that is very early in a project. Before you really know what it is, you’re going to be building tools and models to estimate. Once you get to the point where you’ve eliminated three out of the four quadrants where you want to work and you’re narrowing in, you’re at a point where you need a different level of exploration. The best thing you can do with that exploration once you’ve figured out what you want is to throw it away. It got you to this point where you know where you want to focus. After that, you have to switch focus so you can look at kernels of code and compilers. You need a simulator that looks like what you want for a reference design. This early stuff isn’t something you want to maintain anymore.
Mathur: That’s not any different than what we do. People do have performance models. At the very beginning of a project you’ll have a model for the graphics, the processor, and other things. That high-level model serves a purpose, but once you’re done you have to discard it and move onto implementation. There is no magic. Your accuracy only has to be sufficient to make decisions at that level. Even if you’re off 90%, if you’re looking at two different microprocessors you can determine which one will be better as long as the correction on both is the same. People already have performance models and they will continue to need them. From the implementation point of view they will need to raise the level of abstraction. Once you have done all your performance analysis and architectural exploration, you have to have a standardized level of abstraction that you design to, verify, validate and then push on in terms of implementation.
Frank: It’s a combination of using the tools and applying methodology for using it.
Mathur: But you can’t have three or four of these levels. You do performance evaluation and then power evaluation using a different model, and then you’re going to have another model. Design teams don’t have that much bandwidth. The bulk of their work is in implementation.
Clermidy: What we need is to combine the constraints, both in terms of performance and core measurement, and thermal if we are talking about stacking chips. In the past you might have been able to put this block with this block because we knew it worked in previous designs. That’s no longer possible. There are too many different constraints. You need something very efficient to make sure it works.
Mathur: But you have to do all of that from one level of abstraction. Design teams will only do one model. You have to find the right level. If there is some purpose that requires a different model, maybe there’s one other model people can do. But you can’t have three or four different flavors of things.
Kaiser: I don’t think it’s a good idea to have a single model that is used for implementation and a single model that is used for architectural exploration. At the very high level of abstraction you want to do what-if analysis and try to assess various derivatives and techniques. But if you do that on the same one that will be used for implementation you may jeopardize your design because you may introduce flows and things that are not under control. Today with ESL there are several models doing different things. One model is for the implementation and the implementation flow. This model is used just for the design of a new product. Another model is used for architectural exploration. This model can be maintained and used to try out various things such as different IPs and different core management techniques to try and assess a distribution using this model. This is something that is changing.

SLD: So how many different models do we need?
Kaiser: One for the implementation, one for the exploration that is kept synchronized with the product development and that is used for closure all along the flow. Using this architectural model you can achieve closure of all the non-functional properties along the flow.

SLD: It sounds as if one of the takeaways is that you need to set up a methodology specific for your team and what you’re trying to achieve. Is that right?
Frank: Yes, and for what your specific task is. If you are synthesizing and you want to converge timing, area and power, do you make changes downstream or do you go back to SystemC and make changes to impact that? You have to learn how to have that impact with area, timing and power. There’s a tremendous temptation not to do that when you get close, but there’s a learning curve. The way you do that with SystemC is very different than when you have RTL and a netlist and you’re trying to make tweaks. The whole methodology of having ECOs is creating other source code. There are other models that creep in that you don’t even realize when you get toward the end.

SLD: In theory ESL should reduce the time on both sides of a design, the architectural exploration and implementation on one side and the verification on another. Is that happening?
Frank: Being able to cut down the number of lines of code has cut down the verification time. We base our verification on the architectural versus the implementation and comparing the two. If we’re building a multi-core processor and we have one unit that does the caching and coherence, we do a unit test to do a verification of the algorithms. Out of a team of 13 people, there are two people full time on the verification. Most of the other work is done by the architects and designers because they’re familiar with the results of the verification.
Clermidy: We’re developing a network on chip with different protocols between the cores. We don’t need to wait for the implementation of these protocols to verify whether it’s correct. We can do some formal verification, for example at a very high level. When we go into the details, using the golden model of SystemC is the right way to go. You will not develop multiple different testbenches. You have just one. The problem is simulation time. Sometimes you have to develop very specific tests and know what has to be covered.

By Ed Sperling
System-Level Design sat down to discuss ESL modeling with Anmol Mathur, CTO of Calypto; Steve Frank, CEO of Paneve; Fabian Clermidy, senior architect at Leti, and Sylvian Kaiser, CTO of Docea Power. What follows are excerpts of that conversation.

SLD: Why is ESL growing so slowly?
Mathur: Part of the problem is the definition of ESL. For some people it means a change in the level of abstraction. My opinion is it involves a lot more than that. It requires a whole ecosystem of tools and methodologies to evolve along with the level of abstraction you’re doing for design and verification. But as you shift the level of abstraction up from C to C++ and SystemC, what portion of the design can be effectively represented and verified along with RTL is a challenge. That means you have two different kinds of models and two different kinds of expertise in your design team. Then there’s the other issue of keeping the models in sync. If you’re generating RTL anyway, you need to make sure the system-level model is consistent with the RTL model.
Kaiser: There is no doubt ESL is widely used for real problems. ESL can be used to explore the architecture. It can be used to create hardware models. These various usage models prove that ESL has value for the user. At the very beginning of SystemC development, I don’t know whether people had this full picture. The use of SystemC is widespread now and it addresses real needs on the market.
Frank: I don’t really think of it as ESL. I think of it as a problem where we’re designing a general-purpose processor with a small number of people as opposed to teams of hundreds that build them for big companies. You have to think differently. We started doing prototypes of designs in 2005 using SystemC as an implementation model. If you take the language and layer a methodology on top of that, what we have at the end is 20,000 lines of SystemC that’s equivalent to designs that are 1 million to 2 million lines of Verilog. As a user it did require us to layer a methodology on top and to create pieces that fill in what those tools don’t provide. From a system-user perspective, I don’t think any of the tools out there deal with the whole picture yet. We needed to do some things on our own to make it work.
Clermidy: We are quite similar. We have small teams and were an early user of SystemC. We’ve been using SystemC since 2003. What we intend to do with ESL is use it from the very high-level model to the RTL and down to the gate. So we’re developing something at a high level, something at a low level, and we have a gap between the two levels. We think SystemC is very important for architectural exploration.

SLD: Are you using TLM 2.0 and IP-XACT?
Clermidy: Yes, we are using both. We are doing exploration of the full architecture. What’s missing are some of the tools. At this time, we can’t get everything we want. We need to be able to use the tools more efficiently.

SLD: Is it a problem to keep all the models in sync?
Mathur: That’s a major challenge, from RTL on up. If you look at the RTL design and verification and implementation flow, you have a very clearly defined entry point. Over the years people have standardized on the Verilog and SystemVerilog subset. It’s a very clearly defined flow. But when people move to a different starting point in terms of abstraction, the interface libraries are different. First, there needs to be a convergence in the subset of SystemC. That’s starting to happen, but there has been a lot of confusion about what tools to use. There have been many levels of abstractions and interfaces over the past 10 years. Eventually people will converge on a high-enough level of abstraction that also gives them a path down into silicon.
Clermidy: It’s very difficult to have the same models for different levels because we have very different needs. For example, we are working on power enhancement. We now have dynamic voltage scaling. It’s hard to get a good estimation of power on a chip using low-level or mid-level estimation. You need to do this at a high level.

SLD: But don’t you also need some accuracy for those numbers so they actually mean something?
Clermidy: Yes. You need something that is at a high enough level to be able to try things very quickly, so you need to be able to mix this high-level modeling of power with some low-level power. Ten hours of simulation just for one core measurement is too slow. You need to do it quickly and go on to something more accurate after that.
Frank: We’re building a processor, so it’s a special case. But we have an architectural model based on a markup language that’s defining the behavior of an instruction set. That drives automated software that implements our instruction set simulator and our compiler for other tools. Then there’s the actual SystemC, which is the implementation path. So we have two very different implementations for a design. We also have a tool that explores the state space at instruction level because we’re interested in verification of instructions and sequences of instructions.

SLD: Can you keep those two models in sync?
Frank: Yes, and we depend on the fact that we can run the verification suite across both—and they’d better agree. We have an automated process with hundreds of thousands of instruction sequences that are 10 to 15 instructions long. We run those against the instruction set simulator and against the SystemC design, and we look at the before and after state and match them. We run those every night. There are challenges in keeping those in sync, but our model is based on doing that.
Mathur. The two-model style works well. People have RTL and a higher-level executable model. Two models has been the norm. But right now people have algorithmic models, fixed-point models, models that potentially can go into high-level synthesis. That’s the challenge.
Frank: The golden reference model drives our instruction simulator and all of our other tools. We’ve automated a bunch of that. In some sense, the SystemC is much higher than RTL. On the implementation side we resist all temptation to have more than one. We have the model police who say, no matter how tempting it is to bifurcate that model and make something for simulation and something for synthesis, that bites you every time. But within the SystemC we have evolved the methodology where in parts we use a TLM and in other parts we specify how things run on a cycle-by-cycle basis.

SLD: But does that work for an SoC, as well?
Frank: There is something like that for an SoC. Having this discipline sometimes makes you do a little more work, but in the end you have something that’s correct by construction. And every time we deviate from that, we pay.

By Gabe Moretti
Electronic computing systems have gone through an evolutionary cycle since the invention of the mainframe, and the process is continuing. Semiconductor technology, mostly based on CMOS fabrication methods, has enabled an increase in design complexity and device functionality that have revolutionized the world.

But 20nm processes may be the last that obey Newtonian physics. The next process, 14nm, must deal not only with atomic effects, but most likely with quantum effects. At those dimensions, the laws of physics laws are different and much more costly to obey.

The development of electronic computing devices
A brief history will help clarify this. Until the late ’60s, mainframes were the only way to execute computer programs. The hardware was built by electronic engineers, the operating system and device drivers by system programmers, and application programmers developed application programs to automatically solve specific problems.

The introduction of microprocessors followed the increased capacity of manufacturers to diffuse sufficient transistors on a die, and opened the opportunity to build a computing system on very few—and eventually only one—printed circuit board. The systems were still designed using standard parts from suppliers offering both digital and analog components and continued the separation between hardware and software.

Synopsys’ introduction of the first commercially available digital logic synthesis marked a watershed in the design of computing systems. By 1992 Design Compiler was mature enough to understand the semantic flavor of both VHDL and Verilog. It allowed designers to develop integrated circuits that replaced the functionality of standard components to such an extent that it made that industry relatively obsolete. Only analog components survived, because no one had found a way to synthesize an analog design in a cost-effective manner.

Today ICs containing hundreds of million of transistors are built almost routinely. Analog functions can be easily integrated with digital function using IP cores, or, in some cases, even take advantage of specific analog synthesis applications.

The EDA industry is focused on enabling engineers to do the same thing with every processing node. Integrating more functionality in an IC seems the “thing to do”.

Reality will force a new paradigm.
But during the impressive growth in computing capacity of an IC, the semiconductor industry has failed to manage costs. Financial realities are replacing engineering capabilities as the determining factor in deciding what to build and what markets to serve. The ITRS road map shows that unless a new development paradigm is found, the cost of developing an ASIC could reach the $1 billion mark by 2015. This, of course, is an unsustainable proposition. It just does not make sense.

The generally accepted architectural solution today is to design and build a family of devices. Starting from a common hardware architecture, designers count mostly on software to tailor each device to specific tasks or human interfaces. The aim is to keep manufacturing costs constant, or to slightly lower them by increasing yield, while producing end products that look different enough to entice consumers to purchase a new device in the same family every couple of years.

This strategy is enabled by the fact that CMOS fabrication technology has remained constant enough, from a product design point of view, to allow engineers to focus on integration as the primary goal. The increasingly complex DFM, meanwhile, has followed the rules of Newtonian physics. The last process that supports this approach is now being ready for commercial release—the 20nm node.

To design and develop such complex devices, engineers have had to face the daunting task of designing hardware/software systems in the same amount of time as was required for hardware systems. This has turned out to be impossible, because no one can debug a software system without executing it on the hardware it is destined to use. EDA vendors have used their creativity to provide virtual prototyping capabilities. Just like in the old days when engineers developed instructions set simulators of the CPU, today virtual prototyping aims to allow the development of a model of the hardware system before the system prototype is available.

This is not an easy task, and one that has yet to reach maturity. In the last couple of years Synopsys has focused on developing and supporting efficient virtual prototyping. After purchasing Virtio a few years ago, it discovered that having a virtual prototype of a CPU alone was not enough. It looked for complementary technology and eventually purchased both CoWare and VaST. Last week Synopsys announced the result of the integration of these technologies: the Virtualizer. The product is a big step forward, but it still is based on the common methodology of building a compute system in CMOS.

A possible future
The EDA industry was built to provide tools for hardware designers. This has now morphed in supporting system designers, as well. But the tools still keep hardware and software as separate disciplines that require new methods to co-exist efficiently. In the future designers will have to look at providing complete system solutions that erase this distinction. A system architecture should not be based on the characteristics of hardware or software, but instead on the characteristics of the system itself.

Companies still have to address four fundamental issues in deciding to develop a product: cost (time and resources), power use, chip size and packaging, and product family ROI. These four items taken individually for a new ASIC program may be difficult to solve until development is so far along as to make it impractical to even start the project. That means system tools will be needed not just to estimate, but to predict with enough accuracy both the power consumption and the size of the device.

Reusable IP is a partial solution to the problem, but it is still marketed as a replacement to the old component market. In insufficient number of standards make the choice non-deterministic, at best. Hardware IP integration is still difficult and time consuming as busses become more and more complex. Even with advances in virtual prototyping, software development and integration will continue to increase in difficulty, especially due to the lack of standards in software architecture. There also are no standard platforms—true computing systems tailored to a specific application market. Standard platforms can deliver solutions to both power consumption and packaging, thus simplify the problem considerably.

This isn’t without risk, of course. It potentially puts EDA vendors in the position of competing with their customers. But if the customers fail, so will the EDA industry. EDA must still provide all of the tools necessary to develop a product specific platform, should a customer choose to do so, but an increasing number of companies will require system solutions, not just an inventory of IP components. To successfully grow, EDA must be in the system business, not “just” in the tools business.

By Ann Steffora Mutschler
Skyrocketing software development costs, which for years have been “somebody else’s problem,” are now firmly part of the SoC development teams list of headaches. That has made virtual prototyping far more popular, particularly at 40nm and beyond, where engineers are looking at this approach as a way of managing complexity, doing architectural exploration and even performing very early functional verification using abstract models.

These models are meant to provide the design team with a view of the device and its environment at varying levels of accuracy, depending on the user requirements. The hardware model can then be executed within the virtual platform with device drivers to enable concurrent hardware/software development, rather than waiting to write the software until after the silicon came from the fab.

“We see customers going through this interesting next leap of adoption,” said Steve Brown, director of product marketing for system design and verification at Cadence. “Our perspective is that the market has experimented with commercial virtual prototyping tools for the last several years, and through that process the normal discovery of the real requirements has been going on. What I see happening is a real breakpoint where the problem the customer has is now so significant that they are rushing almost in desperation to find anything that can help them with the problem of software and multicore, and the set of challenges that come with that.”

Looking at how virtual prototyping is used today, Marc Serughetti, director of product marketing for virtual prototyping at Synopsys noted, “You have to go back to where the value is. Where does it make sense? What do you get out of those virtual prototypes? If you look at the range of customers we are talking about, the first group of customers—the semiconductor companies—this is where it starts. Especially in markets like wireless and consumer you really have a lot of pressure on the timeline, needing to make sure that the software is going to run fine on the hardware. The whole concept here is starting my software development much earlier. In semiconductor companies that means before any form of RTL is available. That’s really the starting point for all of this—doing software development earlier.”

Earlier doesn’t just mean shifting the development schedule to start sooner so you can finish on time. It also means finding ways to increase efficiency of the software development because the hardware platform complexity is growing, the software content is growing, but schedules are not shrinking.

Some users build their virtual prototypes themselves, but there might be a split within the customer community. For example, a modeling group may be involved in creating the virtual prototypes while an internal set of consumers such as the software engineers within the company actually use it.

“There are various ways of how a virtual prototype gets created,” said Shabtay Matalon, ESL market development manager at Mentor Graphics. “They can be created within a company, they can be created in a partnership between a company and an EDA vendor, but there is clearly a separation between those that are involved in the creation process and those that are on the software side that are using it, which usually are not involved in the creation process.”

Bill Frome, virtual platform manager at Texas Instruments, noted that his company has been leveraging virtual platforms for a number of generations of chips starting back to OMAP 1 days and now currently in OMAP 5.

“The focus has been on leveraging that time from pre-silicon development so we can begin verifying our software and more of our functionality before we actually get to silicon. Like a lot of companies we’ve got shorter and shorter cycle times as far as getting customers into production, so we are seeking to leverage that virtual platform to get more software running sooner to reduce cycle times. That’s really a key for us,” Frome said.

TI has been partnering with Synopsys on its virtual platform development to create the platforms. In some cases Synopsys develops the models for TI and in others TI develops the models. Then Synopsys does the final platform integration and turns it back over to TI.

“There are some other third parties that come in there as well including ARM,” said Frome. “We essentially take that final platform and then internally, we unleash our developers on that to where we can actually boot software on there, begin running some of our use cases before we get to the silicon level,” Frome continued.

Throughout the process communication is critical. Frome noted that there is definitely a communication path as far as when the architects are developing the specs. The specs are shared with the users so they can understand what that model is intended to do. Then, as a model is created, there is a feedback channel because the engineers developing the models may have questions about specific details. The final level of communication involves verification, when the models are actually being utilized.

“What we’ve seen is if we have really well written specs and there is good communication between the architects and the model developers, by the time we get to the final model, that usually goes fairly smoothly—it’s more a clarification,” said Frome. “There will be some updates that need to happen but they are fairly minor in nature at that point.”

Rules of engagement changing
None of this is done in a vacuum, however. The rules of business engagement are constantly changing. Kurt Shuler, director of marketing at Arteris, says some cell phone vendors that design their own chips are now providing requirements to their semiconductor suppliers. “They are communicating very specifically to the chip provider about the specific requirements and they are in the process of using the platform architect-type tools to say, ‘Here’s the scenario, give me a model of your [chip] and I will tell you back what changes I want you to make to your hardware to make it better for me.’ That is a totally new thing.”

Marc Serughetti, director of product marketing for virtual prototyping at Synopsys confirmed this activity. “There is definitely some of this happening. And that happens not only on the software side, but on the architecture of the SoC, too. They want to give feedback as early as possible in terms of making sure that what they have as software will run efficiently on the hardware they are getting from the semiconductor company. So we are definitely seeing this request going back and forth. One reason is to make sure the hardware and whatever software you’re getting from the semiconductor maker meets your requirements, but also to start developing that software earlier. In some markets, like consumer and wireless, it is so competitive that a two-month difference can be huge. The earlier they can start, the better.”

Some go as far as saying these business engagement changes are exactly why ESL is happening now.

“This is the key reason ESL and virtual prototyping is becoming a reality now,” asserted Mentor’s Shabtay Matalon. “In the current level of competitiveness that exists in the marketplace and the complexity and the amount of software that is embedded in each one of those devices, the software people don’t want to be treated as the afterthought in the design cycle. The only way that they will become part of it is if they get models not only before the boards are done and before the processors are fabricated, but even before the RTL is implemented. As soon as they know there is a set of processors that are in the works, they want to participate. They are putting significant pressure on the semis to give them early models of their designs even before RTL is solidified so they can influence the RTL.”

By Ed Sperling
There are two schools of thought in designing complex SoCs. One says that increasing complexity requires a higher level of abstraction. The other says providing enough detail to get the design right is the only effective way to do it.

There are staunch proponents of both approaches, but what has been missing are bridges to tie the higher level of abstraction to the more laborious—and much slower—gate-level details. Tools that allow more exploration on both sides are beginning to emerge, along with a recognition that they are definitely necessary to complete designs.

These bridging exploratory or path-finding approaches rely heavily on what-if questions. What if a certain piece of IP was used next to another piece of IP, for example? Would a different IP block work better? How about if the frequency of a core was changed or a different I/O was used? And what happens if the voltage in one area is lowered or raised?

These kinds of tradeoffs are common, but increasingly each step of the way can update other pieces along the design flow. At 45nm and beyond, there are many of these kinds of tradeoffs, and the number increases dramatically at 28nm and in 2.5D and 3D structures.

“There are some path finding methodologies available today,” said Riko Radojcic, director of engineering at Qualcomm. “The part that is missing is incorporation or spatial awareness into these methods and tools, which is why it is especially important for 3D exploration. I started feeling the lack of this capability when we first looked at the tradeoffs between regular ‘complex’ design rules and ‘gridded’ design rules, and when we were looking at the tradeoffs associated with aggregating memories into a smaller set of larger instances and equipping them with redundancy versus having many small instances all over the place. In both cases we needed spatial awareness that was not easy to import up to the SoC level. “

Help is on the way
All of the major EDA vendors see opportunity in path finding at the architectural level and early in the design process. For one thing, there is already market demand for these kinds of tools among their largest customers. For another, these kinds of capabilities can be added into existing tools, so even though the development work is difficult it’s not the same as developing and marketing new products.

“The conflict on the design side is between design complexity and schedules remaining the same,” said Gal Hasson, senior director of marketing for RTL Synthesis at Synopsys. “To make matters worse, many designs are done by geographically dispersed teams. Once the RTL is complete the constraints might be way off. So you clean up the constraints, and based on this data you check whether the design is likely to meet the requirements of area and clock speed. Many times the answer is ‘no.’ This is the big challenge we’re wrestling with, and it’s causing designers to re-think the flow. You need early exploration that enables RTL and constraints to get a detailed analysis.”

The addition of software development only complicates things further.

“It used to be one architecture on a spreadsheet,” said Shabtay Matalon, Mentor’s ESL market development manager. “Now there’s an architecture team and companies are bringing in people from different disciplines into that team.”

Matalon said it’s still possible to build everything using SystemC and TLM 2.0 models, but those models require additional tradeoffs to be analyzed. Rather than starting at functionality and then moving onto timing and performance, power has to be analyzed from the outset. And then it all has to be tweaked and reanalyzed as part of the exploration process.

“As you go through the refinement process in a design you have to recalibrate your initial assumptions,” Matalon said. “The number of ‘what ifs’ and the dimensions of exploration are exploding as we move to multicore. And then you have do deal with another dimension of how you achieve performance and power.”

Where bridges are needed
One of the most important areas where this kind of bridging is necessary is in the hardware and software arena, which may be one of the hardest areas to fix. While tools are available for prototyping software, the real-time links between hardware and software design changes are sparse. From a chipmaker perspective, though, these are part of the same thing.

“We don’t see hardware and software as separate worlds,” said Bill Bench, senior director of the WLAN Media Business unit at Broadcom, which is designing wireless video chips. “You can’t do hardware without the software.”

Bench said what Broadcom also finds important for engineers is a deep understanding of cores, the electrical characteristics of a particular process node, and the availability of the right libraries. “What’s most important is that engineers are paying attention to these problems. We expect that EDA tools will mature over time,” he said

Another trouble spot is in the mixed signal world, where different engineering teams can lead to power problems and proximity effects that can impact signal integrity.

“We need to break down the silos,” said John Stabenow, group director for customer/analog design management at Cadence. “At 28nm the SoC is still distinctly divided into digital and analog. We need to bring more and more intelligence into layout at the designer’s desk and be able to abstract an analog block. The challenge is that the schematic has to wait for the layout engineer to complete the job, but there are layout-dependent effects that can impact circuit performance.”

Starting at the beginning
A common theme that runs through all of the current thinking in EDA and system-level design these days is that complex design is best addressed at the architectural level and very early in the design phase rather than later in the design.

“There is very limited opportunity to go back and change a decision,” said Ravi Varadarajan, an Atrenta fellow. “If you change a decision because the chip is not feasible, it’s a very long and painful process. The best way to avoid that is to explore more at the front end. And if it’s important in a 2D chip, it’s a necessity at 3D.”

This is easier said than done at advanced geometries, where process rules are constantly changing, process variation is higher, and even some of the structures are likely to change. At 20nm there almost certainly will be some double patterning required. At either 20nm or 16nm designs it’s also likely that designs will begin to incorporate transistor structures such as FinFETS. How those will work with new types of memory and at a variety of voltages is unknown, but it’s almost certain that all of this will require far more exploration than existing designs.

“But even in the early stages the exploration has to involve fundamental techniques that correlate to the back end,” said Varadarajan. “You still need to set up constraints and test against those constraints.”

Conclusion
Simplifying the complexities in a complex design process will probably never be complete. It will be a long-running process of development. There are simply too many variables and tradeoffs, and at advanced nodes and in stacked die those tradeoffs can have much larger effects than at older nodes. Some of those effects are physical, some are electrical, and many are business-related.

But it’s also clear that preventing problems at the front end can avoid many problems at the back end if there is a better understanding of all the factors that go into make a design work. At the very least, awareness of this problem is rising, and some of the tools that have hit the market over the past year are a reflection of that. Still, far more work needs to be done for the industry to continue progressing along the Moore’s Law road map and into 2.5D and 3D designs.

System-Level Design sat down with Thomas Bollaert, product marketing manager for Mentor Graphics’ high-level synthesis product line; Johannes Stahl, director of marketing for system-level solutions at Synopsys; Ran Avinun, marketing group director for system design and verification at Cadence, and Brett Cline, vice president of marketing and sales at Forte Design Systems; What follows are excerpts of that conversation.

SLD: Is the TLM 2.0 model going to be sufficient? There is now software, power, IP, and new layout issues in 3D.
Avinun: I don’t think the industry needs more standards and levels of abstraction. I think the problem is actually the opposite. Between TLM 2.0 and 1.0 there are untimed models, loosely timed models, approximately timed models and cycle accurate. For each one of them the subject is not fully defined for virtual platforms and a synthesizable subset. The direction is to eliminate some of those levels and define them better. Obviously certain companies will push new levels and new standards. But if you talk with the customers the complaint isn’t about the need for new standards. It’s about minimizing the subsets and defining them better. They can’t maintain five or six levels of abstraction with five or six sources.
Cline: We agree with that. The state of the art for each level of abstraction may not be there. If you have a TLM 2.0 model that’s modeling virtual platforms at a software level that may not be synthesizable in a chip smaller than the size of a table. There are certain constraints to produce good hardware. It’s not just what you put in software. So you have the TLM model for a virtual system platform and what’s synthesizable and you might have a gray area in between. How do you migrate both so you have enough abstraction and enough detail?
Avinun: And the push from customers is to have enough source files so they can serve them for multiple use models. Otherwise it’s an infinite amount of work for them and it’s confusing. You have models here and other models here. Did they come form the same source?
Bollaert: In regards to TLM 2.0, there’s lots of noise and communication around it. I think it’s very good for what it does, which is bus-centric communications. But it’s not about using TLM 2.0 everywhere else because it’s not made for that. It’s not about TLM 2.0 everywhere. It can be complicated and it should be simplified, for sure, but it’s not going to be everywhere. What will be everywhere will be TLM 2.0 concepts.
Avinun: People are using a combination of SystemC and C++, but processor models are still based on C.
Stahl: It doesn’t really matter what’s inside the model. TLM 2.0 is an interface model. It can be a C model inside. It can be a model that generates C. It doesn’t matter.
Avinun: And sometimes people need to use TLM 1.0 and sometimes they need a certain point to move into C even before they move into RTL. The pins are still signal-level pins. If the IP you’re developing is interacting directly with the I/Os, at the end of the day you need to define the order of those I/Os, one to nine or nine to one. If you don’t, the tool doesn’t know what to do. It’s the same with RTL. I don’t see how people will be able to avoid RTL for the foreseeable future.
Stahl: If you look at model availability on a smaller scale, the customer needs models developed for simple transactors. A methodology is nice, but they don’t want to develop it themselves. They want to have a block to plug into a block diagram-based tool and start simulating. You don’t care about the simulation modeling standard. It just needs to work.

SLD: Over the next 18 months we start moving into 3D stacking, or at least 2.5D. What happens with the tools that are there now?
Avinun: As far as the functionality of the system, there won’t be any significant change. At the end of the day, it might affect the back-end tools. They might provide you a different number.
Bollaert: It’s not so much about the change. It’s another opportunity for system-level. If you can stack chips on top of each other, even simple things like memory with a through-silicon via, you can access much wider bandwidth. What are you going to do with that? Now you can completely change the architecture. You have much more bandwidth and different interconnects. Instead of accessing data that’s 32 bits by 32 bits, now you can have a much wider bandwidth. There is great potential with 3D chips.
Avinun: So if you are designing new IP and using high-level verification, you still want to make the tradeoffs. You will get the same library as today with different numbers. It will be transparent to you. And you may get different optimization. But it’s not that much different.
Stahl: But it is more design space. The technology we have today provides a huge space for design exploration. Maybe this will add another dimension. But it’s not fundamentally changing the equation.
Bollaert. It does provide a wider opportunity for ESL. But it’s more than that. There will be a change in technology, as well. It’s not just about libraries. Libraries will change and they will reflect some new possibilities. But you also need to be aware of placement. If you have TSVs and I/O clamps in your chip you cannot just assume your design will work. 3D adds a new dimension.
Cline: It’s trickle up technology. As soon as people get good at 3D this information will move up. You only automate and abstract something once you become expert at the root level. Over time we’ll get really good, the models will get really good, the understanding of what to do with those models will get really good, and then people will start to use those better.
Avinun: There is a challenge to link ESL to high-level synthesis and the place-and-route tools. That’s the first-order challenge. But whether it’s 2D or 3D, first we need to solve the initial challenge.Back in 2005 when people talked about the challenges in ESL, one was the specific implementation capabilities of RTL. We’ve gotten better at this, but even today many tasks are being done at the RTL level rather than earlier. We have to solve this problem before we move to 3D.
Stahl: Someone needs to simulate at this low level. Once you can simulate you can model, and then you can have a synthesis flow to utilize this information.
Bollaert: Modeling and simulation cannot go hand in hand.

SLD: From an education standpoint this is a different world, isn’t it? Right now most ESL is for top customers. In the future everyone will have a role in complex designs, and everyone can use these tools.
Avinun: But if you look at the key challenges, it’s still the integration of IP and of hardware and software. If something hangs up you need to look back and figure out if it’s the IP you bought or one of the software stack layers. Those problems are still going to be there.
Cline: A big company is a subset of the market. You have early adopters at these companies, but if you go to the designer next door they may not touch it. Then you can go find a startup that’s going to bank their future on a new methodology because it’s quicker. Any company can be a subset or superset of the market. I’m not sure it changes our education mechanism.
Avinun: We all have the challenge to educate designers. That’s half of our engagement process, especially for the new tools. But every time you go to the next group it seems they don’t know anything about this and you have to start all over again. The industry has been stuck at the same level of abstraction for 20 years. The people who were out of college 20 years ago don’t want to learn about something totally new. And if you talk to the recent college graduates they may know software but not hardware. You have gaps on both sides. Over time it’s changing, but it’s changing slower than you want.
Cline: There’s about $200 million in ESL revenue. We don’t think that’s the goal. There’s $2 billion or more. As a result all the companies here are pitching a common message. That hasn’t happened in all segments of EDA, but it is happening in ESL.
Bollaert: Today HLS can do more than blocks. It can do complete subsystems. There are a lot of benefits for people out there. Whether they want to test hardware and software ahead of time, validate architectures for performance or power, or reduce time to verified RTL, ESL can really help them.
Avinun: Once we get to the point where people can’t compete without these tools, then you’ll see a major shift in the market. I think we’re getting close to being there. Large companies—at least their executives—are realizing this is the case. They’re instructing their middle management that this is the way you need to structure the company to do this. It takes years for these shifts to occur, but once they do start the shifts happen very fast.

System-Level Design sat down with Thomas Bollaert, product marketing manager for Mentor Graphics’ high-level synthesis product line; Johannes Stahl, director of marketing for system-level solutions at Synopsys; Ran Avinun, marketing group director for system design and verification at Cadence, and Brett Cline, vice president of marketing and sales at Forte Design Systems; What follows are excerpts of that conversation.

SLD: What are the big problems in system-level design?
Cline: When it comes to high-level synthesis, we’re like the dog that caught the car. We’ve been talking about this technology coming and coming and coming, and all four companies here now have real customers, real tapeouts, and real products in Best Buy or Fry’s that have had a chip designed with one version or another of software that has produced a new design flow in these chips. As an industry, we need to figure out how to unify that and make it more of a standard among companies that have spent hundreds of millions of dollars over the years on their own internal flows and now can start to adopt different technologies. There’s a different side, too. There are a lot of pieces available in the RTL flow that are just now making their way up to the system-level design flow. That includes new tools, migrating abstractions up beyond just high-level synthesis—everything from virtual platforms to high-level synthesis tools to code coverage.
Avinun: Over the last 10 years many of us have been involved in ESL. Initially, the focus was just to get the tools to a sufficient level of maturity. With high-level synthesis the goal was to get quality results so customers are willing to look at these tools compared to hand-written RTL. In the last few years there has been more interest by customers. Customers don’t question whether they can do it anymore. We’re moving to a different problem. If 90% of a design was written with legacy RTL, what can be done with those pieces? If every new design was created at another level of abstraction it would take another 5 to 10 years.

SLD: But companies are comfortable with this technology now?
Avinun: That’s the other issue, education and getting to a comfort zone. In 1993 when RTL was introduced to replace schematics, customers still kept their schematic books. But that happened pretty fast—five to six years. Now there are a lot of legacy tools that have to go through this shift. If you talk to 10 engineers, 8 would say they’re not comfortable with C++ or software and they aren’t interested in doing this—unless someone forces them. Over time successful companies will force them to change to be competitive. We tend to talk about ESL in isolation. We need to look at the overall issues in design verification, not in ESL. If we don’t, we’re still looking at point tools and point domains and ignoring other domains that are just as important. The big picture is designs are getting more complex and there is software that needs to run on this.
Stahl: The big picture is important. What drives ESL from a top-level perspective isn’t necessarily tied to the SoC guys. It’s the guys who use the SoC at the end of the day. Ideally for them everything would be in software. After all, why do anything in hardware if you can avoid it? So they use as many cores as they can to get everything to run, but they find it’s not good enough. They cannot implement everything in software because it takes too long. In many cases it is faster to develop a hardware block. Most companies that develop hardware blocks using high-level synthesis add content that is innovative. But if you cannot integrate a high-level synthesis flow into a good chip-level verification flow then people won’t adopt it. If you cannot integrate it into a software flow it won’t happen, either. It’s not a standalone event. From a high-level perspective, high-level synthesis helps you to develop a block faster and to verify it faster, but you have to do it in an overall context.
Bollaert: The technology is not the challenge anymore. Many companies have been working on this for 5 or 10 years. Whether it’s high-level synthesis, virtual prototyping or other components, this is proven and customers should not be worrying about that. But you need flows and methodologies, and you need a complete ecosystem. It’s way beyond just EDA vendors. You need support from foundries, IP vendors and potentially from consulting and design services. These are the kind of resources people rely on. When you look at ESL, five years ago none of that ecosystem existed. We’ve seen a lot of progress since then. TSMC’s Reference Flow 11 is an example of that. These components give confidence to the user that it’s more than just tools. Beyond the ecosystem, the methodologies need to be firmed up a little bit. Until now there have been a lot of point tools. While this was adequate initially, people are asking for flows and high-level solutions. ESL is not only about high-level synthesis. Customers are asking for virtual prototyping and high-level architectural exploration. They also want tools that can talk to each other.

SLD: What changes in ESL now that we’re using more off-the-shelf reusable IP?
Stahl: What’s changing is that instead of using more internal IP companies are using more commercial IP. With commercialization, the expectations of customers are much higher in terms of quality and integration into the flows and verification and implementation. That means we need to have all the models for the IP. I’ve lived through this pain at CoWare, getting models for critical IP out to customers. It took a long time for the industry to convince IP vendors to do this.

SLD: But it’s getting even harder with proximity effects and thermal issues, right?
Stahl: Yes. At all levels of abstraction you have the complexity of the IP. And down at the technology node things are extremely complex. At the system-level, you have to understand what is the level of detail you want to have in the model to have a reasonable result from your simulation and verification—and speed. Customers want fast and accurate models. That’s possible in certain areas, but not in all, and not for all kinds of IP. We are defining what are the models you need and what makes them useful in the flow. That still is happening. It’s by no means complete.
Bollaert: It’s all about the make vs. buy decision. Even though IP is very prevalent there are still a lot of blocks and subsystems being created because IP does not address everything. The IP question is very important. You need to understand whether you can re-use something and how best to use it. These are system-level questions. One of the issues customers have seen with IP is that it has a limited life.
As you shrink the nodes, the IP may still work but it becomes sub-optimal. The need to re-optimize for a new technology node and avoid power issues and integrity issues isn’t easy.
Stahl: That’s not the biggest challenge for IP. The biggest challenge today is the moving standard and the moving stack. You may get a completely new standard, which means you cannot re-use IP.
Bollaert: That’s very true. The IP question needs to be looked at by specific application. If you are doing an image signal processor there is no need for IP. You need to develop that. For bus IP, it makes sense to buy it.
Avinun: We need to define IP. For small digital IP there are two challenges. One is re-use. They don’t want to re-invent the wheel every time they go from one process to another. They don’t want to re-invent an algorithm each time, either. This is about productivity. If you look at the transition to higher levels of abstraction, that’s what’s driving IP re-use. IP also can include subsystems. ARM’s IP is on a different scale. In their case they need a full ecosystem of IP providers. That’s one set of challenges. The other set of challenges is integration. You take IP developed by other companies and integrate that together. We are a long way away from where all IP can be integrated at a high level of abstraction, so we can’t throw away the other tools.
Cline: Companies are running into problems where the IP never completely meets your needs. It may not be at the cost you want or the process you want. What we’re finding is IP vendors are just now having the same problems as the semiconductor companies. They have to produce their IP faster, smaller, lower power, and if they’re using an older process they’ll never be able to keep up with a company like Sony or Samsung generating chips at all different nodes for all different kinds of products. Customers are now starting to take a look at the IP they’ve been buying and do it themselves because they can trim off 10% of the area or lower the power to spec or add some unique value—and maybe even do it more efficiently. We’re seeing more people move to their own internal IP model.
Stahl: That only holds for IP that’s specific to their products. Nobody in their right mind should do standard IP today by themselves. It’s not economical. The investment to set up an infrastructure, verify the IP and track a specification is the business of IP vendors.

System-Level Design talks about the challenges of ESL with Cadence’s Ran Avinun, Synopsys’ Johannes Stahl, Mentor Graphics’ Thomas Bollaert and Forte Design Systems’ Brett Cline.

By Ed Sperling
Growth returned to almost all sectors of EDA in Q3 of 2010, from ESL to semiconductor IP. Moreover, that growth occurred in all geographies except Japan, with Asia showing the strongest upswing.

In raw numbers, EDA revenue for Q3 was $1.3 billion, which is 11.9% higher than in Q3 of 2009. The numbers also increased sequentially by 6.9% over Q2, so the comparison isn’t just to a down year.

“Typically after a recession EDA lags,” said Wally Rhines, chairman of the EDA Consortium, and chairman and CEO of Mentor Graphics. “That makes this pickup especially encouraging.”

The big winners in the technology categories were IP layout, which grew 11.8% globally (28.5% in Asia/Pacific); Emulation, up 18.5%; design for test, up 75%; and IP, up 25%. ESL grew 4% and power analysis grew 30%, reflecting the complexity of designing semiconductors at advanced nodes.

The number of engineers working in EDA also increased by 1.9% to 26,474 in Q3.

Things were a bit slower in the system-design world. PCB and multi-chip module revenue were down 5.4% compared to Q3 of 2009. The four-quarter moving verage for this sector was down 1.8%.

By region, the Americas were still the strongest buyers of EDA tools. Sales were $577 million, up 12.9% over the same period in 2009. Asia/Pacific bought $274 million in tools, up 34.6%. Rhines noted that most of the tools sales in that region, which includes India, China, Taiwan and Korea, came from large multinational semiconductor companies, whose design teams typically are spread out around the globe.

Source: EDAC