Much though some of us might wish otherwise, distributed development teams are here to stay. Modern SoC design requires strength and depth in expertise in too many domains to effectively source from one site; competitive multi-national businesses have learned they can very effectively leverage remote sites by building centers of expertise to service company-wide needs. Multi-national operations aren’t going to go away, which means we need to get better at multi-site and multi-time-zone development.
Years of experience have shown that multi-site development can be effective but requires rather more management overhead than you might expect and much more care in ensuring that intent is very carefully communicated and cross-checked at each sync-up. The problem is never in broad expectations – it’s most commonly in the details, especially around implicit assumptions we think we all share. I’ve done this for 20 years so I have some experience of what can go wrong.
The most common way to synchronize understanding and flush out those implicit assumptions is crude and painful, but generally effective. Lots of early and late-night group meetings, generating mountains of status and update documents but you do enough of it and maybe no balls get dropped. It works (mostly) but it’s not very efficient (witness continued schedule overruns), pulling many people into meetings to which any one participant might contribute to 10% or less of the discussion. There must be a better way – and there is for implementation teams.
Implementation is an area that particularly lends itself to distributed development thanks to deep expertise needed (among others) in each of timing analysis, placement and power distribution network design. Distributing tasks like these between different sites is common today, especially on large designs (billions of gates). But of course while each domain is specialized, these objectives are very interdependent. Getting and keeping all these team on the same page the old-fashioned way is what spawns all the meetings, PowerPoints and spreadsheets.
Which is kind of ironic. In this 21[SUP]st[/SUP] century Web-based, instant-access world we’re building the very latest in electronic systems using 20[SUP]th[/SUP]-century management methods. Pinpoint from Consensia aims to change that, particularly in implementation management. You may have heard about this tool when it was first developed by Tuscany Design; the organization is now part of the Dassault ENOVIA PLM group. They have an impressive list of customers, though the only one I can find publicly cited is Qualcomm, who have been using the tool for many years (an impressive reference in its own right).
Pinpoint isn’t replacing any of your favorite/process-of-record tools for implementation. Each of those continues to play its full role in whichever design center-of-expertise has responsibility for that function. What Pinpoint provides is effectively a real-time consolidated web-based view of results and status across a variety of disciplines. This starts with a dashboard view across all monitored projects. You can drill down into a project to see progress on metrics and trends by run versions, across covered analyses.
This alone provides an important sanity check and management tool for how the design is progressing. We all know that the average project consumes 30-40% of (actual) schedule at around 90% complete (funny how that happens). Much of that time is spent diagnosing problems and negotiating suggested fixes, many of which require tradeoffs across domains. The first synchronization time-saver is that you can all look at the Pinpoint status page without needing to first build presentations; which blocks are in good shape and which are struggling is immediately obvious. In fact, if your block is doing well, you may not need to turn up to the meeting at all, a second time-saver for at least some of you. Not that you don’t love extra meetings.
All that’s great to reduce management overhead, but can it help get the job done as well? Yes it can. From the dashboard reports, block teams can drill down from a current or earlier analysis to connectivity-aware layout views overlaid with IR-drop heat maps and critical paths. And they can filter paths to display, based on all the usual criteria. But instead of one tool expert sharing screens from a process-of-record tool with others who aren’t expert in that tool, all teams with an investment in the problem can look at and experiment with the data, before, during and after the meeting.
Now you have a basis for productive conference call between smaller hands-on teams. You’re all seeing the same thing, you can debate real-time how to triage the analysis results and what to do next. You can look back at previous runs to see if a suggested fix made the problem better or worse. You converge faster because you’re all working from the same page (literally). You’re synchronizing real-time on fixing problems, without needing to get to a larger meeting.
If you’re at a small company, all working around the same table, this probably isn’t for you. But if you’re building big designs across multiple time-zones, think a moment on why Qualcomm and other big companies are using this software. For the managers, it saves time and money (~$1M in allocated headcount cost in one project, just by pulling in the release date), for the workers it saves time, reduces time spent in soul-sucking meetings, and lets you spend more time wrapping up your part of the design and spending quality time with your family. You can learn more from this Consensia Webinar.
Also ReadShare this post via: