( ESNUG 365 Item 5 ) --------------------------------------------- [02/15/01]
Subject: ( ESNUG 364 #11 ) 2 Users Share Synchronicity DesignSync Troubles
> Your readers are being a little tough on Synchronicity's DesignSync. It
> is a part of the very fabric of life here at Cypress, and we're successful
> in using this tool to allow us to distribute design work among Cypress
> design centers worldwide. Sure, we have a few problems, and sure, it
> takes longer than we'd like to copy data from India or the UK. We have
> to devote CAD resources to its maintenance. But it is working for us,
> and we have made dozens of chips successfully with it.
>
> - Grant Erwin
> Cypress Washington State
From: Bill Corr <bcorr@micron.com>
Hi John,
I noticed on the DeepChip site that you were asking for feedback from users
of the Synchronicity tools. Well here it is...
I would like to comment on my experiences implementing a Synchronicity
design management framework in a community of around 30 engineers. I had no
say in the purchase of this product nor was I involved in the Sys Admin side
of it's roll out. I have taken the "out of the box" product and fitted it
to the needs of the local design community.
So what is it like? Once you have got to grips with the concept of vaults
and local workspaces it is all very simple. You populate your local
directory with the design files you want to use and off you go. You can
check files in and out with the GUI or from the command line. The Project
Sync side is also quite simple and easy to use (it runs on your browser).
It really is nothing special, but it works. The Project Sync framework is
very customisable and Synchronicity use it for their own customer bug
tracking system which users can access via the web for support.
Design Sync also manages Cadence DFII objects, known as collection objects.
So you can say 'check in the layout for cellx' and DesSync checks in the
layout.cdb, master.tag, pc.db and prop.xx file together. This is great in
principle, but if you want to have a cell-centric data space containing more
views than just Cadence ones i.e. cellx/layout, cellx/documents and
cellx/synopsys then Synchronicity won't help you at all. Basically you
can't do this. Cadence is quite happy with this data structure in DFII, but
Design Sync can't cope with this. You can either recognise Cadence objects
or not. If you choose to recognise Cadence objects DesSync will ignore the
contents of your Synopsys directory. If you choose to disable recognition
of Cadence objects (to see your Synopsys objects), DesignSync will make a
mess of your Cadence views. It will check-in each of the Cadence files
individually and thus make it impossible to access them from DFII. Not very
clever. It does say you shouldn't do this in the manual, but then engineers
don't always agree with manuals.
However the DFII integration does work well. In my experience circuit
designers aren't interested in revision control, anything that can help them
manage their data without getting in the way is good news. From within the
DFII framework it is quite simple to use Synchronicity. You just open a view
for editing and it is automatically checked out for you. There are two ways
of getting to Synchronicity from within DFII, the Synchronicity drop-down
menu and via the Cadence library manager. Both ways work, though going
through the Synchronicity menu is slicker and is the recommended route.
As to files getting lost I can definitely say that I have never seen this
happening. What can happen is that a user changes their mind about where in
their workspace or server vaultspace they want DesSync to put their files.
If they are not careful about how this change is performed the server will
not place the data where it is expected, leading to confused users claiming
that the data has been lost. In all cases I have experienced of this the
server vault has been correct and no data actually lost. Checking in the
first design database can be a bit hit and miss. There is a wizard that is
genuinely useful, but for some reason if you say you want to put directory A
in the vault, the contents of directory A get put in there and not directory
A itself. This is quite confusing, but you get used to it. Once the first
database has been done it becomes a lot simpler as you then have a framework
to work around.
Things I don't like about the Synchronicty tools - the GUI is a port from a
Windows implementation and you can't copy/paste from text fields. This is
very poor indeed. The speed of access to vault data could be better, ver 3
(the latest release) is much faster than the previous version, but still
not really fast enough.
The command line mode has two 'cd' commands 'cd' and 'scd'. They do
different things, the problem is I am forever typing 'cd' when I should
really be typing 'scd' (the 'scd' command used to be called 'cd' until the
latest release), each time I get it wrong I get an extremely misleading
message saying the directory I want doesn't exist - prompting more 'cd'
commands until I remember what I am doing wrong. This is extremely
annoying.
Things I do like about the Synchronicity tools - the system may not be
perfect, but it works well and the integration between DesignSync and
ProjectSync is good. The ability to customise Project Sync is very good and
the batch mode commands available for DesignSync are very good. The DFII
integration works well, it's a shame that the DFII object handling by Design
Sync seems to be an afterthought. The triggers that can be set to 'fire'
when events happen to vault objects are excellent and easy to set up. They
are a great idea, probably the best part of the system.
The online help system is good and the technical support (via the SCINC
online help desk) is good too. Most problems get a reply within the working
day. This is infinitely better than other EDA vendors I can think of.
So on the whole I am quite happy with the system. I wasn't involved in it's
selection, so I didn't compare it with other tools and I don't know how much
better or worse it is than it's competitors, but it works and it is being
used by most of the engineers on my site. The libraries generated are being
shared with colleagues around the world with a remote mirror which took me
about ten minutes to set up.
A final note - the spell checker's recommended replacement for DesSync is
'dissent', which is exactly what you get when you tell a group of circuit
designers they are going to use a revision control system!
- Bill Corr
Micron
---- ---- ---- ---- ---- ---- ----
From: [ Elvis of Graceland ]
John, PLEASE KEEP ME ANONYMOUS !
We used Synchronicity up until version v212p1. I can't speak for ver 3+.
My first day at work, 2 years ago, they told me "you're not going to like
this thing called Synchronicity". Being fresh in the industry, I
didn't know what they were talking about, but a little while later I
understood. After everything started breaking months later, I was named
synchronicity czar at my company and began filing a steady stream of bug
reports. Eventually, we got things running again, but this was after
learning what commands not to rely on and what commands fail often.
A lot of the problems we had have been addressed in the latest release
(3.0). However, seeing how things were done in version 2 didn't give us
assurance that the company knows how to write software. Example: the null
operation of just pinging the server from a client would fail about 90% of
the time if it was the first thing you did in the morning. That's like
having 'ls' fail! It's not acceptable! We had cases where two people could
edit the same file. A hierarchical copy operation, copying many files,
might take 3 tries before everything got copied. It made the tool
impossible to script. On top of that, it was so slow that you never knew
if it was working or not. Labelling was so slow (over an hour to "label"
the project!?), that I wrote a Perl script that did the same thing 20x
faster. (By comparison, perl4 can label in 10's of seconds)
The ONLY thing that the company has to its advantage is that it is the
only company offering an interface between cadence tools and its version
control software. Synchronicity now owns the GDM interface of Cadence, so
it might retain its monopoly.
One telling thing: The company did not use its own version control
software during development of version 1 and 2 -- they used CVS. It wasn't
until management forced the company to use its own tool did they start
fixing things in version 3.
After much toil and turmoil with the tool, we decided to scrap the whole
thing and write our own interface for Cadence based on Perforce. We also
considered using CVS or even just UNIX tar/cp nightly.
Our project database contains about 35,000 files, used by about 50 users.
- [ Elvis of Graceland ]
|
|
