Whether it's in a technical paper, a pundit's article, or a live discussion with a customer, the term PPA—power, performance, and area—is always in the discussion. Of course, PPA is not simply one fixed point. Targets for PPA are three different, but extremely interrelated, goals that you set out to achieve when building the latest chips and systems. Change the area, and the power changes. Increase the performance, and the area and power change. Attempt to minimize power, and the area goes down—or up—depending on the optimization. Unfortunately there's no simple formula and different design groups have different PPA goals depending on their unique design and application. One size does not fit all. Recently, I was in Japan at a customer meeting talking about this very subject. Our customer makes components for consumer devices and PPA is very important to them. (I realize this is fairly generic!). We were talking about how they could continue to increase the device performance while minimizing area and power—or trading off area for power savings in certain cases—using our high-level synthesis (HLS) technology. Of course, with HLS it's quite easy to explore a number of different macro- and micro-architectures, quickly create RTL, and get PPA data—something simply not possible with hand-coded RTL. That's not entirely true, but it's pretty much not feasible with hand-coded RTL within a reasonable timeframe. At this point in the discussion the design manager pointed out that there is more to it. PPA wasn't enough. It's really PPAS. GASP! PPAS? What is this "S" that has been added to the PPA that everyone talks about? "Schedule," the manager explained. "PPA is important, obviously, but without the understanding of the schedule, PPA is somewhat meaningless." Of course! This makes perfect sense. As engineers, we know that, if given just a little more time, we could continue to improve the results of whatever it is we are working on. Squeezing down the area of the latest chip, running just a few more vectors through the latest simulation build, or even tweaking the text in the latest blog post. We want things to be right—as good as they can be. I've personally spent too much time getting the last 1% “optimized” because it felt like the right thing to do, but that isn't always an option. We live in a world where time is a limited resource and it doesn't slow down for anyone. Sometimes the schedule dictates that something must be shipped to meet the time-to-market goals (of course, to be successful it had better meet the other goals, as well). So, clearly PPA isn't all you need to think about. It's now PPA S. Working towards PPAS goals is perfect for our Stratus HLS platform. For many years, our customers have been able to quickly implement optimized hardware from high-level SystemC algorithms. And, with the advancements in the HLS technology over the past few years, they've been able to take advantage of new ease-of-use features to help manage their aggressive schedules, improved algorithms to minimize area, and our low-power features to trade off area and power to meet their targets. As your team works to achieve your PPAS goals, maybe it's time to check out HLS... ASAP. Brett Cline![]()
![]()
↧