gelöst OPV, Funktionsgenerator und Konsorte

Glückwunsch !
Nur ne kleine Rückfrage: +/- 7,5V mit GND. R6 ist 375, R7 = 750 Ohm. Hat sich dadurch der GND verschoben ? Wenn ja, wären es nicht genau +/- 7,5V, bezogen auf GND.
Wahrscheinlich sind diese +/-7,5V stabil. Dann sind die Werte R6 und R7 wenig relevant.

VG
Udo
 
Hallo @Udo

sagen wir mal so, denn 7,5 + 7,5 = 15, und das sind die 15 V, die über ein Schaltnetzteil aus der Steckdose kommen. Die Stabilität ist mit < 1% angegeben. Jetzt baue ich mir daraus einen künstlichen GND, der bei symmetrischer Belastung schon von sich aus in der Mitte liegt. ansonsten soll der OPV nachhelfen und den einen oder den anderen Transistor aufmachen. Ich hab rein aus Gründen des Effektes mal unterschiedlich Werte eingetragen, als ich mal die Ausgleichströme testen wollte, wenn die Belastung unsymmetrisch ist.

VG
 
Ich hab' noch ein wenig weiter experimentiert. Mein Ziel ist es, ein DAC-Projekt mit dem Raspberry Pi Pico zu entwickeln. Das Herzstück ist natürlich der DAC daselbst. Die DAC-Widerstands-Logik hatte ich schon länger auf einem Blatt zur Simulation errichtet, das ist eigentlich keine Kunst sondern nur eine reine Fleißarbeit.

Wenn man jetzt so einen DAC mit 8 Bit Auflösung macht, wird man noch nicht allzu sehr gefordert. Über einen Internet-Kontakt bin zu einem Schaltungs-Entwurf für einen Raspberry Pi Pico gekommen, der eine Auflösung von 22 Bit ermöglicht. Weil mich das Geschehen interessiert und ich noch einen Retro-Röhrenverstärker bei etwa 70% (Halb-)Fertigstellung hier liegen habe, war die Aussicht auf einen Funktionsgenerator, den man mit einem solchen Mikrocontroller realisieren kann, schon sehr verlockend.
01 DAC vorläufer.png
Ich hab' dann mal angefangen die DAC-Widerstands-Logik für die Simulation herzurichten. Das war ja noch relativ harmlos. Die Widerstandswerte lassen sich mit diesen zwei Parameter gemeinsam bestimmen:
.param RT1 100k
.param RT2 50k
Schwieriger war schon die Aufgabe, das Gesamtwerk dazu zu bringen, dass alle Bitzweige sich nach einem gemeinsamen Wert ausrichten, um damit die Amplitude bestimmen zu können. Jeder T-Zweig der Widerstandslogik ist an einen GPIO des Raspberry Pi Picos angeschlossen. Folglich kennt dieser Anschlusspunkt nur zwei Zustände: Bei logisch LOW den Pegel 0 V bzw. bei logisch HIGH den Pegel 3,3 V. Es lag also nahe zu diesem Zweck und Behufe solche Spannungsquellen des Typs Arbitrary behavioral voltage source (wird mit bv ausgewählt) mit der Aufgabe zu betrauen.
02 BV-Spannungsquelle.png
V=f() steht in der Mathematik für eine Lösung, die über eine Funktion erfolgt. Die hab' ich dann auch hier angewendet:
.func BVal(n) = floor(Amp / (2**n)) % 2
  • BVal, der Funktionsname entsteht aus der Kategorie-Kennung B für diese Art der Spannungsquellen und Val als Abkürzung für Value.
  • n, ist ein Übergabeparameter für die Bitposition (0, 1, 2...), die ausgewertet werden soll.
  • floor, der Begriff stammt aus der Mathematik und Informatik und bezieht sich auf die Funktion, die den größten ganzzahligen Wert zurückgibt, der kleiner oder gleich einer gegebenen Zahl ist. Die Verwendung von floor ist hier angebracht, weil LTspice intern mit Gleitkommazahlen rechnet.
  • Amp, ich hatte keine bessere Abkürzung gefunden, nach dem Pfeife dieses Parameters sollen sich alle 22 Bitauswertungen richten. Über .param Amp 2097152 konnte ich z.B. einen Wert vorgeben, um die DAC-Widerstands-Logik zu testen und zu erfahren, was am Ende herauskommt.
  • 2**n, bedeutet nichts anderes 2 hoch n und berechnet den Dezimalwert, der durch diese Bitstelle repräsentiert wird, wenn das Bit logisch HIGH ist.
  • % ist der in LTspice nicht dokumentierte Modulo-Operator, der viele Sorgen bereitet hat.
Soweit die Funktion. Am Einsatzort wird die Funktion noch mit einer if-then-else-Anweisung verknüpft, if steht da noch, then und else muss sich jeder denken. Das Ergebnis der Funktion ist entweder 0 oder größer 0. Bei 0 bleibt es auch bei 0, bei >0 wird der Wert des Parameters VHigh, in dem Falle 3,3 V ausgegeben.
V={if(BVal(0)>0, VHigh, 0)}
.param VHigh 3.3
Also, mit dieser Schaltung könnte man schon mal was simulieren, aber es war noch nicht zufriedenstellend. Der Parameter Amp ließ sich trotz guten Zuredens einfach nicht überreden, einer anderen Funktion zu folgen. Denn das wäre ein Nahziel gewesen, um später die Amplitude und Frequenz vorzugeben, um so z.B. eine Sinuskurve zu generieren.

Es gibt noch ein paar mehr Fallstricke in LTspice, ich glaub', ich hab' einige davon in diesem Zusammenhang kennen gelernt.
03 subckt.png
Auf der Suche nach einer Umgehung der großzügig ausgelegten Fallstricke bin ich mal wieder auf die Idee gekommen, einen Baustein zu kreieren. Aber dieses Mal nicht auf dem klassischen Wege, sondern direkt durch Eingabe in den Texteditor.
B0 b0 0V V={if(int(V(In)/2**0) != int(V(In)/2**1)*2, V(VL), 0)}
  • B0, ein Gerät (Device), in dem Falle ein Arbitrary behavioral voltage source, erkennbar an dem Kennbuchstaben der Kategorie.
  • b0, der Anschlusspin mit dem das Gerät die Verbindung zur Außenwelt aufrecht erhält und so die Spannung an den T-Zweig des DAC liefern soll.
  • 0V, der zweite Pol des Gerätes und gleichzeitig ein ganz wichtiger, denn der muss nach "draußen" geführt werden, weil es sonst keinen Potentialbezug gibt.
  • V=, hier wird die Funktion definiert, die dafür sorgt, dass der Anschluss b0 auch mit einem Wert versorgt wird.
Bleibt noch die Funktion für b0 zu erläutern:
V={if(int(V(In)/2**0) != int(V(In)/2**1)*2, V(VL), 0)}
Wenn die Prüfbedingung wahr ist, dann wird V auf den Wert gesetzt, der am Baustein-Eingang VL verfügbar ist, sonst 0.
Zugegeben, das ist ein bisschen tricky, aber mir scheint es eine wirksame Art zu sein, die nur in seltenen Fällen bei LTspice verfügbare Modulo-Operation wirkungsvoll zu umgehen.

Die Zeilen für die Geräte B1..B7 folgen dem gleichen Muster.
Die Zeile B8 ist wieder eine Besondere:
B8 Cc 0V V={int(V(In)/256)}
  • B8, gleiches Gerät wie bei B0
  • Cc, ähnlich wie bei b0, weil gleiche Funktion, aber auf einer anderen Berechnung beruhend.
  • 0V, hatten wir schon mal, wie oben.
  • V=, dieses Mal eine simple Division durch 256. Das wird dafür gemacht, weil der Baustein kaskadierbar ist. Da Cc über das Funktionsergebnis bei V= versorgt wird, kann so der nächste Baustein bei In mit dem für den Gebrauch korrigierten Wert versorgt werden. Der Baustein BIDEC8C dekodiert ausschließlich Werte von 0..255, daher werden die Werte für jeden kaskadierten Baustein entsprechend herunter geteilt.
04 DAC  endgültig.png
Das ist nun der erfolgreiche Einsatz des Bausteins. Kaskadiert in Serie um die Auflösung von 22 Bit abzudecken. Also, mir gefällt die Sinuskurve, die hier zur Demonstration des DACs mit dieser echten Auflösung in dem Plot produziert wurde. Zumindest das Simulationsergebnis belegt eindeutig die richtige Dimensionierung.

VG
 
Wow, super Arbeit !!

Hast Du noch ein .asc-file mit den kreierten Bausteinen anzubieten ? Kannst ja Deinen Namen als Erfinder hinterlegen.

VG
 
Wow, super Arbeit !!

Hast Du noch ein .asc-file mit den kreierten Bausteinen anzubieten ? Kannst ja Deinen Namen als Erfinder hinterlegen.

VG
Moin Udo,

ich bin ja noch nicht fertig. Gerade entwickle ich den Verstärker- und Filter-Part zu dem Gesamtwerk. Dann kommt das Gesamtwerk als ZIP.

VG
 
@Udo
Hallo an alle,

Ich hab in den letzten Tagen sehr mit den Überlegungen zu kämpfen gehabt, ob die Realisierung eines Funktionsgenerators mittels eines Mikrocontrollers überhaupt mit einem brauchbaren Ergebnis endet. Einen Mikrocontroller einzusetzen hat schließlich was faszinierendes und suggeriert letztendlich einen Eindruck der einfachen Umsetzbarkeit. Doch die Tücke leigt im Detail. Geschockt habe ich wahrgenommen, dass bei einer Auflösung von 22 Bit das Spannungsrauschen die kleinste Schrittweite des DAC schon zunichte machen kann.

In Bezug auf die Eingangsspannungsrauschdichte habe ich eine neues Modell entwickelt, um die Steuerung eines DAC mittels eines Raspberry Pi Pico von einem Nachteil zu befreien, der bisher nur durch zusätzliche Schaltungsmaßnahmen zu umgehen war. Bekanntlich kann der Pico nur Signale erzeugen, die mit seinem System verbunden sind. Wird der GND des Pico mit dem GND des übergeordneten Systems verbunden, dann ist die Herbeiführung der Signalsymmetrie nur durch das Hinzufügen mindestens einer weiteren OP-Stufe zu lösen. Hinzu kommt noch der direkte Einfluss des Pico auf den DAC, da dessen Systemspannung direkten Einfluss auf die Spannungskette des R2R-Netzwerkes hat.
Bildschirmfoto 2024-07-24 um 12.14.08.png Bildschirmfoto 2024-07-24 um 12.14.19.png
Ich schlage vor, eine duale Spannungsversorgung höchster Güte zu errichten, die ausschließlich dazu dient, die OPV der Verstärker- und Filterstufen zu bedienen. Der GND des Pico wird über eine Referenz etwa 1,65 V unterhalb der Systemmasse der dualen Spannungsversorgung gelegt. Da zur Zeit nicht genau auszumachen ist, ob der Signalpegel des Pico genau die Grenzen 0V und 3,3 V bedient, sollte eine Nullpunktkorrektur berücksichtigt werden. Mit dem Pegel des Pico sollen nicht wie bisher die T-Zweige des R2R-Netzwerkes bedient werden, sondern werden dem invertierenden Eingang eines OPV vom Typ AD8665 von Analog Devices zu geführt. Der AD8665 ist auch als Quad-Version erhältlich, was das Schaltungsdesign wesentlich erleichtern dürfte. Der AD8665 beteiligt sich mit 8 nV/√Hz bei 10 kHz maximal mit etwa 1,13 µV am Signalrauschen. Da der AD8665 ein ausgesprochener Rail-2-Rail-Typ ist, habe ich beschlossen, ihn auch mit der typischen Maximalspannung (nicht die absolute Maximalspannung) zu betreiben, was bewirkt, das am DAC-Ausgang eine Amplitude von knapp 16 Vss zur Verfügung gestellt werden kann. Ich glaube, das ist die beste Idee überhaupt.
 
Hallo Batucada,

falls ich noch in Sachen Spannungsversorgung mit einsteigen soll, lass mich es wissen, sobald Du mehr Details zu den Pegeln und dem Strombedarf hast.

Ansonsten hast Du das Problem gelöst.

Alles Gute
Udo
 
@Udo

Hallo Udo,
vielen Dank für dein Angebot, ich werde ggf. darauf zurückkommen.
Bild Schaltung.png
Bild Plot bei 10 Hz.pngBild Plot bei 10 kHz.png
Ich mach's mal kurz. Im Augenblick bin ich etwas ratlos. Hab' ich jetzt eine Hürde genommen, deutet sich schon die nächste an. Wobei ich aber nicht weiß, ob sie im LTpice selbst begründet ist, oder ob es tatsächlich ein Fingerzeig ist, der in der digtialen Umsetzung liegt. Ich habe zwei Plots produziert einen bei 19 Hz und einen bei 10 kHz.

Generell: fuwe ist der Zahlenmäßige Funktionswert, der im BIDEC8C in einzelne Bits zerlegt wird.

Der Plot bei 10 Hz zeigt einige Glitches, die mich beunruhigen sollten, wenn sie tatsächlich aus dem DAC heraus begründet sind. Anders als beim Gray-Code, wo sich immer nur eine Stelle ändert, gibt es selbst bei 8 Bit genügend Stellen, wo 3 oder 4 Bits zur gleichen Zeit umkippen sollten, deren Auswirkung auf die Umsetzung mittels der OPV, die daran beteiligt sind, wenn sie dann von einer Schiene zur anderen schwingen, könnte auf ein zeitliches Problem hindeuten. Nun ist das hier eine Simulation, in wie weit diese deckungsgleich mit der Wirklichkeit ist?

Den zweiten Plot bei 10 kHz werte ich als LTspice-Fehlfunktion. Ich weiß aber nicht, wie ich das beheben kann. Und das ärgert mich.

VG
 

Anhänge

  • DAC-Test.zip
    4,1 KB · Aufrufe: 1
Hallo Batucada,

mich hat die Verwendung der OPs als switch etwas gestört und auch vermutet, dass die Glitches mit den AD8665 OP's zu tun haben. Nur probehalber habe ich mal aus der Lib...\Digital\diffschmtbuf.asy den Schmitt-Trigger geladen und die AD8665 OP's durch diesen Schmitt-Trigger ersetzt, mit Vlow=-8V und Vhigh=8V.
Die V(out) ist damit sehr sauber.
File hänge ich mal an.

VG
 

Anhänge

  • DAC-Test2_Versuch.asc
    6,8 KB · Aufrufe: 2
  • DAC-Test2_Versuch.plt
    2 KB · Aufrufe: 0
Moin @Udo ,

mich hat die Verwendung der OPs als switch etwas gestört und auch vermutet, dass die Glitches mit den AD8665 OP's zu tun haben.
du bist exakt auf dem Wege, das latente Problem zu erkennen, aber nur fast. Die Idee mit dem Schmitt-Triger ist zwar gut für die Simulation, aber nicht gut für die reale Umsetzung.

Meine Erkenntnis:
Unter dem Beleg dessen, dass es nur im idealen Zustand zum gleichzeitigen Umschalten entsprechender Bitsstellen kommt, ist der Amerikaner Frank Gray 1953 zum Inhaber eines Patentes geworden, das eine technische Lösung beschreibt, die genau dieses Problem zu vermeiden hilft. Der Gray-Code wechselt bei einer Änderung von einem Wert zum nächsten genau 1 Bitsstelle. Bei einem gewöhnlichen binären System gibt es markante Punkte, z.B. bei einem 4-Bit-System ist es der Wechsel von 7 nach 8, an dem alle 4 Bit-Stellen zur gleichen Zeit ihren Wert ändern müssen, und zwar gleichzeitig ohne Zeitverzug, das dies paradox ist, versteht sich von selbst. In einem 8 Bit-System liegt die kritischste Stelle beim Wechsel von 127 auf 128, bei 16 Bit bei 32767 auf 32768. Das es da unterwegs noch viel mehr kritiche Stellen gibt, ist völlig klar, aber das sind nur die kritischsten Stellen.

In deiner Simulation hast du das prima gelöst und bist damit das Problem umgangen, dass es in der realen Welt der OPV jedoch weiterhin gibt: die Slew-rate bei dem AD8665 liegt bei 3,5 V/µs. Um die paradoxe Forderung (gleichzeitig ohne Zeitverzug) erfüllen zu wollen, müsste die Slew-Rate aber bei ∞ V/µs liegen.

Ich bin mit dem Einsatz des AD8665 nur ein Problem umgangen, habe das grundsätzliche Problem damit aber nur vertagt. Das grundsätzliche Problem ist auch nach wie vor vorhanden, wenn ich nicht den AD8665 verwenden würde, sondern direkt über die GPIOs des Picos das R2R-Netzwerk steuern würde, die Strecke auf der Platine wäre dann kürzer, was aber den Effekt nur unwesentlich beeinflussen würde, alleine die Kapazitäten auf der Platine selbst würden sich bei den Signallaufzeiten bemerkbar machen, wenn bei einer Wertänderung alle 22 Bits des R2R-Netzwerkes nahezu gleichzeitig umkippen würden.

Fazit:
Die Ansteuerung eines R2R-Netzwerkes über eine gewöhnliche binäre Dekodierung ist unter realen Bedingungen nicht machbar. Kann eine Lösung darin bestehen, das Gray-Code-System anzuwenden?

VG
 
Hi Batucada,

Du hast Dich schon tief in die Materie eingearbeitet. Ich muss diesbezüglich (Gray-Code/DAC-R2R Ladder) noch etwas nachsitzen.
Aber ich habe etwas Literatur gefunden, die sich mit Thema beschäftigt (Glitches "included").
Ich hänge das pdf-file mal an.

VG
 

Anhänge

  • 15804102.pdf
    2,9 MB · Aufrufe: 1
Danke @Udo ,

die letzten beiden Sätze aus der Einleitung der Dissertation:
Es wurde festgestellt, dass die Glitches aufgrund des mehrfachen Schalterübergangs auftreten. Dies geschieht nur im Falle des Binärcode-Eingangs-DACs und nicht im Falle des Gray-Code-Eingangs-DACs.
Zunächst bin ich einmal froh, dass ich über die Simulation, auf diesen Punkt aufmerksam geworden bin und keine Hardware-Anstrengungen unternommen habe, das Projekt zu realisieren.

VG

P.S. aufgegeben habe ich deswegen das Projekt aber noch nicht, mal sehen wohin die Reise geht :ROFLMAO:
 
Hallo Batucada,

ersetz mal den AD8665 durch den LT1226 (aus der lib) und max. time step auf 10n. V(out)-Kurve bei 10 KHz sieht gut aus.
VG
 
Ich danke dir, bester Udo

die slew reate ist a schon mehr als um das 100-fache besser. allerdings kost der auch ein bisschen was :mad:
ich hab' mal nach dem LT1356 Ausschau gehalten, der ist in der Eingangsspannungsrauschdichte nicht ganz so gut wie der LT1226, aber immer noch im erträglichen Bereich.

Tja, ich hab' mal die Gray-Code-Variante studiert und selbst ein wenig experimentiert. Die Lösung von Gopal Adhikari ist für den normalen User nicht praktikabel, weil ich nicht in der Lage sein werde mit normalen Mitteln einen Kreuzschalter herzustellen. Sich mit einer einfachen R-2R-Kette begnügen zu wollen, geht auch nicht - um das zu beweisen, dass es nicht geht, muss man lediglich einen 2 Bit-Gray-Code betrachten, denn spätestens beim Wechsel der Wertigkeit von 2 auf 3, wird der Fehler augenfällig. Also lass ich mal die Spielerei mit Gray-Code.

Als nächste Idee würde ich eine Sample-and-Hold-Verstärker ins Spiel bringen wollen, das dürfte kein Problem sein, den zu integrieren jedes Mal, bevor der DAC seinen Zustand ändern soll, geht der Sample-and-Hold-Verstärker in den Haltezustand, während dessen wird der DAC geändert und nach der Änderung wird der Sample-and-Hold-Verstärker wieder freigegeben. Die Glitches bei der binären Umschaltung des DACs kämen dann nicht mehr durch..
 
slew-rate ist ein wichtiger Parameter, richtig erkannt. 3,5V/usec beim AD8665 ist nicht sehr sportlich.
Ein Blick in das Datenblatt hilft immer weiter.
VG
 
Ich hab' jetzt noch einmal Anlauf genommen und mein Konzept hergerichtet.

Das umrahmte Feld symbolisiert den Raspberry Pi Pico. Das Netzteil, das ausschließlich den Pico bedient, habe ich weggelassen, wichtig ist für die Simulation nur die Verbindung über die negative Referenz (Spannungsquelle Offset), welche den System-Ground mit dem Ground des Pico verbindet. Das, was sich da abspielt, sind minimale Nano-Ampere, wie man im Plot unschwer erkennen kann.
DAC-Simulation.png
Die Bausteine U1...U4 habe ich auf der Basis der in LTspice verfügbaren Modelle des LT1356 zusammen gebastelt, der LT1356 ist schließlich von Hause aus ein Quad-OPV. Damit gelingt es halbwegs, eine realistische Abschätzung des Leistungsbedarfs zu erlangen.

Am Ausgang des DACs, der hier noch mit 16 Bit gehandelt wird, kommt eine Sample&Hold-Verstärker des Typs LF398S von Analog Devices, der dann später über einen GPIO des Pico immer dann gesteuert wird, wenn das Programm die Absicht hat, die Ansteuerung des DACs zu verändern. Das ist die einzige Methode, um die Glitches zu minimieren.
DAC-Plot.png
Der Funktionswert wird als Spannungswert in die "BIDECS8C0" eingeschleust, um dann intern als Zahlenwert verarbeitet zu werden. Da der Spannungswert mit mehr als 37 kV schon einen Hochspannungs-Charakter hat, muss man ihn auch mit "gewöhnlichen" Widerständen herunterteilen, damit die Skalierung im Plot nicht aus dem Rahmen fällt. Den "BIDECS8C0" habe ich noch einmal überarbeitet, damit er exakt die Potentiale trennt und nicht mit dem System-GND der Simulation verbindet.

Das DAC-Signal kommt mit einer Amplitude von 14,2 Vss daher und sollte damit einen gehörigen Abstand zu Grundrauschen haben. Ob ich das R-2R-Netzwerk noch auf auf 20 Bit ausbauen werde, weiß ich jetzt noch nicht. Man wird sehen. Recherchen haben ergeben, dass ich für meine geplante Anwendung mit 18 Bit ausreichend versorgt wäre. Aber auf keinen Fall wird es eine 22 Bit-Lösung werden, diese technische Spielerei würde extremst viel Aufwand benötigen, was ich im Rahmen einer höchst privaten Freizeitgestaltung als völlig übertrieben bezeichnen würde.
 

Anhänge

  • Pico-DAC-LT1356.zip
    7,4 KB · Aufrufe: 1
Sieht auch bei 10KHz sinewave noch gut aus. (max. timestep 10nsec, Sim. dauert allerdings etwas)

VG
Hallo Udo,

joa die Simulatin dauert etwas. Aber sag mal. woher nimmst du die Info über 10 nsec?
ich bin bei der Einstellung des tran total ungeübt, bin für jede Hilfestellung dankbar.

VG
 
Spice – Programme wie LTspice benutzen eine “interne”, variable zeitliche Schrittweite (time step).

Die besagt, wie weit Spice voraus blickt bis zum nächsten Punkt eines Simulationsablaufes. Eine variable time step ist für die Spice-Simulation gut brauchbar. Wenn diese intern fix wäre, dann würden manche Simulationen steckenbleiben (verharren) oder zu falschen Ergebnissen führen. Deshalb ist sie variabel gestaltet. Wenn Signale sich sehr schnell ändern, dann wird die time step kürzer. Wenn die Signale sich zeitlich nicht stark ändern, dann könnte die time step größer sein. Die mittlere interne time step tendiert sowohl zur Abhängigkeit von den benutzten Spice-Modellen, als auch zur Abhängigkeit von den Signalen, die für eine Schaltung vorgegeben werden. Ebenso wie die Schaltung auf die Eingangsbedingungen reagiert. Es lässt sich als user nicht vorhersagen, welche interne time step Spice anwendet. Modellen mit diskontinuierlichen Zeitabläufen sind besonders anfällig.

Die „maximum time step“ setzt eine obere Grenze für die interne Timestep.

In vielen Fällen funktioniert die Simulation auch, wenn man die Eingabe ignoriert. Es kann aber passieren, dass schnelle Signale im plot der Transienten Simulation plötzlich an manchen Stellen ungewohnt langsam erscheinen („krumme Flanken“), weil der Simulator falsch abgetastet hat. Das war in Deiner Schaltung bei den Rechtecksignalen (ich glaube bei Bo......up) der Fall. Deshalb habe ich die max. time step limitiert.

Aber Achtung! Die Simulationsdauer kann extrem lang werden, wenn man die max. time step zu klein wählt. Die Simulationsdauer kann man in der „spice error log“ – message auffinden. "Total elapsed time" = ...seconds.

Im spice error log habe ich gerade noch gesehen, dass noch viele Fehlermeldungen eingetragen sind, etwa des Typs:
Questionable use of curly braces in "b0 b0 0v v={if(int(v(in)/2**0)!=int(v(in)/2**1)*2,v(vn),v(vl))}"
Error: undefined symbol in: "if(int([v](in)/2**0)!=int(v(in)/2**1)*2,v(vn),v(vl))"

VG
 

Benutzer welche diesen Thread betrachten (Mitglieder: 0, Gäste: 2)

Wer hat diesen Thread gelesen

Zurück
Oben