Posts Tagged ‘JEDA Technologies’

Experts At The Table: ESL And Low Power

Friday, August 7th, 2009

Low-Power Design sat down with Walter Ng, senior director of platform alliances at Chartered Semiconductor; Brani Buric, executive vice president of sales and marketing at Virage Logic; John Sanguinetti, CTO at Forte Design Systems and Andrea Kroll vice president of marketing and business development at JEDA Technologies. What follows are excerpts of that discussion.

By Ed Sperling

LPD: How much does software affect the overall system architecture?
Buric: It can affect it quite a bit. If you look at Linux, that is a growing standard worldwide. There are more than 10 suppliers, so their target market is fairly limited and there is no common spec. So they overdesign to make specs for different target markets. Those are areas where if you do everything from a system-level design, you can save a lot because you can optimize where to share implementations.
Ng: One of the problems we see is the legacy mindset. Because the time-to-market pressures are so great, most companies don’t have the time to go back and re-do their design infrastructure. If your design teams are designing the next technology, they’re more than likely leveraging their previous designs. But because that wasn’t captured at the system level, it’s hard to go back and get an optimal implementation. You’re fighting to get this chip out the door and generate revenue. It’s not a matter anymore of trying to find the optimal implementation. And because of resource constraints, nobody has the luxury of having one team doing the implementation of the next design and having another team off to the side doing the more strategic infrastructure and maybe generating models for some of the existing IP that’s already been proven.
Sanguinetti: No one wants to take something that works and write a higher-level model of it.
Kroll: We do see that happening more often, though. People do see the value of the models and being able to integrate that into the whole system. More people are investing in high-quality models, verifying them upfront and making sure they represent the hardware. You can annotate technical information from downstream back to the model so that you really can do the verification or validation of the chip complete at the beginning. Then you have the process and also the possibility to say, ‘I have an RTL model of this. Does it still match the specification?’ Or if the software running on an FPGA doesn’t work you can go back to the model and match the software to the model and find the bug.
Ng: If the industry shifts to where designs get outsourced to the fabless ASIC guys—and from a business need that has to be there—then it might accelerate all of this. But it’s very tough for a newer company that doesn’t have a lot of legacy stuff.
Sanguinetti: That’s absolutely right. It’s the legacy stuff that gets left behind. For new code and new implementations, there’s a tremendous amount of value in ESL with faster time to market and better quality RTL. What we hear from our Japanese customers, after two generations of using this, the top thing they get out of it is IP re-usability. This was a revelation to them and to us. The real value of ESL is IP re-usability.
Buric: This trend will happen. About 20% to 25% of fabless startups today have, as part of their business plan, where they create a working component for something and then to sell it to someone who has a more complex chip. That is one trend. Another trend is the big companies are selling components like Bluetooth into even more complex designs for big bucks. You need a consistent way to transfer that knowledge. This trend of building bottom-up models will be there.

LPD: Does this trend toward a higher abstraction layer open the door for more startups, or does it close the door to them?
Kroll: I think it will open the door for more startups. If you can develop a component and it can be integrated in a chip. People can develop a technology or an FPGA prototype and sell it to a bigger company.
Ng: We have a couple customers. One we’ve supported on a 65nm process. They went out of the chip business and they’ve sold their designs. Now they handoff their design, which gets integrated into their customers’ larger design. In effect, we’ve lost a customer. Instead of selling the chip, they’re selling the design. I’ve seen a few instances of that.
LPD: There are a lot of companies that have their own homegrown tools. Does complexity make those tools less valuable over time?
Buric: If you think about the way the industry has grown up, there are two directions. Established companies figure out ways solve a number of problems specific to them. Equally important, a large number of startups have experience with individual problems and develop tools to solve those. There is a lot of internal knowledge captured in the early phases of design, and I believe there will be a lot of startups based upon that knowledge.
Sanguinetti: I agree with that. The fundamental dynamic of EDA involves people who had a problem, they leave the company and form a startup because they think they have an idea of how to solve it. They develop a solution to the problem and then get acquired by the consolidators. I think that will continue. The only fly in the ointment is it’s becoming harder to solve a problem in an EDA context, and that’s becoming increasingly necessary. As the consolidators have gotten bigger and have more influence they put roadblocks in the way of little companies. System Verilog is a killer for someone who wants to support RTL’s input. They have to import System Verilog test bench code as input. They have to spend man-years on it, whereas 15 years ago doing it in Verilog wasn’t too hard. Things have gotten harder for the little guys.

LPD: They’ve gotten harder for the big guys, too.
Kroll: One of the thing that needs solving is where do the models come from, who can use them, and how to improve success with them as a vehicle to solve problems. Currently, the big guys have the manpower to build those models. Maybe everyone needs to pitch in and have the models available. TLM 2.0 is one of the bigger opportunities out there. Right now there are IP vendors developing models, the semiconductor companies are also developing models and then the ESL companies are developing models.
Buric: Once we have enough models out there it will be chaos, and then there will be standards.
Ng: There are a lot of proprietary systems out there and it’s easy to develop models for those within that context. If at some point those systems run out of gas, you can have a wider solution and more standardization and collaboration.
Buric: Another problem is that certain groups create obstacles. They don’t want to adopt a common model. This will continue for awhile. If I create something in silicon and it fails, that’s my problem. For that reason, there will be constructive paranoia. Failure costs a lot. On advanced process chips, you can’t fail.

Experts At The Table: ESL And Low Power

Friday, July 24th, 2009

Low-Power Design sat down with Walter Ng, senior director of platform alliances at Chartered Semiconductor; Brani Buric, executive vice president of sales and marketing at Virage Logic; John Sanguinetti, CTO at Forte Design Systems and Andrea Kroll vice president of marketing and business development at JEDA Technologies. What follows are excerpts of that discussion.

LPD: As we go down the Moore’s Law road map, are there more variables to consider that affect power?
Buric: You can trade off area and performance for power three or four ways just by modulating the gateway. You can implement three different sets of libraries because you are concerned about leakage. But you have to contemplate all of that on a system level because you want to verify that it matches your spec.
Sanguinetti: There are new constraints that are being put on whoever is providing that input. If it’s an engineer writing RTL by hand, he’s got to do those. If it’s a synthesis tool providing RTL, it has to do the right thing. Ultimately, one of the biggest problems we’ve got is understanding what’s going to happen downstream.
Buric: Very often, when we talk about system-level design, we are talking about SoC-level design. More and more, system-level design will be partitioning between multiple SoCs. You will have a completely different set of problems with interfaces, which work at multiple gigahertz speeds. You have to find a way to model and verify. Today, ESL doesn’t do that.

LPD: Are you talking about board-level design?
Buric: Everything we’re doing is SoC-centric right now. We do not contemplate what happens outside the chip.
Kroll: Companies like VaST and Virtutech are working with Freescale and the big networking companies to look at those issues like Internet connections and other connectivity problems. While it’s not perfect and automated yet, there are known steps of how you get from one area to the next. To me, ESL is coping with the complexity of the systems at the moment. It’s not one person who can do this, either. So you need to work in a team and share resources. Then you have a flow with high-level synthesis and possibly more flows to incorporate IP.

LPD: The definition of what is ESL is changing. What will ESL be in two to three years.
Sanguinetti: ESL is just a convenient acronym for the next level above RTL. It’s just going to grow.
Buric: It is whatever specification the system needs.
Sanguinetti: You can apply that to RTL, as well. And you can do FPGA prototyping. That’s how people are doing full system simulation. It would be nice if they didn’t have to do that.
Kroll: To me, ESL mimics hardware and software timing at a system level, and then being able to break it down into the right flows. That’s compilers and operating systems on the software side, and on the hardware side it’s implementation from flow to silicon.
Ng: With so much of the leading edge being driven by the consumer and form factor, the ability to do this design exploration and try out different types of architectures and splits between hardware and software, get to the optimal implementation and minimize the risk of issues downstream is really going to be the boundary. One of the biggest gripes in cell phones and laptops is battery life. Battery technology is only progressing at a limited rate. A netbook that last nine hours is going to get more attention than one that lasts two hours. It’s not so far off you’ll see a quad core in a smart device you’re carrying around all day. The need for power efficiency will go all the way back to the system design.

LPD: ESL used to be all about the best possible design. Is it changing to just getting the chip out the door?
Ng: I think so.
Sanguinetti: With our first customers, they didn’t do design exploration. That was okay for that time. As these SoCs are getting more complex and algorithms are getting more complex, this design exploration has gotten to the point where people are paying more attention to it. If you can get a chip to the point where the first tool in the chain will swallow it, then everything down the chain will work.
Kroll: ESL started out as architectural exploration. The realistic view is, ‘Well I have my product and I want to add more functionality.’ When you want to get a product out, you add a little bit. A lot of tools were not ready to do that. You assume you start from scratch. At the end of the day, the shift will go to getting the chip out. But as you understand more of the process and the tools can handle it, there will be more exploration. That’s probably five or six years out, though.
Buric: The last three to four years, what I’ve seen is companies overdesigning functionality and then cutting it out. They reserve additional function and give it to customers who need it.
Ng: We’ve seen that, as well. It’s on-the-fly additional capabilities. If you can’t get it working on time, de-code it out. It’s fairly common.
Sanginetti: We had a customer where the first spec had 10 processors. If they had gone forward with this spec, it never would have been successful. It was programmable, but it never would have been able to compete on power consumption and area with a hard-coded solution. We could show them with ESL that you could cut it back to four processors.

Experts At The Table: ESL And Low Power

Thursday, July 16th, 2009

By Ed Sperling

Low-Power Design sat down with Walter Ng, senior director of platform alliances at Chartered Semiconductor; Brani Buric, executive vice president of sales and marketing at Virage Logic; John Sanguinetti, CTO at Forte Design Systems and Andrea Kroll vice president of marketing and business development at JEDA Technologies. What follows are excerpts of that discussion.


LPD: What will the differentiator be in the future?

Sanguinetti: We have to take as input designs that are relatively high level. Our customers tell us the higher the better. We spend most of our time in raising the level of abstraction. But we also have to be cognizant of what happens downstream. We don’t want to put out RTL that is junk. And it can’t just be acceptable to the tools. We want to put out RTL, for example, that can make dramatic improvements to power optimization. That’s true with any of the logic synthesis tools. But we don’t have very good visibility downstream, so we’re very reactive.

Ng: On our end, everything is about cost. Cost touches time to market and all the specs. We’re seeing much more widespread adopting of ESL tools. If you’re looking at power and selection of architectures, that can be most influenced at the system level. At the gate level, optimizing on power techniques, the wrong selection of an architecture can more than skew what kind of power you’re going to get. With more integration happening because of silicon’s capabilities, the more complex functions and the more important ESL should be. Getting from the algorithm level through system description, RTL and the physical implementation is a huge cost. The verification of each one of those representations is a huge cost. The more structured that approach can be, the better. Most of the leading edge of design is consumer applications, and these are extremely cost and power sensitive applications.


LPD: Why hasn’t ESL taken off until now?

Buric: It did. But there’s a difference between what has been used and what is commercially available. ESL has been adopted in one form or another over the last 15 years, at least. Most of those are internally developed tools targeted at a particular application. If you want to move from there to the commercial market, you have to make those tools very generic. That makes the problem more difficult to solve. But complexity of designs is going through the roof, so you have to start using these kinds of tools everywhere. If you’re not first-time right, you can lose your business or even your company, but you certainly will lose your market opportunity. It is now a must-have to make sure everything downstream matches your intent.

Kroll: One of the problems in ESL is the models are not of sufficient quality to estimate what’s going on in the technology later on. What is the power consumption, what is the area and what is the cost factor for the models. That’s the problem in the commercial market. You can’t make the tools broad enough and still use them for a specific task in an individual company for a specific application.


LPD: Does the number of models increase for each node?

Sanguinetti: That’s the way abstraction goes. We recognized we need a higher level of abstraction in ESL for the past 15 years, but it’s taken a long time to get to any kind of agreement about what it looks like. There are a number of approaches to it, which are largely overlapping. That’s what happened with SystemC. It took a long time before it became a standard. TLM is the same. There were a lot of ways of abstracting out interfaces. That’s why there are a lot of different models.

Kroll: They just specified TLM 2.0 last year.

Ng: As more folks come to adopt ESL and more is flushed out, this is part of a natural maturation of the process.

Buric: As this happens, you’re also going to see the rise of a second generation of ASIC vendors—eSilicon, Open-Silicon, Global Unichip. And due to design complexity, there will be an ESL signoff between design intent and design implementation if you don’t have a clear signoff.


LPD: Can ESL handle all the power islands that are cropping up in designs?

Kroll: I don’t think so. There are people already doing power analysis with SystemC and TLM 2.0. They are switching off components and making sure the dynamic power is captured properly. There needs to be more standardization on how to do it.

Sanguinetti: ESL can do anything. You can write lower-level code in your higher-level environment. It’s a bogus complain about ESL that you can’t do this or that. Maybe it’s as much effort to do it if you weren’t using ESL, but that doesn’t mean it can’t be done. In some cases, ESL hasn’t made your life easier—yet. But that’s where continuing work will be done.


LPD: Such as?

Sanguinetti: Power islands. Right now you put a module in one domain, another module in another domain, synthesize them and hook them up with an interface. Writing that abstract interface is work.

Buric: It becomes structural ESL. You have to partition the problem.

Sanguinetti: You want to be able to write code at a higher level, and what you take advantage of is the language’s expressability and the tools’ capability.


LPD: As we get to the next several nodes we’re facing restrictive design rules. Does that limit the demand for ESL?

Ng: Now that the flow is a connected flow, through RTL to physical, more and more people will be adopting it. They don’t have a choice. The challenge is creating a really good representation of the physical design at such an abstracted level. Even developing a synthesizer to put out good RTL good, dealing with the different interpreters and synthesis tools, is a challenge when it comes to power. Connecting that physical implementation is to the highly abstracted algorithmic world is difficult.


LPD: How do changes at the smaller geometries affect RTL?

Ng: From an RTL standpoint, not much. But it does affect the implementation of gates. We’re getting to the point where we will have to question what physical structures are allowed. We’re not saying they’re bad or good. But it will be a fairly limited set. From that to gate-level implementations that leverage those changes. I don’t know how you can comprehend that in a model. It’s more constraints on the physical implementation.