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.
Und hier noch der CPLD Report den mir die ISE erstellt (als htm-File). Vielleicht ist die noch hilfreicher als nur die Warnungen.
>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.
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!!!
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.
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...
>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...
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.
Diese händische Buffer-Instatiierung ist unnötig, das machen die Tools automatisch. Tristate-Buffer können einfach so im VHDL-Text beschrieben werden:
1 | input <= pins; |
2 | 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.
>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...
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.
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?
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...
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.