UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

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
作成日 08/31/2007
最終更新日 01/18/2010
ステータス アーカイブ
タイプ 一般