AR# 4065


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


General Description:

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;


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.

AR# 4065
日期 01/18/2010
状态 Archive
Type 综合文章
People Also Viewed