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.
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.
