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
:
Bearbeitet durch User
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.
1 | PWL VALUE_SCALE_FACTOR=1.5 ( ... ) |
Oder, wenn du schon ein A-Element dabei hast, Vhigh, Vlow und (wichtig) Ref des A-Elements parametrisieren.
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).
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Beitrag #5926993 wurde vom Autor gelöscht.
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.
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.
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.
:
Bearbeitet durch User
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?
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
:
Bearbeitet durch User
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.
Simon K. schrieb: > An dieser Stelle vielen Dank, Helmut und Abdul, für eure Lösungen! Danke dass du meine Hinweise ignoriert hast.
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?
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.
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.
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.
Zumindest bei BroadR is die TA-Tabelle auch noch von einem Extra-Bit vom Scrambler beeinflußt.
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. ;-)
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.
:
Bearbeitet durch User
Bisserl abartig diese Komplexität. Broadcom will offensichtlich den Markt für sich.
Hier steht einiges dazu: http://www.ieee802.org/3/1TPCESG/public/BroadR_Reach_Automotive_Spec_V3.0.pdf
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.
:
Bearbeitet durch User
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?
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.
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.
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.
:
Bearbeitet durch User
Die Slew-rate ist aber lastunabhängig, damit ist dein Vorschlag nicht die Lösung.
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.