Answers Database
PPR 5.0: Information for users upgrading from APR for 3000A designs
Record #297
Problem Title:
PPR 5.0: Information for users upgrading from APR for 3000A designs
Problem Description:
Solution 1:
1. LCA File versus XNF/MAP File Input
One of the primary differences between the operation of APR and PPR
is that APR can read an existing LCA file and modify it according
to command-line options, constraints, and a second LCA guide file.
PPR, however, reads only an XNF-style input file (from XNFPREP
or XNFMAP). The LCA file can only be used as a guide for the
data in the 'raw' XNF file.
Because APR reads an LCA file, it is possible to use XDE to
modify a design (pre-place, pre-route) and then submit that
design directly to APR to complete. PPR must be directed
to read the XTF/MAP file, and then use the XDE-modified design
as a guide. The effect is essentially the same.
2. Command-line Option Differences
APR -T (timing improvement)
There is no direct equivalent for the APR -T option in PPR.
The -T option directed APR to 'grind away' at routing an
input design with locked placement. If you want PPR to
'work hard at routing an existing placed design', you can
use an LCA file that has good placement as a guide file to
PPR, set the "router-effort" option to 4, and set
the "lock_routing=none" option so that PPR can rip-up and
improve the routing. Of course, PPR also has the Timespec
functions to provide real control over timing issues.
APR -L (lock placement)
Because the incoming XTF/MAP file to PPR has no inherent
placement, it is not possible to tell PPR to lock the
input placement.
APR -P (preserve routing)
Because the incoming XTF/MAP file to PPR has no routing
information, it is not possible to tell PPR to lock the
input routing. It is possible to affect the PPR guide
file routing with several options.
APR -J (just do placement)
It's possible to use the PPR "route=false" option to prevent
the routing operation.
APR -Q (quench), -Y (deterministic annealing)
The PPR placement algorithm is affected by the "placer_effort"
option.
APR -A (routing attempts)
Use the PPR "router_effort" option to modify the effort that's
spent in routing.
3. Schematic LOC Values
Prior to XACT 5.0, design files headed for APR used the LOC
syntax with alphabetic characters for the row and column
designations (ie. LOC=AA), while PPR used numeric row and
column designations (ie. LOC=CLB_R5C6). These constraints were
not interchangeable. In XACT 5.0, the software has been changed
to be more flexible so that existing 3K/3KA designs can be
re-targeted to PPR without changing the constraints in the
schematics. PPR will be able to understand the APR-style
alphabetic row and column coordinate system in the LOC constraints.
There is no need to alter an existing "LOC=AA" attribute in a
3KA schematic. It is not possible, however, to use the
PPR-style numeric row and column designation in a 3KA schematic.
XNFMAP is still the mapper for 3KA designs, and there was no
time to modify it to process the "LOC=CLB_R5C6" kind of schematic
location constraints.
4. Constraint File Differences.
CSTCVT
There is a new program called CSTCVT that is shipped with
XACT 5.0 that will convert an APR .CST file into a PPR .CST file.
This was done because the syntax and references to objects are
quite different between the two files. CSTCVT will read an
existing APR-style CST file, and translate the constraints
into the PPR CST file syntax. CSTCVT will retain the original
APR constraints as comments in the new file, so that the
translation can be easily examined. It will also put any
constraints that could not be translated into comment lines
in the file. This output file can be directly used by PPR.
APR CST File Command translates to...PPR CST File Command
---------------------------------------------------------
Allow Block <blknm> <loc> ...; Place block <blknm> : <loc>...;
Place Block <blknm> <loc>; Place block <blknm> : <loc>;
Prohibit Block <blknm> <loc>...; Prohibit block <blknm> : <loc>...;
Prohibit Location <loc>......; Prohibit block * : <loc>...;
Flag Net Critical <netnm>....; Flag Net Critical <netnm>....;
Weight Net Critical <netnm>..; Flag Net Critical <netnm>....;
Flag Net Uncritical <netnm>..; Flag Net Uncritical <netnm>....;
Weight Net Uncritical <netnm>...; Flag Net Uncritical <netnm>....;
Weight Net <weightval> <netnm>...; Weight net <weight> <netnm> ....;
There are some APR constraints file commands that cannot be
translated to PPR's constraints file. The "Lock" constraints
cannot be translated because PPR does not read an LCA file
as it's input. The other constraints are simply not supported
by PPR.
APR CST File Commands That Cannot Be Translated to PPR CST File
---------------------------------------------------------------
Lock IOBs;
Lock Block <blknm>...........;
Lock Net <netnm>.............;
Lock Pin <pinnm>.............;
Place Net <netnm> <longline>;
Flag Net Longline <netnm>....;
Flag Net Normal <netnm>......;
Weight Net Normal <netnm> ..;
Flag IOB Internal <blknm>....;
Flag IOB External <blknm>....;
Include <filename>...........;
CST Syntax
The PPR constraint file was also modified in several ways so that
it is more compatible with the APR-style of CST file. The APR-style
constraint file keyword "prohibit" has been added to PPR's vocabulary.
It is interchangeable with PPR's existing "notplace" constraint. It
will be possible to use alphabetic notations for the row and column
fields in the PPR CST file. Instead of requiring the constraint
syntax "place block <gork> : CLB_R5C6", it will be possible to
say "place block <gork> : DE" so that the same APR-style alphabetic
row and column designators can be used.
Note that the modifier "block" rather than "instance" should be
used in the PPR constraint file when referencing 3KA designs
(ie. use "place block" rather than "place instance"). The
3KA design has already been mapped into LCA blocks by XNFMAP,
and so "block" is the appropriate object reference for 3KA
designs.
NOTE: the `prohibit' keyword did get implemented in PPR 5.0, but never
made it into the documentation. Since CSTCVT uses it, this could
cause some confusion.
5. "Guide" Flexibility
PPR is can be made much more flexible than APR in processing information
from the LCA guide file. The APR guide file provides absolute constraints
to the input design. There are only a few ways to modify it's
operation (ie. unrouting nets to blocks in XDE). The PPR Reference
Guide lists a number of command-line constraints that can be used
to modify how "absolute" the guide file should be considered. The
default operation of PPR is to consider the guide file as "absolute",
but constraints can be used to soften this behavior, and allow
PPR more flexibility to improve the design.
End of Record #297 - Last Modified: 10/10/96 18:13 |
