Forum: FPGA, VHDL & Co. parallel -> seriell: Schieberegister oder Multiplexer?


von Benedikt K. (benedikt)


Lesenswert?

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.

von Jan M. (mueschel)


Lesenswert?

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.

von Fpgakuechle K. (Gast)


Lesenswert?

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.

von Fpgakuechle K. (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Jan M. (mueschel)


Lesenswert?

@ 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.

von Fpgakuechle K. (Gast)


Lesenswert?

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.

von Jan M. (mueschel)


Lesenswert?

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

von Benedikt K. (benedikt)


Lesenswert?

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 ?

von Fpgakuechle K. (Gast)


Lesenswert?

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.

von ralf (Gast)


Lesenswert?

Wenn die Datenquelle ein Ausgangsregister hat kann es oft gleichzeitig 
als Schieberegister verwendet werden.

von FPGA-Mannteufel (Gast)


Lesenswert?

>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.

von Oliver Bründler (Gast)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.