( ESNUG 467 Item 3 ) -------------------------------------------- [07/26/07]
Subject: ( ESNUG 461 #3 ) We moved to BlastCreate/Conformal due to a DC bug
> My company recently decided to purchase Formality because of the reason
> Jay is unhappy. The Formality-DC flow is better integrated than other
> flows. This makes it easier to use. With a Synopsys flow, you get some
> of the setup straight out of DC, so it's not as hard to setup as when you
> mix and match tools. This is a technical advantage, not a deficiency.
> Formality is still independent (the data is verified) and it can be used
> with Cadence & Magma. You just lose the setup advantage when you're
> not using it with DC.
>
> - Vittorio Melini
> Xignal Technologies AG Unterhaching, Germany
From: Jay Pragasam <jpragasam=user domain=plxtech bot calm>
To: John Cooley <jcooley=user domain=zeroskew bot calm>
Hi John,
I see some interesting responses to my post. Here's my followup.
First of all I am not unhappy that Formality-DC flow is better, but I am
unhappy that the Formality-BlastCreate flow is worse, at least in our case.
On the same lines, I have no grudge against using dwsvf files if it improves
runtime without messing up with accuracy, but Formality should be able
to verify fairly smoothly in the absence of the dwsvf files.
In our design where we used BlastCreate, Formality simply could not come to
a conclusion and we were "officially" told that dwsvf is the only savior. I
refrained from revealing that we had to use our out of maintenance version
of LEC to get going. The fact that this outdated LEC compared the design
just fine killed our faith on Formality. My prior experience with Formality
has always been good; be it a Synopsys flow or a Magma flow, but the
synthesizer has always been DC. Bottom line is BlastCreate/Formality did
not work. Was it a tool issue or a support issue is up for debate.
BTW, why did we switch to BlastCreate midstream when we had DC? That's a
whole different story. DC produced bad logic which couldn't be fixed before
our tapeout schedule.
- Jay Pragasam
PLX Technology Sunnyvale, CA
---- ---- ---- ---- ---- ---- ----
From: John Cooley <jcooley=user domain=zeroskew bot calm>
To: Jay Pragasam <jpragasam=user domain=plxtech bot calm>
Hi, Jay,
Please explain more about the bad logic created by DC. You can't drop a
bomb like that without details.
Also, what is this "out of maintenance LEC" you speak of? Verplex?
In general, I'm ask you to not be vague in ESNUG. Engineers are all about
the details, details, details....
- John Cooley
ESNUG/DeepChip.com Holliston, MA
---- ---- ---- ---- ---- ---- ----
From: Jay Pragasam <jpragasam=user domain=plxtech bot calm>
To: John Cooley <jcooley=user domain=zeroskew bot calm>
Hi John,
Yes, DC did create bad logic. We struggled together with the Synopsys R&D
folks to figure out the root cause. We were given multiple patches, but the
bug persisted. Due to lack of time, we couldn't afford anymore debugging
and switched to BlastCreate. Synopsys claimed that it was a "ghost bug"
which appeared once in a while. Unfortunately, in our case, on that
specific design it happened every time. Since then we have completely moved
out of DC as BC/Fusion is able to meet our needs. I hope the bug has been
resolved now. That's all the detail I have. I'm not the RTL designer and
so I don't know exactly what construct & circumstances created the DC bug.
As far as LEC, it was a Verplex LEC copy that the company had purchased a
long time back but had chosen not to renew their maintenance contract. So
in essence we had the binary but not the support for any crashes or revision
updates. After our Formality experience, we've signed up for a full
Conformal license with maintenance.
- Jay Pragasam
PLX Technology Sunnyvale, CA
Index
Next->Item
|
|
