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
Spartanist schrieb: >> Da muss man in der halben Bank > Irgendsowas scheint es bei mir auch zu sein Poste doch mal di Fehlermeldung. Kommt die von Pack?
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.