Pins stimmen nicht mit Vorgabe aus .ucf überein. Warum?!

Da wird es doch sicher eine Warnung zu geben, wenn irgendein Constraint 
nicht übernommen wir.

Christian R. schrieb:
> Poste doch mal die Log-Dateien von Map und PAR. Da steht bestimmt was
> drin dazu.

Das ucf file wird vom NGDbuild eingelesen. Fehler beim Einlesenen 
sollten also in desen Log-file zu finden sein (meist *.bld). PAR hat nix 
mit dem einlesen der LOC-constraints aus dem ucf zu schaffen und MAP 
baut auf das Ergebniss von ngdbuilt auf.

Options zu NGDbuildfindest du hier: 
http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_1/pp_db_translate_properties.htm

Interessant könnte -r sein, der alle dazu führt das alle LOC-Constraints 
ignoriert werden.

Schreib mal irgendeinen Bockmist in das ucf, wenn die tools nicht 
abbrechen, dann liest er ein anderes ucf als das an dem du editierst.

MfG,

Lothar Miller schrieb:
>> dass im ucf spezifizierte Pins nicht vorhanden sein müssen
>> und nur Warnings produzieren.
> Insbesondere, wenn man "Allow Unmatched LOC Constraints" angekreuzt
> hat...

Das ist so nicht ganz korrekt. Allow Unmatched LOC Constraints
bezieht sich nicht auf nicht vorhandende PINS, sondern auf nicht 
vorhandene
(bspw. wegoptimiert da (noch) nicht beschaltet) SIGNALE.

Lt. TO gibt es die Signale aber sehr wohl im Schlussdesign, werden aber 
an andere pins geroutet als vorgegeben ("Leider werden einige der
im .ucf spezifizierten Pins von ISE 12.4 nicht übernommen, sondern
anders geroutet.") Das klingt m.E. nicht nach einem "Allow Unmatched LOC 
Constraints" (wegoptimierte IO-Signale).

MfG

Georg A. schrieb:
>> Das klingt m.E. nicht nach einem "Allow Unmatched LOC
>> Constraints" (wegoptimierte IO-Signale).
>
> Doch, wenn die Signale nach der Synthese irgendwie anders heissen und
>  Die im UCF vorgesehenen Pins bleiben für die nicht
> vorhandenen Signale reserviert, die "falsch" Benannten suchen sich einen
> freien Platz...


Ob es solche Signale gibt, die sich selbst einen Stuhl pardon Pin 
genommen habeb kann man aus dem PAR-Report ershen (*.par) ->

   Number of BUFGMUXs                        3 out of 8      37%
   Number of DCMs                            1 out of 4      25%
   Number of External IOBs                 102 out of 173    58%
      Number of LOCed IOBs                 102 out of 102   100%

Die Pins die in der Zeile " Number of LOCed IOBs" an den 100% fehlen, 
sind solche.

Das die Ports der Top_entity nach der Synthese "irgendwie anders 
heissen" ist mir noch nicht untergekommen. Grad mal bei den arrays gibts 
es definierte Umbenennungen. Und das die Pin-Locs für nichtaufgefundene 
Signal automatisch für diese Implementierung als do not use reserviert 
sind, ist mir auch neu. Nach meinen Wissen werden pins nur durch das 
Schlüsselwort PROHIBIT für die anderenen Tools blockiert.
Aber ich lasse mich gern durch Zitate der entsprechenden Passagen in der 
Dok vom Gegenteil überzeugen.