Blog

Thoughts on IC development, EDA, and hardware design languages.

Success: RTL level power/activity estimator in 48 Hours at DAC!

Posted by: Trent McClements | Posted on: July 22nd, 2015 | 2 Comments

Share on LinkedIn30Share on Facebook0Tweet about this on Twitter0Share on Google+0Email this to someone

If you recall from this post the Invionics team put on a 48 hour design challenge during DAC2015 (you may have read about the 48 hour challenge here). During the Monday morning of the conference we took suggestions for an EDA tool people would like to see developed. The suggestions were voted on by attendees during the day and then two of our Invionics developers had 48 hours to create the app based on our Invio EDA tool development platform.

To be honest, I was a little cocky going into this development challenge. Our team knew Invio pretty darn well and I was confident in their coding skills. I also figured most CAD/EDA engineers and software developers wouldn’t throw us under the bus as they understood the limits of 48 hours of wall-clock development time, especially when we only put two developers on the case! What I wasn’t expecting was an old employee of ours from our last startup, Veridae, to throw out an idea. Dan Hoggar, of New York Digital Design, decided to throw RTL-level power estimation into the mix. Of course, this is a really cool app idea that is applicable in many different areas of a design flow, and indeed it did win out over the other suggestions (non-reset flop detection, UPF domain analysis, static glitch detection, undriven net detection, etc), but man, when you get into the nuts and bolts of the idea, that app is non-trivial!

So, with the die cast and feeling a little bit nervous, we threw the app challenge to our developers back in Vancouver and waited to see what they came up with. In the end, the duo managed to pull it off and create an application, complete with a GUI front-end visualizer!

dac52_gui_with_legend_small

The development path chosen was to use activity estimation at the RTL level as a proxy for power. The idea being that when coding RTL what is really important is the signals and processes that are toggling a lot. Seeing these allows you to optimize your design to minimize switching activity, which is guaranteed to help minimize power. The classic example of this is someone who forgets to gate off the data path of a bus based on the transaction valid signal. While not necessarily functionally wrong, this non-optimal design may result in the busses data signals toggling needlessly.

Now, a lot of people have tried to do something like this app in the past and it turned into a daunting process (warning, I’m about to shamelessly self-promote the Invio platform here but hey, that was kinda the point of the whole challenge after all!). With the help of Invio this app was able to be built from the ground up in under 96 person-hours of effort (yes, we did let our 2-man team sleep during the 48 hours!). It turned out that the hard part was actually the algorithmic development.

In Activity Estimation, the hard part is to be able to model how activities propagate (from primary inputs to primary outputs) through all of the logic described in the design. This is straight-forward with a gate-level netlist, but at the RTL-level, it becomes a lot more challenging to identify the resulting logic.

With Invio it turned out this part was really easy because the Invio API lets you easily find all the RTL constructs that produce logic (assignments, processes, module instantiations etc.), and find how these constructs are connected. Invio also makes it easy to inspect the logic operations described by these constructs – a key part in activity estimation.

Scott Chin
Invionics 48-Hour Design Challenge Developer

With Invio accelerating the back-end development the developers were also able to implement an activity estimation algorithm and tie the results back to the RTL constructs. Invio’s GUI Builder package was then utilized to develop a front-end to visualize the results (for those familiar with GUI development, this alone is no small feat within 48 hours!).

In terms of user interfaces, the hard-part is designing an interface that is intuitive, concise and easy to use and then all the work associated with realizing that design intent. How will the UI be used in the design flow? How do you summarize the power for the entire design? How do you see power of a specific instance or signal? At least with Invio, once you have a design worked out, you can leverage the integrated Tk engine and Gui Building library so creating the actual GUI…well, that’s become the easy part!

Mike Lee
Invionics 48-Hour Design Challenge Developer

Finally, and after the prerequisite final hour panic of “uh-oh, I don’t think this works at all…” that every project seems to go through, the developers were able to use Invio’s Application Packager functionality to package up an executable for download by us at DAC. By 2pm on Wednesday we were showcasing the app to anyone who stopped by the booth!

dac2015

All-in-all it was a very successful app challenge! The activity estimation application is now available as part of the existing, and growing, suite of example apps that ship with the Invio platform. I’d encourage you to check it out and start thinking about what you’re going to build in the next 48 hours!

4-Ways-to-Build-Best-in-Class

Share on LinkedIn30Share on Facebook0Tweet about this on Twitter0Share on Google+0Email this to someone

Comments (2)


  1. Djoudi khelifi - Reply
    October 28, 2015

    First I don’t know about your power explorer tool at rtf level (if you have one).
    The application is very interesting but if you have a tool to estimate the power at rtf level, this app should be available as part of your toll and no need to create a standalone app for this purpose. You may just extract the existing parser/procedure and use it.
    I would like to know more about your tool and this app.
    I’m know how complex to extract the activity to estimate the power in an accurate way.
    The presence of multiple clock domains and the complexity of the implementation of certain class of rtf to gate may contribute to a big g inaccuracy of the activity estimation , hence the power.
    Regards
    Djoudi Khelifi

  2. pharMella - Reply
    November 10, 2015

    Good day making friends. I*like*you!

Leave a Comment