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!

  • Updates for Effective Collaboration

    Who will Apple partner with at 20nm: TSMC, Intel, Both, or Neither?-met0.jpgManaging any design data management system requires a policy on how often users should be submitting their changes to the central repository. If users commit frequently with less local testing then other users will more likely see errors. If commits are done less often, but with better testing, then other users are protected from problems.

    In practice, submits and workspace updates may not get done regularly until close to a release. So everyone has a smooth time during development since they are not inconvenienced by other people's changes but at the most critical point in the project users experience major because, in the end, submitted code needs to run against the latest release, not against an old snapshot.

    In the software world, things are relatively simple since compilation and running some limited regressions is not particularly expensive in either time or money. In the semiconductor design world, this is often false. Running a DRC/LVS on a block may take an hour and certainly involves expensive physical design verification tool licenses.

    Most projects use one of two methods to ensure that teams can always have a functional design to work on:
    1. Commit gates: this method blocks teams from committing changes to the source code repository if that change does not pass some sort of ‘sanity’ check. This sanity check is usually a compilation or other light-weight check that ensures a nominally working design repository
    2. Releases: this method allows users to check in changes into the repository with minimal checks or with no checks at all. Instead of striving to keep the repository always ‘clean’, users can wait until they are happy with a portion of their design, and then ‘release’ their changes to the team. The project will set the level of testing or checking required before a user is allowed to make a release. A release can consist of anything from multiple check-ins from several team members down to a single check-in from one team member.



    For most practical situations, the second, release- based flow is preferable. The compilation or checks required by the commit gate method are usually too time-consuming to be effective, and tend to block progress.

    ProjectIC from Methodics makes managing this release process more straightforward by using "keep local" mode for updates. A simplified example can make this clearer. The design consists of all the green files.

    Who will Apple partner with at 20nm: TSMC, Intel, Both, or Neither?-met1.jpg
    The user has modified and checked in a couple of them (red).

    Who will Apple partner with at 20nm: TSMC, Intel, Both, or Neither?-met2.jpg
    Then all the files in the workspace can be updated to the next release (yellow) except the ones the user is working on, any changes to these files in the new release are essentially ignored and the workspace keeps the local versions in the users workspace. This allows testing with other users' changed files without affecting the users ongoing work

    Who will Apple partner with at 20nm: TSMC, Intel, Both, or Neither?-met3.jpg
    If everything looks good then it should be safe to check the work in without causing any other users to see anything broken.

    There is a 4-minute video that explains effective collaboration in more detail here.
    The white paper Workspace Updates for Effective Collaboration is here.