Ich verwende ISE in der aktuellen Version, um ein vorhandenes (und komplett funktionierendes!) Design auf der Basis eines Spartan 6 LX 75 auf einen Artix zu portieren und muss feststellen, dass praktisch nichts funktioniert. Die Cores sind alle konvertiert und Signale angepasst, das UCF dreimal gegengecheckt und die Simulation läuft wie zuvor auch. Es tut sich aber nichts. Die Ausgänge sind tot. Der Chip ist ok, weil ein manuelles Testdesign komplett funktioniert. Hat jemand eine Idee, wie man da rangehen kann? Die Ingenieure in der Abteilung sind auch ratlos.
Vielleicht sollte man noch hinzusetzen, dass wir hier noch kein ChipScope haben. Ich habe es aber bestellen lassen, um dem Problem beizukommen. Mein Ansatz ist momentan der, dass die PLLs nicht laufen und im Reset hängen oder sonst irgendwie die HW sich anders verhält, als die Simulation, denn diese zeigt keine Auffälligkeiten, wie schon erwähnt. Ich habe jetzt seit 10 Jahren mehr oder weniger Erfahrung mit FPGAs, aber sowas ist mir noch nicht passiert. Gibt es irgendeinen bug mit dem Chip, der nicht dokumentiert ist? Irgendwelche Sonderanforderungen mit dem Strombedrf oder der Config? Der Conig_Done kommt wie erwartet.
Also ich hab keine direkten Bugs und Probleme mit dem Artix 7 bei mir. Hab auch ein Spartan 6 Design portiert. Eventuell hast du den Standby Pin nicht korrekt beschaltet und das ganze FPGA schläft? Ansonsten sind die MMCM sogar gutmütiger als die DCM_SP im Spartan 6, denn die brauchen nicht unbedingt einen externen Reset. Einfach den Clock-Stopped Ausgang auf den RST Eingang legen reicht da aus. Bissl putzig ist die Reset- und Init-Geschichte der GTP Transceiver (Das ist ein wirklicher Bug), aber wenn man den Code vom Example Design benutzt, geht das auch. Vielleicht wartet dein Design auf ein Done vom GTP und du hast diesen großen Wrapper (*_init.vhd) aus dem Example Design nicht drin?
Thomas Ulrich schrieb: > Vielleicht sollte man noch hinzusetzen, dass wir hier noch kein > ChipScope haben. Ich habe es aber bestellen lassen, um dem Problem > beizukommen. > > Mein Ansatz ist momentan der, dass die PLLs nicht laufen und im Reset > hängen oder sonst irgendwie die HW sich anders verhält, als die > Simulation, denn diese zeigt keine Auffälligkeiten, wie schon erwähnt. Da lässt sich doch sicher ein Frequenzteiler einrichten und auf eine externe LED legen und dann sollte es blinken. Die Frage lässt isch sicher schnell beantworten. > Ich habe jetzt seit 10 Jahren mehr oder weniger Erfahrung mit FPGAs, > aber sowas ist mir noch nicht passiert. > > Gibt es irgendeinen bug mit dem Chip, der nicht dokumentiert ist? Nein, die ISE hat eine Macke. Wenn du eine Testbench mit in das Design einfügst, ist das ucf File an der Testbench (hat ja auch Endung vhd) dran. Da du das Top File für den Fitter nimmst, ist das ucf File nicht aktiv. Lösch alle Files, die sich über dein Top.vhdl File befinden aus deinem Design. Auch das UCF herausnehmen und nochmal das UCF file einbinden. Dann hängt ISE es richtig ein. Du siest es auch an der Struckturdarstellung, wo das UCF File hängt. Ich hatte mal gefittet. Ging in auf der Hardware (allerdings Spartan6) Dann Testbench geladen simuliert. Wieder gefittet. Ging nicht mehr die Hardware. UCF File neu geladen. Ging alles wieder.
René D. schrieb: > Nein, die ISE hat eine Macke. Wenn du eine Testbench mit in das Design > einfügst, ist das ucf File an der Testbench (hat ja auch Endung vhd) > dran. Aber nicht zwangsläufig. Ich hatte das auch mal, aber in letzte Zeit nicht mehr vorgekommen. Das kann man so pauschal nicht sagen.
Thomas Ulrich schrieb: > Ich habe jetzt seit 10 Jahren mehr oder weniger Erfahrung mit FPGAs, > aber sowas ist mir noch nicht passiert. 10 Jahre Erfahrung und noch kein Chipscope angefasst? Aber einen Logicanalyzer oder ein Scope habt Ihr schon zur Verfügung?!? Ansonsten wie schon geschrieben: Erstaml die Takte und die Resets prüfen. LED kann ich zum Takt prüfen nicht empfehlen: Ich hatte schon eine LED, die bei 50 MHz 50/50 Takt nicht geleuchtet hat. Duke
Duke Scarring schrieb: > Thomas Ulrich schrieb: >> Ich habe jetzt seit 10 Jahren mehr oder weniger Erfahrung mit FPGAs, >> aber sowas ist mir noch nicht passiert. > 10 Jahre Erfahrung und noch kein Chipscope angefasst? Naja, das obergeniale Werkzeug ist ChipScope ja nun auch nicht. > LED kann ich zum Takt prüfen nicht empfehlen: Ich hatte schon eine LED, > die bei 50 MHz 50/50 Takt nicht geleuchtet hat. Na SO macht man das ja auch nicht. Bitte runterteilen auf einige Hz. Bei 50MHz ist die Frequenz so hoch, dass der Strom über die Raumladungskapazität abfliesst und sie gfs sogar zerstört.
- im Süden nichts Neues: Der Chip tut immer noch keinen Schlag. Xilinx ist eingeschaltet. - ich kenne ChipScope schon, nur die Firma hatte es noch nicht im Gebrauch. Das Paket kommt jetzt wohl nächste Woche. - Es handelt sich um den 200er Chip. Von denen gibt es bestellmässig nur den einen. XC7A200T
Thomas Ulrich schrieb: > - ich kenne ChipScope schon, nur die Firma hatte es noch nicht im > Gebrauch. Das Paket kommt jetzt wohl nächste Woche. Paket für Chipscope? Für chipscope braucht es nur einen Lizencode, oder die Evalversion für 30? Tage. Und natürlich einen Xilinx-Programmer, den habt ihr doch im Hause? Oder etwa nicht? Wenn nicht, wie programmiert ihr den Artix?
Ein Projekt sofort komplett portieren ohne die grundsätzliche Hardware zuerst prüfen - da kann ich dir wirklich nur viel Spaß bei Fehlersuchen wünschen. Stimmen alle Spannungen? Läßt sich der FPGA überhaupt laden? Was sagen die Status-Bits in Impact? Funktioniert ein Minimal-Design? (Frequenzteiler an LED, etc.) Dann kann man sich mal ein Design mit einer PLL etc. überlegen und so weiter. Leider kommen von dir auch zu wenig Infos, was du schon probiert hast und was nicht. Die Antwort mit der Glaskugel spar ich mir mal Schöne Grüße
port map (
Q => GmiiGTxClkxCO, -- 1-bit output data
C0 => Clk125MxC, -- 1-bit clock input
C1 => not Clk125MxC, -- 1-bit clock input
CE => '1', -- 1-bit clock enable input
D0 => '0', -- 1-bit data input (associated with C0)
D1 => '1', -- 1-bit data input (associated with C1)
R => ResetxR,-- 1-bit reset input
S => '0' -- 1-bit set input
);
So Kanidaten wie ResetxR ..GND
C1 => not Clk125MxC, -- 1-bit clock Input
not_ticks Feedback .
http://forums.xilinx.com/t5/Spartan-Family-FPGAs/driving-clock-on-IO/m-p/212829#M15751
Oder direkt da im x Forum schreiben & suchen.
Viel Erfolg.
Gruss Holger.
Holger schrieb: > port map ( > Q => GmiiGTxClkxCO, -- 1-bit output data > C0 => Clk125MxC, -- 1-bit clock input > C1 => not Clk125MxC, -- 1-bit clock input > CE => '1', -- 1-bit clock enable input > D0 => '0', -- 1-bit data input (associated with C0) > D1 => '1', -- 1-bit data input (associated with C1) > R => ResetxR,-- 1-bit reset input > S => '0' -- 1-bit set input > ); ??? Ist das das auf Artix portierte Design, das nicht läuft? Oder hat sich dieser beitrag in den falschen threasd verirrt? MfG
Nee, das hat Holger einfach aus dem Xilinx Forum kopiert. Wahrscheinlich wollte er nur was schreiben. Seine Postings vertehe ich auch manchmal nicht, da werden immer Buzzwords reinkopiert, ohne richtigen Zusammenhang zum eigentlichen Thema. Nichtsdestotrotz ist die Fehlerbeschreibung sinnlos, "läuft nicht" ist kein Fehler. Als FPGA Designer sollte man in der Lage sein das Problem einzugrenzen.
:
Bearbeitet durch User
Thomas Ulrich schrieb: > Der Conig_Done kommt wie erwartet. Wann erwartet ihr das Done? Man kann man mit bitgen optionen einstellen, wann das DONE-Signal aktiviert werden soll. Beispielsweise vor oder nach dem LOCK der PLL. Ebenso kann man per bitgen festlegen, ob auf das LOCK gewartet werden soll, bevor der FPGA startet (FF, IO freigegeben). Stopp nach Fehlgeschlagener CRC Check lässt sich dort auch aktivieren/deaktiviern. Siehe http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_3/devref.pdf S.225 - 247 MfG,
Ich glaube da muss er sein Ref-Design mal sehr genau ansehen. BUF, BUFG usw via UCF File was da drin ist. Power Supply Management in High Availability Systems Link: Hier wird das Power-up behandelt, sollte man sich mal ansehen. http://www.youtube.com/watch?v=AXPJhNFe6bM&feature=c4-overview&list=UUitjOEmRnBEvfn6fbAUmNjg reliability system design is getting reliable power. Das Xilinx FPGA hat 7 Power-Rails,die in einer seq. gefahren werden. Z.B Reset MCU kommt auch noch dazu. INST DCM_INST STARTUP_WAIT = FALSE; # Generated by Xilinx Architecture Wizard # --- UCF Template Only --- # Cut and paste these attributes into the project's UCF file, if desired INST DCM_INST CLK_FEEDBACK = 1X; INST DCM_INST CLKDV_DIVIDE = 2.0; INST DCM_INST CLKFX_DIVIDE = 3; INST DCM_INST CLKFX_MULTIPLY = 10; INST DCM_INST CLKIN_DIVIDE_BY_2 = FALSE; INST DCM_INST CLKIN_PERIOD = 16.667; INST DCM_INST CLKOUT_PHASE_SHIFT = NONE; INST DCM_INST DESKEW_ADJUST = SYSTEM_SYNCHRONOUS; INST DCM_INST DFS_FREQUENCY_MODE = LOW; INST DCM_INST DLL_FREQUENCY_MODE = LOW; INST DCM_INST DUTY_CYCLE_CORRECTION = TRUE; INST DCM_INST FACTORY_JF = 8080; INST DCM_INST PHASE_SHIFT = 0; INST DCM_INST STARTUP_WAIT = FALSE; Gruss Holger.
Er hat ja geschrieben, dass ein "manuelles Testdesign" (was auch immer das ist) funktioniert. Also scheint das FPGA selber zu starten. Die ganzen MMCM Constraints müssen nicht zwangsläufig in das UCF, wenn man die als Generic beim MMCM mit angibt (was der CoreGen macht) dann werden die automatisch übertragen.
Also, der Fehler wurde dann gefunden: 1. Eine PLL setzte aus, wegen einen instabilen Eingangstakt 2. Eine andere PLL setzte planmässig aus aber nicht wieder ein, weil die Resetschaltung nicht arbeitet. Der aufrechterhaltende selbstoszillierende Takt der im Spartan 6 noch lief, war nicht mehr in Gang gesetzt worden 3. etwas änhliches vollzog sich dann im Testdesign rund um den BS-Core. Irgendwie haben sie da einen selbstlaufenden Osci drin, der beim ARTIX anders taktet. Ein Xilinx FAE musste eingreifen in der neuesten ISE ist da wohl ein workaround drin. Wie auch immer, das Design läuft jetzt, wie gewünscht.
Es war ISE und ich hatte zum Zeitpunkt der Fragestellung nicht die heutige Version. Diese ist wie bekannt die 14.7. Damals war es glaube ich 14.5 oder so.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.