Irgendwo habe ich mal gelesen, dass eines von beiden nicht schön/gut/richtig/ordentlich ist, wenn man es in einem FPGA/CPLD verwendet. Wie macht man es also richtig ? - Ein Schieberegister parallel laden und dann alle Bits rauschieben. - Mit einem Multiplexer die Bits der Reihe nach auswählen und ausgeben.
Ich würde immer mit Multiplexer arbeiten. (Folgende Antworten beziehen sich auf xilinx, andere Chips dürften sich aber ähnlich verhalten) Ein PISO-Schieberegister braucht eine Unmenge an Flipflops - für jedes Eingangssignal ein Fifo, macht bei 8 Bit 4 komplette Slices, die belegt sind. Ein 8-zu-1-Multiplexer braucht dagegen nur ein Slice. Dazu noch eines für den nötigen Counter und das war es. Einzig bei der maximalen Geschwindigkeit könnte die Schieberegister-Variante einen minimalen Vorteil haben.
Jan M. wrote: > Ich würde immer mit Multiplexer arbeiten. (Folgende Antworten beziehen > sich auf xilinx, andere Chips dürften sich aber ähnlich verhalten) > Ein PISO-Schieberegister braucht eine Unmenge an Flipflops - für jedes > Eingangssignal ein Fifo, macht bei 8 Bit 4 komplette Slices, die belegt > sind. > Ein 8-zu-1-Multiplexer braucht dagegen nur ein Slice. Dazu noch eines > für den nötigen Counter und das war es. > > Einzig bei der maximalen Geschwindigkeit könnte die > Schieberegister-Variante einen minimalen Vorteil haben. Nur ein slice für den 3 bit counter? Nicht 1,5? Nur 1 slice für eine 8:1 nicht 2 Slices (+F6Muxer)? Also für eine Spartan3 Architektur komme ich lt. Xilinx Unterlagen auf fast den selben Slice-verbrauch für Shiftreg und MUX. Sollten wir mal testhalber synthetisieren und mappen und die logfiles entscheiden lassen. Bei CPLD mit seinen Makrozellen für hohes FanIn siehts deutlicher aus, da dürfte die Mux-architectur bei weitem "kleiner" sein.
So ich habs mal mit ise 9.2 für spartan3 mit Area-optimierung getsetet (code liegt bei): anzahl Parallel bits|slices Mux variante|slices Shiftreg 8| 4| 4 16| 7| 8 32|12|16 die slices pro componente wurden mit fpga editor bestimmt. Die Muxer Variante ist also auch bei FPGA's kleiner.
@ Fpga Kuechle: Ja, da hast du recht. Mein Gedankengang, ohne ins Datenblatt zu schauen, war: Ein Slice hat zwei LUTs mit je vier Eingängen, also passt ein 8-zu-1-Mux rein - stimmt natürlich nicht, man braucht ja auch noch drei Eingänge zur Auswahl. Und ein zwei Bit Zähler reicht verständlicherweise auch nicht für 8 verschiedene Signale... Aber ich muss ehrlich sagen, ich hätte mit höheren Unterschieden gerechnet.
ich hab nicht im Detail geschaut was die Optimierung daraus macht. Und ich hab noch Xtra FF für den seriellen Ausgang sowie overflow für den counter eingebaut (was nicht unbedingt nötig ist). Ohne das wird die Muxer Variante wohl um 1-2 slices kleiner. Die ISE hat grad ein Problem mit CPLD so daß ich dies nicht checken kann. Ich bin mir aber sicher das beim CPLD die FF-Variante richtig weh tut. Ansosnten könnt ihr gern mit dem Code rumspielen. Es ist noch nicht beantwortet welche Variante schneller ist.
Ich habe die Eingangsflipflops entfernt, wir wollen schließlich nur
diesen parallel-zu-seriell-Part testen, und synthesiert. Es entsteht
genau das erwartete: Einmal eine Kette von FF und einmal Mux, Counter
und ein FF.
Shift Mux
Frequenz (8Bit) 596 MHz 367 MHz
D-FF (8Bit) 8 1 + 3
Slices 4 5
Frequenz (32Bit) 596 MHz 274 MHz
D-FF (32Bit) 32 1 + 5
Slices 19 12
Danke für den Vergleich. Wie sieht es mit Glitches aus ? Die können bei einem Multiplexer doch auftreten, oder ? Wenn man das Signal also ohne FF dahinter ausgibt, sollte man besser die Schieberegister Variante wählen ?
Benedikt K. wrote: > Danke für den Vergleich. > > Wie sieht es mit Glitches aus ? Die können bei einem Multiplexer doch > auftreten, oder ? Ist zuerst die Frage wie glitchfrei du das Select signal des Muxers bekommst. bei dem synchronen Counter sollte das OK sein. Nun ist die Frage nach der Laufzeitunterschied der Signale vom counter zu den LUT's etc des Muxers, da könnte es zu Glitches kleiner 1 ns kommen. > Wenn man das Signal also ohne FF dahinter ausgibt, sollte man besser die > Schieberegister Variante wählen ? Besser ist FF hinter den MUX, der eine Takt Verzögerung sollte nichts ausnachen. Insgesamt ein für mich sehr interessantes Ergebnis, vor Jahren hieß es noch im FPGA FF nehmen wegen den knappen Kombinatorik/Routing Ressourcen. Das sieht heutzutage anders aus.
Wenn die Datenquelle ein Ausgangsregister hat kann es oft gleichzeitig als Schieberegister verwendet werden.
>Besser ist FF hinter den MUX, der eine Takt Verzögerung sollte nichts
ausnachen.
Die Betrachtgung der glitches ist nicht ganz sinning, den wir arbeiten
in einem synchronen Schaltwerk. Damit muss unterstellt werden, daß die
feed-Signale des MUX stabil sind, damit sind es auch die Ausgänge im
Bezug auf die Taktflanke. Selige muss natürlich spät genug kommen und
genau das sagt ja die fmax aus, de ihr oben angegeben habt.
Hat man KEINEN stabilen Eingang, dann müsste auch bei de FF-Kette
einsynchronisiert werden, was FFs kostet.
Es gibt aber noch einen Unterschied zwischen den beiden Varianten: Mit
nur einem clock Pause je AusleseZyklus kann man bei der MUX Variante von
einem FIFO sprechen, mit dem man Clock-Domains überwinden kann: Parallel
Einschreiben mit clock 1, einen Takte pause in der Zieldomain, dann
erste beginnen auszulesen.
Ausserdem ist es ein Unterschied hinsichtlich des Energieverbrauches: Da
ist die FF-Kette schlechter.
Nur den Parallel-Seriel Teil allein anzuschauen macht so oder so wenig Sinn... Erstens müssen die zu Serialisierenden Daten irgendwo gespeichert werden, damit sie sich während dem Serialisieren nicht ändern, was zu falschen Übertragungen führen würde --> Es werden wieder FFs für das Speichern benötigt. Zusätzlich muss das ding auch noch irgendwie gesteuert werden. Man muss also auch erkennen, wann alle Bits übertragen wurden und dann die Übertragung einstellen bzw. ein ready-Signal nach aussen generieren. Dies ist bei einem Schieberegister einfacher zu realisieren.
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.