LTspice - 3B2T Leitungscodierung

[Simon K. (simko299)]

Hallo zusammen,

ich möchte in LTspice einen 3B2T-Leitungscodierer umsetzen.
Hierbei wird ein binärer Bitstream (Zustände: 0 / 1) in einen ternären 
Symbolstream (Zustände: -1  0  +1) umgewandelt. Ein Block aus 3 
binären Bits entspricht dann einem Block aus 2 ternären Symbolen. Die 
Zuordnung erfolgt über eine Tabelle (siehe Anhang). Ein Beispiel ist 
ebenfalls angehängt.

In LTspice möchte ich nun beispielsweise eine beliebige Bitfolge z. B. 
als Parameter vorgeben und daraus dann eine 3B2T-Umwandlung machen.

Für eine fest vorgegebene Bitfolge wäre das natürlich über eine 
PWL-Source realisierbar. Das Problem ist jedoch, dass die Bitfolge 
variabel sein soll. Ich müsste also jedes Mal die PWL-Source anpassen, 
wenn ich eine neue Bitfolge simulieren will.
Zusätzlich möchte ich die Flankenzeiten als auch die Amplituden (-1 / 
+1) des ternären Symbolstreams per Parameter variabel einstellbar 
machen.

Gibt es beispielsweise die Möglichkeit, irgendwie die Zuordnungstabelle 
in LTspice anzugeben? Oder hat jemand eine Idee, wie man das sonst noch 
in LTspice umsetzen kann?

Danke im Voraus!

Grüße
Simon

Quelle der Bilder: http://www.ti.com/lit/wp/szzy009/szzy009.pdf

[Marten Morten (Gast)]

Simon K. schrieb:
> Das Problem ist jedoch, dass die Bitfolge
> variabel sein soll. Ich müsste also jedes Mal die PWL-Source anpassen,
> wenn ich eine neue Bitfolge simulieren will.

Ja, irgendwas musst du machen, die Bitfolge wird sich nicht alleine 
variieren. Warum zur Variation nicht die PWL-Werte anpassen?

> Zusätzlich möchte ich die Flankenzeiten

Alle A-Elemente lassen sich mit Anstiegs und Abfallzeit oder einer 
Zeitkonstante parametrisieren. Das ist bequemer als Zwischenwerte in die 
PWL-Daten einfügen.

D.h. Ausgang der PWL-Quelle auf ein A-Element wie einen BUF(fer) oder 
INV(erter) geben und die Zeiten des Elements parametrisieren.

> als auch die Amplituden (-1 /
> +1) des ternären Symbolstreams per Parameter variabel einstellbar
> machen.

PWL VALUE_SCALE_FACTOR=1.5 ( ... )

Oder, wenn du schon ein A-Element dabei hast, Vhigh, Vlow und (wichtig) 
Ref des A-Elements parametrisieren.

[Helmut S. (helmuts)]

Man könnte da mit einer Mischung aus Bv-Tabellen und Flipflops etwas 
machen.
Bv-Quelle:
V = table(V(n),0,1, 1,1, 2,0, 3,1, 4,1, ......)

Jetzt müsste man immer 3 bits selektieren und mit weiteren Bv-Quellen 
umkodieren. Das Ergebnis dann mit Flipflops abtasten und damit das 
3-Level Signal generieren. Die Anstiegszeit müsste man mit einem 
passenden Tiefpassfilter einstellen.

Wäre es da nicht einfacher mit irgend einem Programm(Python) einen 
PWL-File zu machen. Den kann man direkt mit einer V-Quelle einlesen. Die 
Amplitude kann man ja ganz leicht in LTspice anpassen. Auch die 
Anstiegszeit könnte man in LTspice machen (Tiefpassfilter).

[Simon K. (simko299)]

Danke für eure Hinweise!

Bisher habe ich es auch über PWL gemacht und Parameter für t_rise_fall, 
v_high, v_low, delay mit reingepackt. Dies wird aber schnell extrem 
unübersichtlich und fehleranfällig beim ändern, wenn man eine 
entsprechend lange Bitfolge hat. Mit der Variante V=Table(...) wird es 
ohne Parameter schon ziemlich übersichtlich, jedoch fehlen dann noch die 
Parameter. Gut, mit einem nachgeschalteten BUF könnte ich trise/tfall 
und vhigh/vlow anpassen.
Aber bei der Umcodierung von 3-Bit-Blöcken in 2-Bit-Blöcke komme ich 
bisher nicht weiter.

Helmut, wie kann ich 3 Bits aus einem Bitstream "selektieren"?
Hast du da vielleicht ein Beispiel?

Ja, ein Programm, dass die PWL generiert, würde es selbstverständlich 
einfacher machen. Ich würde es jedoch auch gerne mittels Spice 
versuchen, falls möglich.

Gruß
Simon

Anbei die Bitfolge aus dem Beispiel. Aber bei der Codierung von 3B auf 
2T komme ich bisher nicht weiter.

[Abdul K. (ehydra)]

Für Bitbreitenoperationen ist LTspice nicht gut geeignet. Vielleicht 
wird das mal besser in der Zukunft.

Ich würde das Ausgangssignal aus zwei A-device Buffern generieren, die 
fast gleich parametrisiert sind. Die zwei Signale dann einfach addieren.


Mit dem Modul Sample&Hold kann man auch vieles tricksen. Einfach 
probieren.

[Abdul K. (ehydra)]

Hier mal schnell zusammengefrickeltes Beispiel für 2Bit-Codierung. So 
prinzipiell.
Schau dir auch mal an wie ich den Takt durch 3 realisierte und die 
Verzögerung sowie Addierung und die Slew-rate Verstellung.

Der Rest ist eigentlich nur noch eine Fleißaufgabe. Bin aber zu müde. 
Ich vermute es gibt einen Trick bei der Zuordnung der Leitungspegel. 
Google mal, die Chip-Hersteller wollen es auch möglichst einfach ;-)


Was soll das denn werden? Viel praktischen Nährwert hat das Projekt in 
LTspice nicht.

[Helmut S. (helmuts)]

Hallo Simon,
anbei der 3B2B Coder mit Tabellen.

Es wird dreimal die gleiche Tabelle benötigt, damit man immer drei Bits 
parallel holen kann.

Aus den drei Bits und dem TATB-Bit wird dann ein 4Bit-Zeiger gebildet.

Mit dem wird dann auf die 3B2B-Tabelle zweimal hintereinander 
zugegriffen.

Da der Simulator hier manchmal bei den Übergängen einen Glitch erzeugt, 
taste ich das Ergebnis mit einem S/H ab.

Zum Schluss kommt noch ein 3-poliges Bessel-Filter für die 
Bandbreite/Anstiegszeit.

[Abdul K. (ehydra)]

Nicht schlecht Helmut.

Hier meine Lösung:
Oberhalb des Doppelstrichs mit Tabellen, unten drunter mit Logik.

Ganz oben das Eingangsschieberegister. Die drei parallelen Bits werden 
zur Zeit der Mitte des dritten Bits gesampelt und zweimal als Index für 
die beiden Tabellen benutzt. Am Ausgang sitzt dann nur noch ein 
Multiplexer, der von 33MHz getaktet wird.

Bei dieser Lösung ist alles 3 Bits verschoben durch das Shiftregister.


Bei der unteren Variante habe ich die Tabellen in eine entsprechende 
Logik konvertiert. Da dann die drei Bits zu passender Zeit einzeln 
gebraucht werden, gibt es auch drei Sampler anstatt einem.


Zumindest ich finde die Tabellenlösung übersichtlicher. Alles unterhalb 
des Doppelstrichs kann also gelöscht werden.


Am Ausgang kann natürlich noch ein Filter sitzen bzw. die slew-rate 
begrenzt werden. Für die Begrenzung per slew-rate würde ich einen 
parametrisierbaren Universal-OpAmp der Lib benutzen, der intern auf 
einem OTA mit angebaren Limits basiert.
Wegen der Multilevel-Logik ist es leider nicht möglich, die A-device 
slew-rate Option zu benutzen. LTspice unterstützt nur 2-level Logik.


Übrigens enthält die LTspice Lib neuerdings Symbole für diverse 
OTA-Varianten. Das war doch früher streng geheim. Hat die einer schon 
benutzt?

[Simon K. (simko299)]

Abdul K. schrieb:
> Was soll das denn werden? Viel praktischen Nährwert hat das Projekt in
> LTspice nicht.

Ich möchte einen Ethernet-PHY bzw. auch die Übertragungsstrecke 
simulieren. Hierzu gehört natürlich dann auch die Leitungscodierung, 
welche ich bisher über PWL-Quellen mit Parametern realisiert hatte. 
Gefallen hat mir dabei nicht, dass die Codierung von 3B auf 2T nicht in 
LTspice umgesetzt war.
Mir ist klar, dass für solche Codierungs-Aufgaben Matlab oder ähnliches 
viel besser geeignet ist. Dennoch hat es mich interessiert, wie man es 
in LTspice umsetzen könnte.

An dieser Stelle vielen Dank, Helmut und Abdul, für eure Lösungen! So 
schnell wäre ich da erstmal nicht drauf gekommen.
Bin jetzt Schritt für Schritt die Lösungen durchgegangen, um alles 
nachzuvollziehen. Hab dadurch vieles hinzugelernt - es hatte also einen 
großen Lerneffekt!

Gruß
Simon

[Abdul K. (ehydra)]

Das ist schön.

Ich würde die 3.Bits-Gruppen  als 0..7 in ein externes File setzen. 
Damit würde die Simulation auch einfacher und schneller. Der Sampler 
würde z.B. komplett wegfallen.
Man kann auch den wav-Import benutzen. Oder gar die drei Bits in drei 
Audiokanäle getrennt schreiben.
Der Anfang des wav-Files ist eigentlich nur ein konstanter Block, danach 
kommen die Daten.


So "schnell" ging das bei mir auch nicht ;-) Ich habe aber schon öfters 
so Sachen simuliert, also digitale Empfänger, Modulatoren usw.

Auch Helmut hat sichtlich gekämpft. Und das heißt was beim LTspice-Gott.


Ne Ausgangsstufe habe ich auch noch gebastelt. Hat mich interessiert ob 
man das doch noch halbwegs elegant hinkriegt.

[Marten Morten (Gast)]

Simon K. schrieb:
> An dieser Stelle vielen Dank, Helmut und Abdul, für eure Lösungen!

Danke dass du meine Hinweise ignoriert hast.

[Abdul K. (ehydra)]

Wenn es dir auf das richtige Spektrum ankommt, dann ist die Codierung 
allerdings falsch laut dem hier:

https://de.wikipedia.org/wiki/MLT-3-Code

Denn die sagen es wäre MLT3 codiert, also Sprünge sind immer nur um 
einen Spannungsstep, niemals aber mehrere auf einmal.


Bisserl chaotisch dieses Normenwirrwarr.


Hast du das Spektrum mal real aufgenommen?

[Simon K. (simko299)]

Marten Morten schrieb:
> Simon K. schrieb:
>> An dieser Stelle vielen Dank, Helmut und Abdul, für eure Lösungen!
>
> Danke dass du meine Hinweise ignoriert hast.

Hab mich doch im zweiten Beitrag für die Hinweise bedankt. Das hat sich 
auch auf deinen Beitrag bezogen!
Und hier war es jetzt nochmal speziell auf die Lösungen bezogen, wo 
nochmal einiges an Zeit reingesteckt wurde.

[Simon K. (simko299)]

Abdul K. schrieb:
> Ich würde die 3.Bits-Gruppen  als 0..7 in ein externes File setzen.
> Damit würde die Simulation auch einfacher und schneller. Der Sampler
> würde z.B. komplett wegfallen.
> Man kann auch den wav-Import benutzen. Oder gar die drei Bits in drei
> Audiokanäle getrennt schreiben.
> Der Anfang des wav-Files ist eigentlich nur ein konstanter Block, danach
> kommen die Daten.

Ok, da muss ich mich dann nochmal mit befassen, mit wav hab ich in 
LTspice noch nichts gemacht.

> So "schnell" ging das bei mir auch nicht ;-) Ich habe aber schon öfters
> so Sachen simuliert, also digitale Empfänger, Modulatoren usw.
>
> Auch Helmut hat sichtlich gekämpft. Und das heißt was beim LTspice-Gott.

Das beruhigt ein bisschen. ;-) Hab schon eine Weile gebraucht, um alles 
nachzuvollziehen.

[Simon K. (simko299)]

Abdul K. schrieb:
> Wenn es dir auf das richtige Spektrum ankommt, dann ist die
> Codierung
> allerdings falsch laut dem hier:
>
> https://de.wikipedia.org/wiki/MLT-3-Code
>
> Denn die sagen es wäre MLT3 codiert, also Sprünge sind immer nur um
> einen Spannungsstep, niemals aber mehrere auf einmal.

Das ist richtig, wenn man von den gewöhnlichen 100BASE-TX ausgeht.
Zum Einsatz kommt bei mir zusätzlich 100BASE-T1, wo dann PAM3 verwendet 
wird. MLT3 muss ich dann auch noch simulieren. :-)

> Hast du das Spektrum mal real aufgenommen?

Noch nicht, hab noch keine fertige Schaltung vor mir liegen.

[Abdul K. (ehydra)]

Zumindest bei BroadR is die TA-Tabelle auch noch von einem Extra-Bit vom 
Scrambler beeinflußt.

[Simon K. (simko299)]

Abdul K. schrieb:
> Zumindest bei BroadR is die TA-Tabelle auch noch von einem Extra-Bit vom
> Scrambler beeinflußt.

Ja, stimmt, das ganze ist physikalisch etwas komplexer als nur PAM3. Es 
wird auch noch zwischen Idle Symbol Mapping und Data Symbol Mapping 
unterschieden, Training Mode / Send Mode, Data Scrambler / Side-Stream 
Scrambler / Power Density Scrambler usw.. Aber das möchte sicherlich 
keiner alles in LTspice umsetzen. ;-)

[Helmut S. (helmuts)]

Wenn man nur an dem Augendiagramm interssiert ist, dann reicht es mit 
einer random-Funktion die Übergange zu erzeugen. Im Anhang ist ein 
Beispiel. Es gibt dort keinen direkten -1+1 bzw. +1-1 Übergang. Das 
untere Augendiagramm ist verzögert wegen der Durchlaufzeit durch das 
Filter.

[Abdul K. (ehydra)]

Bisserl abartig diese Komplexität. Broadcom will offensichtlich den 
Markt für sich.

[Simon K. (simko299)]

Hier steht einiges dazu: 
http://www.ieee802.org/3/1TPCESG/public/BroadR_Reach_Automotive_Spec_V3.0.pdf

[Abdul K. (ehydra)]

Helmut, das geht eleganter.

[Helmut S. (helmuts)]

Abdul K. schrieb:
> Helmut, das geht eleganter.

Ich kannte buf() in B-Quellen nicht oder ich habe es vergessen.

Für das Augendiagramm darf bei deiner Lösung .tran erst ab der 3. 
Periode die Daten speichern. Das ist aber kein wirkliches Problem für 
das erstellen des Augendiagramms.

.tran 0 {400/F0} 16n 10p



Vorteil meiner Lösung:
In meiner Lösung kann man die Anstiegszeit einstellen.

[Abdul K. (ehydra)]

Ist mir nicht aufgefallen. Das Augendiagramm benutze ich einfach zu 
selten.

Natürlich kann man buf(x) auch in die Quellen schreiben. Oder durch 
(a>=0.5) ersetzen.


Eine Frage:
Die A-devices bieten ja die Definition der Slew-rate an. Wie ist das 
realisiert? Ich habe mit dem OTA experimentiert, es aber nicht 
hinbekommen. Eigentlich dachte ich, diese Funktionalität ist bereits im 
OTA drin.

Meine letzte Vermutung ist ein zusätzlicher Spannungbuffer am Ausgang, 
dem eine schaltbare Stromquelle mit einem Kondi nach Masse vorgeschaltet 
ist. Aber das klingt umständlich und verdammt nach Konvergenzproblemen.

Die Analyse der sub der universal OpAmps hat mich auch nicht weiter 
gebracht, da da GBW und Cout mit einwirkt.

Eine Idee?

[Helmut S. (helmuts)]

Abdul K. schrieb:
> Ist mir nicht aufgefallen. Das Augendiagramm benutze ich einfach zu
> selten.
>
> Natürlich kann man buf(x) auch in die Quellen schreiben. Oder durch
> (a>=0.5) ersetzen.
>
>
> Eine Frage:
> Die A-devices bieten ja die Definition der Slew-rate an. Wie ist das
> realisiert? Ich habe mit dem OTA experimentiert, es aber nicht
> hinbekommen. Eigentlich dachte ich, diese Funktionalität ist bereits im
> OTA drin.
>
> Meine letzte Vermutung ist ein zusätzlicher Spannungbuffer am Ausgang,
> dem eine schaltbare Stromquelle mit einem Kondi nach Masse vorgeschaltet
> ist. Aber das klingt umständlich und verdammt nach Konvergenzproblemen.
>
> Die Analyse der sub der universal OpAmps hat mich auch nicht weiter
> gebracht, da da GBW und Cout mit einwirkt.
>
> Eine Idee?

OTA
Vielleicht mit Rout und Cout die Grenzfrequenz der Leerlaufverstärkung 
einstellen und die Slew-rate über Iout einstellen.

UniversalOpamp2
Da kann man direkt die Slewrate einstellen. Dazu GBW sehr hoch 
einstellen.

[Abdul K. (ehydra)]

Ja, nur haben die A-devices mir keine bekannte Grenzfrequenz. Muß also 
anders realisiert sein. Die Ausgangsspannung per ddt() in eine 
Regelschleife bringt die Simulation zum Stöcken.

Interessanterweise ist deren maximaler Ausgangsstrom ohne Optionen genau 
30A.

[Helmut S. (helmuts)]

Abdul K. schrieb:
> Ja, nur haben die A-devices mir keine bekannte Grenzfrequenz. Muß also
> anders realisiert sein. Die Ausgangsspannung per ddt() in eine
> Regelschleife bringt die Simulation zum Stöcken.
>
> Interessanterweise ist deren maximaler Ausgangsstrom ohne Optionen genau
> 30A.

OTA hat Rout und Cout. Damit lässt sich die Grenfrequenz der 
Leerlaufverstärkzng einstellen. Die liegt bei den meisten Opamps im 
Bereich 1Hz bis 100Hz.

[Abdul K. (ehydra)]

Die Slew-rate ist aber lastunabhängig, damit ist dein Vorschlag nicht 
die Lösung.

[Helmut S. (helmuts)]

Abdul K. schrieb:
> Die Slew-rate ist aber lastunabhängig, damit ist dein Vorschlag nicht
> die Lösung.

Dahinter kommt natürlich ein E-Quelle oder eine G-Quelle plus Serien- 
bzw. Parallel-Widerstand.

[Abdul K. (ehydra)]

Ganz so einfach ist es dann auch nicht, denn dann würde es keine 
Begrenzung auf 30A geben.

Ich denke das macht alles der OTA mit irgendwelchem mathematischen 
Trick.