Using Releases for Analog IC Design

In a typical analog IC design team, multiple engineers and layout professionals work on cells and libraries. At various points during the design process they will commit changes to their designs into the Design Management (DM) system that manages their files – be it Subversion, Perforce or some other commercial tool.

Using the VersICAnalog Verification flow from Methodics, designers now have a way to run scripted tests and regressions from within their Cadence environments. These tests can be launched, tracked and analyzed right from the Cadence GUI. Once a designer is satisfied with her changes – say with a combination of visual checks and scripted regressions – she can commit these changes to the DM.

Committing changes to the DM system achieves two goals – it allows designers to save their work, and to communicate their changes to peers and integrators. However, there is no real check to ensure that a particular design change committed to the DM works within the context of the overall design. Often, individuals may commit changes that may work in their context, but break the design as a whole. At the integration level, it is usually hard to pick up a set of commits from the design team and try to integrate them, particularly for larger designs.

The VersIC release flow is designed address this particular problem – ensure that check-ins that are visible to other team members adhere to a minimum quality level. The quality level itself can be dialed in by the team – it can be as strict or as loose as the team chooses it to be.

The VersIC Release Server is a process that runs qualifying scripted regression in the background on release candidates to ensure that they meet this minimum quality requirement. A release candidate is created when a designer reaches some logical point in the design cycle – and submits her recent changes for release. These changes can be a single change set, or multiple change sets accumulated across multiple days of work. Release candidates are submitted to the Release Server by VersIC and they are added to the tail of a queue of candidates.

Release Server Flow

The Release Server pulls candidates out of the queue in FIFO order, creates a special workspace with the last known good release, applies the changes in the candidate to that workspace and runs a qualifying regression. If the regression passes, the team is informed of a new release. The next time any user updates her workspace, VersIC will update it to this new release. If the release fails, the user that submitted the candidate is informed of the cause for the failure, along with logs to look at and then debug the failure mode.

The advantage of this flow is that users can continue to check-in changes into the DM system as before. However, every time that they reach a small or large internal goal, they can attempt a release, which allows them to fix problems in an incremental fashion. Also, other users do not see their changes until it passes through a quality check.

VersIC Release Management Console

The VersIC Release Server has many advanced features to optimize for both run time and resource usage. The key run time optimization feature is Pipelining – the release server can handle multiple releases from different users simultaneously, building workspaces and running them in true pipelined fashion so that it can scale dynamically with the load. Another key feature is the ability to split designs up into self-contained ‘blocks’ (say a Cadence library can be designated as a ‘block’), which allows users to release changes to cells within a block without impacting other blocks. VersIC also automatically picks up the right qualifying regression to run based on the current context so that relevant qualification is applied to the release candidate.

VersIC implements a well thought-out release management system right within the Cadence environment which makes collaboration, integration and tracking seamless and effective for both large and small IC design teams.

Further Reading
Bringing Sanity to Analog IC Design Verification using RegressionsMethodics CEO on Managing Design Quality!
Analog IC Verification – A Different ApproachA Brief History of Methodics

lang: en_US