( ESNUG 440 Item 7 ) -------------------------------------------- [03/03/05]
Subject: ( DAC 04 #8 ) Four Users on DC-FPGA vs. Synplicity Synplify Pro
> Synplify Pro:
>
> Only complaint we have is that it doesn't always create an EDIF that will
> time in the backend but, rerunning it always creates an EDIF that times.
> Go figure.
>
> DC-FPGA:
>
> Synopsys did an eval for us on an existing design (133 MHz Virtex II Pro)
> and couldn't do better than Synplify Pro. They wouldn't give me the
> backend timing report (only the DC-FPGA report) so I'm not sure how well
> the tool really did.
>
> Exemplar: never used.
>
> - Don Monroe of Enterasys Networks
From: Dave Brown <dbrown=user domain=agere spot gone>
Hi, John,
We used DC-FPGA as a beta-site customer on the development of one of our
network processors. We came from a background of using FPGA Compiler II to
map our ASIC source code into FPGA gates for our chipset.
We were faced with the following choices:
- continue using FPGA Compiler II (FC2)
- become a beta-site for DC-FPGA
- use Synplify Pro
As it turned out, we ended up doing all 3 during the life of the project.
We started out with the strategy of being a beta-site for DC-FPGA, with a
fall-back plan of using FC2. Since we had an evolutionary design, this was
pretty straight-forward because we had used FC2 on the previous version of
the product.
Our previous synthesis flow used a bottoms-up methodology to:
- minimize the time it took to turn one of our FPGA partitions.
(We would only resynthesize the modules that changed.)
- match FC2's capacity limitations - compile times went up and QOR went
down when the amount of logic that FC2 had to synthesize went up.
Starting out with DC-FPGA, we used the same methodolgy as we had with FC2.
Being early in beta, we did not see any QOR improvements so we stayed with
FC2. However, as we progressed in our project and the size of our design
grew, FC2 was no longer able to meet gate capacity.
At this point, we started experimenting with Synplify Pro in parallel.
Synopsys worked on improving the QOR of DC-FPGA. While FC2 met capacity
for some of our FPGAs, it couldn't do all of them. By using Synplify, we
were able to "fix" one of our FPGAs from a density perspective. However,
we still had one FPGA where we couldn't fit our logic into with any of
the synthesis tools that we used.
Subsequent releases of DC-FPGA showed improvements in both run-times and
density QOR. We were able to switch both FPGAs that we were having problems
with back to DC-FPGA. Also we were able to adopt a top-down synthesis
methodoolgy, which greatly simplified the FPGA creation process for us.
In my experience, DC-FPGA offered several benefits over FC2:
- Great improvement in runtime - on the same compute engine, an FPGA that
took 12-13 hours to synthesize in FC2 was reduced to 2-3 hours.
- Improvement in methodology:
1) DC-FPGA scripting is similar to what we do in PhysOpt/DC, so we will
no longer have to control two very different synthesis tools
(FC2 vs PhysOpt/DC). Focusing on one methodology (top-down) for
both FPGA and ASIC builds saves time.
2) output reports for FPGA builds were exactly like the ASIC output
reports; parsing through the reports for warnings/errors was easier
because all tools reported the problems in the same fashion.
With DC-FPGA, we were able to go from a 3 hour synthesis for a *portion* of
one FPGA to a 3 hour synthesis for the *entire* FPGA. In addition, because
of the improved gate capacity, we were able to actually fit the critical
functionality of the design in the FPGAs.
- Dave Brown
Agere Systems Austin, TX
---- ---- ---- ---- ---- ---- ----
From: Jeff Benis <jeff.benis=user domain=synfora spot gone>
Hi John
We rely on heavily parameterized code, with hand instantiated DesignWare.
Our goal was FPGA prototyping of ASIC designs, with the possibility of FPGA
as a final target. We synthesized 9 designs using DC-FPGA. We wanted:
1. Few/No modifications necessary to our current ASIC DC Ultra scripts.
2. No modifications necessary to our RTL (including use of DesignWare).
3. Very easy integration into our current DC/PhysOpt Synopsys flow.
The modifications necessary to our normal DC Ultra scripts were minimal.
Most changes involved the inclusion of FPGA specific libraries and commands,
and were expected.
There was some confusion concerning the ordering of some DC-FPGA commands.
Our normal flow, using 2003.12, consists of:
read
analyze
elaborate
link
uniquify
set constraints
set compile options
compile
report
DC-FPGA was very sensitive to the order of these commands, and particularly
where "set_fpga_target_device XXX" was placed, sometimes resulting in
unusual error messages. Trial and error did result in robust scripts.
I believe part of the ordering problem is due to differences between DC-FPGA
and DC Ultra, and part due to differences between 2003.12 (which we now use)
and 2004.03 (the DC-FPGA version). 2004.03 handles uniquification
differently than previous versions. More experimentation will be necessary
once we download updated synthesis binaries for Ultra and PhysOpt.
Overall, I was please at the ease by which DC-FPGA scripts were created.
As expected, no modification was necessary to the RTL.
The necessary changes to the synthesis scripts requires a small effort to
integrate the DC-FPGA flow (particularly an automated flow) into our
standard flow. I consider this small effort expected and acceptable.
In general, when compared to Syplicity tools, DC-FPGA had a slightly longer
run time, but slightly-to-moderately better timing results. Area reported
by DC-FPGA was usually similar or slightly larger than Synplify.
After placement and routing by Xilinx tools, results were mixed. Some
designs synthesized by DC-FPGA had better timing results, while other
designs benefited by synthesis using Synplify. In all cases, results by
both tools were acceptable for our use.
DC-FPGA has the distinct advantage of correctly handling DesignWare parts
in all test cases. These test cases were not able to run through
the Synplicity flow.
Overall, I was very pleased with the DC-FPGA. I consider this tool a great
choice for ASIC creators interested in prototyping in FPGA.
- Jeff Benis
Synfora, Inc. Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: Nelson Yue <nelson.yue=user domain=idt spot gone>
Hi John,
We evaluated DC-FPGA vs. Synplicity in our current design. In general,
DC-FPGA gives 5+% of timing improvment with about the same slice utilization
and run time of Synplicity. As we're ASIC designers, we're DC users; the
abilitly to leverage our DC scripts and constraints for our FPGA prototypes
gives DC-FPGA an edge over Synplicity. (No one likes to spend time doing
this kind of book-keeping between 2 unrelated tools.)
- Nelson Yue
Integrated Device Technology, Inc. Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: [ The Invisible Man ]
Hi John,
Could you keep me anonymous please.
We are currently working with DC-FPGA to do ASIC prototyping on FPGA. We
compared it to Synplify Pro, but found DC-FPGA more attractive because it:
a. Has the same environment as DC, and our ASIC engineers are very
familiar with DC language.
b. It works with all DC constraint language (not only SDC), netlist
editing script, and timing reporting script.
c. It processes DesignWare components.
d. It has a HDL compiler that we have confidence in.
e. Preserve boundary by default.
f. Capability in controlling FPGA specific optimization (i.e. turning
them off is easy.)
Our last project used DC-FPGA. We started with Synplify Pro but switched
to DC-FPGA because of all reasons above. Synplify was not suitable for our
case of ASIC-to-FPGA prototyping.
- [ The Invisible Man ]
---- ---- ---- ---- ---- ---- ----
From: [ Chicken Man ]
Hi, John,
Just wanted to give some positive feedback on DC-FPGA. Please keep me
anonymous.
So far the tool has been working well for me. I have been using it for
about a year now basically using FPGAs for ASIC prototyping. The run times
and QOR are excellent. I can do a complete top-down compile (one script)
on a large RTL design (about 1.4 Million ASIC gates) containing a 32-bit
CPU core, AMBA busses, memories, etc; in about 3 hours.
Seems to go smoothly taking the .edif into the Xilinx backend tools. I am
targeting a Virtex2 8000. I like using the TCL scripting as it is quite
similar to DC which I am most familiar with.
So overall, a big improvement compared to FPGA Compiler II. DC-FPGA was
quite easy to use for people like me coming from an ASIC background and
who don't want to spend a lot of time & effort converting my design to an
FPGA form. Another advantage is it supports DesignWare stuff natively, an
issue when moving to Synplicity or Mentor.
- [ Chicken Man ]
Index
Next->Item
|
|
