Ich muss kontinuierliche Daten von einem 24 Bit ADC mit 768kHz verarbeiten (4 Kanäle a 192) habe nur einen langsamen Spartan 3E zur Verfügung. Weil ich zu wenige Multiplier habe, müssen viele LUTs benutzt werden und die Taktfrequenz geht runter. Leider muss ich FFs sparen und die Frequen geht nochmal runter. Spricht etwas dagegen, noch mehr in Kombinatorik zu machen und die Taktfrequenz auf 1MHz abzusenken, statt mit enable zu arbeiten? Ich würde eine PLL nehmen und den Eingangstakt des FPGA von 25 MHz einfach runterteilen. Die Datenübernahme liefe mit einem Fifo.
@ Analogi (Gast) >Ich muss kontinuierliche Daten von einem 24 Bit ADC mit 768kHz >verarbeiten (4 Kanäle a 192) Nicht sonderlich viel. >habe nur einen langsamen Spartan 3E zur Verfügung. Ach du Armer! :-( >Weil ich zu wenige >Multiplier habe, müssen viele LUTs benutzt werden und die Taktfrequenz >geht runter. Leider muss ich FFs sparen und die Frequen geht nochmal >runter. Spricht etwas dagegen, noch mehr in Kombinatorik zu machen und >die Taktfrequenz auf 1MHz abzusenken, statt mit enable zu arbeiten? Nö. Damit sinkt deine Siliziumausnutzung noch mehr. Du brauchst eher MEHR Pipelining und eine sinnvolle Nutzung von BRAMs als (Zwischen)speicher. Man kann auch über ein Multiplexing deiner Logik nachdenken. >Ich würde eine PLL nehmen und den Eingangstakt des FPGA von 25 MHz >einfach runterteilen. Die Datenübernahme liefe mit einem Fifo. Man muss schon viel Unsinn machen, wenn man die erreichbare Taktfrequenz in einem S3E unter 25 MHz drückt. Ich tippe mal, dass deine VHDL-Beschreibung suboptimal ist. Du bist eher Softwerker, stimmts?
Analogi schrieb: > Spricht etwas dagegen, noch mehr in Kombinatorik zu machen und die > Taktfrequenz auf 1MHz abzusenken, statt mit enable zu arbeiten? Spricht was dagegen, die Berechnungen zeitlich gemultiplext durchzuführen und das Design mit 100MHz zu takten? Immerhin kannst du dann in der selben Zeit z.B. 100 Berechnungen hintereinander machen... > (4 Kanäle a 192) 192 Erbsen oder wie? Achja: kHz... Und warum sind das dann 768kHz? Wieso verarbeitest du nicht 4 * 192kHz parallel? Wie sieht denn dieses System aus? Was tut es?
Lothar Miller schrieb: > Und warum sind das dann 768kHz? Wieso verarbeitest du nicht 4 * 192kHz > parallel? Wie sieht denn dieses System aus? Was tut es? Das tue ich doch, es kommen 4 Kanäle mit 192kHz, die in eine pipeline fliessen, welche zyklisch abtastet. Daher brauche ich nu 768kHz. Schneller laufen lassen würde nur dazu führen, dass der Prozess warten muss und die pipeline zu 90% auf ein enable wartet. Ich würde ja gänzlich auf 768kHz runtergehen, aber die pipeline muss ja etwas schneller den Fifo abfragen, als Daten kommen. Daher die 1 MHz. Nochmals zum Verständnis: Das Absenken der Taktfrequenz soll soviel Raum schaffen, wie es geht, um lange Kombinatorik ohne FFs zu nutzen, damit FFs gespart werden können und alles rein geht. Gibt es eine untere Taktfrequenz?
Die Absenkung der Taktfrequenz ist im Prinzip genau das gleiche wie die Verwendung von Clock-Enable. Du must es nur deinem Synhtesetools entsprechend mitteilen, Stichworte sind hier Multicyle-Path und TimingConstraint, wird ausgibigst in den Constaint Manuals erklärt. Und: im Spartan3 können bei 1MHz sicherlich 20-50 LUTs hintereinander geschaltet werden, entsprechende Plazierung der LUTse. Diese Ketten durchzuschneiden und ab und an ein FF platzieren schadet sicher nicht.
Welcher 3e ist es und was muss darin alles passieren? Meine 3e können problemlos bei 100MHz noch >32 bit Additionen machen, daher würde ich eher höher takten wenn mehr gerechnet werden soll. Oder eben wie schon vorgeschlagen parallel machen oder pipelinen. Den einzigem Grund für kleinen Takt sehe ich bei der Leistungsaufnahme aber auch das ist minimal.
Analogi schrieb: > Gibt es eine untere Taktfrequenz? Meines Wissens nach nein. Man kann auch den externen Takt stoppen. Wenn man ihn wieder einschaltet, rennt das FPGA-Design weiter. Daniel
Daniel schrieb: > Meines Wissens nach nein. Definitiv : Nein. Wieso auch? > Man kann auch den externen Takt stoppen. > Wenn man ihn wieder einschaltet, rennt das FPGA-Design weiter. so ist es. Der FPGA "merkt" sich ja nicht, wann er das letzte mal getaktet hat, das sind jeweils vollkommen isolierte Vorgänge. Im Grunde ist es vollkommen richtig, den FPGA so langsam wie möglich zu takten, weil insbesondere die Taktnetze und PLLs Strom brauchen. Ich bin erstaunt, dass hier Ratschläge kommen, es hochzutakten. Die untere Grenze ergibt sich dann aus den Datenanforderungen, bzw in Sonderfällen, wenn man einen DDR-Speicher zu bedienen hat. Der geht nicht beliebig langsam oder verkraftet Taktaussetzer. Analogi schrieb: > ch würde eine PLL nehmen und den Eingangstakt des FPGA von 25 MHz > einfach runterteilen. Wenn möglich, die PLL einsparen und einen DCM nehmen. Deine Idee, FlipFlops einzusparen, wird aber nur bedingt funtionieren, weil auch alleine durch LUT-Benutzung die slices verbraten werden und die darin enthaltenen FFs gleich mit. Allenfalls lässt sich Kombinatorik besser zusammenfessen, wenn die Synthese vieles in einem Taktzwischenraum "sieht" aber auch das ist irgendwann ausgeschöpft. Ob es also viel bringt, den FPGA so weit runter zu "lassen", muss ausprobiert werden. An der Stelle muss sogar die Frage gestellt werden, wozu hier überhaupt ein FPGA eingesetzt wird und ob es nicht ein Controller tut. Darf man fragen, was hier verarbeitet wird? Hört sich stark nach Audio an.
@ Analogi (Gast) >Das tue ich doch, es kommen 4 Kanäle mit 192kHz, die in eine pipeline >fliessen, welche zyklisch abtastet. Daher brauche ich nu 768kHz. Zeitlupe für ein FPGA. >Schneller laufen lassen würde nur dazu führen, dass der Prozess warten >muss und die pipeline zu 90% auf ein enable wartet. Nöö. Wenn man z.B. einen FIR FIlter mit 100 Anzapfungen (aka Taps) rechnen will, takte man die Logik mit 100*768kHz=76MHz. Damit braucht man nur weng Logik und einen RAM. > Ich würde ja >gänzlich auf 768kHz runtergehen, aber die pipeline muss ja etwas >schneller den Fifo abfragen, Nö, wenn alles synchron ist reichen 768kHz. >Das Absenken der Taktfrequenz soll soviel Raum schaffen, wie es geht, um >lange Kombinatorik ohne FFs zu nutzen, damit FFs gespart werden können >und alles rein geht. Nochmal. Du machst was falsch. Ich rate nochmal. Du machst einen FIR mit vielen Taps REIN kombinatorisch? >Gibt es eine untere Taktfrequenz? 0 Hz, wenn man keine PLLs oder DCMs nutzt.
Jürgen S. schrieb: > Im Grunde ist es vollkommen richtig, den FPGA so langsam wie möglich zu > takten, weil insbesondere die Taktnetze und PLLs Strom brauchen. Ich bin > erstaunt, dass hier Ratschläge kommen, es hochzutakten. Mich wundert hier am meisten dieser Satz, den Analogi schrieb: >>> Weil ich zu wenige Multiplier habe, müssen viele LUTs benutzt werden Wenn ich zu wenige Multiplizierer habe, dann denke ich über einen Multiplexer nach... Analogi schrieb: > Das tue ich doch, es kommen 4 Kanäle mit 192kHz, die in eine pipeline > fliessen, welche zyklisch abtastet. Daher brauche ich nu 768kHz. > Schneller laufen lassen würde nur dazu führen, dass der Prozess warten > muss Nein. Schneller laufen heißt, dass die Multiplikationen nicht gleichzeitig berechnet werden, sondern eine nach der anderen. Und von diesen Berechnungen dann genau so viele parallel, wie du Multiplizierer hast. Aber wenn dein Design im ganzen Leben nur die 768kHz sehen wird, dann kannst du es ja gern darauf synchronisieren. Eine "höhere" Taktfrequenz von 1MHz bringt hier ausser mehr Jitter gar nichts... > es kommen 4 Kanäle mit 192kHz Dann kannst du das Design ja sogar mit 192kHz laufen lassen und alles parallel machen...
Umfangreiche Kombinatorik spart doch auch gar keine FF oder sehe ich das falsch? Wenn ich nur die LUT in den slices benutze und die FF nicht, mache ich doch einfach -nichts- damit. Bei sparen denke ich erst mal an verwaren für später. Wenn slices fehlen kann auch Kombinatorik nicht komplexer werden. Rückmeldung wäre nett.
Analogi schrieb: > Leider muss ich FFs sparen und die Frequen geht nochmal runter. Der logische (Kurz-)schluss hinter diesem Satz will mir auch nicht einleuchten...
Lothar Miller schrieb: >> Leider muss ich FFs sparen und die Frequen geht nochmal runter. > Der logische (Kurz-)schluss hinter diesem Satz will mir auch nicht > einleuchten... Ich könnte mir vorstellen, dass er es so meint: "Ich habe zu wenige Register und kann deswegen nicht pipelinen und dadurch wird die Logiktiefe immer größer und daher geht die maximale Frequenz in den Keller"
@ Schlumpf (Gast) >Ich könnte mir vorstellen, dass er es so meint: >"Ich habe zu wenige Register und kann deswegen nicht pipelinen und >dadurch wird die Logiktiefe immer größer und daher geht die maximale >Frequenz in den Keller" Glaub ich nicht, der OP scheint das Konzept von Pipelining und Multiplexen nicht wirklich zu kennen.
Clemens M. schrieb: > Bei sparen denke ich erst mal an verwaren für später. Ich denke da eher an die Frage, ob es überhaupt reingeht und an einen kleineren Chip. Lothar Miller schrieb: > Analogi schrieb: >> Leider muss ich FFs sparen und die Frequen geht nochmal runter. > Der logische (Kurz-)schluss hinter diesem Satz will mir auch nicht > einleuchten... Weil man üblicherweise FFs setzt, um die mögliche Frequenz hochzusetzen. Da ich da sparen muss (der FPGA soll ja kleiner werden) habe ich diesbezüglich weniger Optionen. Falk Brunner schrieb: > @ Schlumpf (Gast) >>Ich könnte mir vorstellen, dass er es so meint: >>"Ich habe zu wenige Register und kann deswegen nicht pipelinen und >>dadurch wird die Logiktiefe immer größer und daher geht die maximale >>Frequenz in den Keller" > Glaub ich nicht, der OP scheint das Konzept von Pipelining und > Multiplexen nicht wirklich zu kennen. Schlumpf hat es erfasst und das Konzept von Pipelining habe ich verstanden. Es gibt hier aber nicht mehr zu pipelinen. Falk Brunner schrieb: > Nöö. Wenn man z.B. einen FIR FIlter mit 100 Anzapfungen (aka Taps) > rechnen will, takte man die Logik mit 100*768kHz=76MHz. Damit braucht > man nur weng Logik und einen RAM. Vollkommen richtig, aber sowas brauche ich ja gar nicht. Es gibt keine sequenzielle Bearbeitung dieser Art, die es nötig machen würde, dass ich einen Takt brauche, der n-mal schneller ist, als die Daten reinkommen. Ich brauche nur einen etwas schnelleren, um das Fifo abfraqen zu können.
Achtung schrieb: > Weil man üblicherweise FFs setzt, um die mögliche Frequenz hochzusetzen. > Da ich da sparen muss (der FPGA soll ja kleiner werden) habe ich > diesbezüglich weniger Optionen. Man kann ein FPGA zwar schneller takten, wenn man in die Logik FFs einfügt. Die eigentliche Berechnung wird dadurch aber nicht schneller! Es ist nur wie wenn man im Auto einen anderen Gang einlegt: die Geschwindigkeit belibt gleich, nur der Motor läuft schneller oder langsamer. > Schlumpf hat es erfasst und das Konzept von Pipelining habe ich > verstanden. Es gibt hier aber nicht mehr zu pipelinen. Richtig, du musst hier nichts pipelinen. Dass dein Design kleiner wird, dafür musst du multiplexen und die Multiplizierer nacheinander für unterschiedliche Aufgaben verwenden. Du hast ja zuhause auch nicht ein Auto zur Arbeit, eines zum Einkaufen, eines für den Baggersee und eines für die Disco. Sondern du verwendest ein und das selbe Auto nacheinander für alle diese Aufgaben. Und das ist der Trick: die Multiplizierer können mit einer Taktfrequenz von 100MHz rechnen, also 100mal schneller als du es brauchst. Du kannst somit, wenn 99 Multiplizierer einsparen, wenn einer schnell genug umgeschaltet wird. In deinem Design sind die Multiplizierer "blitzartig" fertig und "warten" dann 99% der Zeit auf neue Daten... > Ich brauche nur einen etwas schnelleren, um das Fifo abfraqen zu können. Er nicht schneller sein. Er muss nur genauso schnell sein. Dann brauchst du nicht mal einen Fifo.
Auch wenn ich Probleme damit habe, mir vorzustellen, wie komplex das Design ist, dass man es nur noch mit 1MHz laufen lassen kann (längster logischer Pfad wäre dann ja knapp 1000ns), kannst du natürlich mit der Frequenz runtergehen. Ich würde mal eine "normale" Frequenz vorgeben (z.B. 20MHz) und schauen, was mir die Synthese berichtet. Wenn dann z.B. der kritische Pfad um x ns nicht gehalten werden kann, hast du einen Anhaltspunkt, welches deine maximale Frequenz ist. Aber mal Hand auf´s Herz: um einen Pfad mit 1000ns Latency zu bauen, musst du ca. 1000 CLBs hintereinander schalten. Und dann hast du nur diesen einen Pfad abgedeckt. Wieviele CLBs hast du denn in deinem FPGA? Also wie viel Prozent deiner Ressourcen gehen dann schon für diesen einen Pfad drauf? Und offensichtlich musst du ja noch viele andere Pfade haben, wenn dir die Register ausgehen. Das macht aber auch nur Sinn, wenn diese Register mit Logik untereinander verknüpft sind, wofür dir wieder CLBs drauf gehen. Also LUTs hast du im Überfluss, aber die Register gehen dir aus, richtig?
Der TO könnte ja mal den Auszug des P&R-Reports posten, wo die Ressourcenauslastung aufgeführt ist. Danile
@ Achtung (Gast) >Weil man üblicherweise FFs setzt, um die mögliche Frequenz hochzusetzen. >Da ich da sparen muss (der FPGA soll ja kleiner werden) habe ich >diesbezüglich weniger Optionen. Eben DARUM packt man Logik in eine State Machine und RAMs. Welche Operationen willst du denn ausführen, dass sie soviele Ressourcen benötigen? >Schlumpf hat es erfasst und das Konzept von Pipelining habe ich >verstanden. Es gibt hier aber nicht mehr zu pipelinen. Vielleicht. Dein Wirkliches Problem hast du aber noch nicht mal ansatzweise erklärt, siehe Netiquette. Damit kann man dir auch nicht wirklich helfen. >Vollkommen richtig, aber sowas brauche ich ja gar nicht. Es gibt keine >sequenzielle Bearbeitung dieser Art, die es nötig machen würde, dass ich >einen Takt brauche, der n-mal schneller ist, als die Daten reinkommen. Dann verstehe ich das Problem noch weniger. >Ich brauche nur einen etwas schnelleren, um das Fifo abfraqen zu können. Ja und, dann tu das doch. Aber das alles kann unmöglich größere Logikressourcen benötigen!
@ Lothar Miller (lkmiller) (Moderator) Benutzerseite >Und das ist der Trick: die Multiplizierer können mit einer Taktfrequenz >von 100MHz rechnen, also 100mal schneller als du es brauchst. Du musst IHM doch nicht das Multiplexen erklären!
Nicht doch... ;-)
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.