( DAC 04 Item 7 ) ---------------------------------------------- [ 02/09/05 ]
Subject: Synplicity Identify
THE BUG HUNT -- Wow. I'm impressed. It's not often that you hear FPGA
designers praising an FPGA debugging tool. Yea, the user below are bitching
about small flaws in the tool (which means they're actual users) but they're
pretty much happy with it. I'm impressed.
We do use Identify here on occassion. I initially tried it about a year
ago and the only other tool that I compared it to was ChipScope Pro. I
have never used any of the Altera tools. During the evaluation period,
we found that although Identify was not perfect, it was not as much of a
manual process as using ChipScope was. I have been told that ChipScope
has had some improvements since then, but I have not re-evaluated it.
Overall, we are reasonalby happy with Identify (currently using version
2.1.0). As I said, it is not perfect, there are some annoyances and
integration issues on Synplicity's side. For example, when launching
Identify Instrumentor from Synplify Pro, it places all the files in the
project into the Identify project (including *.sdc) files. When you
then try to open the Identify project in Identify Debugger, it fails
because it does not recognized the file type "other".
The work-around is to manually edit the Identify project file and
comment out the .sdc files, since they aren't needed by Identify. You
would think the people at Synplicity would have realized and fixed this
during testing, but I don't work for them.
Another example, when you implement a design Identify and then go back
to Synplify (using the synplify.tcl file provide from the Identify
project), you need to re-enter all your implementation options,
including which part you're targeting, desired clock rate, etc. The
flow went
Synplify (options set) -> Identify -> Synplify (no options set)...
Hmmm.... slightly annoying, but not unbearable.
With the integration quirks aside, we have been happy with the results
from sampling and debugging. The complex and state machine triggering
has come in very handy. Overall, I would say that the time that
Identify has saved us during various debugging tasks has made the tool
worth it.
- Jason White of Exegy Inc.
Identify works at the RTL level, rather than on a placed and routed FPGA
image, which I believe is how ChipScope works. Instrumenting the RTL is
pretty simple. Just bring it into the tool (can import Synplify
projects) and start clicking.
I've told them that they should license Debussy for this portion of the
tool -- Debussy makes it very easy to trace drivers of signals
backwards, and loads forwards. This facility would be handy when trying
to instrument the cone of logic that leads to or from a bad signal.
But anyway, you can achieve the same with the text search. As you
instrument you get a summary of how much of your FPGA is being used up
by the instrumentation -- very useful.
Once you're done instrumenting, save the project. This causes it to
create a new RTL hierarchy in a new subdirectory. All files are copied
into this new hierarchy whether they were instrumented or not. Here's a
wart: You have to create a new synthesis project/Tcl script (my flow is
script based, I don't use the GUI) in order to synthesize this new set
of RTL. Identify will create a Tcl script with the Synplify commands in
it, but they use relative paths and so only work from that particular
subdirectory. This doesn't fit well into our flow, which has an
established directory structure (netlists in one place, scripts in
another, logs somewhere else, etc.)
You may have a collision if you instantiate FPGA primitives in your
design, because Identify will include blackboxes of the FPGA primitives
it uses in the synthesis script, leading to multiple definitions of the
primitives.
Not insurmountable, but not the kind of issues want to have when using
two tools from the same vendor. In their defense, Synplicity bought
this product from Bridges2silicon and these kind of integration
problems have gotten much better since the 1.0 days when I started
using it.
I would like to see the synthesizer and instrumentor completely
integrated, with all this copying and project modification done
privately behind the scenes.
Verilog 2000 support was missing in previous versions, but is there
now. I'm always amazed that EDA tools lack support for Verilog 2000
syntax. HELLO? It was adopted in 2000!
Identify Warts: small small.
Once the design has been reduced to a bitfile the fun starts. Part of
what Synplify puts into your design is a TAP controller (actually, it
can optionally use the FPGA's built in TAP controller) but in my
particular system that's not an option. It talks to this TAP controller
via a couple different commercially available parallel cables. From the
cable to your FPGA is your responsibility. This may involve soldering
some fly wires, or a home brew adapter to an existing connector. In my
case it's an adapter cable to an existing connector. This requires hand
editing of the RTL after it's been instrumented and before it's
synthesized. Identify adds the 4 JTAG wires as ports to the top level
of your FPGA, but in my case the JTAG port already exists, the new TAP
controller just needs to be hooked to it. It's a bummer to finish a
2 hour synthesis/place/route and then realize you forgot to make that
edit.
Why not USB? Some computers don't even have parallel ports anymore!
And the ones that do make them tricky -- does that port respond to LPT1,
LPT2, or something else? One laptop I tried with a single parallel port
had to be set to LPT4 for the tool to work.
Establishing communication with the FPGA is picky. In my current
project, I've been trying to get this communication working off and on
for over a month with little luck. I've had problems come and go
depending on which version of the synthesizer I use, and which version
of the instrumentor I use, etc. There's very little visibility into
where a connection problem may be -- I've had to use the scope and break
open the parallel cable.
Identify Warts: medium to large
I've gotten very responsive support from Synplicity with these problems.
Part of the problem that makes it drag on is that it's difficult to get
more than a trivial testcase out of ARM and to a vendor!
With that said I still like Identify very much. When it works, it's the
cat's meow, as they say. You view the RTL in a GUI same as when you
instrumented it. A trigger is as simple as clicking on a signal. It
supports more complicated state machine triggering also, and provides
a counter that can be used. In the past it took a complicated command
line syntax to set up these triggers but I see the latest version has a
state machine builder. Since I haven't actually gotten the debugger to
connect I haven't had a chance to use that yet. Once it triggers it
downloads the waves and you can view them with the included GTKwave.
I don't like it that much so I usually save as a VCD and bring it up in
Debussy. I have used it with great success on 2 previous projects,
which makes my current problems that much more vexing -- I know what
I'm missing!
They recently added the ability to reinstrument a design without having
to repeat the entire synthesis/place/route flow. Once the initial
instrumentation is done you can re-instrument directly on the FPGA image
(.ncd or .ngd or whatever). I think you can only move around the
existing instrumentation wires not add new ones. But since I haven't
gotten the communications working I haven't been able to use this
feature either.
If you want a bottom line, I'd say that the usefulness of Identify very
much outweighs the problems I've had. Every release that has come out
has addressed some of the integration or other problems so they're
making good progress.
- Steve Ravet of ARM
I don't think I'd be overestimating if I said Identify has saved us
weeks of debug time. If we couldn't reproduce a bug in simulation,
our previous method of debug was to add probes to the design using the
Xilinx FPGA editor. The numerous limitations included pinout (limited
number of pins available for debug), routing delays all over the map,
translated state machines and optimized logic. In our design we only
have 32 available pins for debug. Considering our data bus is 35 bits
wide... you get the idea.
Now we instrument entire modules in one go and dump a waveform into
Cadence's SimVision. Usage has spread from just me to everyone in my
group involved with FPGA prototyping. There's no denying the benefits
of Identify.
- Marty Stainbrook of Emulex Corporation
Index
Next->Item
|
|
