Hallo an Allo,
ich habe gerade ein Problem mit meinem aktuellen FPGA Design.
Ich habe unter anderem einen XPS_GPIO mit 15 I/O's und einen
XPS_UART16550 mit SIN und SOUT in meinem Design. An einigen GPIO's des
XPS_GPIO hängen momentan die Flusssteuersignale für die
UART-Kommunikation. Diese möchte ich jedoch jetzt vom XPS_UART16550
steuern lassen, doch dabei ergibt sich leider folgendes Problem:
Wenn ich den Pin der /CTS Leitung im UCF-File nicht mehr an den XPS_GPIO
hänge, sondern direkt an den XPS_UART16550 meldet das EDK für viele Pins
die Fehlermeldung: ERROR:PhysDesignRules:755 - IOB comp <"signal-Name">
at location <"pin-name"> is VCCO incompatible für bank <"bank-nummer">.
The VCCO established for this bank is <3.300000>.
Verstehen würde ich die Fehlermeldung, wenn zwei Signale, die an der
gleichen Bank liegen unterschiedliche VCC's haben, dies ist aber bei mir
nicht der Fall.
Hat jemand eine Ahnung woran das liegt, bzw. wie man das Problem
beseitigen kann?
Vielen Dank!
Lieben Gruß,
ChrisB
Du schreibst nicht, welches FPGA du überhaupt hast und welchen Pin du
nehmen willst. Dann könnte man in den Pinlayouts nachschauen. Es gibt
AFAIR bei den Spartan 3E einige Pins, die eigentlich zum
Konfigurationsbereich gehören und damit an den 2.5V hängen.
Hallo Georg,
ich nutze den Spartan 3E 1200 und möchte einen Pin (habe die Pin-Nummer
leider nicht im Kopf und nicht zur Hand, trage diese aber nachher nach),
den ich vorher als GPIO benutzt habe nun an den UART16550 hängen.
Da ich den Pin vorher ja schon als 3.3V GPIO benutzt habe sollte es doch
kein Problem sein, diesen jetzt als Eingang für den UART zu benutzen.
Zum Konfigurationsbereich wird dieser Pin nicht gehören, da ich sonst
auch Probleme gehabt hätte den Pin als GPIO zu nutzen oder?
Lieben Gruß,
ChrisB
Das UCF habe ich ja selber geschrieben/modifiziert. Bei dem Pin den ich
verwenden möchte habe ich schon mehrere Optionen versucht. Zum einen
garkeine Spannung und zum anderen 3,3V. 2,5 Volt habe ich dort also
nicht stehen.
Es muss an irgend etwas anderem liegen...
Das werde ich nachher nochmal überprüfen, aber ich glaube eigentlich
dürfte kein Zahlendreher oder schreibfehler drin sein. Kann es sein,
dass das Design aus irgend einem völlig anderen grund nicht geroutet
werden kann oder ähnliches?
Jetzt mal der Nachtrag:
So wie unten geschrieben ist es Momentan, und so lässt sich das Design
auch generieren:
Net GPIO_1_IO_pin<11> LOC=R5 | IOSTANDARD = LVCMOS33;
Ich möchte den Pin R5 jedoch nur als Eingang für das /CTS-Signal des
UART's benutzen, also habe ich folgendes ausprobiert:
Einmal:
Net UART_2_ctsN_pin LOC=R5;
und:
Net UART_2_ctsN_pin LOC=R5 | PULLUP;
und:
Net UART_2_ctsN_pin LOC=R5 | LVCMOS33 | PULLUP;
All diese Konfigurationen liefen jedoch auf den oben beschriebenen
fehler hinaus und ich habe keine Erklärung dafür.
Ich wäre für jede Idee sehr dankbar!
Lieben Gruß,
ChrisB
Was passiert mit
Net UART_2_ctsN_pin LOC=R5 | IOSTANDARD = LVCMOS33; ?
Weil nur LVCMOS33 als Argument bringt glaube nix...gerade bei einem
Eingang dürfte da nix schief gehn, bei einem Ausgang muss man bei S3e
bissl aufpassen wegen der Input only Pins....
> gerade bei einem Eingang dürfte da nix schief gehn
Kaputt sicher nicht, aber die Schaltschwellen sind anders. Und die SW
will einen wohl vor seltsamen Effekten durch inkonsistente H/L-Erkennung
bewahren.
> wegen der Input only Pins....
Der OP hat zwar das Package nicht genannt, aber entweder ist R5 ein VCCO
(beim FT256) oder sonst immer I/O. Aber die Input-Only-Pins sind schon
das Werk von Sadisten bei Xilinx gewesen, so ausführlich wird darauf
auch nicht eingegangen. Einer ist mir beim Layout mal durchgerutscht :(
Georg A. schrieb:
>Aber die Input-Only-Pins sind schon> das Werk von Sadisten bei Xilinx gewesen, so ausführlich wird darauf> auch nicht eingegangen. Einer ist mir beim Layout mal durchgerutscht :(
Da bist du nicht der einzige. Zum Glück wars keine lebensnotwendige
Funktion, aber die nerven. Naja, bei den Virtex Typen gibts keine mehr.
Ein Glück.
Hallo,
also ich habe den Spartan 3E im FT320 Gehäuse. Da sollte der R5
eigentlich nen I/O Pin sein.
Net UART_2_ctsN_pin LOC=R5 | IOSTANDARD = LVCMOS33; Habe ich glaube
noch nicht ausprobiert, kann ich aber bei Gelegenheit probieren.
Momentan habe ich mal versucht von der 10.1er Version auf die 11.3er
Version der Xilinx Tools umzusteigen, was ich früher oder später eh
gemacht hätte. Ich habe dazu ein neues Design aufgesetzt, da ich dem
Versions-Updater nicht so ganz traue.
Nun habe ich beim generieren ein völlig anderes Problem.
ERROR:Route:472 - This design is unroutable. To evaluate the problem
please use fpga_editor.
Routing Conflict 1:
Net:DDR_SDRAM_mpmc_clk_s on pin OTCLK1 on location PAD134
Net:dlmb_port_BRAM_Clk on pin OTCLK1 on location PAD135
Conflict detected on wire: DUMMY(104816,35425)
Kann mit der Meldung jemand was anfangen? Also ich werde nicht so ganz
schlau darauß.
Lieben Gruß,
ChrisB
Klingt mir nach einem verkorksten Clock-Design. D.h. falsche Planung, wo
welche Clocks, rein, raus und intern rum müssen. Schau mal, ob die
beiden Takte auch wirklich auf einem Taktnetz geführt werden. Wenn sie
das wären, müsste das nämlich problemlos gehen...
Und der Rat mit dem fpga_editor ist durchaus sinnvoll. Editieren kann
man zwar vergessen, aber gerade die Besonderheiten des
Takt/DCM/BUFG-Routings kann man sich dann wesentlich besser vorstellen.
Hm, bei der 11.er Version haben die ziemlich viele Warnungen als Fehler
ausgegeben. Da gibts eine Umgebungsvariable XIL_CONTINUE_ON_IMPOSSIBLE
oder sowas ähnliches, muss ich morgen auf Arbeit mal gucken. Aber ich
schätze, die beiden Probleme hängen irgendwie zusammen, werfen nur einen
anderen Fehler...
Ich werde das nachher mal versuchen mit dem FPGA-Editor zu öffnen.
Leider habe ich noch nie mit dem FPGA-Editor gearbeitet. Kann mir jemand
kurz erkären, welche Datei ich wie öffnen muss und was ich dann zu sehen
bekomme?
Lieben Gruß,
ChrisB
Ich hab die beiden Umgebungsvariablen drin, damit routet er durch und
zeigt auch Details an:
XIL_TIMING_ALLOW_IMPOSSIBLE 1
XIL_PAR_DESIGN_CHECK_VERBOSE 1
> XIL_TIMING_ALLOW_IMPOSSIBLE 1
Das ist aber was anderes als das obige Problem. Das verhindert nur, dass
bei offensichtlich nicht erfüllbaren Constraints kein Abbruch passiert.
"Offensichtlich" heisst in dem Fall, dass schon die Laufzeiten durch die
LUTs allein grösser als gewünscht sind. Das lässt sich ja ohne Routing
auch schon direkt mit den Mapping-Infos berechnen...
> Kann mir jemand kurz erkären, welche Datei ich wie öffnen muss
fpga_editor <design>.ncd
> und was ich dann zu sehen bekomme?
Zuviel ;) Du siehst LUTs, Pads und Netze, je nach angeknipsten Buttons
oben alle oder nur die im Design benutzten. Man kann Netze/Instanzen
suchen und highlighten. Nicht verlegte Signale tauchen auch auf. Ganz
wichtig ist die Positionierung der Clock-Netze/Quadranten, DCMs, BUFGs
und der GCLK-Pins. Nur so wird einem klar, was die diversen App-Notes
eigentlich sagen wollen und warum manches Design nicht gehen will...
