标签: RTL

Estimating likely power consumption of a piece of silicon before building it is necessarily an approximate endeavor -- not quite divining the future by poking through chicken bones, but certainly laden with assumptions and approximations. Unfortunately, early estimates are critical to the economic and timely development of world-class designs. You can't just iterate through design, manufacture, and measurement as many times as it takes to get it right.   The gold-standard of pre-silicon estimation starts from a full physical gate-level implementation -- synthesized to final gates and placed-and-routed. Using this representation, with detailed power models for gates, extracted parasitics, and activity files from gate-level simulation, power estimates are claimed to fall within 5% of silicon measurements (with multiple caveats). However, a full implementation cycle takes time (enough time that you are not going to complete more than one a day for a ~1M gate block), and it is difficult to correlate power problems back to the RTL design. So, while an improvement over waiting for silicon, this method is still not well-suited to rapid design-measure-debug iteration.   The electronic system level (ESL) may be the best place to estimate and optimize architecture for power, but either way you have to re-estimate at the RTL (register transfer level) to get the implementation architecture right. This offers the fastest and most direct debug cycle, but with a penalty in accuracy over gate-level estimation. RTL estimation still uses the same Liberty power models used in gate-level estimation and the same simulation testbench, but takes a scientific wild-ass guess (SWAG) at what gates will be mapped to in synthesis, Vth mixes, cell drives, data path optimization, net capacitances, and more. Still, for many purposes at less aggressive nodes, this approach can provide useful guidelines to major implementation decisions.     While basic estimates are often reasonably accurate in terms of overall power, they don't typically stand up well to close examination. If you want to understand, for example, static versus dynamic power components or contributions by module or contributions of memories versus the clock tree, basic analysis can be significantly off. One way to get significant improvement is to calibrate the SWAG estimates against a fully-implemented version of an earlier generation/similar design. Unsurprisingly, mapping Vth mix, drive strengths, capacitance models, and clock trees by clock domains can significantly tighten up estimates at the detail level.   But what if you are working on a new design and you don't have prior examples to guide calibration? Or what if you want to optimize for power at the micro-architectural level -- for example, splitting high-fanout nets and pipelining? To usefully guide decisions in these cases means the estimation tool has to more closely emulate a real implementation flow. In turn, this means close correlation on cell selection module-by-module -- not just threshold mix, but also DesignWare selections. It also means close correlation on drive strengths, interconnect capacitances, and clock tree implementation, all of which require some form of physical prototyping. The trick here is to get a reasonable level of accuracy faster than you can through a full implementation cycle, so you can run through multiple design-measure-debug cycles in one day. Some approximations can be made to help achieve this speed, but your vendor still needs to provide a credible case that they can accomplish reasonable correlation with the real implementation flow.   Getting to really useful RTL power estimation is hard work. We are constantly refining correlation at the component level (static versus dynamic), at the module level, and at the detailed architectural level. If you have additional ideas or feedback on the limitations in RTL power estimation, I'd be very interested to hear them.   Bernard Murphy CTO Atrenta Inc.

Estimating likely power consumption of a piece of silicon before building it is necessarily an approximate endeavor -- not quite divining the future by poking through chicken bones, but certainly laden with assumptions and approximations. Unfortunately, early estimates are critical to the economic and timely development of world-class designs. You can't just iterate through design, manufacture, and measurement as many times as it takes to get it right.   The gold-standard of pre-silicon estimation starts from a full physical gate-level implementation -- synthesized to final gates and placed-and-routed. Using this representation, with detailed power models for gates, extracted parasitics, and activity files from gate-level simulation, power estimates are claimed to fall within 5% of silicon measurements (with multiple caveats). However, a full implementation cycle takes time (enough time that you are not going to complete more than one a day for a ~1M gate block), and it is difficult to correlate power problems back to the RTL design. So, while an improvement over waiting for silicon, this method is still not well-suited to rapid design-measure-debug iteration.   The electronic system level (ESL) may be the best place to estimate and optimize architecture for power, but either way you have to re-estimate at the RTL (register transfer level) to get the implementation architecture right. This offers the fastest and most direct debug cycle, but with a penalty in accuracy over gate-level estimation. RTL estimation still uses the same Liberty power models used in gate-level estimation and the same simulation testbench, but takes a scientific wild-ass guess (SWAG) at what gates will be mapped to in synthesis, Vth mixes, cell drives, data path optimization, net capacitances, and more. Still, for many purposes at less aggressive nodes, this approach can provide useful guidelines to major implementation decisions.     While basic estimates are often reasonably accurate in terms of overall power, they don't typically stand up well to close examination. If you want to understand, for example, static versus dynamic power components or contributions by module or contributions of memories versus the clock tree, basic analysis can be significantly off. One way to get significant improvement is to calibrate the SWAG estimates against a fully-implemented version of an earlier generation/similar design. Unsurprisingly, mapping Vth mix, drive strengths, capacitance models, and clock trees by clock domains can significantly tighten up estimates at the detail level.   But what if you are working on a new design and you don't have prior examples to guide calibration? Or what if you want to optimize for power at the micro-architectural level -- for example, splitting high-fanout nets and pipelining? To usefully guide decisions in these cases means the estimation tool has to more closely emulate a real implementation flow. In turn, this means close correlation on cell selection module-by-module -- not just threshold mix, but also DesignWare selections. It also means close correlation on drive strengths, interconnect capacitances, and clock tree implementation, all of which require some form of physical prototyping. The trick here is to get a reasonable level of accuracy faster than you can through a full implementation cycle, so you can run through multiple design-measure-debug cycles in one day. Some approximations can be made to help achieve this speed, but your vendor still needs to provide a credible case that they can accomplish reasonable correlation with the real implementation flow.   Getting to really useful RTL power estimation is hard work. We are constantly refining correlation at the component level (static versus dynamic), at the module level, and at the detailed architectural level. If you have additional ideas or feedback on the limitations in RTL power estimation, I'd be very interested to hear them.   Bernard Murphy CTO Atrenta Inc.

In this second instalment , we have another expert panel talking about the intellectual property (IP) industry. In part 1 , we tackled the concept of IP as a partnership between the supplier and the user. Taking part in this discussion are Warren Savage, president and CEO of IPextreme; John Koeter, vice president of marketing for the solutions group at Synopsys; and Chris Rowen, Cadence Fellow and CTO of Tensilica. EE Times : When the IP industry was first being formed, a lot of people would create a piece of RTL IP, hang out a shingle, and attempt to start selling it. They quickly realised that there was more to it than this. Have we moved beyond the point where this is within the realm of a start-up? Warren Savage : I don't think so. For example, we have our constellations program. It is a lot of smaller companies, very smart people with innovative ideas. There has been enough written about IP in the last 15 years, and the industry itself has matured enough such that there's been success stories written. People know how to put IP together—better than they did in 1998. It's a much different environment. It's not the Wild West anymore. EE Times : How does a company build up enough trust to get established? Savage : Usually, it's the technology innovation that is the driver to make the customers make a leap—they need that specific technology that's not commoditized. Early adopters are willing to work with them in a real partnership model. Sometimes technology is not fully baked such that it needs that close cooperation to get to that maturity level. John Koeter : I think, if you're really doing complex IP, like physical IP and highly configurable IP, you have to have a certain scale to be able to build the quality into the product. Being able to afford to do that, to run all the tests and simulations and running the characterisations and split lots and get certification and so on and so forth, takes a lot. Having said that, though, there are many small IP companies that fill a vital niche. There's certainly room for many smaller companies to have a speciality that could do very well. In Warren's case, you resell other people's ideas, and they've already proven them, right? They've already put the investment in, and you've put more investment on top of it, so you can make that happen because of your unique business. Chris Rowen : I don't think that the barrier to the IP business has gotten relatively higher. It's gotten absolutely higher. But I think that's true for every area of electronic innovation. The barrier to entry for new start-ups has gone up—a lot. I think IP, particularly if it's a small team that has some unique insight into a particular vertical application domain—a particular kind of technology that may allow them to encapsulate those insights into something they can license—that's still a viable opportunity. I think we also see the emergence of new kinds of intellectual property. We're starting to see, for example, in the case of Tensilica, the ability to extend something that is already there. They can create a set of processor extensions in a standard form that plugs into our processor. Now this customer can build an entire application-specific processor without needing a compiler team, an RTOS team, a debugger team, a simulator team, a hardware team, a verification team, or models working at the next level of abstraction. A lot of that becomes automated, and it distills out just their know-how. * * * In the next installment, we will look at the areas that are most ripe for increased IP adoption. Brian Bailey EE Times  

This is the second instalment of an expert panel discussing the intellectual property (IP) industry. In part 1 , we tackled the concept of IP as a partnership between the supplier and the user. Taking part in this discussion are Warren Savage, president and CEO of IPextreme; John Koeter, vice president of marketing for the solutions group at Synopsys; and Chris Rowen, Cadence Fellow and CTO of Tensilica. EE Times : When the IP industry was first being formed, a lot of people would create a piece of RTL IP, hang out a shingle, and attempt to start selling it. They quickly realised that there was more to it than this. Have we moved beyond the point where this is within the realm of a start-up? Warren Savage : I don't think so. For example, we have our constellations program. It is a lot of smaller companies, very smart people with innovative ideas. There has been enough written about IP in the last 15 years, and the industry itself has matured enough such that there's been success stories written. People know how to put IP together—better than they did in 1998. It's a much different environment. It's not the Wild West anymore. EE Times : How does a company build up enough trust to get established? Savage : Usually, it's the technology innovation that is the driver to make the customers make a leap—they need that specific technology that's not commoditized. Early adopters are willing to work with them in a real partnership model. Sometimes technology is not fully baked such that it needs that close cooperation to get to that maturity level. John Koeter : I think, if you're really doing complex IP, like physical IP and highly configurable IP, you have to have a certain scale to be able to build the quality into the product. Being able to afford to do that, to run all the tests and simulations and running the characterisations and split lots and get certification and so on and so forth, takes a lot. Having said that, though, there are many small IP companies that fill a vital niche. There's certainly room for many smaller companies to have a speciality that could do very well. In Warren's case, you resell other people's ideas, and they've already proven them, right? They've already put the investment in, and you've put more investment on top of it, so you can make that happen because of your unique business. Chris Rowen : I don't think that the barrier to the IP business has gotten relatively higher. It's gotten absolutely higher. But I think that's true for every area of electronic innovation. The barrier to entry for new start-ups has gone up—a lot. I think IP, particularly if it's a small team that has some unique insight into a particular vertical application domain—a particular kind of technology that may allow them to encapsulate those insights into something they can license—that's still a viable opportunity. I think we also see the emergence of new kinds of intellectual property. We're starting to see, for example, in the case of Tensilica, the ability to extend something that is already there. They can create a set of processor extensions in a standard form that plugs into our processor. Now this customer can build an entire application-specific processor without needing a compiler team, an RTOS team, a debugger team, a simulator team, a hardware team, a verification team, or models working at the next level of abstraction. A lot of that becomes automated, and it distills out just their know-how. * * * In the next installment, we will look at the areas that are most ripe for increased IP adoption. Brian Bailey EE Times  

Generally speaking, there are only so many books I can read on RTL design before my eyes start to glaze over. Given that, there's the occasional gem that's well worth a read. One example is Sanjay Churiwala and Sapan Garg's Principles of VLSI RTL Design – A Practical Guide . There are several things to note about this book, starting with the fact that it's written by people who actually know what they are talking about (sadly, this is less common than one might hope). It's also important to understand that this book is not intended to teach you about any particular flavour of Register Transfer Level (RTL) hardware description language (HDL) like Verilog or VHDL. The idea is to teach you how to write better RTL. The thing is that there are a lot of very competent RTL designers when it comes to understanding an architectural or functional requirement and generating some RTL that will "do the job". What this book does is to take things to the next level by making you realise the downstream implications of any decisions you make while coding your RTL. For example, the way in which you code your RTL may affect testability, data synchronisation across clock domains, synthesisability, power consumption, routability, and so forth. Thus, the book walks us through various aspects associated with the following topics: * Ensuring RTL intent * Creating simulation-friendly RTL * Creating timing-analysis-friendly RTL * Creating clock-domain-crossing (CDC) RTL * Creating power-friendly RTL * Creating DFT-friendly RTL * Creating timing-exceptions friendly RTL * Creating congestion-conscious RTL This isn't a huge book – approximately 180 pages – but it's jam-packed with useful information. Also, it's written in a chatty, conversational style that will appeal to a lot of people (I personally like it a lot), but not to others (but they are grumpy little rascals and they don't count, so let's not worry about them). Both of the authors work for Atrenta, which provides SoC Realisation solutions for the semiconductor and electronic systems industries. I've always been impressed with the folks at Atrenta and with their solutions. With regard to this book, the various members of Atrenta's SpyGlass family of products are absolutely relevant with regard to ensuring "XYZ-friendly RTL" ... so one thing that really impressed me here is that the authors studiously managed to avoid mentioning Atrenta or SpyGlass in any way. It's so easy for a technical book to end up as a marketing exercise – so all credit to the authors for not falling into this trap. The list price is $129, although it's currently available for $102 from Amazon.com. On the one hand this is a tad expensive – on the other hand, if coding RTL is what you do a lot of and this makes you better at doing it, then $102 may be a bargain (especially if you can persuade your company to buy it for you). The bottom line is that if you spend a lot of time coding RTL, or if you are hoping to become a member of the RTL design engineering fraternity, then I think that reading this book would be well worth your time.