Bei der Konversion eines Spartan 3E designs auf Spartan 6 komme ich zu
keinem Syntheseergebnis. Das Problem liegt an den Takten und
Buffer-Resourcen, die die Synthese nicht zuordnen kann, bzw die nicht
zusammenschaltbar sind / sein soll.
Im Original verwende ich 2 Oszillatoren (66MHz und 27MHz) sowie einige
Mehrfach-DCMs, die die jeweils benötigten Takte erzeugen (3+4).
Egal, ob ich die Architektur so belasse oder alles mit einzelnen DCMs
oder sie anders zusammenfasse, jedesmal kommen die Probleme mit Routing
Resourcen:
Einmal ergeben sich angebliche doppelte Buffer, einmal will er von einem
Buffer nicht auf den nächsten routen und wenn ich einzelne nehme, gehen
ihm die BUFGs aus.
Aus der SPEC entnehme ich, dass der S6 nur 16 Buffer hat, während der S3
deren 20 aufweist. Das allein kann es aber nicht sein, weil ich im
Grunde nur 7 Takte habe.
Wie liesse sich das Problem angehen?
Ja, das hatte ich auch schon. Der Spartan 6 ist im Clocking leider
extrem beschränkt. Schau dir mal die Übersichts-Schaltpläne im Clocking
User Guide an. GCLK Taktnetze gibts wesentlich weniger als im Spartan
3e, dafür viele regionale Clock Geschichten. Wenn du das eingrenzen
kannst, kannst du versuchen die DCM mit BUFR am Ausgang zu benutzen.
Ich hatte ein Design, welches 4 BUFGMUX im S3e verwendet um wählbar 4
Takte auf einen ODDR-Ausgang zu schalten, das ging im S6 nicht so zu
realisieren.
Christian R. schrieb:> das ging im S6 nicht so zu realisieren.
Ich habe ohnehin den Eindruck, dass im Spartan6 so einiges nicht zu
realisieren ist, was im Datenblatt steht. Wenn man mal gedanklich die
zur Verfügung stehenden Resourcen addiert, kommt man auf einen extrem
kostengüsntigen Chip, vor allem unter Beachtung der theoretischen
Taktgeschwindigkeiten. Allerdings schliessen sich so viele Dinge
gegenseitig aus, dass am Ende immer noch ein Bruchteil davon übrig
bleibt.
Gerade bei den Taktbifferresourcen kollidieren doch so einige
Möglichkeiten miteinander, die man zu haben scheint, z.B. wenn man GTPs
und MCBs benutzen will, dann wird es mit den Takten ebenso schnell
"eng", wie wenn man mit den SERDES was einsynchronisieren und
eye-matching betreiben will. Im Xilinx-User-Forum wird das auch an
mehreren Stellen diskutiert, dass den Umsteigern von S3 auf S6
überraschend schnell die DCMs / PLLs bzw. die Buffer ausgehen.
Besonders lustig finde ich die Auflistung der RAMs, die einmal als
RAMB16 und einmal als RAMB8 gelistet werden, so, als lägen beide
Einheiten jeweils parallel vor. Das spiegelt einem schnell die doppelten
Resourcen vor. Hinzu kommt, dass der Spartan 6 keine Ausgangsregister an
den RAMs hat, sondern diese mit jeweils 2 FF-Stufen bilden muss, was bei
der Nutzung höherer Taktraten praktisch immer von Nöten ist und bei der
Registrierung von ADR+DAT, jeweils rund 40 FFs je angefangenen 2k-Block
kostet, beim DP-Funktion das Doppelte. Bei meinen Spartan 75 (Trenz)
kostet das bei allen 172 BRAMs >10kFFs und damit mehr, als 10% vom Chip.
Die Slices gehen einem dann noch schneller aus!
Das ist für Altera-verwöhnte User z.B. ein ziemliches Problem, vor
allem, wenn man shadow-RAMS verwendet. Bei der Cyclone-Serie
synthetisiert die Software kurzerhand mal einen 3.RAM-Anschluss dran,
der nur zusäztliche Register kostet. Beim Xilinx ist ein weiteres BRAM
fällig - inklusive weiterer Register.
Schön kann man das auch beim Vergleich von Virtex auf Spartan sehen: Um
das Takttempo zu halten wird der Spartan zum Registerfresser. Das fängt
schon ab 100 MHz an!
Man muss klar sehen, dass der S6 ein preisgünstiger und auch billiger
Chip die maximalen Taktreserven ansieht
Ja den Eindruck hab ich auch. Einen S6-150 kriegt man mit "relativ"
wenig trotzdem schnell voll. Da helfen auch die LUT6 nicht viel. Das
Clocking ist leider ziemlich beschränkt, auch diese halbe-Bank
Geschichte an den I/OSERDES. So ein Gedöns. Aber er ist was er ist: Ein
abgespeckter Virtex 5 der mit Kampfpreisen neue Abnehmer finden
will/wollte. Ich überlege für das aktuelle Design in Entwicklung doch
noch auf den Artix zu warten, aber vor Q2/2013 ist ja damit nich zu
rechnen. Ich hab allmählich die Befürchtung mit dem S6 trotz üppig
scheinender Ausstattung in die Falle zu tappen, vor allem da ich einen
8-Kanal ADC per ISERDES anschließen und nahezu den gesamten BRAM
aufbrauchen muss. Und das bei 125MHz, das wird sicherlich selbst im
LX150T eng. Dazu muss dann auch noch ein GTP dran....
> Einen S6-150 kriegt man mit "relativ"> wenig trotzdem schnell voll.
Definier mal "relativ". Wundert mich schon etwas, dass in einen LX150
nicht viel reinpassen soll o_O
Wollte eigentlich demnächst mal mit einem LX45er experimentieren...
Artix geht ja erst so bei 125 Euro los (dementsprechend werden die
Entwicklungsboards wohl recht teuer werden), die kleinen hat Xilinx ja
leider alle rausgeworfen.
Ich hab ja relativ extra in Anführungszeichen gestellt. Es geht schon
einiges rein, aber gerade bei den Spezialfunktionen und BRAMs sind die
Grenzen schnell erreicht. Mich ärgert am meisten das eingeschränkte
Clocking, vor allem bei den ISERDES. So eine halbe Bank ist nicht
besonders breit, und wenn man die PLLs nehmen wöllte um eine ganze Bank
zu benutzen, fehlt das BUFPLL Zeugs wieder an anderer Stelle.
Reine Logik, BlockRAM usw. ist aber schon reichlich vorhanden, keine
Sorge.
Die block-RAMs sind derzeit kein Problem, obwohl man ja davon nie genug
haben kann:-)
Mich drücken eher die Schwierigkeiten, die die Software offenkundig beim
routen der Clock-Resourcen bekommt. Leider blicke ich noch nicht recht
durch, woran es genau liegt, da entweder Ergbnisse kommen, die nicht
timen, oder aber die lapidare Meldung erscheint, man könne das "so"
nicht machen.
Spartanist schrieb:> Leider blicke ich noch nicht recht> durch, woran es genau liegt, da entweder Ergbnisse kommen, die nicht> timen, oder aber die lapidare Meldung erscheint, man könne das "so"> nicht machen.
Mal mal auf (clock tree), wie Du es gern hättest. Ich habe mich letztens
erst durch die Clocking resources durchgewühlt, um ISERDES zu verwenden.
Duke
ISERDES ist wirklich gemein. Da muss man in der halben Bank bleiben wenn
man den BUFIO2 nehmen will und außerdem muss der IO Clock an einem GCLK
in eben diser halben Bank ankommen. Wenn man aber nicht allzuviele Takte
im Design hat, gehts auch mit dem Spartan 6 ganz gut. Noch eine
Gemeinheit: LVDS Ausgänge können nur in 2 der IO-Bänke platziert werden.
LVDS Eingänge gehen an jedem I/O.
Christian R. schrieb:> Da muss man in der halben Bank
Irgendsowas scheint es bei mir auch zu sein
Duke Scarring schrieb:> Mal mal auf (clock tree), wie Du es gern hättest
kommt
