( ESNUG 447 Item 1 ) -------------------------------------------- [09/26/05]
From: Kevin Broe <kevin_broe=user domain=britestream spot calm>
Subject: Two Users Hands-on Eval of Synplicity Certify FPGA Partitioning
Hey John,
I recently completed an evaluation of Synplicity Certify for partitioning
our chip across multiple FPGA's for prototyping purposes. The evaluation
was between Certify and doing it by hand (the old fashion way) in which I
took our design all the way through Xilinx P&R, but I did not actually
build the hardware.
The evaluation was to take an existing multi-million gate ASIC and partition
it to 10 large Xilinx devices. Then we evaluated how easy/hard it was to
make a change to the partitioning.
The bottom line is that Certify worked well, and automated all of the
tedious, error-prone tasks associated with partitioning an ASIC to multiple
FPGA's. The learning curve was short and the quality of results was good.
I also evaluated Certify's QPT feature (auto-partitioning) and found that
in at least 1 case it reached a better solution than I could find by
hand (in terms of I/O and resource usage).
There were a couple of usability improvements that I would like to see:
- the ability to modify a board file without starting over.
- the ability to add pin info through a TCL script.
- the ability to add RAMs and connectors more accurately to a board file.
And the resource "estimation" feature in Certify was in some cases
dramatically optimistic.
Overall a good tool and we are going to use it on our current project.
- Kevin Broe
Britestream Networks, Inc. Austin, TX
---- ---- ---- ---- ---- ---- ----
From: David Davies <ddavies=user domain=ikanos spot calm>
Hi John,
Since you asked, here are my thoughts on Certify.
Who should use Certify:
a) If you need to partition into more than 2 devices then you may want to
consider Certify because the complexity grows quickly with the number
of possibilities for what modules will go into what FPGA.
b) Also, if you need to partition multiple times during a project. For
example, if you're emulating a large ASIC you may want to break it
into pieces for emulation purposes.
Pros and Cons of Certify:
a) Certify will take in a Verilog board file (.vb) so the tool will know
the number of traces that connect each FPGA. A downside of the tool
is the creation of the .vb is not automatic. Certify should take a
OrCAD netlist and create the .vb automatically, but it doesn't. If
you buy Certify, Synplicity will give you some scripts that will help
out. Synplicity created the .vb for me so I never dealt with creating
my own .vb.
b) Certify is smart about auto trace assignments. It won't waste a common
trace connecting more fpga's than needed. It will use traces that only
connect to the required points.
c) Certify gives nice screen showing module connectivity so user can be
smart about how to partition modules if user wants to partition manually.
I did manual partitioning because I wanted to insure that pin muxing was
not used as may occur if you request the tool to do automatic partition.
Pin muxing refers to Certify inserting logic to allow a trace to serve
double or triple duty, (or more) by providing 3x or faster clock for
those signals. Pin muxing is supposed to be a big benefit of the tool,
but I never used it.
d) Certify creates top level modules for each fpga, which is nice.
e) Documentation is good.
Bugs:
I used Certify 6.7 Beta.
a) Compile doesn't recognize some intermodule connectivity is loadless or
sourceless but still includes them in I/O count calculation. Current
workaround is to find all these and manually tie them off at the top
level, otherwise, drap/drop info is not correct.
b) Verilog files containing only `defines are missing from generated .prj
for each FPGA.
c) I have various signals in the trace assignment window as already
assigned via .paf. I want to have the tool automatically place the
rest. I can't seem to do it unless I manually click around the matrix
to avoid the preassigned pins when selecting those I want to auto
assign. If I select to top left corner (selecting all) then I can't
"Mark" them because the "Mark" is greyed out. It is a bug and should
be fixed in a later version.
Sometimes top level signal names will get changed by the tool during compile
stage. This causes constraints applied to original signal name to fail
because original signal name is gone. The current problem is with original
signal FPGA_DEBUG[39:0] gets changed into FPGA_DEBUG_1[39:0] and this causes
my traces assignment in .paf to not get used for these signals. Certify
should never change the name of a top level signal.
- David Davies
Ikanos Communications Fremont, CA
Index
Next->Item
|
|
