( ESNUG 401 Item 7 ) --------------------------------------------- [10/17/02]
Subject: ( DAC 02 #2 ) Synchronicity Was So Bad We Wrote Our Own RCS Tools
> "We use Synchronicity for configuration management and issue tracking.
> It does a solid job of both. For configuration management, I still
> wonder if you couldn't piece together equally useful tools using free
> open source packages, e.g., CVS."
>
> - John Busco of Brocade Communications
From: Shiv Sikand <sikand@matrixsemi.com>
Hi, John,
I have used DesignSync DFII from Synchronicity and found it to be one of the
worst tools I have ever used in my life. In fact, it was so bad I wrote my
own interface while at SGI and subsequently open sourced it. I wrote to you
about this a while ago. Here is the URL:
http://public.perforce.com/public/perforce/cdsp4/index.html
A little history lesson:
Cadence 4.3 was based on the Edge database. The Edge database was not very
amenable to software configuration management because it used a proprietary
'catalog' file which contained the list of cells in the library. This
catalog was also the source of many corruption issues in the DB because it
was a single access bottleneck in a multi-user environment. However, this
DB contained a checkin/checkout mechanism and a versioning system. This
worked well at the cell level, but the configuration feature which allowed
you to manage versions across a set of objects was flawed and never worked
correctly.
In Cadence 4.4, they shifted away from the catalog idea and moved to a
different architecture that was more amenable to UNIX style manipulation
like cp and mv. This database was almost like normal files, except for
one feature: co-managed file sets. i.e. it takes multiple files to
represent a single 'cellview' in Cadence. In conjunction with this new
scheme, they also announed Team Design Manager, TDM, their configuration
management software. Unfortunately, this was an overly complex and buggy
piece of software and after a while Cadence decided that they were going
to outsource this capability and end-of-life TDM. They released an
abstraction layer called GDM (or Generic Design Manager) which was meant
to be a general API for managing all Cadence database objects. However,
it too is fundamentally flawed since it has no error handling mechanism
nor a communication channel to allow for error recovery and messaging.
It was not intended for customer use, but rather for third party
integrations. The Spectrum Design Services folks came up with an RCS
integration which they called CRCS. This was the time that Synchronicity
first showed up to the party. They built a GDM integration for their
DesignSync tool and later a stripped down 'free' version called Version
Sync.
The Synchronicity revision engine is based upon RCE, Walter Tichy's (the
author of RCS) follow up. This had a particular claim to fame: the Byte
Differencing Engine or BDE that they claimed allowed incremental storage
of binary files. Apart from the storage format, RCE is still just really
only RCS. Synchronicity wrapped it around a http protocol as a means to
enable easy access thru the enterprise intra and extra nets. However,
their extremely poor implementation of this system meant an extremely
slow, unresponsive and very buggy system that needed expensive UNIX
servers to run. Coupled with the flaws in GDM, this was a nightmare. I
used it at three separate companies and was involved with replacing it
at all three. However, Sync had a very good marketing department and
sold it to Intel, Lucent, Philips and a bunch of other players. These
companies were big Cadence houses and bought it because no-one else was
providing a solution at the time. Clio entered the market much later.
The horrors of DesignSync forced me to consider writing my own. I
convinced SGI/MIPS management (then headed by Lavi Lev, who is now
ironically the VP at Cadence responsible for IC Tools) to allow me to do
so. We purchased a GDM license from Cadence who were extremely helpful
and sympathetic to our cause at all time. After the work was finished
and proved to be a success, SGI and Cadence agreed to allow this
interface for Cadence, using the Perforce SCM system to be Open Sourced.
Perforce Software is now the copyright holder and the interface is
available under the BSD license. I avoided the GDM pitfalls by using the
Skill trigger model to manage the data, providing a NULL operation GDM
server. The GDM piece is Cadence proprietary and is available as a
binary. However, since it performs a NULL operation, it never changes.
In addition, through the use of Perforce's atomic transactions I was
able to avoid the use of extra marker files to handle the co-managed set
problem. This results in an ultra-high performance integration with a
very rich feature set, possibly the richest and fastest available today.
My whole point is this: Synchronicity is so bad that I spent hundreds and
hundreds of hours coming up with an alternative and I make the interface
available for free. In addition, I have recently completed a paper on
using Perforce for Hardware Design. This is available at
http://www.perforce.com/perforce/hardware.html
Anyway, enough of my rambling. I've probably gone on way too much about
my own stuff but I thought that this would be a good way to prove that I
suffered and then actually did something about it and made it available
for no cost rather than cry at EDA vendors.
- Shiv Sikand
Matrix Semiconductor
|
|
