Hallo zusammen, für ein Physikalisches Experiment mit Röntgenstrahlen erfassen wir Detektorcounts in Abhängigkeit von verschiedenen äußeren Zuständen. Die Detektorpulse sind sehr kurz und wir erfassen sie im Moment mit einem Virtex-4 womit die Erfassung mit 100MHz Clock noch vernünftig läuft. Um den neuen Detektor richtig ausnutzen zu können, möchten wir das ganze schneller betreiben können. Welche Geschwindigkeitsvorteile sind in etwa von einem Virtex-6 zu erwarten. Hat jemand eine Bezugsquelle, wo das ML605 wirklich erhältlich ist? Gibt es schon sonstige Boards mit dem Virtex-6? Gruß Andreas
Ich denke die Frage sollte eher heißen mit welcher Geschwindigkeit kann ich meinen Detektor auslesen. Ich bin mir zwar nicht 100%ig sicher jedoch vermute ich der Virtex4 hat auch ein paar PLL´s die eine 200MHz Frequenz liefern. Für eienen ersten Test sollte wäre das kostengünstiger als ein neuer FPGA.
Das ist richtig, bin auf dem Gebiet auch totaler Anfänger und hab den Code bisher nur übernommen. Aber beim compilieren steht da max. Frequenz 165 MHz. Das bedeutet doch, dass ich den FPGA nur so hoch takten darf, wenn ich keine Fehler riskieren möchte, oder sehe ich das falsch? Und daher die Frage, ob beim Virtex6 da ein wesentlich anderer Wert zu erwarten ist.
Das ist richtig. Versuch doch einfach mal das Design für einen Virtex 6 zu übersetzen. Wird der V6 nicht schon in der ISE unterstützt?
Also der Virtex 6 dürfte schon schneller sein, schließlich läuft da der BlockRAM auch mit 600MHz, der Virtex4 schafft "nur" 500MHz auf dem RAM udn den DSP Slices. Probier´s doch einfach aus. Mach ein neues Projekt in ISE mit dem Virtex 6 und schau, was der ausspuckt. Wo zeigt der die Frequenz an? Nach der Sythese oder nach dem Place&Route? Die Frequenz nach der Synthese ist ein grober Richtwert, die kann durch das Routing noch um einiges nach oben oder nach unten verändert werden. Wie voll ist der FPGA jetzt? Je voller desto langsamer wirds in den meisten Fällen....
Ich vermute mal auf dem FPGA ist ein Softcore wie der PicoBlaze drauf. Wenn der nur bis 164MHz stabil läuft dann wird es sich bei einem anderen FPGA auch nicht wirklich viel ändern. Wobei dort meiner Meinung nach nicht das Problem liegt, sondern wirklich an der Frequenz des Detektors. Den kann man unabhängig von der CPU Frequenz durchaus schneller betreiben - falls es nicht sogar schon gemacht wird. Für jemanden der bis jetzt noch gar nichts mit einem FPGA gemacht hat wird es schwer werden dieses zu kontrollieren bzw. zu ändern.
Hmm, meine Xilinx ISE Version 10.1 kennt den Virtex 6 leider noch nicht. Einen Softcore oder auch den eingebauten PowerPC nutze ich nicht, wie kann ich denn erkennen, was dann meine sichere Maximalgeschwindigkeit ist? Ausprobieren bis zur Grenze kann ja nicht die einzige Möglichkeit sein, oder? Die 164MHz sind tatsächlich nach der Synthese, wo kann ich die Geschwindigkeit nach dem Route and Place ablesen? Gibt es hierzu ein vernünftiges Tutorial, was Timings, beste Geschwindigkeitsausnutzung und sowas betrifft. Bei VHDL programmiert man ja doch recht abstrakt, so dass einem nicht bewusst ist, welcher Befehl Resourcen frisst. Bei uns hier an der Uni machen zwar viele was mit FPGAs aber in der Hinsicht kann einem auch keiner weiterhelfen... Was den Detektor betrifft, der kann Pulse generieren, die eine einstellbare Pulsbreite von 5-50 ns haben. Wenn ich die Pulsbreite vergrößere, ergibt sich halt eine größere Totzeit, während der keine weiteren Ereignisse erfasst werden, ist daher unerwünscht. Im Moment muss ich aber mit größerer Pulsbreite arbeiten, um alle Pulse sicher erfassen zu können. Schonmal vielen Dank für eure Hilfe! Gruß Andreas
Das Problem mit den erreichbaren Geschwindigkeiten ist noch etwas komplexer. Einfach einen andern FPGA einsetzen und "nichts" zu ändern muss nicht unbedingt eine höhere Maximalfrequenz zur Folge haben: Neben der eigentlichen Verhaltensbeschreibung gibt es noch ein Sack voll Parameter die ebenfalls zu beachten sind. Z.B. Timing-Constrains, die Verwendung der IOs und der zugehörigen IO-Standards usw. Angenommen der FPGA wird von einem externen Takt synchron betrieben ohne die Verwendung von irgendwelchen PLLs im internen des FPGAs und das Timings-Constain des Clocks ist auf die 100 MHz angepasst, dann versuchter die Synthese dieses Timing hinzubekommen. Die Timinganalyse ergibt dann z.B. eine theoretische maximale Clockfrequenz von 165 MHz. Da sagt sich das Tool doch: Wunderbar! Alles funktioniert. Warum sollte ich daran was weiter optimieren? Wenn man nun aber das Timingconstrain auf Beispielsweise 200 MHz setzt, dann versucht die Synthese dies auch hin zu bekommen. Bei Verwendung von PLLs im FPGA versuchen die meisten Tools schon das Timing auf die Ausgangsfrequenz der PLL zu optimieren. Und jetzt wird es spannend: Leider hilft es nicht einfach das Timing auf einen X-beliebigen Wert (z.B. 500 MHz) hochzusetzen und mal zu schauen was der FPGA wohl kann. Das funktioniert nicht. Die Timing-Constrains sollten schon auf die Erfordernisse angepasst werden. Weiterhin gibt es aber noch Viiiiiieeeeele Parameter an denen man drehen kann um ein optimiertes Syntheseergebnis zu erreichen. Speedoptimierung erfordert Erfahrung. Sorry.
Schon die Ausgabe von xst (der .syr Report) gibt eine erste Geschwindigkeitsabschaetzung und zeigt die laengsten Pfade. Diese Pfade sollte man dann ueberdenken.
Andreas Wiese schrieb:
> Hmm, meine Xilinx ISE Version 10.1 kennt den Virtex 6 leider noch nicht.
Dann installier dir die 11.1 und Update auf 11.4 und dann hast du alle
aktuellen Virtex 6 auch drin. An der Uni habt ihr doch garantiert eine
Hochschullizenz dafür....
Andreas Wiese schrieb: > Was den Detektor betrifft, der kann Pulse generieren, die eine > einstellbare Pulsbreite von 5-50 ns haben. Man muss ja nicht immer gleich den Vorschlaghammer rausholen. Wenn du ein IDDR des Virtex4 verwendest, erhälst du den Wert deines Eingangssignals an der steigenden und fallenden Flanke. Das ist bei deinen 100MHz bereits eine Auflösung von 5 ns. Falls das nicht reicht, erzeugst du dir einen 200 MHz Takt. Damit betreibst du das IDDR und zwei 4 Bit Schieberegister, jedes für einen Ausgang des IDDR. Die parallelen Daten der Sregs schreibst du mit 8 Bit Breite und 200 MHz in ein BRAM. Den liest du auf der anderen Seite mit 16 Bit Breite und 100MHz aus. Damit liegt deine Auflösung bei 2,5 ns. Mit einem ISERDES müsste man auch was machen können. Tom
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.