( ESNUG 516 Item 6 ) -------------------------------------------- [12/13/12]
Subject: Dassault FAE warns DesignSync V6 critic was neglectful DDM user
> DesignSync V6 is a dangerous tool. For example, the workspace we used
> for tapeout got corrupted just before the final checks we run prior to
> sending the GDSII to foundry. It took us one full day to recover data
> and the tapeout got delayed accordingly.
>
> - [ Burn Me Twice ]
> http://www.deepchip.com/items/0514-06.html
From: [ Rodney Busfield of Dassault Systemes ]
Hi, John,
These are very serious accusations that you published from an anonymous
former DesignSync V6 customer. I would like an opportunity to respond.
Dassault Systemes has dozens of global accounts that each have thousands of
daily licensed users of DesignSync. DesignSync V6 is responsible for tens
of millions of transactions per day, 1.5 billion (with a B) transactions at
one customer last year alone. Now THAT is a lot of DDM! I would hardly
qualify V6 as dangerous. Complex, yes. Dangerous, no.
There is an inflection point where a company needs DDM, then a tipping point
where proactive management of DDM environments is required for global design
methodologies. Many customers ignore the tipping point & carry on as usual.
While I am fairly certain which customer account this happens to be, I can
tell you that neglect of a critical system will always end in failure.
---- ---- ---- ---- ---- ---- ----
> Ironically, one of the perverse effects of the DS V6 "manifest" was that
> if one module is corrupted, the populate step seemed to freeze and it
> wouldn't do anything. ... Debugging these problems were tough. We
> tried, Dassault tried, Cadence's audit team tried, and we even looked at
> the hardware configuration. No one could find the problem.
First, the author of this post was probably a design engineer and has no
idea of the real issues, root cause and resolution. In fact, I am only
guessing as to the customer, so it is impossible for me to repudiate these
claims.
With that in mind, I am certain they were not using DesignSync V6 Modules.
The only corruption that we have ever had from a server is after serious
hardware failure with inadequate backup procedures in place; or (I think) in
this case, a failed hardware upgrade based on inadequate backup procedures
in place. There is a common thread. The only reason a workspace would be
corrupted and unrecoverable is that their server were not 100% operational.
---- ---- ---- ---- ---- ---- ----
> DesignSync V5 was slow. DesignSync V6 was supposed to speed up things
> using a "manifest" to help the server keep track of local changes. So we
> did a major transition, both to using Open Access and to DesignSync V6.
>
> Unfortunately V6 didn't fix problems, instead it got worse.
>
> I wished I had the prior DS version back! DS V5 was slow, but at least
> it was robust and reliable.
As for performance, hardware scaling and networks rule the day. Don't put
all your DDM on one server and one SAN. IT DOES NOT SCALE!
A bad configuration on a network accelerator or switch can be catastrophic.
It usually surfaces as a single design site with skewed throughput or
latency. For reading DeepChip on company time, the network runs fine, but
for sending 6 Tb of design data to Oslo, you tend to see the network
inadequacies.
Since DesignSync traffic runs over http/s, network accelerators try and do
bad things like cache and compress. It is very hard to find a bad
configuration on a box somewhere out on your global network.
In fact, we do regular performance testing against several CM systems and
the transaction time differences are negligible. Mostly we are faster,
some we are slower.
---- ---- ---- ---- ---- ---- ----
> It didn't take much with Linux permissions to bring DS off-balance. When
> we updated/populated a workspace with DS V6, we would have to just stop
> and wait. We would see no activity nor feedback and wouldn't know for a
> few minutes if it even populated properly. Even checking in one cell was
> like the Twilight Zone. V6 was very unpredictable -- sometimes it would
> work and continue to the next cell. Sometimes it would stop.
>
> Also, after following Dassault's hardware instructions to the letter, two
> years later, they told us we needed new hardware.
As I look back over notes on this customer's account, I can summarize their
issues in a few points:
- Failure to keep up with relevant/supported versions (6 version back!!!)
- Resistance to follow best practices that were outlined and demonstrated
to them.
- Denial by system administrators to accept our methods of backup for
such a critical system.
- Lack of dedicated people for managing a critical infrastructure tool.
- Putting all their eggs in one (hardware) basket.
Think about it.
- Would you ever run ALL you simulations on one box?
- Would you ever let Oracle lapse beyond support on your ERP system?
- Would you ever blatantly disregard your Cisco or Juniper rep telling
you that you have a bad switch configuration?
- Would you ever take a backup snapshot of a live DB without queries?
- Would you ever let go of your SOC validation engineers and just let
the circuit guys do it?
AE resources is only part of the problem. Had the customer implemented all
recommended changes, from AEs and Support Engineers, most of these problems
could have been mitigated.
There are reasons why companies are successful at DDM, DesignSync or not.
It has to do with understanding that Work-In-Progress Design IP should be
treated as the foundation for the entire design methodology. I work with
companies that have adopted this principal and see success on a daily basis.
Millions of them.
- Rodney Busfield
Dassault Systemes Austin, TX
---- ---- ---- ---- ---- ---- ----
Related Articles
Our Dassault DesignSync V6 nightmare and the IC Manage GDP fix
Join
Index
Next->Item
|
|
