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