www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Par:228 - At least one timing constraint is impossible to meet because component delays.


Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein "Ziel": Ich möchte ne Status LED für die RS232 Kommunikation, 
welche Lustig vor sich hinblinkt. Leider kriege ich beim "verbinden" des 
Ausgabe Ports einene Fehler:
Par:228 - At least one timing constraint is impossible to meet because component delays alone exceed the constraint.

Meine Portdefinition sieht folgendes vor
Port ( CLK_50M : in  STD_LOGIC;
SW             : in STD_LOGIC_vector(3 downto 0);
FPGA_AWAKE     : out std_logic;
RS232_DCE_TXD  : out  STD_LOGIC);

Mittels eines Signals (tx_out), lege ich die RS232 Daten auf den 
Ausgang:
RS232_DCE_TXD <= tx_out;
was sich auch einwandfrei übersetzen läßt.
Weise ich jezt aber in einem Prozess dieses Sigal auch der LED zu kommt 
obiger Fehler
txtest: process(CLK_50M)
    begin
        if rising_edge(CLK_50M) then
           FPGA_AWAKE <= tx_out;
            tx_data <= "01010101" XOR "0000"&SW;
            if (tx_full = '0') then
                tx_write <= '1';
            else
               tx_write <= '0';
            end if;
       end if;
    end process;

Die Konstraints sind aus dem Userguide für das Board (Sparta-3A Starter) 
entnommen:
NET "CLK_50M"       LOC = "E12"  | IOSTANDARD = LVCMOS33 | PERIOD = 20.000 ;
OFFSET = IN  10.000 VALID 20.000 BEFORE "CLK_50M" ;
OFFSET = OUT 20.000 AFTER "CLK_50M" ;
NET "FPGA_AWAKE" LOC = "AB15" | IOSTANDARD = LVTTL | SLEW = QUIETIO | DRIVE = 4;
NET "RS232_DCE_TXD" LOC = "F15"  | IOSTANDARD = LVCMOS33 | DRIVE = 8 | SLEW = SLOW ;
Das Place Tool schlägt vor das ich die Konstraints lockern soll, das 
scheint mir auf den ersten Blick aber keine Gute Lösung zu sein 
schließlich haben diese sicherlich ihre Bewandnis.

Gibt es hierfür eine Lösung (außer Hardverdrahtung) oder ist meine 
Anforderung in irgeneiner Weise "Hardwareinkompatibel", prinzipiell seh 
ich erstmal keinen Grund warum das nicht gehen sollte-

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habs jezt dadurch lösen könne das ich die Konstraints angepaßt habe:
NET "FPGA_AWAKE" LOC = "AB15" | IOSTANDARD = LVCMOS33 | DRIVE = 8 | SLEW = SLOW;
NET "RS232_DCE_TXD" LOC = "F15"  | IOSTANDARD = LVCMOS33 | DRIVE = 8 | SLEW = SLOW;
Hat das irgenwelche Nachteile? Ich mein der LED sollte es nicht schaden, 
aber die bei Xilinx werden sich bei der Ursprünglichen Definition was 
gedacht haben...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenigstens den Takt solltest du einschränken (constrainen):
NET "CLK_50M"       LOC = "E12"  | IOSTANDARD = LVCMOS33 | PERIOD = 20.000 ;
Wenn das dann immer noch schiefgeht (aber 50MHz sind noch gar nicht 
sooooo arg schnell), solltest du einen Blick in die Statische 
Timinganalyse werfen. Dort wird dir der langsamste Pfad angegeben. 
Üblicherweise kannst du da dann mit geringen Anpassungen schnell noch 
ein paar MHz rausholen.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke mal hier liegt der hund begraben:

OFFSET = OUT 20.000 AFTER "CLK_50M" ;


lass die constraint einfach mal raus, sollte eigentlich nicht schaden.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Äh ja die Taktkonstraints hab ich natürlich belassen, habe nur die 
Konstraints für die LED an die des UART angegelichen. Der Konstraint der 
nicht erfüllt werden kann war der für den Takt wenn ich den Report 
richtig verstanden habe.

Also entweder die sache mit dem SLEW oder DRIVE war wohl untereiander so 
unverträglich das er da durcheinader gekommen ist.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit DRIVE und SLEW sollte für jeden Ausgangstreiber unabhängig 
einstellbar sein...

> ... IOSTANDARD = LVTTL ....
> ... IOSTANDARD = LVCMOS33 ....
Hat es damit was zu tun? Allerdings ist es seltsam, dass dann an den 
Timings herumgemäkelt wird... :-/

Autor: Läubi .. (laeubi) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also sobald ich SLEW auf QUIETIO ändere kommt der Fehler, im Anhang mal 
der komplette Bericht. Zeile 51 ist der Fehler...

(Der IOStandard hat keinen Einfluß)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> QUIETIO
ist 5 mal langsamer als SLOW und im Zeitbereich um 30ns. Wenn du nur 
20ns Ausgangsdelay zulässt, ist dieser Wert mit QUIETIO nicht zu 
erfüllen. Du solltest diesen QUIETIO-Pfad weniger streng einschränken.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab das jezt mal rausgenommen, ich denk der LED ist es egal :)
Kann man QUIETIO dann überhaupt sinnvoll bei der Taktfrequenz einsetzen? 
Vermutlich dann nicht in nem getakteten Prozess..

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Kann man QUIETIO dann überhaupt sinnvoll bei der Taktfrequenz einsetzen?
> Vermutlich dann nicht in nem getakteten Prozess..
Nicht, wenn du eine externe Komponente angeschlossen hast, die mit dem 
selben Takt wie das FPGA betrieben wird...

Wie gesagt, du kannst durchaus auch an ein FF mit 50MHz einen 
QUIETIO-Pin anschliessen, nur muß dann der Signalpfad vom 
Takt-Constraint herausgenommen werden.

> ich denk der LED ist es egal :)
Genau für sowas ist das QUIETIO auch gemacht: zeitlich unkritische 
Signale.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kann ich den "QuietIO" von den Taktkonstraints ausnehmen? Ich hatte 
die LED schonmal als "BlinkTest" mißbraucht da hat er komischerweise 
sich nicht beschwert...

Autor: bko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dies nennt sich in Synthese-Neu-Deutsch dann "False Path";
nun aus dem "ise92-constraints guide" Seite 63 hierher kopiert:
"False Paths by Pin
You can define false paths for all paths that pass through a particular 
instance pin using the
following UCF syntax:
PIN “instance.pin_name” TIG;"

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So... da es bisher nicht akut war hab ich nicht weiterverfolgt, da ich 
es jezt aber doch nochmal benötigt habe hier mal meine Lösung:
# Aktive HIGH
NET "HALT_LED" LOC = "AB15" | IOSTANDARD = LVTTL | SLEW = QUIETIO | DRIVE = 4 | TIG;
# Aktive LOW
NET "ERROR_LED" LOC = "V13" | IOSTANDARD = LVTTL | SLEW = QUIETIO | DRIVE = 4 | TIG;

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.