( ESNUG 362 Item 6 ) --------------------------------------------- [11/30/00]
Subject: ( ESNUG 359 #9 ) How We Use ClearCase To Manage ASIC Design Data
> I was searching through ESNUG archives and found several people
> recommending the ClearCase configuration management tool for hardware
> design [ESNUG 345 & ESNUG 281]. I would appreciate it if anyone who is
> using ClearCase could elaborate on the usage model for ASIC design.
> Specifically, is the entire ASIC database (including Synopsys .db files
> and other miscellaneous files and directories created by various ASIC
> tools) under ClearCase management or just the HDL source? Managing the
> entire database seems to be overkill, but if a file is not managed it is
> not easily visible to other users working in other "views".
>
> - Shuhui Lin
> Alcatel USA Raleigh, NC
From: Anders Nordstrom <andersn@nortelnetworks.com>
Hi John,
We have used ClearCase on several ASICs for about a year. We have set up a
directory structure "/vobs/asicname" for each ClearCase domain. Under
"~asicname" we have the same directory structure for all chips:
/Documentation
/RTL
/Simulation enviroment
/Testcases
/Netlist
/Testplan
/Lab verification plan
We do not put the entire database under ClearCase. Log files and VCD files
which are only used for debugging and which change daily are kept in users
own views. All the RTL, documentation, testplans, verifcation enviroment,
testcases and synthesis scripts are kept under ClearCase management.
Basically everything you need to build the gatelevel netlist. We do not
keep .db files for lower level modules in ClearCase, only the final full
chip gatelevel netlist. We had one person doing all the synthesis so the
issue of the files not being visible was not an issue for us. In the future
we will have more people doing syntesis and then we will probably put
sub-system db files in ClearCase.
- Anders Nordstrom
Nortel Networks Ottawa, Ontario, Canada
---- ---- ---- ---- ---- ---- ----
From: Jim Avant <javant@mindspring.com>
John,
I was acting manager of a group where we were starting to use ClearCase. I
thought it was the best solution at the time. However, it was a real pain
trying to enlist the engineers to actually use it. Most dragged their feet
until the project got cancelled (got other reasons). Getting engineers to
use a new tool, especially a REVISION CONTROL tool, is like trying to herd
cats (sorry for the overused metaphor, but dammit it fits!). Most ASIC
engineers (and I'm guilty of this too) are "fly by the seat of the pants"
guys that don't like non-command-line, non-ASCII tools. And most are not
easily convinced that revision control is a NECESSARY evil (they pick up on
the evil part right away).
Also, ASIC design flows are different from S/W design flows in some tricky
ways. I found it difficult to preserve intermediate files (like .db files)
under revision control and still be able to build a chip without having to
do manual checkout of the intermediate files. Sure it can be done, but the
situation I was trying to avoid in the first place was having a dedicated
person writing scripts for revision control. Of course ClearCase is also
MUCH more expensive than most other solutions.
At my new job (www.socsolutions.com; check us out), I have another decision
to face. Do I try to leverage the software team's choice of PVCS and if so
how? Or do I maintain an independant tool and database for ASIC designs.
I'm still gathering information, but I will make a choice soon. ClearCase
is not even an option because we're still in start-up mode. But if I had
an open budget, I'm not sure I would pick it again. Don't get me wrong. I
think it's a great tool. But a shiny new tool that sits in the shed and
never gets used just doesn't impress anyone.
Good luck.
- Jim Avant
SoC Solutions
---- ---- ---- ---- ---- ---- ----
From: "Martin d'Anjou" <mdanjou@nortelnetworks.com>
John,
I do not use ClearCase, but your questions apply equaly well to any
revision control software. On my current project, we let the revision
control software manage only the files that can't be recreated by an
automatic process, i.e. anything that is an output of an EDA tool is not
managed: most times those files are too big. However, the scripts and the
configuration files are under revision control. This way, any designer or
verifier in the team can recreate any part of the design/verification they
wish. This is useful when one of us is on vacation and our boss wants an
up to date regresion for example. Anyone can launch the regression or
the systhesis and let it go.
If an EDA tool creates directories or files on its own, we typically don't
put those under revision control. I am thinking of putting regression
results under revision control (typically the "pass-fail" output text file
from simulation).
For the "final" or "official" synthesis and layout files, we store them to
a common release area sub-directory named after a unique release id number.
Currently, we don't put those under revision control, but the release area
is backed up on a regular basis. Then designers don't need to occupy disk
space in their own home dirs, and the results are available to all to
look at.
The revision control software we use is SOS from http://www.cliosoft.com/
and so far we are happy with it. I find it fairly easy to configure.
- Martin d'Anjou
Nortel Networks
|
|
