You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

  • 3 small-team design productivity challenges managed

    “Data management tools? We use small teams doing small designs. Each project only has two or three designers. Everyone uses the same EDA tools. Why do we need another tool for collaboration?” Good question. If you enjoy frequent meetings and redoing work because someone didn’t understand the status of IP blocks, the answers may not interest you.

    It’s common thinking that design data management tools are only for big teams working on big projects. Traditionally, that has meant large digital design projects with many different types of IP blocks, a range of project team roles, possibly different EDA tools in play, and expertise distributed across designers at multiple sites. Benefits of design management tools are well established for these situations where complexity is a given and collaboration is a must. The proposition becomes even more compelling where face-to-face interaction between team members is infrequent at best simply due to distance and time.

    Analog and RF design tends to be a bit more boutiquish in nature. Expertise is often concentrated in a couple of gurus. Sharing has been seen as more a matter of handoffs, for example where a schematic is finished and a physical layout starts. However, is that really the way a design flow works today, in a serialized fashion with a firm over-the-wall handoff between team members? What about communication with a third-party foundry? What about mixed signal designs with digital IP blocks integrated? What about feedback from test?

    Article: GlobalFoundries Announces 14nm Process-small-board-hand-jpg

    Small team members likely share more data more often than expected. Productivity challenge #1 is when a design has to be handed back upstream for any reason. Without a design data management package, when a problem is found the downstream team essentially stops, hands “the design” in entirety back to a designer to investigate, and waits for “the revised design” to come back before proceeding.

    With a design data management platform such as ClioSoft SOS, all data is in a repository and is robustly tagged. This provides granular revision control and version history for each IP block, and also provides system-level insight for downstream teams. Rather than a strict check-in, check-out model, SOS supports the concept of a workspace with role-based permissions. A team member can “populate” their workspace with read-only copies from specific parts of a design, or all of it, and do their work without impeding other team members. IP blocks can be tagged with states such as “verified” or “rel2layout” (released to layout), providing a positive indicator to all team members of design progress.

    Productivity challenge #2 is the handoff to fab, thanks to the fabless environment many of us operate in today. Often in mixed signal platforms on unique processes, the foundry actually performs much of the final physical verification as library data is merged in at the foundry. If minor iterations are required, the design team can quickly see exactly what was handed to the foundry – both IP blocks and schematic versions are associated and fully tracked. Revisions can be made, a new full-up version created, and the result handed back to the foundry. This happens without copying databases every time a handoff needs to happen; tagging and scripting extract the right data quickly and accurately.

    Reuse is productivity challenge #3. In the past, reuse was largely a cut-and-paste operation, lifting a section of circuitry in an editor, or pulling in a swath of HDL code. The result was stitched into the new design. Which version of the IP block was picked up? Was it the “current” version, fully verified through system-level tests at a foundry? Does it need to be a “special” version for a specific use case? Without design data management, the odds of grabbing the wrong stuff go up rapidly. With design management, all versions of an IP block and its associated metadata are ready instantly, and designers make an informed choice instead of a guess.

    In ClioSoft’s SOS platform, all this capability is integrated into the familiar EDA tool designers are already using. This is a huge pushback from small teams that typically don’t have training resources or full-time administrators and can’t afford wasted overhead. Since ClioSoft adds only a few pull-down items to the menus of a tool teams are already using, and data formats are already understood by the platform, designers can be up and running with design management capability in hours instead of weeks.

    A short case study testifies of the advantages small teams derived (it's from a few years back, but still valid) from making the leap to a powerful design data management platform such as ClioSoft SOS. It’s interesting to see the designer talk about the initial resistance to moving into such tools, and how those assumptions and concerns proved mostly false. On the other hand, the benefits gained in streamlining the handoffs and removing stalls in the project from just gathering data were larger than expected.

    Smaller, less experienced teams may become more of the norm as design size and time-to-revenue shrink with the IoT, maker, and crowdfunding movements. It will be fascinating to watch EDA practices evolve to meet the needs of these teams. Collaboration will likely prove to be a competitive weapon for these teams, and data management platforms could play a big part.