Experts At The Table: ESL Reality Check

By Ed Sperling
System-Level Design sat down to discuss electronic-system-level design with Stephen Bailey, director of emerging technologies for the design verification technology group at Mentor Graphics; Michael McNamara, vice president and general manager of Cadence’s System-Level Division; Ghislain Kaiser, CEO of DOCEA Power, and Shawn McCloud, vice president of marketing at Calypto. What follows are excerpts of that conversation.

SLD: As power becomes more of a consideration, both with more third-party IP and what is considered mainstream design moving down to 40nm and beyond, will the companies using ESL change?
Kaiser: It’s not a just question of power consumption. It’s power consumption and power techniques and implementation in software and hardware. The ideal flow will have at the system level some tools and methodology to analyze and estimate power very quickly, and then to have implementation down to the silicon. Unfortunately that’s not possible today. Nevertheless, there is interest to explore power and implement power using a refinement methodology for meeting the power budget in a design flow and making decisions earlier. One part is to implement power reduction techniques and to keep consistency between the system-level definition and implementation. That’s the first phase of UPF/CPF. We need to move this standard to a higher level. For the software part, we need to make sure that is well captured at the system level and implemented in the software development phase. The main system level goal for power is to define the critical use cases for power and the most efficient implementation. We have to look at the ‘V’ cycle process flow. The system level is in front of the validation of the system. What is missing today is, when customers get back their silicon how is it possible to validate the power consumption? They run the software, measure the power consumption, and get maybe 500 milliwatts. Is it correct? Do they have some bugs? They’re working blind. The information should come from the system-level design.
McCloud: There’s a reason why the power of the actual subsystem on the chip is very critical. It’s not just a question of battery life. It’s also thermal integrity and power and supply integrity. As we pass 45nm it’s very difficult to scale your supply voltage to reduce power. If you don’t do anything, you’ll see a chip that has four times the number of transistors and four times the amount of power in the same die space. That would be impossible.
McNamara: That was the death of a processor at one large company. There was too much power density.
McCloud: It becomes critical from a thermal perspective. Your chip is going to burn up or you’re going to have supply dropouts and the chip will ultimately fail.
McNamara: It’s a matter of getting the power there and the heat out. Even if the chip survives, you don’t want to burn the hand of the person holding the phone.

SLD: So with growth of third-party IP, does it change system-level design?
Bailey: The way I see the market going, there already are 2.5D devices where there are hardened 2.5D platforms. Xilinx, Altera and Microsemi have products in this area. When you look at the economics involved, this opens the door for a lot more companies to get involved in electronic-system-level design than before because they don’t have to hire and spend millions of dollars just to get the chip out, let alone any of the software. Even if it costs them $25,000 to $50,000 for leading-edge chips at the latest process nodes, that’s nothing compared to the millions of dollars it would have cost them to engineer that up front. They can focus on a small amount of differentiating logic or just software. It’s a much lower cost for NRE, so a lot more companies can afford to be startups and try to do something innovative. They can take these chips into consumer markets and new market-specific applications.
McNamara: The Zynq platform from Xilinx is one of them. We’re working with a company that will use those in scanners for inventory. You only need a thousand of these. But now you can build a fully customized device with volume 1,000 for no NRE. You’re basically buying an FPGA SoC. Now you can do system-level design with that and determine what goes into software, what goes into the FPGA, and what goes into the peripherals.
Bailey: You might have some custom peripherals on there and maybe an accelerator block.
McCloud: We see a similar trend between early production in FPGAs and volume production in ASICs in Japan. They’re making very high-end TVs in low volume. The consumer market is all about time-to-market, which may be a six-month development cycle. ASICs can take a long time, so they’re doing early production with FPGAs. HLS makes this possible. It’s the same C/C++/ESL model being used to go to the FPGA for early production and then re-targeted for an ASIC.

SLD: What standards are necessary in the short-term to make all this work?
McNamara: With transaction-level modeling, we need version 3.0. One of the big missing pieces is the separation of communication from computation. If there’s a standard way of representing a communication port that I can model, that would be useful. The virtual platform can be just a pass-through, with no need to model it. When it’s being synthesized to logic, you’re using the OCP bus or AXI or Amba 3. There are different choices for the communication. That should be something you just swap in or out for doing the calculations. You want HLS that can work with a communication model and a computation model as an ensemble, that has all the details you need of the protocol. That’s important for the next level. When you go from the transaction level to RTL, you have to get to signals and wires. You don’t need to model the signals at the transaction level. It’s just a block of data. That’s one standard that’s need. The other thing that’s needed is a way to extract power from the lowest level and represent it at the system level. There are two aspects to that. One is, what is the cost of an ‘and’ operation on an A9? What is the cost of a divide operation? You can do some software profiling to get the cost of power in the processor cores. Then there’s the other bunch of logic that is an MPEG-3 or MPEG-4 decoder. How do you represent the power in a way you can trade off designs in a way that is more than ‘A’ is better than ‘B’? We have to improve on 30% accuracy. We also have to pull in software. We’ve talked about software as a user of power. What about software shutoff of a radio? And there’s some other software that’s not aware it’s shutoff and is dependent on data from this radio. There’s a correctness modeling that needs to be there.
Kaiser: The power needs standardization at the system level to capture the power behavior and the power interface with the software and the hardware. You need to keep consistency from the system level to implementation, taking into account exploration and software and hardware implementation. Those are the three topics that need to be considered in hardware standardization.
McCloud: TLM 2.0 is certainly in the right direction, but it does need further standardization around power policies and performance policies. We need a better way to standardize moving power up to the ESL level. UPF and CPF have to move up to the ESL level, as well. There needs to be some progress in that direction. And we need to do a better job of connecting these point tools in a flow, even if that means going across companies. We have great point tools. How do we bring those together to create an overall ESL solution?
Bailey: I chaired the UPF committee through the first couple of revisions. UPF definitely could be used at the TLM level. In addition, there will be continued innovation and new bus fabrics on SoCs. GALs (generic array logic devices) will grow in use, and that will create new on-chip bus structures. There will be new interfaces external to the chip, as well. You’ll see more standardization pushing up into the software levels of these protocols so there is less to change in software stacks because the underlying hardware protocol will change. The other thing in standardization is that with the move up in abstraction, verification will move up in abstraction beyond that. You can’t have verification at the same level of abstraction as HLS or TLM. It has to move up further. You’ll see some standardization in verification, as well, beyond UVM and OVM. People need to know what to test, to make sure they’ve tested what they want to test, as well as being sure their results are correct. That’s what verification should be about, not writing testbench plumbing code.
McNamara: There could be a stage of having a testbench language for TLM, and there are efforts in UVM to address that, but the real leap forward is testing the hardware/software system. If I’m supplying IP, today that IP has a driver. Sometimes it’s fairly large. If you look at memory IP, there’s a lot of software that comes with it. How do you not just verify the hardware, but also the software to make sure there are not any deadlocks in these device drivers? And then you need to eliminate deadlocks between these devices and IP you’re buying from other people.
McCloud: One of the biggest challenges we hear about is unpredictability of systems. You’ve got RTL, software and you upload it on emulation That’s very late in the design process. You need to pull that forward and verify the software and hardware and all the pieces working together.
Kaiser: Anticipating issues is key to the system level. But being able to keep the flow consistent, and being able to provide information from the system level to implementation teams for power consumption to have guidelines and specifications earlier is a problem if your specification is frozen at the RTL level. Your planning is impacted. If you can freeze your specification earlier you can get the specification closure earlier. That’s a key benefit.