( ESNUG 427 Item 2 ) -------------------------------------------- [04/14/04]
Subject: ( ESNUG 426 #6 ) Two Users Share Their Experiences With DC-FPGA
> As a side note, Synopsys DC-FPGA looks like interesting. I'm willing to
> try it when it's available. Though as we all know, previous Synopsys
> FPGA tools have been terrible. DC-FPGA seems like a good way to use
> similar scripts for both FPGA synthesis and later an ASIC port. I do
> think that if I knew I was going to stay with an FPGA for the end
> product I would stay with Precision though.
From: Dave Ohmann <dave.ohmann=user domain=alereon spot calm>
Hi John,
Now that DC-FPGA has been announced I thought I'd relate our experience it.
First the caveats. Synopsys is marketing this tool by stating you can use
it without changing any of your source code. This isn't exactly true. In
our design there were 3 blocks which differ between FPGA & ASIC: I/O cells,
clock generation, and a Dual Port SRAM. In each case I had to maintain the
block as a separate module at the top level of the hierarchy and switch
between the implementations as appropriate. I don't consider this
unreasonable.
We are a startup with experienced ASIC designers but with little or no
recent experience using FPGA's. We decided we wanted to prototype our UWB
MAC ASIC in an FPGA primarily to provide a development platform for the
software/firmware engineers in advance of the ASIC delivery. We bought an
off-the-shelf FPGA development board containing a Xilinx Virtex-II device
(XC2V1000-4FG456) to implement our design. Since our design was relatively
small by ASIC standards, would only be running at 33 Mhz., we desired
not to use time and resources to develop and maintain a distinct FPGA
prototyping flow separate from our ASIC flow. We decided to just use DC to
implement the design. We knew it would be inefficient with FPGA resources
but thought it would be acceptable for our design. We started implementing
functional blocks and initially the results were acceptable, but after
attempting to add one of the larger blocks in the design Xilinx ISE reported
that we were at 115% utilization. It would not fit in the chosen device.
The vendor for the FPGA development board did not offer a compatible board
with a larger device.
While we were exploring other options our Synopsys account manager suggested
we try DC-FPGA. I downloaded the tool, made a handful of changes to my DC
synthesis scripts, and within a couple of hours Xilinx ISE was reporting our
design was at 82% utilization. This allowed us to add functionality to our
design such that we were able to complete a working prototype with basic
compliance with IEEE 802.15.3. We were sufficiently impressed with DC-FPGA
that we bought it and continue to use it.
At SNUG the demos of DC-FPGA had shown a GUI. I am an experienced DC
user, am comfortable using dc_shell-t. I have never used the GUI, so I
cannot comment on it.
Finally, I have no idea how the results I obtained compare with what's
obtainable with either Synplicity or Mentor Graphics.
- Dave Ohmann
Alereon, Inc. Nevada City, CA
---- ---- ---- ---- ---- ---- ----
From: Han Nuon <hnuon=user domain=qualcomm spot calm>
Hi John,
We used to use the old Synopsys FPGA Compiler II as well as Synplicity's
tool, and I've evaluated most of the other FPGA synth products on the
market. A year ago, FPGA Compiler II had some serious issues. We were
about to toss out FPGA Compiler II when they came in to ask us to try an
early version of their next generation FPGA synthesis tool, Tornado (which
they later officially renamed "DC-FPGA".)
Surprisingly, rather than over-hype this like they did with FPGA Compiler
II, Synopsys seemed content to keep a low profile, and to really work with
us to ensure that this new tool solved our issues and truly added value,
rather than rushing out to announce DC-FPGA. I think this is the right
way to develop EDA tools.
Before we actually allowed Synopsys to bring in the early rev of DC-FPGA
a year ago, we benchmarked DC-FPGA head-to-head against Synplicity and
Aplus (Magma now). Synplicity ended up being a no contender and wasn't
even able to synthesize the designs in our design environment. We didn't
feel Aplus was worth the additional cost at the time we evaluated it, so
we chose DC-FPGA.
At first cut, Tornado beta was dog slow. We threw it back to Synopsys R&D
and, the DC-FPGA synthesis times dropped from 7 hours down to 1 hour. I
saw Nighthawk2 in ESNUG 424 #1, so it looks like Synopsys has also put
Tornado code inside of DC, too, except their marketing people now call it
"Adaptive Optimization Technology" instead. After using DC-FPGA for a few
other projects, we decided to replace all our existing FPGA synthesis tools
with DC-FPGA.
Most of the problems we had with DC-FPGA were fairly minor (interface
problems to Xilinx tools, renaming design problems, handling interaction
with some of our internal EDA tools, etc.) and were resolved quickly.
Also, none of these issues were show stoppers or unexpected for a new tool.
Synopsys tended to be very responsive when we had problems. All-in-all,
DC-FPGA is a pretty comprehensive tool and has a lot of functionality some
of which we hadn't had a chance to use yet. On future projects we plan
to use its gated clock transformation feature and perhaps the multi-FPGA
partitioning capabilities.
It looks like Synopsys might have actually got FPGAs right this time.
- Han Nuon
Qualcomm, Inc. San Diego, CA
|
|
