mikrocontroller.net

Forum: FPGA, VHDL & Co. Kann mir jemand helfen und etwas zu meinen Warnungen der ISE 9.2.04i sagen? Bin Ratlos.


Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
ich bin relativ neu auf dem Gebiet der Hardwarenahen Programmierung und 
habe zur Zeit keine Ideen mehr was ich falsch mache.
Mal kurz zu dem was ich mache / bzw. machen möchte:
Ich sende Daten (8 Bit - parallel) von LabVIEW über einen USB-Baustein 
(FT245) an einen Xilinx XC9572 (das klappt wunderbar - habe ich schon 
mehrfach mit einem Logic-Analyser kontrolliert). Der Xilinx soll die 
Eingangsdaten 1:1 auf einen Ausgang legen und zusätzlich (je nachdem was 
gesendet wurde) noch weiter Ausgänge schalten. Leider weichen die 
Ausgangsdaten manchmal von den Eingangsdaten ab (der Fehler passiert 
immer am selben Ausgangspin). Deshalb habe ich den Pin auf dem immer der 
Fehler passiert schon in einen anderen Block gelegt - die Hardware 
entsprechend abgeändert - aber ohne Erfolg.
Programmiert habe ich den VHDL-Code mit der ISE 9.2.0.4i. Hier bekomme 
ich keine Fehler - aber ein paar Warnungen mit denen ich leider nichts 
anfangen kann:

WARNING:HDLParsers:3607 - Unit work/top_level is now defined in a 
different file.  It was defined in 
"C:/Xilinx-ISE/Frequenzgenerator04/top_level.vhd", and is now defined in 
"C:/Frequenzgenerator/top_level.vhd".
WARNING:HDLParsers:3607 - Unit work/top_level/Behavioral is now defined 
in a different file.  It was defined in 
"C:/Xilinx-ISE/Frequenzgenerator04/top_level.vhd", and is now defined in 
"C:/Frequenzgenerator/top_level.vhd".
WARNING:Xst:819 - "C:/Frequenzgenerator/top_level.vhd" line 146: The 
following signals are missing in the process sensitivity list:
WARNING:Xst:647 - Input <PWREN> is never used.
WARNING:Xst:2734 - Property "use_dsp48" is not applicable for this 
technology.
WARNING:XdmHelpers:662 - Period specification "TS_CLK" references the 
TNM group
Mapping a total of 41 equations into 4 function 
blocks.....WARNING:Cpld:125 - Signal
WARNING:Cpld:125 - Signal
WARNING:Cpld:125 - Signal
WARNING:Cpld:125 - Signal $OpTx$INV$13 has been split into multiple 
macrocells

Ich denke dass man vielleicht schon hier den Fehler erkennen kann - Ich 
habe leider zu wenig Erfahrung und alle die ich gefragt habe sind 
anscheinend auch mit dem Fehler überfordert:(

Aber vielleicht kann mir ja einer von Euch weiterhelfen. Bin über alle 
Ideen dankbar.

PS: Im Anhang ist meine aktuelle Pinbelegung des Xilinx.

Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und hier noch der CPLD Report den mir die ISE erstellt (als htm-File). 
Vielleicht ist die noch hilfreicher als nur die Warnungen.

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>WARNING:HDLParsers:3607 - Unit work/top_level is now defined in a different 
>file.  It was defined in
>"C:/Xilinx-ISE/Frequenzgenerator04/top_level.vhd", and is now defined in
>"C:/Frequenzgenerator/top_level.vhd".

Du hast einfach das Verzeichnis gewechselt in dem du arbeitest, beim 
naechsten Mal ist die Warnung weg.

>WARNING:Xst:819 - "C:/Frequenzgenerator/top_level.vhd" line 146: The
>following signals are missing in the process sensitivity list:

In einem Prozess verwendest du ein Signal, das aber nicht in der 
Sensitivity list auftaucht. Fuer die Synthese ist das egal, aber in der 
Simulation kann es Fehler geben.

>WARNING:Xst:647 - Input <PWREN> is never used.

Du definierst einen Port in deiner entity, benutzt ihn aber nicht.

>WARNING:Xst:2734 - Property "use_dsp48" is not applicable for this
>technology.

Ein Fehler von ISE - einfach ignorieren.

>WARNING:XdmHelpers:662 - Period specification "TS_CLK" references the
>TNM group

Da fehlt ein Teil der Meldung.


Das sind aber alles nur Warnungen, wegen des Fehlers, zeig besser den 
kompletten Code.

Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich dachte an die drei Meldungen:
- WARNING:XdmHelpers:662 - Period specification "TS_CLK" references the
TNM group
- WARNING:Cpld:125 - Signal $OpTx$INV$13 has been split into multiple
macrocells
- WARNING:Xst:2734 - Property "use_dsp48" is not applicable for this
technology.

Habe mal mein Project-Ordner gezipt (ich wusste nicht welche Dateien man 
im einzelnen braucht).

PS: Das ist mein erster VHDL-Code den ich geschrieben habe!!!

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Nummer 2734 kannst du einfach vergessen, das ist ein unwichtiges 
Problem in den Bibliotheken von ISE.

Bei den anderen beiden fehlt jeweils ein Teil der Meldung, wenn du sie 
komplett liest, sollte klar sein, was gemeint ist:

>WARNING:Cpld:125 - Signal $OpTx$INV$13 has been split into multiple
>macrocells to improve timing.




>WARNING:XdmHelpers:662 - Period specification "TS_CLK" references the TNM
>group "CLK", which contains both pads and synchronous elements. The
>timing analyzer will ignore the pads for this specification. You might want
>to use a qualifier (e.g. "FFS") on the TNM property to remove the pads from
>this group.

Du gibst das Signal CLK auf einen Pin des CPLD aus, diese Ausgabe wurde 
im Timing Report nicht weiter beruecksichtigt.




Fuer deinen ersten Code sieht es aber schon mal nicht schlecht aus.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für deine schnellen Antworten. Wenn ich dich richtig 
verstehe dann haben die Warnungen nichts mit meinem Fehler zu tun. Bei 
mir auf dem Display werden die Fehler leider nicht ganz ausgeschrieben.

Ich habe inzwischen verschiedene Bausteine (natürlich immer XC9572) 
getestet - ohne Erfolg. Dann habe (wie oben geschrieben) die fehlerhafte 
Signalleitung auf einen anderen Pin gelegt - auch ohne Erfolg. Dann habe 
ich die CLK des Xilinx anstatt mit 30 MHZ mit 20 MHz, 2 MHz, 1 MHz und 
500 kHz getatktet - leider auch ohne Erfolg.

Was könnte ich denn noch testen?

>Fuer deinen ersten Code sieht es aber schon mal nicht schlecht aus.
Ich hatte ja auch ein bisschen Hilfe von einem Kollegen - der jetzt 
leider für längere Zeit krank ist und mir am Telefon leider auch keinen 
Tipp mehr geben konnte...

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Du gibst das Signal CLK auf einen Pin des CPLD aus, diese Ausgabe wurde
im Timing Report nicht weiter beruecksichtigt.

Aus lauter Verzweiflung dass das Signal meines Oszilators nicht richtig 
erkannt wird habe ich über einen Signalgenerator mir die CLK erzeugt und 
im Xilinx durchgeschleift um den DDS Baustein damit zu füttern. Wird 
aber wieder Rückgängig gemacht...

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex wrote:
> Vielen Dank für deine schnellen Antworten. Wenn ich dich richtig
> verstehe dann haben die Warnungen nichts mit meinem Fehler zu tun. Bei
> mir auf dem Display werden die Fehler leider nicht ganz ausgeschrieben.

Du darfst nicht unter "warnings" schauen, dort wird immer nur die erste 
Zeile angezeigt, sondern in den kompletten Reports (Synthese, Timing, 
Place&Route (so heissen sie zumindest bei FPGAs, aber du weisst sicher 
was ich meine)


> Ich habe inzwischen verschiedene Bausteine (natürlich immer XC9572)
> getestet - ohne Erfolg. Dann habe (wie oben geschrieben) die fehlerhafte
> Signalleitung auf einen anderen Pin gelegt - auch ohne Erfolg. Dann habe
> ich die CLK des Xilinx anstatt mit 30 MHZ mit 20 MHz, 2 MHz, 1 MHz und
> 500 kHz getatktet - leider auch ohne Erfolg.

Guter Ansatz, damit sind Timing-Probleme wohl erst einmal 
ausgeschlossen.

> Was könnte ich denn noch testen?

Hast du das ganze schon simuliert? Im Prinzip klingt das im Augenblick 
nach einem Fehler in der Logik.
Ausserdem: Warum benutzt du zwei unterschiedlich Taktflanken fuer die 
Flipflops? Das sollte man auf jeden Fall vermeiden!


>Aus lauter Verzweiflung dass das Signal meines Oszilators nicht richtig
>erkannt wird habe ich über einen Signalgenerator mir die CLK erzeugt und
>im Xilinx durchgeschleift um den DDS Baustein damit zu füttern. Wird
>aber wieder Rückgängig gemacht...

Edit (nicht richtig gelesen): Das kann Probleme geben, da dieser Takt 
nicht gleichzeitig mit den Daten aus den Flipflops des CPLDs ausgegeben 
wird, sondern um eine (unbekannte) Zeit frueher / spaeter.

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

Bewertung
0 lesenswert
nicht lesenswert
Diese händische Buffer-Instatiierung ist unnötig, das machen die Tools 
automatisch. Tristate-Buffer können einfach so im VHDL-Text beschrieben 
werden:
  input <= pins;
  pins  <= output when richtung='1' else (others=>'z');
Beim CLK hast du ja auch keinen CLK-Buffer eingefügt...


Du solltest keine so langen if-elsif-Konstrukte beschreiben. Das sind 
hintereinandergeschaltete Logikebenen, die brauchen jetzt offenbar 
zuviel Platz. Ergebnis:
>- WARNING:Cpld:125 - Signal $OpTx$INV$13 has been split into multiple
> macrocells


Und
> elsif rising_edge(CLK) then
zusammen mit
> if falling_edge(CLK) then
will gut überlegt sein.


Checking timing specifications ...
WARNING:XdmHelpers:662 - Period specification "TS_CLK" references the 
TNM group "CLK", which contains both pads and synchronous elements. The 
timing analyzer will ignore the pads for this specification. You might 
want to use a qualifier (e.g. "FFS") on the TNM property to remove the 
pads from this group.

Das kommt von der Direkten Zuweisung vom CLK auf ein Pad:
> CLK_DDS <= CLK;
Und sagt aus, dass der Timing Constraint (CLK=33ns) nur für die FFS 
angewendet wird.



Eine kleine Schreiberleichterung:
> when B"1110"
ist genau gleich wie
> when "1110"

Der Prefix B ist default.

Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>Hast du das ganze schon simuliert? Im Prinzip klingt das im Augenblick
>nach einem Fehler in der Logik.
>Ausserdem: Warum benutzt du zwei unterschiedlich Taktflanken fuer die
>Flipflops? Das sollte man auf jeden Fall vermeiden!

Ja habe das ganze mit ModelSim simuliert (siehe Anhang)- ansonsten hätte 
ich als Anfänger glaube ich das nie hinbekommen. Habe mal die Simulation 
angehängt (mit genau den Eingangsdaten teste ich die ganze Zeit schon 
meinen Baustein).

>Und
>> elsif rising_edge(CLK) then
>zusammen mit
>> if falling_edge(CLK) then
>will gut überlegt sein.

Ich konnte mir als Anfänger leider nicht anders helfen. Ich versuche das 
jetzt aber mal umzuschreiben - bin für alle Ideen offen - da ich diesen 
Ausweg nur gegangen bin weil mir nichts anderes eingefallen ist...

Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier habe ich mal eine Aufnahme der realen Messung.
D0 ... D7 ist der Eingang
D8 ... D15 ist der Ausgang

hier ist zu erkennen das D14 nicht richtig schaltet macht die anderen 
aber richtig sind. (Wenn ich andere Testdaten probiere dann stimmt er 
mal für ein paar Signale und dann aber auch wieder nicht). Den 
Testaufbau habe ich die letzten Tage schon mehr als 10mal durchgeschaut 
und auch schon von einem Freund durchschauen lassen (man selbst 
übersieht ja gerne den selben Fehler). Leider konnten wir nichts finden.

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

Bewertung
0 lesenswert
nicht lesenswert
Das sieht nach HW-Problemen aus, in deiner Beschreibung gibt es keine 
Sonderbehandlung von D6.

Du kannst Probleme beim Einlesen der Daten (nicht synchron) oder beim 
Ausgeben haben. Probier doch mal, einfach die Eingangsdaten getaktet auf 
den Ausgang durchreichen, was passiert?

Tausche mal ein paar Bits vor der Ausgabe, statt
> Data_OUT <= Data_OUT_int;
z.B.
> Data_OUT(7 downto 4) <= Data_OUT_int(3 downto 0);
> Data_OUT(3 downto 0) <= Data_OUT_int(7 downto 4);
Was passiert?


Oder am Ausgang einen 8-Bit-Zähler ausgeben, geht das?

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss jetzt leider meinen Platz hier in der FH räumen (die wolen alle 
ins Wochenende - kann das gar nicht verstehen...).
Ich darf aber das ganze Equipment mit heim nehmen. Werde da heute Abend 
wieder alles aufbauen und testen. Melde mich von da nochmal...

PS: Vielen Dank schon mal für die vielen Antworten. Habe schon mal alles 
auf falling_edge umgeschrieben. Die Simulation klappt aber in der Praxis 
tritt leider der selbe Fehler auf...

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,
ich möchte mich bei allen die mir am Freitag geholfen haben BEDANKEN ! ! 
!
ich habe am Wochenende meine Fehler gefunden (sowohl Hardware als auch 
Software) und konnte schon ein paar beseitigen. Ohne eure schnelle Hilfe 
hätte ich als Einsteiger die nicht so rasch gefunden...
Gruß Alex

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.