( ESNUG 365 Item 10 ) -------------------------------------------- [02/15/01]
Subject: ( ESNUG 364 #3 ) 4 Users Discuss A Boatload Of Synopsys ACS Bugs
> A question I asked Synopsys when we first found the problem was "has
> anyone else used ACS?". They've been unable to come up with anything, so
> I was wondering if anyone in the ESNUG community would like to share their
> experiences? How they found its compile times, how well constraints were
> met, impact on layout, gotchas and successful techniques etc.
>
> - Tom Fairbairn
> 3Com Europe Ltd. Hemel Hempstead, UK.
From: Mario De Weerd <Mario.DeWeerd@mie.alcatel.be>
Hi, John,
I have tried out this ACS system from Synopsys in Q2 of 2000 to see if it
would obtain better results than what I was doing manually. I was using
V99.10(-4) of Synopsys ACS.
At the time I ran into 4 or 5 major problems with their system. I succeeded
in bypassing most of the bugs by modifying the ACS generated scripts or not
using certain combinations of options. The final staw for us was ACS had a
consistent crash of its budget_shell tool for which a STAR was issued
(105427). Since that date (16 Jun 2000), I have not been informed about the
status of this problem.
Prior to that, there was a problem with a gated clock that remained unmapped
after synthesis with ACS. This stems from the set_dont_touch_network
constraint adds set_dont_touch constraints on every combinational part of
the clock. This became STAR 105055. I have no feedback on that either.
Furthermore the 'set_critical_range' constraint is propagated for pass
"pass 0" (acs_compile_design) and not for the acs_refine_design or
acs_recompile_design passes. This was filed under STAR 104882.
So, despite my efforts, I was not able to obtain an acceptable results
with ACS mainly due to the fact that budget_shell was crashing. ACS is
surely no miracle system, and for optimum results, Design Compiler must
still be guided with the appropriate options that you can set by using
ACS attributes.
Maybe somebody else has more positive feedback.
- Mario De Weerd
Alcatel Microelectronics Colombes, France
---- ---- ---- ---- ---- ---- ----
From: Tom Fairbairn <tomf@pdd.3com.com>
John,
Many thanks for putting Mario in touch with me. Interesting stuff indeed.
It's taken us 2 months to get Synopsys to tell us of ANY other customers
using ACS at all!
Mario, thanks for your experiences. We've been struggling to get Synopsys
to refer us to some customers using ACS. It looks like it might be more
than just unwillingness to change methodologies causing the lack of
adoption. Bugs are a pain but bearable if they're fixed. Synopsys doesn't
seem to be committed to fixing ACS related bugs.
John, in the interests of sharing results, here's a table of ACS/Budgeting
related STARs Mario and I submitted for ACS:
STAR Num Description Fixed?
113984 budget_shell crashes on my design N
109279 timing exception on a block caused
that block to not be compiled due to
dont_touch Y
105427 budget_shell crashes on my design N
105055 set_dont_touch_network sets dont_touch
on all combinatorial fanout of that net N
104882 set_critical_range constraint not
propagated further than pass0 N
Thanks a lot guys!
- Tom Fairbairn
3Com Europe Ltd Hemel Hempstead, England
---- ---- ---- ---- ---- ---- ----
From: "Darach O'Murchu" <spud_chopper@yahoo.com>
Hi John,
I used ACS for our latest chip (comms chip, 200Mhz, 0.18 micron, 200 Kgates)
Synopsys version 2000.11.
I ran a pass1 compile (acs_refine_design) with no apparent problems, but it
did not improve on timing and it only yielded a 1.4% improvement in area
(over pass0).
I did have a few problems however with the initial compile run (pass0). ACS
did not derive some of the commands properly from the top level constraint
file when generating the constraint files for each partition of the design.
So a few hand edits were required:
- it did not propigate set_multicycle_path commands correctly
- it did not propigate set_dont_touch commands correctly
- some of the create_clock commands were screwy
- I was using a custom wire load model, so i had to re-write the
set_wire_load_model information for each sub design in each of
the partition blocks
This seams to offset some of the advantage of having ACS automatically
generate the individual partition level constraint files. But we were
satisfied with the clock speed our design achieved using ACS.
- Darach O'Murchu
---- ---- ---- ---- ---- ---- ----
From: Peter Kamphuis <peter.kamphuis@infineon.com>
Hi John,
Yes, somebody out there is using ACS. Well at least we are starting to
use it. Our current design system version offers the possibility to
use ACS as "kernel". Things like analysis, elaboration, scan insertion
and generation of data for backend are done with scripts similar to
those we have been using for a longer time.
We decided to implement ACS to be able to process larger designs more
easily. But, also to be prepared for future extensions by Synopsys.
Our synthesis environment now entirely sets up on Design Compiler's
Tcl-mode. Instead of ACS we can, for example, "plug in" Physical
Compiler. We are currently using release 2000.05-2. Unfortunetaly
we haven't had the time to take a closer look at 2000.11. We hope to
do that soon.
At Infineon in Munich there are two bigger projects that were the first
candidates for using this new, ACS based environment. No tape-out has
been done yet. I don't expect that to be different from other projects
however. We discovered a number of problems in using ACS, which I'll
try to describe in the following. Nevertheless I hope that more projects
will follow. Having learned from our first experiences, I think we know
how to handle ACS for these.
First issue should have been obvious: If one wants to process a complete
chip, the whole design needs to be budgeted. RTL budgeting can run for
hours. And also pass 1 budgeting needs appropriate CPU and memory
resources. Don't underestimate this. Our recommendation is to use ACS
on a level below chip-level and to only "link" chip-level together. Of
course this means that we must write constraints for more designs again.
The compiling of the ACS partitions after budgeting, using the parallel
processing capabilities of ACS, really improves run times.
Next, what should be obvious too, the parallel processing capability
of ACS needs many licenses. One license is always needed for the main
invocation of Design Compiler. Then one or more additional licenses
are needed to compile the ACS partitions.
Then we found out that not all top-level constraints are passed down to
the ACS partitions correctly. We know about the set_ideal_net and, as
discovered recently, the set_false_path or set_multicycle_path commands.
Luckily it is possible to patch any generated partition constraint
script. This should be improved, of course, by Synopsys.
Finally we are seeing problems with the use of LSF (Load Sharing
Facility) that is supported by ACS. This could be, however, dependent
on our infrastructure. At the moment that ACS starts a larger number
of partition compiles in parallel with LSF, a larger number of machines
try to access the same (automounted) directories at the same time.
Here we have seen various crashes of the LSF processes, leading to
incomplete results. As a workaround it is possible to reduce the
number of parallel processes. This means a longer processing time of
course. Problems may also arise when the parallel processes steal away
the last available license.
Nevertheless I think the ACS methodology has the ability to process
large designs more easily and faster. Some improvements are still
needed to be made by Synopsys. We see ACS as the tool for top-level
designers. For sub-level design development simple compile scripts
(and simple constraints) can be used. On top-level ACS will squeeze
the best out of the design.
- Peter Kamphuis
Infineon Technologies AG Munich, Germany
|
|
