mikrocontroller.net

Forum: FPGA, VHDL & Co. EDK meldet ERROR:PhysDesignRules:755


Autor: ChrisB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ChrisB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau doch mal ins UCF rein, was für den Pin angegeben ist. Vielleicht 
steht da ja 2,5V VCCIO.

Autor: ChrisB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die idiotischsten Fehler haben meist die einfachsten 
Ursachen.....Zahlendreher in der Pin-Nummer?

Autor: ChrisB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das gibts bei Xilinx auch immer mal. Dann musst du mal die Meldungen 
weiter oben im Log ganz genau durchlesen.

Autor: ChrisB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 :(

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ChrisB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: ChrisB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.