DAC Wrap-up

Last week the 48th Design Automation Conference (DAC) was held in San Diego. This marks the 11th conference (I think) that I've been to and this year left few surprises. Cloud computing, 3-D extraction and discussions on lowering the cost appeared to generate the most buzz.  For me it was moderating an interesting PDK panel, and as always meeting up with old colleagues and friends.  For the first time I'm starting to see my peers gracefully aging; in fact I made a few comments to old friends and it seems as though I wasn't alone in my observations. Whether it was the growing waistline, receding/graying/balding hairlines, it seems as though we all have aged a bit over the past year.

For my part it was a little different this year. In past years DAC week was one of curiosity and interest in the new  Esemiconductor technology, meetings with vendors on their new promises and vapor-ware solutions, and hope that this coming year would bring some new "stuff" to the table. While all of that was still true this year I also was listening. I spent a fair amount of time in the IC Manage booth listening to colleagues challenges with respect to IP management. One colleague came in lamenting that senior management was pushing IP re-use initiatives (presumably the VP was incentivized) without bothering to define the process by which that should happen. Another colleagues was trying to deal with a "multiple (Data Management) DM stategy". It seems as if using subversion (svn)  wasn't cutting it so some teams were shifting to git, while the hardware guys weren't using anything outside of VersionSync. Lastly I heard colleagues who simply were so massive they had no idea what IP they had and had actually repurchased the same IP twice (fortunately the honest vendor clued them into that small fact before the PO went in).

All of this rang true to me, having seen first hand the pitfalls of not having a solid IP strategy in place only makes the job of the designing chips that much more difficult.  IP Strategies ultimately come down to having a solid Data Management (DM) strategy.  Data management is the process of managing the data through the lifecycle of the product.  In all cases it means having a game-plan of understanding 1) What data do we need to do design? 2) How are we going to organize the data? 3) What data are we going to keep?  Fortunately for most teams the key to unraveling this is to have a solid design process in place.  If you have this then you probably can answer those questions, and then the difficult part becomes how well do you play with others.  In other words if I have to use someone else's IP do we have a mechanism which can bridge my data management strategy with thier strategy as simplistically as possible with (hopefully) no loss of information.   It's at that point that I usually get called in.

Having seen many companies struggle with this intersection of IP/Data management and design engineering I have an interesting perspective.  You need to design a flexible and scalable system which evolves with you over time.  8 years ago nobody would have thought that Open Access (OA) would have been as prevalent as it is.  And who knows where High Level Synthesis is going to take us.  Knowing where that data is used, how to organize this information, and what do we keep as a result is key.