mikrocontroller.net

Forum: FPGA, VHDL & Co. asynchrones Monoflop realisieren


Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
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

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Aha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: df1as (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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?

Autor: df1as (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: df1as (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: df1as (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
'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!

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: df1as (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: DF1AS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es schon irgendwie weitergegangen?

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
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 bestätigst du, die Nutzungsbedingungen anzuerkennen.