Customer perspective: STMicroelectronics

By Ann Mutschler
With eight SoC designs currently in development on its 28nm manufacturing process, STMicroelectronics is well acquainted with the power challenges of making those designs work. LPE discussed these issues with Philippe Magarshack, ST’s Technology R&D Group Vice-President. What follows are excerpts of that conversation.

LPE: What are the biggest challenges in getting ST’s 28nm designs started up?
Magarshack: We believe we have made significant progress on [the system-level] angle in the past year and now we are at the stage where we are really able to bring up the system virtually before the silicon comes out. The hardware and software are already co-simulated and we are able to boot the operating system and run real application test cases. Of course, 28nm brings more complexity in terms of transistors, but our methodology is robust enough that we can observe that growth. But the biggest challenge at 28nm is keeping total power under control. That is the case for wireless designs, which have very stringent low-power requirements, but also for designs that had not seen that as a big issue in the past like designs in the consumer space, or designs in the networking space. We are actually grateful for the fact that we have been working for several generations with the wireless group in putting together those low-power design techniques that we start now to apply as well in consumer and in networking. So things like multiple power domains, putting blocks in retention, and basically dealing with bringing several voltage supplies on the chip for different blocks and having the chip understand itself if it is a slow or fast chip and basically ask the power supply to give it more voltage or less voltage. Intricacies of this sort are something that are either still too complex to utilize at a system level or really becoming handy for those applications that we’re not seeing that.

This is the case particularly in the networking space where you see the guys – without naming names – doing big network processors or routers or switches, that go into racks in compute farms seeing that there are limitations that they have to live with in terms of total power. They have to be looking more at what they can turn off to consume less power and basically implement the same algorithm in a much more efficient manner. The fact that ST has such a broad base in terms of applications is actually helping us in this case because we are able to bring solutions to these other application domains like networking. It’s the case, as well, in digital TV, where we also see requirements that the TVs and set top boxes have to be aware that they are either in use consuming power, or in standby mode not consuming power, and therefore they can intelligently switch off those parts that are not needed.

One of the challenges for these guys is they have not been exposed at all (or very little) to all these low-power complexities and we have to bring to them a methodology that is as push-button as possible—which is not really the case—but we have to deploy these low-power concepts and methodologies to these other users. This is what we are facing right now—more of the deployment. We have the techniques and they are usable by those experts we have in terms of designers in the wireless space, but we have to deploy it to the broader base and this is where we are struggling a little bit.

LPE: Is RTL early enough to implement a design-for-power methodology?
Magarshack: No. Unfortunately the reality is that this is where we typically start, at the RTL stage. We are working to be able to instrument SystemC-type of models for our IPs with some power awareness—both of power modes as well as awareness of how much power will be consumed by a given algorithm—but this is certainly not something that is available today, unfortunately.

One ingredient for low power is not only the functional part. So SystemC would be a way to simulate the function earlier than RTL, but also I would say from a physical level that in a sense we are putting the chip in a package, in a board, and we stack chip over chip. At a very abstract level without thinking about functionality we are looking at ways to do some early power simulation with rough numbers but it is already giving us indication as to what architecture makes sense, what stacking of die makes sense in particular for wireless phones.

LPE: At what point do we decide we need to consider power at a higher level of abstraction than RTL or is it just that we can’t do it because the model issues haven’t been solved?
Magarshack: There is some work ongoing at the standardization level to actually have a placeholder for the power, which is obviously a first step, but then the difficulty becomes how to annotate the correct number in the SystemC models. So we still have a long way to go to be able to have a complete chain but certainly this is the direction, for sure.

LPE: What will standards like IP-XACT have to do with system-level modeling?
Magarshack: In some sense, you can view IP-XACT as the language and the syntax that will enable you to assemble the IPs together at the architectural level, whereas SystemC will be the functional description, the executable description of an IP. Then you have to make decisions at the SoC architecture or system architecture level of which IPs you choose and how you stitch them together. This is where IP-XACT kicks in and where it is able to do a lot of the nitty gritty verification when you assemble those IPs together. For instance, you can automatically take care of address space and register mapping when you have all of these registers in the different IPs—how do you construct a consistent address space that assembles all the IP together? Once you have this homogeneous description of all the IPs and their condition in IP-XACT then you can generate views for the rest of the CAD flow, for documentation and for software drivers. This is a place where you keep track of all these connections. It’s great for people doing architecture that basically have to transmit their latest and greatest architecture down the chain to the implementation teams.

LPE: What would make life easier for ST’s design teams?
Magarshack: My No. 1 wish would be to have the standards be one standard. We still have the unfortunate war between UPF and CPF. Even though there has been great progress, and there is some consensus or at least some common subset that is being defined, still there are some vendors that are supporting one, others supporting the other and there are still some ambiguities in the semantics between the two languages. So unfortunately we have to stitch tools from different camps together and fix the inconsistencies between the two. We end up wasting our expert resources on something that should not even exist, but this is where we are. Given this situation, people in the standardization bodies on both sides are working now to recover slowly as fast as they can. But standards bodies being what they are, this is still very slow.

As a consequence, if we had this single placeholder for the power intent, then this could be used both for the implementation side of the methodology as well as for the verification side with great benefit. We are still obviously working both with the implementation tools and the verification tools to utilize this low-power design intent, while at the same time recovering the slight differences that exist between UPF and CPF.