Answers Database

M1 NGDBUILD/CSTTRANS: Why INST can sometimes be used instead on NET for Pad LOCs


Record #4065

Product Family:  Software

Product Line:  FPGA Implementation

Problem Title:
M1 NGDBUILD/CSTTRANS: Why INST can sometimes be used instead on NET for
Pad LOCs



Problem Description:
Keywords: csttrans, pad loc

Urgency: standard


CSTTRANS is a program that will translate XACT 6.x style
constraints to M1 constraints. If the source .cst file has
a Pad LOC ("place instance ..."), then CSTTRANS is not
capable of distinguishing that from any other type of LOC.
It will therefore translate all the LOCs to "INST ... LOC"
records in the .ucf.
Since the PAD instance does not exist in the XNF/SXNF, this
often a technically incorrect assumption (outputs are
defined by EXT records in XNF/SXNF). For any user-entered UCF,
NGDBUILD would error out. However, NGDBUILD is capable of
recognizing a CSTTRANS-generated .ucf file, and it will
overlook this problem and search for a padnet by the same
name if it fails to find the INST (in other words, it will
regard the failing INST LOC constraint as a NET LOC
constraint, to see if that succeeds).

If you are creating a .ucf yourself, you should NOT take
your cue from CSTTRANS. You should LOC a pad by using
the padnet (net between pad and IBUF/OBUF/BUFG/IFD/ILD/OFD).
The following is proper for LOC'ing a Pad:

NET my_padnet<0> LOC = p6;





Solution 1:

If you have altered the CSTTRANS-generated UCF, then be sure
the following line remains at the top:

#PROG, CSTTRANS, 1.0, Mon Mar  2 14:09:19 1998

This is how NGDBUILD knows the UCF file came from CSTTRANS.
Without this line, NGDBUILD will not behave in the way
described above.



End of Record #4065