www.mikrocontroller.net

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


Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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.
Autor: Jan M. (mueschel)
Datum:

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.
Autor: Fpga Kuechle (fpgakuechle)
Datum:

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.
Autor: Fpga Kuechle (fpgakuechle)
Datum:
Angehängte Dateien:

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.
Autor: Jan M. (mueschel)
Datum:

@ 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.
Autor: Fpga Kuechle (fpgakuechle)
Datum:

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.
Autor: Jan M. (mueschel)
Datum:

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
Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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 ?
Autor: Fpga Kuechle (fpgakuechle)
Datum:

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.
Autor: ralf (Gast)
Datum:

Wenn die Datenquelle ein Ausgangsregister hat kann es oft gleichzeitig
als Schieberegister verwendet werden.
Autor: FPGA-Mannteufel (Gast)
Datum:

>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.
Autor: Oliver Bründler (Gast)
Datum:

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel




Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder GIF-Format hochladen.
Siehe Bildformate
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken erkennst du die Nutzungsbedingungen an.

webmaster@mikrocontroller.netImpressumNutzungsbedingungenWerbung auf Mikrocontroller.net