Managing 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:
[LIST=1]
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.
The user has modified and checked in a couple of them (red).
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
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.
Comments
There are no comments yet.
You must register or log in to view/post comments.