( ESNUG 435 Item 11 ) ------------------------------------------- [12/08/04]
Subject: ( ESNUG 426 #4 ) Mentor On Precision vs. Leonardo Spectrum
> My experience with Leonardo Spectrum and Precision Synthesis is not big
> but what I can say today is:
>
> - I'm using both tools everytime in order to compare results. So,
> there is no sensible difference in the result. Therefore the manner
> of how to set the constraints and everything around, before starting a
> synthese, is more intuitive in the Leonardo compare to the Precision.
> The Precision constraint settings are very poors (or I still miss
> something in the procedure to do it).
> - The Precision Synthesis has the Verilog 2001 support which is one of
> the reason why I will use it instead of Leonardo. I heard that there
> is no plan for Leonardo to support Verilog 2001.
> - The Leonardo Spectrum is more stable.
>
> Due to the fact that Verilog 2001 is a big advantage, I will push myself
> to use the Precision Synthesis as the first tool to use.
>
> My configuration today is a licencied Precision Synthesis tool + an
> archival license Leonardo Spectrum.
>
> - Laurent Hausammann
> Yminds SA Switzerland
From: Dan Gardner <dan_gardner=user domain=mentor spot calm>
The constraint methodology is very different between Leonardo Spectrum
and Precision RTL. Chapter three of the Precision RTL Synthesis Users
Manual has a lot of information on how to set the timing and design
constraints in the product. The big difference between the two products
is the ability to fully constrain your timing requirements, including
advanced path based constraints.
Precision RTL has a sophisticated timing engine that can fully analyze
the timing of your design, including clock propagation through the
various FPGA clock managers. Rather than treating them as primary
clocks, Precision RTL understands derived clocks whether they are
created from a digital clock manager in the FPGA or from other logic.
Leonardo Spectrum didn't do this, so you may be confused by the new
commands you see like the following:
find_clock -derived
remove_propagated_clock
The Precision RTL timing engine also understands the concept of clock
domains, which were not in Leonardo Spectrum. Since the Synopsys Design
Constraint (SDC) language does not support the concept of clock domains,
Precision RTL Synthesis has added a switch to the create_clock command
to model this behavior. See the following syntax:
create_clock -period <value> -name <value> -domain <domain_name>
The <domain_name> argument can be any name that you want. If two clocks
have the same domain name, they are modeled as synchronous. If no
<domain_name> is specified, the domain name "ClockDomain0" is used.
Other tools that use SDC constraints may require you to use false path
definitions to model asynchronous clocks. Although Precision RTL
Synthesis supports this method, it is much less efficient in terms of
runtime and memory utilization. For large designs it is well worth the
effort to convert false path definitions to domains.
Of course, if you have never used a full-featured timing analyzer, the
amount of commands and switches can be overwhelming. Things get even
deeper when you start to use false path and multicycle path constraints
for exception timing constraints.
False paths are design paths that you want Precision to ignore for
timing optimization purposes. Timing optimization focuses it's efforts
on paths in the design that violate timing constraints. If a path is
seen in violation, but is in fact not a problem, then Precision RTL
Synthesis will waste time trying to fix the false violation. In
addition, Precision will likely insert unnecessary circuitry and may
view real violations as a lower priority. You can use a False Path
definition in these cases to avoid the false violation.
False paths occur for a variety of reasons. A path may be false because
you know that the path will never pass data forward or that the
circuitry involved will operate slower than your constraints indicate.
For example, test logic can usually be operated at a lower frequency if
necessary. Paths from master reset signals are often false for a similar
reason. Often reset sequences occur over many clock cycles, and it
doesn't matter exactly when a particular register is reset.
Another possible reason for using a false path definition is to exclude
paths that exist in the circuit, but because of the operation of the
system, they never interact. Static analysis cannot not know the
relationship of states of your circuit, so false path definitions are
used to help the timing analyzer ignore these paths.
Logic that you know will take more than one clock to propagate through
is quite common. When you set a multicycle constraint, you identify a
path to the timing analyzer to prevent the tool from reporting invalid
violations, and to prevent timing optimization from wasting time and
resources trying to correct valid (but falsely reported) paths.
Single-point multicycle path definitions are much more efficient for the
timing analyzer to process, both in terms of analysis time and memory
utilization. If you have a design with hundreds of multicycle paths, it
is sometimes worthwhile to see if a single point constraint would
suffice.
In summary, having to consider timing analysis during RTL synthesis can
make it more confusing, but you are less likely to be surprised when you
get down to programming the FPGA on the board. However, it is pretty
straightforward to set your initial clock constraints in Precision RTL
and then tune your constraints while you analyze your results. The
incremental timing engine lets you make "on-the-fly" adjusts and see
your results in seconds.
- Dan Gardner
Mentor Graphics Wilsonville, OR
|
|
