Hallo, Ich suche eine Möglichkeit ein asynchrones Monoflop aufzubauen. Es muss folgende Eigenschaften erfüllen: - Die Pulsbreite sollte sich mindestens auf 5ns runter drehen lassen, sowie mindestens auf 1 us hochdrehen lassen. - Die Pulsbreite sollte sich digital einstellen lassen (von mir aus auch über eine Spannung per DAC), am besten sollte die Pulsbreite Proportional zur Spannung sein. - Stromverbrauch ist nicht so wichtig, allerdings sollte ein Kanal nicht all zu teuer sein. Dazu hatte ich folgende Idee mit einem FPGA: Im Prinzip ist es diese Schaltung: http://www.antonine-education.co.uk/Electronics_AS/Electronics_Mod2/topic_2_2/topic_2_monostable_circuits.htm Nur wird für das Gatter Y als Logiklevel V_REF genommen. Diese wird per DAC eingestellt. Durch einstellen der Spannung kann man dann die Pulsbreite einstellen. Würde das funktionieren? Gibt es bessere Möglichkeiten? Ich habe beim suchen viele fertige Monoflop-Chips gefunden, allerdings stellt man da die Pulsbreite über einen C und einen R ein. Ich weiß, dass es programmierbare Widerstände gibt, allerdings kenne ich keinen der mehr als ein paar kHz Bandbreite hat. Viele Grüße, Christian
Hast du schon einen FPGA oder geht es dir ausschließlich um diese Funktion? Mit FPGA ist das ein Klacks: Ein Counter der mit 200MHz läuft (oder 100 MHz + ein DDR-IO-Flipflop, dann sollte auch ein Spartan 3 es schaffen). Davon dürftest du in jeden FPGA so viele Kanäle unterbringen wie das Teil I/O-Pins hat. Dann kannst du die Breite direkt digital einstellen und musst auch nicht den Umweg über einen DAC machen. Mit einem diskreten Aufbau ohne FPGA kann ich dir da aber nicht weiterhelfen.
> Diese wird per DAC eingestellt. Durch einstellen der Spannung kann > man dann die Pulsbreite einstellen. Würde das funktionieren? Müsste man probieren... Würde ich aber nicht machen, weil viel zu ungenau, nicht reproduzierbar, zielsystemabhängig und temperaturabhängig. Eben ein schlimmes Gebastel :-( Monoflops macht man in FPGAs immer mit Zählern. Für 5ns Auflösung brauchst du 200MHz Takt, das ist mit aktuellen FPGAs ohne weiteres zu machen. Die wichtigste Einschränkung wird bei der Auflösung eher sein, dass die Schritte dann 5ns, 10ns, 15ns ... sind, du also z.B. keine 7ns einstellen kannst (wobei das mit anderen granularen Lösungen auch der Fall sein wird). EDIT: > ... dann sollte auch ein Spartan 3 es schaffen ... So ein kleiner Zähler (1us/5ns sind ja nur 8 Bit) kann mit lokalem Takt realisiert werden (ohne Taktnetz) das packt der S3 locker und 256 MHz gehen sogar mit dem billigsten MachXO von Lattice. Nur muß man mit irgendwelchen unnötigen Resetbedingungen vorsichtig sein.
Hi Jan, Hi Lothar zuerst geht es mal ums Prinzip. Auf den meisten Platinen dürfte aber ein FPGA drauf sein, wenn nicht kommt halt einer drauf. Bei deiner Idee mit dem Zähler gibt es denke ich ein Problem: Jitter. Die Signale sind asynchron und müssen es bleiben. Wenn ich jetzt mit einem 200MHz Zähler dran gehe habe ich 5 ns Jitter, das ist zu viel. OK, das hätte ich vielleicht oben explizit als weitere Anforderung aufschreiben sollen. 5ns Jitter wären sogar schlimmer als eine Temperaturabhängigkeit.
Wieviel Jitter wäre denn noch verkraftbar? Und wie groß darf die Verzögerung zwischen Startsignal und dem Beginn des Pulses sein? Bei FPGAs musst du auch noch die Zeit vom Pad in die Logik und zurück berücksichtigen. Da kommen schon einige Nanosekunden zusammen, die Zeiten bleiben aber konstant.
> Die Signale sind asynchron und müssen es bleiben. Versuchen wirs doch mal anders herum: was willst du machen? Kommen da z.B. 6 Signale im zeitlichen Abstand von 500ps an und sollen "einfach" nur um (bzw. auf) 5 ns verlängert werden? Bezieht sich deine Angst vor dem Jitter nur auf die "Start"-Flanke? Falls ja: Dann könntest du asynchron ein FF des FPGA mit der z.B. steigenden Flanke deines Signals setzen und anschließend (mit einem Jitter von 5 us) das FF über den Zähler zurücksetzen.
Jitter, so wenig wie möglich. 500ps wären schon viel, ich werde mich mal genauer informieren. Die Verzögerung ist nicht so kritisch. Mehr als 50 ns sollten es aber nicht unbedingt sein. Schön wäre weniger als 10 ns.
Lothar Miller wrote: >> Die Signale sind asynchron und müssen es bleiben. > Versuchen wirs doch mal anders herum: was willst du machen? > > Kommen da z.B. 6 Signale im zeitlichen Abstand von 500ps an und sollen > "einfach" nur um (bzw. auf) 5 ns verlängert werden? Ja, im Prinzip sollen die Signale auf einen Sollwert verlängert werden. In welchen Abständen die Signale kommen ist nicht vorherzusehen. Das gilt für verschiedene Leitungen wie für eine einzelne Leitung (Also muss auch die Totzeit möglichst klein sein.) > Bezieht sich deine Angst vor dem Jitter nur auf die "Start"-Flanke? > Falls ja: Dann könntest du asynchron ein FF des FPGA mit der z.B. > steigenden Flanke deines Signals setzen und anschließend (mit einem > Jitter von 5 us) das FF über den Zähler zurücksetzen. Ah, stimmt, das geht. Wichtiger ist die Startflanke. Wenn die fallende Flanke auch noch synchron wäre, wäre das aber noch besser.
Das: > Die Verzögerung ist nicht so kritisch. Schön wäre weniger als 10 ns. und das: > Wichtiger ist die Startflanke. zusammen ist mit einem FPGA eine leichte Übung. Aber das geht nicht: > Wenn die fallende Flanke auch noch synchron wäre, > wäre das aber noch besser. Wobei "synchron" wahrscheinlich eher "jitterfrei" bezogen auf die Start-Flanke bedeutet.
Lothar Miller wrote: > Das: >> Die Verzögerung ist nicht so kritisch. Schön wäre weniger als 10 ns. > und das: >> Wichtiger ist die Startflanke. > zusammen ist mit einem FPGA eine leichte Übung. > > Aber das geht nicht: >> Wenn die fallende Flanke auch noch synchron wäre, >> wäre das aber noch besser. > Wobei "synchron" wahrscheinlich eher "jitterfrei" bezogen auf die > Start-Flanke bedeutet. Ja, das meine ich damit. OK, sowas hatte ich vermutet. (Da es mit Sicherheit Dinge in FPGAs gibt die ich noch nicht kenne habe ich trotzdem mal gefragt.) Dann muss ich wohl herausfinden wie wichtig wenig Jitter auf der Stop-Flanke ist. Wenn auch da 5ns zu viel sind muss ich mal nach einer analogen Lösung ausschau halten. Oder weiß da jemand Rat? Vielleicht mache ich dazu besser im Elektronik Forum einen Thread auf.
Asynchrone Funktionalitaet hat eigentlich in einem FPGA nichts zu suchen. Dazu gibt es Standardlogik : ECL. Man beginnt mal mit einem Komparator und hat somit die Startflanke. Wenn man nun Nanosekunden zahlen will, so muss man analog die Zeit zur naechsten Clockflanke messen, indem man einen Strom einen Kondensator laden laesst, dann die Anzahl Clocks abzaehlen und nachher die Sub-clock-Zeit mit einem analogen Delay kompensieren. Der 20 jaehrige Stanford DG535 macht das auch so, arbeitet mit heute lahmen 10MHz.
Das ist doch der klassische Anwendungsfall von Delay-Lines. Delay-Lines sind um Größenordnungen temperaturstabiler als Monoflops und die Programmierung erfolgt durch Auswahl der Abgriffe (Taps). Unverzögertes Signal auf den Clk-Eingang eines FF, das verzögerte Signal auf Res. Zur Auswahl reichen ein paar wenige schnelle Einzelgatter (Mux). Das Ganze lässt sich auch kaskadieren. Ansonsten ließen sich bei modernen FPGA auch Delays programmieren (z. B. für die IBUF beim Xilinx in 16 Schritten; Schrittweiten liegen bei 1/4 oder 1/2 ns). Temperatur und Spannung kann man ja berücksichtigen.
Aha wrote: > Asynchrone Funktionalitaet hat eigentlich in einem FPGA nichts zu > suchen. Warum nicht? Dafür aber in CPLDs? > Dazu gibt es Standardlogik : ECL. Man beginnt mal mit einem Wenn du einen Lieferanten hast, der zuverlässig ECL Bausteine liefern kann sag Bescheid. Irgendwas aus der 10H Reihe zu bekommen wird immer schwieriger. > Komparator und hat somit die Startflanke. Wenn man nun Nanosekunden > zahlen will, so muss man analog die Zeit zur naechsten Clockflanke > messen, indem man einen Strom einen Kondensator laden laesst, dann die > Anzahl Clocks abzaehlen und nachher die Sub-clock-Zeit mit einem > analogen Delay kompensieren. Der 20 jaehrige Stanford DG535 macht das > auch so, arbeitet mit heute lahmen 10MHz. Hm? ich verstehe nicht was du meinst. Klingt auch ehr nach Zeit messen als Puls mit bestimmter dauer erzeugen. Vielleicht schaue ich einfahc mal in das Datenblatt von dem Chip. df1as wrote: > Das ist doch der klassische Anwendungsfall von Delay-Lines. Delay-Lines > sind um Größenordnungen temperaturstabiler als Monoflops und die Und um Größenordnungen teurer. Wir hatten hier mal einen der konnte 200 ns Gesamtverzögerung in 20 ns Schritten. Ich glaube da kostete einer um die 30 Euro. Das wäre zu viel. > Programmierung erfolgt durch Auswahl der Abgriffe (Taps). Unverzögertes > Signal auf den Clk-Eingang eines FF, das verzögerte Signal auf Res. Zur > Auswahl reichen ein paar wenige schnelle Einzelgatter (Mux). Das Ganze > lässt sich auch kaskadieren. > > Ansonsten ließen sich bei modernen FPGA auch Delays programmieren (z. B. > für die IBUF beim Xilinx in 16 Schritten; Schrittweiten liegen bei 1/4 > oder 1/2 ns). Temperatur und Spannung kann man ja berücksichtigen. hm. kann man die auch kaskadieren? Vielleicht wenn man das Signal ausgibt und an einem weiteren Pin wieder eingibt und neu verzögert? Wie gesagt, wir brauchen auch "lange" Zeiten. 1 us wäre schön, 500ns gut, 250 ns würden notfalls reichen. Heute habe ich auch erfahren, dass die abfallende Flanke auch Jitterfrei (bzw deutlich weniger Jitter als die 5ns die durch einen 200MHz Zähler entstehen würden) sein soll.
>> Ansonsten ließen sich bei modernen FPGA auch Delays programmieren (z. B. >> für die IBUF beim Xilinx in 16 Schritten; Schrittweiten liegen bei 1/4 >> oder 1/2 ns). Temperatur und Spannung kann man ja berücksichtigen. >hm. kann man die auch kaskadieren? Vielleicht wenn man das Signal >ausgibt und an einem weiteren Pin wieder eingibt und neu verzögert? Vergiss es, du kannst die Dinger nicht (so schnell wie du es bräuchtest) umschalten. > Heute habe ich auch erfahren, dass die abfallende Flanke auch Jitterfrei > (bzw deutlich weniger Jitter als die 5ns die durch einen 200MHz Zähler > entstehen würden) sein soll. Genauere Zahlen?
Also ... 30,- EUR schon zu teuer? Wie viele Signale, und insbesondere: was für Stückzahlen braucht's denn? Ich hatte mal kaskadierte Delay-Lines für ein Gamma-Ray-Teleskop verbaut. Kosten pro Stück waren vierstellig (high-rel, space, mit C.o.C. und sonstwas) und es gab dennoch Ausfälle auf dem Shaker. Aber na ja ... In "billg" gibt es die doch aber schon für wenige Euros, z. B. Maxim DS1000Z-500, 5 x 100 ns. Muss man einfach mal den Markt durchforsten. Ansonsten steht es einem frei, auch Dutzende Gatter in einem FPGA hintereinanderzuschalten. Also ohne S-Logik. Die Laufzeit ließe sich (regelmäßig wegen der Temperatur- und Spannungsabhängigkeit) stichprobenartig mit Zählern bestimmen. Das Zählergebnis ist dann zwar quantisiert auf vielleicht 2,5 ns (200 MHz Zählertakt, Ausnutzung beider Flanken), aber die Verzögerung selbst wäre jitterarm. Für eine ganze µs wäre das aber schon eine riesige Kette an Gattern. GGf. auch aus Pins raus und wieder rein. Regelmäßiges Kalibrieren wäre dann aber Pflicht. Und wenn es eine größere Serie ist, muss natürlich der speed-grade möglichst im gleichen Bereich liegen. Nicht so einfach und eigentlich überhaupt nicht meine Empfehlung. Ich tendiere selbst eher zur synchronen Technik. Mit 500 MHz Takt könnte man den Jitter auf 1 ns drücken. Eine weitere Möglichkeit wäre, die Verzögerung grob synchron (also Zähler) - und einen Feinabgleich durch Eingangs- und Ausgangs-Delay-Lines durchzuführen. Am Eingang werden alle Taps einer DL abgetastet, um die Phasenlage des Eingangssignals zum Zählertakt zu bestimmen. Dieser Wert wird dann unmittelbar (bzw. um die gleiche Taktanzahl verzögert) an die Ausgangs-DL weitergegeben. Für diese hybride Lösung wären bereits preiswerte DL mit kurzen Laufzeiten (brutto im Bereich des Zählertakts) geeignet. Dritte Variante: Die DL werden wiederum mit C-Logik implementiert. (Muss nur wieder kalibriert werden.) Nur so meine Ideen zu diesem Thema. Vermutlich wird es dann gänzlich anders ...
Ach ja: Für die Variante mit dem Phasenabgleich sollten dann auch die Delay-programmierbaren Buffer der "Gehobene-Mittelklasse-FPGA" geeignet sein. Einfach jeweils mehrere Input-Pins parallel mit stufenweiser Verzögerung einsetzen, quasi als "taps". "Tap-Stellung" für den Ausgang ist dann die gleiche wie beim Eingang (out_enable(n) <= '1' when (in(n) = '1') and (in(n+1) = '0') else '0'; oder so ähnlich für alle n). Kann nur sein, dass diese FPGA wieder zu teuer sind. (Kenne mich nur mit den ganz teuren Teilen ein wenig aus.)
df1as wrote: > Also ... 30,- EUR schon zu teuer? Wie viele Signale, und insbesondere: > was für Stückzahlen braucht's denn? Unterschiedlich, mal 2 pro Modul, mal auch 8 oder mehr. Bezahlbar wäre es. Ich finde nur man sollte nicht 30 € für einen Baustein ausgeben, wenn es auch anders billiger geht und die Anforderungen auch erfüllt werden. > > Ich hatte mal kaskadierte Delay-Lines für ein Gamma-Ray-Teleskop > verbaut. Kosten pro Stück waren vierstellig (high-rel, space, mit C.o.C. > und sonstwas) und es gab dennoch Ausfälle auf dem Shaker. Aber na ja ... > > In "billg" gibt es die doch aber schon für wenige Euros, z. B. Maxim > DS1000Z-500, 5 x 100 ns. Muss man einfach mal den Markt durchforsten. Ohja, da schaue ich mich mal um. 100ns als Minimum wäre natürlich viel zu viel, aber ich kann ja 2 verschiedene hintereinander schalten. > > > Ansonsten steht es einem frei, auch Dutzende Gatter in einem FPGA > hintereinanderzuschalten. Wie erreicht man es, dass die am Ende wirklich synthetisiert werden? ich meine, wenn man sie rauskürzen kann erkennt das die Software doch. > Also ohne S-Logik. Die Laufzeit ließe sich > (regelmäßig wegen der Temperatur- und Spannungsabhängigkeit) > stichprobenartig mit Zählern bestimmen. Das Zählergebnis ist dann zwar > quantisiert auf vielleicht 2,5 ns (200 MHz Zählertakt, Ausnutzung beider > Flanken), aber die Verzögerung selbst wäre jitterarm. OK, klingt gut. S-Logik = synchrone Logik? > Für eine ganze µs wäre das aber schon eine riesige Kette an Gattern. > GGf. auch aus Pins raus und wieder rein. Dann würde ich das mit einem externen Delay verzögern. > Regelmäßiges Kalibrieren wäre > dann aber Pflicht. Und wenn es eine größere Serie ist, muss natürlich > der speed-grade möglichst im gleichen Bereich liegen. Nicht so einfach > und eigentlich überhaupt nicht meine Empfehlung. > > Ich tendiere selbst eher zur synchronen Technik. Mit 500 MHz Takt könnte > man den Jitter auf 1 ns drücken. Für 500MHz braucht man aber schon einen FPGA der gehobenen klasse. Oder bekommt man das mit Tricks auch noch in einem Spartan3 unter? > > > Eine weitere Möglichkeit wäre, die Verzögerung grob synchron (also > Zähler) - und einen Feinabgleich durch Eingangs- und > Ausgangs-Delay-Lines durchzuführen. > > Am Eingang werden alle Taps einer DL abgetastet, um die Phasenlage des > Eingangssignals zum Zählertakt zu bestimmen. Dieser Wert wird dann > unmittelbar (bzw. um die gleiche Taktanzahl verzögert) an die > Ausgangs-DL weitergegeben. Interessante Idee. > > Für diese hybride Lösung wären bereits preiswerte DL mit kurzen > Laufzeiten (brutto im Bereich des Zählertakts) geeignet. > > > Dritte Variante: Die DL werden wiederum mit C-Logik implementiert. (Muss > nur wieder kalibriert werden.) OK. Wofür steht das C? Wäre nur wieder die Frage wie man erreicht, dass das nicht weg optimiert wird. > > > Nur so meine Ideen zu diesem Thema. Vermutlich wird es dann gänzlich > anders ... Auf jeden Fall sind viele gute Ideen dabei. > Ach ja: Für die Variante mit dem Phasenabgleich sollten dann auch die > Delay-programmierbaren Buffer der "Gehobene-Mittelklasse-FPGA" geeignet > sein. Definiere gehoben. Virtex? Im Spartan3 gibt es ja auch Delay-Lines in den Eingängen und der ist ja noch nicht soo teuer. > Einfach jeweils mehrere Input-Pins parallel mit stufenweiser Verzögerung > einsetzen, quasi als "taps". "Tap-Stellung" für den Ausgang ist dann die > gleiche wie beim Eingang (out_enable(n) <= '1' when (in(n) = '1') and > (in(n+1) = '0') else '0'; oder so ähnlich für alle n). Hm. Im Spartan kann man aber glaube ich nur den Eingang verzögern und nicht den Ausgang. Kann das sein? > > Kann nur sein, dass diese FPGA wieder zu teuer sind. (Kenne mich nur mit > den ganz teuren Teilen ein wenig aus.) Es wäre gut, wenn die Lösung auch in einem Spartan3 implementiert werden kann.
'C' ist reine Kombinatorik, 'S' sind Speicherelemente (Flipflops), die aber auch 'C' vorgeschaltet haben können. Kann sein, dass diese Nomenklatur nicht allgemein üblich ist. Ich komme aus der Actel-Welt, dort hießen die immer schon so. Ja, mit der Ausgangsverzögerung. Kann schon so sein, dass es diese einstellbare Verzögerung nur für "IBUF" gibt. Man könnte dann aber für den Ausgang auch 1 x raus, n x rein (Auswahl), dann wieder 1 x raus gehen. Das wäre für den guten Parallellauf gar nicht so verkehrt!
df1as wrote: >Ich komme aus der Actel-Welt, > dort hießen die immer schon so. > Noch ein Wort, dass ich noch nie gehört habe :-) > Ja, mit der Ausgangsverzögerung. Kann schon so sein, dass es diese > einstellbare Verzögerung nur für "IBUF" gibt. Man könnte dann aber für > den Ausgang auch 1 x raus, n x rein (Auswahl), dann wieder 1 x raus > gehen. Das wäre für den guten Parallellauf gar nicht so verkehrt! Ah, ja, gute Idee. Ist nur ein bisschen blöd, dass dann für einen Kanal um die 30 IO-Pins verbraucht werden. Aber irgendwo wird man halt Abstriche machen müssen. Aber noch mal die andere Frage: Wie erreiche ich es, dass Logik die nur verzögern soll nicht bei der Synthese entfernt wird? Ich meine, wenn ich nur Buffer oder Inverter hintereinander setze werden die ja als überflüssig entfernt. Das wäre zwar für diese Lösung nicht wichtig, interessiert mich aber allgemein.
Mir war es bisher immer recht, wenn "wegoptimiert" wurde, nur das
gegenteilige Replizieren geht häufig in die Hose (z. B. beim Abtasten
von asynchronen Eingängen).
Es gibt aber Möglichkeiten, genau festzulegen, welche Gatter verbaut
werden. Kann man auch direkt als Entities angeben, z. B. Buffer in einer
Loop direkt anlegen und quasi von Hand verdrahten: loop ... port map {I
<= MyDelay (i), O <= MyDelay (i+1)}. Das ist dann zwar nicht direkt
portierbar, weil die Namen von der Hersteller-Library abhängen.
Ansonsten kann man auch die Constraints bemühen. Diesbezüglich bin ich
aber nicht sehr fit mit der Materie. Von Kollegen, die damit rumbasteln,
weiß ich nur, dass es immer irgendwie geht. Merkwürdige side efects sind
aber auch nicht ausgeschlossen.
Zum anderen: Meine Idee mit dem "Grob-Synchronzähler" plus
"Tap-Feinabgleich" sollte ohnehin 1:1 abgebildet werden können. Diese
Input-Delays stellt man über feste Attribute ein, und Pins können auch
nicht so einfach wegoptimiert werden. Für machbar halte ich das, auch
für nicht allzu teuer.
Wenn es denn mal irgendwann fertig sein sollte, bitte nicht vergessen,
hier zu berichten! Wie lange ist noch Zeit zum Entwickeln? Time to
market ist ja häufig noch ein wichtiger Aspekt.
Hi, Leider noch nicht. Es gab bisher zu viel anderes zu tun, was wichtiger war. Ich melde mich aber definitiv, wenn ich es getestet habe. Viele Grüße, Christian
Hi, geht doch ganz einfach, siehe DS1021..1023 Farnell 15 Euro mit 256 Delayschritten bis herab von 0,25ns auch seriell mit 3-Wire programmierbar, DS1023 auch mit Pulsbreitenausgang Reihenschaltung mehrerer Typen z.B. DS1021-50 256x0,5ns= 137,5ns inclusive Grundverzögerung von 10ns 2 Stück parallel 1.mit Hi 2.mit Lo ansteuern, beide an Ausgängen mit and-verknüpft ergibt schönen Hi-Impuls der in Breite und Delay in 0,5ns Schritten programmiert werden kann.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.