Dear ESNUG readers,
Enclosed is part one of a two part paper I requested from
Peter Sinander of the European Space Agency Technology Centre
discussing his experiences with Synopsys VHDL and Actel chips.
The idea behind this type of ESNUG post is to occassionaly
have articles that discuss an entire project experience using
Synopsys tools. Please tell me what you think of this type of
ESNUG post plus, as always, whatever comments you have concerning
this paper itself.
- John Cooley
ESNUG Moderator
( Post 99 Item 1 ) ---------------------------------------------------------
From: psi@wd.estec.esa.nl (Peter Sinander)
Subject: Synopsys VHDL & Actel FPGAs (Part 1 of 2)
Hi John,
Here are the requested experiences from using Synopsys VHDL synthesis
with Actel FPGAs. I hope that other people will send in their experiences
on this topic. Here we go:
Background
A 4000 gate ASIC was being designed using schematic entry for a
standard cell library. Due to repeated delays in finalising the
ASIC design, it was necessary to develop a separate prototype for
breadboarding. It was acceptable that it should run at lower
speed, and it seemed feasible to synthesize a VHDL model of the
ASIC and implement it in an Actel A1280 (8000 equivalent gates).
An RT-level VHDL description had been written before the gate
level design of the ASIC was started, as, among other reasons, an
aid for writing the specification. It consisted of about 1100
lines of code (including headers, comments etc.), in seven
modules; one 32*3 bit register file, with the rest being mainly
counters and random logic. Before investing in the Actel
libraries, the VHDL model was synthesized for an ASIC library. The
code modification to get acceptable results from the VHDL compiler
took less than one day, since the model had been written bearing
synthesis in mind.
The Synopsys synthesis library for Actel was purchased from the
Dutch Actel representative for around 7 500 US dollars (in
Europe). The complete tool set consisted of:
- Synopsys VSS VHDL simulator, v. 2.2a.
- Synopsys VHDL compiler + Design compiler + Mentor interface v.
2.2b.
- ACT2 library for Synopsys v. 2.2.
- Actel development kit for Mentor v. 7, including ACT2
simulation + schematics libraries, and Actel programming tools
and adapters.
- Mentor Ideastation v. 7, including schematic capture and
Quicksim logic simulation (no VHDL).
Documentation of Actel library for Synopsys
The only documentation provided was a set of 15 photocopied pages,
called "Library release notes (Preliminary)". Apart from that some
of the installation information was wrong, the documentation was
extremely terse; as an example, nothing was mentioned about pad
instantiation, or the names of the in/outputs of the pads
(necessary for instantiation).
Pad instantiation
Luckily, the pad names were the same as had been used in the
figures of the modules in the Actel data book, which solved that
documentation problem. Another problem occurred due to signal
names for cells from the target library being case sensitive in
Synopsys, the VHDL Compiler did not recognize the names unless
written with capital letters. This is probably well-known by users
of the Design Compiler, but is non-compliant with the VHDL
langauge. Some experimenting revealed this "feature".
Results of using Synopsys for Actel
In this paragraph the problems which appeared for this design are
described; as an appendix, there are some refined VHDL examples,
which were sent to Synopsys and Actel, each pinpointing a specific
problem.
When the design was synthesized for Actel, it used 1150 modules,
implying an "equivalent gate count" of 7500 gates (93 % of the
A1280 modules). The first thought was that the claimed "equivalent
gates" were too optimistic - not unusual for PLDs/FPGAs. But it
turned out that the 8000 equivalent gates actually seem to be
realistic, with Synopsys giving up to a 200 % overhead, depending
on the circuit type.
A clear problem area was the 32*3 bit register file, which was
using more than 500 modules,whereas manual design indicated 230
modules should be sufficient. Synopsys had problems synthesizing
multiplexer trees, which often were irregular and up to 3 times
larger than necessary, and enabled flip-flops, for which the Q
output was fed back to the enable signal. See further the examples
in the appendix.
A more severe problem was that flip-flops with the wrong clock
polarity sometimes were instantiated, with inverters being
inserted. First of all, this is not necessary, since all flip-
flops can be selected to use either rising or falling edge.
Secondly, Actel provides a clock buffer that can drive several 100
clock inputs, whereas an inverter/buffer is limited to about 10.
For the third, it is illegal to let the clock buffer drive
inverters/buffers; the design was rejected by the programming
tools.
This polarity problem appeared randomly, both for rising and
falling clock edge specified in the VHDL code, though it seems to
be more common for falling edge. This design had polarity problems
for all of its flip-flops, a later design for about half, and I
have talked to people who had not experienced the problem (yet).
It did not only apply to the clock signal, reset also showed the
same phenomenon, although this did not give a problem with the
clock buffer, only area overhead.
Both Actel and Synopsys were contacted, and the refined examples
(see appendix) were sent to them. Both claimed not to be aware of
the clock/polarity problem. Both were asked for a written response
explaining the cause, suggesting short-term solutions and wether
they intended to address the problem in the long term.
>From Actel we only got the verbal information from Actel that an
overhead of two times was not too bad, apparently larger overheads
had occurred ...
Synopsys explained the reasons for the results:
The algorithms used by Synopsys were designed for gate arrays
and standard cells, where the area and delay cost have some
relation to the cell's complexity. FPGAs feature more complex
structures, where an inverter, a flip-flop and a flip-flop
with built-in enable can have the same area cost, with roughly
the same delay. This seems to confuse the algorithms to
produce unpredictable results.
The clock polarity problem may possibly come from that the
basic flip-flop used by Synopsys is modelled as active on the
rising-edge.
Synopsys proposed different trial-and-error methods, such as
changing signal names, using commands as "group -hdl_all_blocks",
rewriting the code until the synthesis shows usable results. Since
the problems appeared randomly, arbitrary rewriting would probably
solve the problems after enough trials.
Since we did not care about area or speed, as long as the circuit
would fit into one A1280, the following strategy, only focusing on
the illegal clocking, was used:
- Each of the modules were read in from VHDL, and compiled for
minimum area.
- Two modules only used one flip-flop type; the same flip-flop
but with the opposite clock polarity was selected with the
command:
set_default_flip_flop_type -exact <name>
- For the remaining modules, we had to change to the correct
clock polarity for each of the flip-flops (about 200) with the
command:
set_flip_flop_type -exact <name> <instancename>
- Finally, the whole design was recompiled, using minimum
effort, since when the flip-flop types are forced, the module
count will increase, and it seems to increase more for more
optimization.
This resulted in a larger design than the design with clock
inverters, but that barely fit the largest Actel FPGA, using 98 %
of the available modules.
Also, if the correct flip-flops were specified before the initial
compilation, the area of the complete design increased
substantially, exceeding the maximum available number of Actel
modules.
Bug in Actel synthesis library
After being compiled, the schematics were transferred to the
Mentor station using a do-file. Each of the modules were then
simulated and compared cycle by cycle to the VHDL simulation. We
had already developed a version of the VHDL model that generated
force (stimuli) files for Quicksim, and wrote a result file in the
same format as Quicksim, by using an inhouse developed PACKAGE and
TextIO. Quicksim was run with the force file, and the results were
compared using the Unix cmp utility (isn't it fantastic how far
tool integration has come ...).
The simulations differed for one module that contained about 1000
gates of random logic. Different errors appeared for different
optimization, so it seemed that either the Actel library for
Mentor or for Synopsys was incorrect. Neither Synopsys nor the
European Actel support centre had heard about this, but finally
one member of the US Actel support team recognized the problem; it
was a bug in the Actel library for Synopsys, allegedly caused by
a bug in the Synopsys library compiler v. 2.2 beta. A correct
version was shipped immediately from Actel.
The Actel memo detailing the library error was dated more than
once month earlier than the date Actel Europe was first contacted
about the problem. There seems to be a need for better
communication ...
Note that this bug could only be detected by simulating on the
Mentor station, or by using the device on a breadboard (just
imagine the nightmare to try to convince the vendors that the
design is correct, there are no problems with glitches, power
decoupling etc. on the breadboard, but that their library is
wrong). Simulating at the gate level using the Synopsys VHDL
simulator would not detect any error, since the faulty library
would be used for creating the gate level simulation models, and
thus the errors would not appear.
Peter Sinander European Space Agency Technology Centre
ESTEC WDN e-mail: psi@wd.estec.esa.nl
|
|
