Ich arbeite seit Beginn des Jahres mit einem existenten Spartan 6 Design, zunächst mit ISE 14.1, dann 2 und inzwischen Version 4. Je nach Version gibt es andere Synthesprobleme, die aber bei Weitem nicht alle ausdrücklich benannt werden oder in den Eratas auftauchen. So hatte ich z.B. gosse Probleme mit ChipScope, der einmal nicht synthetisieren wollte, ein anderes mal komische Ergebnisse auswarf. Das was Xilinx diesbezüglich an APPS und Sheets veröffentlich hat, scheint nun behoben, dennoch fürchte ich, dass es da noch mehr dunkle Dinge zu geben scheint, da ich weiterhin seltsame Effekte habe, als da wären: RAM-Inhalte scheinen sich wie von Geisterhand zu ändern! Ram Zellen, die von dem beschreibenen Prozess aufgrund der Randbedingungen nicht belegt wurden, haben beim Auslesen dennoch einen Inhalt - andere wiederum, bei denen etwas reingeschrieben wurde, haben keinen oder einen falschen! Ausserdem werden nach Lust und Laune des Tools die timings mal getroffen und mal nicht. Die o.g. Fehler sind damit nicht voll nachvollziehbar oder verfizierbar, da man nicht weiss, ob die timing ok waren oder nicht. Natürlich hinterfrage ich mögliche Fehlergebnisse nur in jenen Fällen, in denen das Tool 100% getroffene timings vorgab - die Schaltungs also funktionieren müsste und sie zudem auch laut Siimulation i.O. sein müsste. Frage: Wer hat ähnliche komischen Effekte mit dem Spartan 6? Ich habe - zum Testen - einige Schaltungen extrahiert, simuliert und auf einen Spartan 3 portiert. Soweit das vom Platz her ging, und die Timings als i.O galten hat die Schaltung dort nämlich ohne Probleme funktioniert, was mich in meiner Annahme bestärkt, dass mein Verilog / VHDL ok sein sollte. Was könnte man unternehmen, um dem Problem beizukommen?
Frank H. schrieb: > RAM-Inhalte scheinen sich wie von Geisterhand zu ändern! > Frage: Wer hat ähnliche komischen Effekte mit dem Spartan 6? Beitrag "Re: Speicherfehler im BlockRAM"
Die Preload-Speicherfehler lassen sich umgehen, wenn man keine BRAM8 Blöcke nimmt. Die BRAMs im S6 sind in der Tat ziemlich buggy, da muss man genau aufpassen. Ich hab zwei verschiedene Designs mit dem Spartan 6, allerdings gleich mit dem -convert-bram-8 Switch drin, da hab ich keine derartigen Probleme. Ergebnisse sind konsistent trotz hohem Füllgrad an DSP und BRAM. Allerdings nutze ich dafür auch die command line für die tools. Das hat aber eigentlich keinen Einfluss.
Christian R. schrieb: > gleich mit dem -convert-bram-8 Switch drin wie genau müsste ich den (ohne command line) applizieren?
Frank H. schrieb: >> gleich mit dem -convert-bram-8 Switch drin > > wie genau müsste ich den (ohne command line) applizieren? Da stehts: http://www.xilinx.com/support/answers/39999.htm aber das umgeht nur den Bug in der Initialisierung. Such mal in den Answer Records nach Spartan 6 BRAM, da gibts massenhaft Einträge. Hoffentlich gibts die Artix 7 bald...
Christian R. schrieb: > Hoffentlich > > gibts die Artix 7 bald... Die werden auch wieder bugs haben... Danke für die Hilfe schon mal
Frank H. schrieb: > Die werden auch wieder bugs haben... Sicherlich, bugfreie Chips gibts nicht. Aber der S6 hat schon einige sehr blöde Beschränkungen, vor allem was die Clocking Ressourcen angeht.
Frank H. schrieb: > Je nach > Version gibt es andere Synthesprobleme, Hast Du geprüft, ob das wirklich (nur) an den 14er Versionen hängt? Syntheseprobleme mit Spartan 6 sind mir in allen ISE-Versionen geläufig. Christian R. schrieb: > Aber der S6 hat schon einige > sehr blöde Beschränkungen, vor allem was die Clocking Ressourcen angeht. Das hat die halbe Welt nun wohl gemerkt und kauft keine Spartan 6 FPGAs mehr. Daher sind sie ja auch so erschreckend billig. Ok, wer keine Blockrams braucht und keine komplizierten Tatkgeschichten veranstaltet, kommt mir dem Baustein shr gut hin, sage ich mal.
Naja, ganz so schlimm ist es ja nicht. Natürlich muss man die Bugs im Hinterkopf behalten, aber gerade wo relativ viele Ressourcen bei wenig Stromverbrauch benötigt werden, ist der S6 ideal. Wir haben hier ein paar Designs, die laufen prima mit dem S6.
Christian R. schrieb: > Natürlich muss man die Bugs im > > Hinterkopf behalten, D.h. konkret was? Die BRAMs nicht in der 9er Version verwenden?
Man kann die auch in der 8/9 Bit Version verwenden, aber dann klappen die Init-Werte nicht (direkt). Da gibts zwei Workarounds, aber in unseren Designs haben wir nur 16/18 Bit breite FIFOs und DP RAMs, also da kein Problem.
>Clocking Resourcen Das ist leider sehr richtig, aber nicht nur das: Wer RAMs und DSPs verwenden möchte, sieht sich dem Problem gegenüber, dass da zwar in den Angaben summarisch aufgelistet wird, wie schon bei den 9er und 18er RAMs untereinander, real aber sozusagen eine Art EXOR-Funktion vorliegt :-( Mr. Z. schrieb: > Das hat die halbe Welt nun wohl gemerkt und > kauft keine Spartan 6 FPGAs mehr Vermutung oder Wissen? Da würden mich Zahlen interessieren. >"drum herum programmmieren" Fragt sich nur zu welchen Kosten. Ich verwende(te) den Spartan 6 sowohl privat als auch in Kundenprojekten und das Erzeugen von Umgehungscode, mit dem man die Probleme umschiffen kann / könnte, ist eben mitunter (unakzeptabel) zeitaufwändig! Der Spartan 6 ist der Problembär unter den FPGAs :-)
Ja, DSP48 ist auch so eine Geschichte. Aber da sind die Xilinx alle nicht besser, da gibts immer zig Einschränkungen. Ich hab es nicht geschafft, alle 180 DSP48 Einheiten auf dem S6 100 zu nutzen, weil ich den BRAM anderweitig brauchte und 4 FIR Filter mit je 45 Koeffizienten nutzen wollte, insgesamt 180 DSP Einheiten. Aber das hat der nicht geroutet, mit den abenteuerlichsten Meldungen. Mit 128 von 180 DSP hats geklappt. Sehr unschön. Aber ob das besser wird? Ich versuche gerade ein Design vom SP605 was die MGT nutzt auf das AC701 zu portieren, also da wird man ja alleine bei der Reset-Sequenz der MGT für den Artix 7 verrückt. Und die Clock Correction funktioniert nicht mal in der Simulation. Mal sehen, wie das wird, wenn das Board dann da ist. Diese asymmetrisch gelegte Clock Backbone ist mir auch erst mal suspekt...
Christian R. schrieb: > Aber das hat der nicht > geroutet, mit den abenteuerlichsten Meldungen. Im Prinzip bräuchte man so eine Art CoreGen, der aus der Funktion die Realisation entwickelt und dabei die Einschränkungen berücksichtigt und dabei die Zahl der benötigten FPGAs ausgibt. Früher hat man mal ein board gebaut und dann das FPGA angepasst. Heute muss das FPGA Design fix und fertig erstellt, geroutet und gegensimuliert sein, bevor man zur Bestellung des parallel entwickelten boards grünes Licht geben kann, weil man vorher nicht weiss, ob es gelingen wird.
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.