Hallo
ich benötige ein digitales Monoflop, das ich in ein FPGA brennen möchte.
Das Monoflop soll auf eine positive Flange von Input triggern.
Anschliessend soll es um einige Taktzyklen von Clk verzögern. Das machen
I58 und I59.
Die Zeitverzögerung funktionieren. I59 bleibt allerdings auf High, so
dass I67 nicht auf neue Flanken an Input triggert (bei t=7,3s).
Wie sieht ein vollständig funktionierendes Design aus ?
Danke
Tilman
> ich benötige ein digitales Monoflop, das ich in ein FPGA brennen möchte.
Monoflops (und eigentlich alles, was mit Zeiten zu tun hat) in FPGAs
sind Zähler, die von einem Ereignis zurückgesetzt werden und dann eine
bestimmte Zeit lang (=bestimmte Anzahl Takte) hochzählen.
> Wie sieht ein vollständig funktionierendes Design aus ?
Zeichne mal ein korrektes Timing-Diagramm und markiere wesentliche
Punkte.
Welche Programmiersprache?
>Monoflops (und eigentlich alles, was mit Zeiten zu tun hat) in FPGAs
sind Zähler, die von einem Ereignis zurückgesetzt werden und dann eine
bestimmte Zeit lang (=bestimmte Anzahl Takte) hochzählen.
Ich habe es mit 2 Toogle-FlipFlops probiert, die nur dann ein Taktsignal
erhalten, wenn I67 gesetzt ist. Nach dem Hochzählen der 2 ToggleFlip
wird I67 zurückgesetzt.
Dann wäre I67 wieder bereit für einen neues Signal an Input -- wenn
auch das Reset-Signal für I67, das im Timimg Diagram bei Pulse1 gezeigt
wird, auf 0 zurückkehren würde.
Ich habe ein weiteres Timing Diagram angehängt. Grün sind die Anteile
der Signale, die sich wie erwartet verhalten. Rot zeigt das
Sollverhalten.
Progammiersprache: Entweder Gatterlogic (ich habe die im ersten Posting
mit ispLever classig erzeugt) oder vhdl.
Danke
Tilman
-- allerdings ist der Eingang für 1 Takt blind: solange sr2='1' ist
18
process(sr2,input)begin
19
if(sr2='1')then
20
merkin<='0';
21
elsifrising_edge(input)then
22
merkin<='1';
23
endif;
24
endprocess;
25
26
-- Asynchrones Merker-FF eintakten
27
processbegin
28
waituntilfalling_edge(clk);
29
if(sr2='1')then
30
sr0<='0';
31
sr1<='0';
32
sr2<='0';
33
else
34
sr0<=merkin;
35
sr1<=sr0;
36
sr2<=sr1;
37
endif;
38
endprocess;
39
40
-- Monoflop-Impuls ausgeben
41
output<=merkin;
42
endBehavioral;
Was noch nicht ganz klar ist:
Soll das Monoflop retriggerbar sein? Aus deinem Timing-Diagramm geht
hervor, dass das offenbar nicht gewünscht ist...
Aber was soll passieren, wenn (ziemlich) genau gleichzeitig das
Eingangssignal weggeht und der Ausgang zurückgesetzt werden soll?
Fragen zum Bild: Warum wird bei der Markierung 1 das Monoflop nicht
wieder gestartet? Was wäre, wenn der Puls bei Markierung 2 einen Hauch
später käme? Warum müsste dann ein 2. Impuls ausgegeben werden?
Insgesamt: Es erschliesst sich (zumindest mir) der Sinn des Ganzen
nicht.
Was willst du genau erreichen? Woher kommt das Signal und was soll
daraus werden?
Hallo
a) das Monoflop muss nicht retrigerbar sein
b) Markierung 1: Das ist ein Zeichenfehler meinerseits - das Monoflop
soll entgegen meiner Zeichnung erneut getriggert werden.
c) Markierung 2: Das Monoflop würde wieder getriggert werden, wenn der
Impuls am Input ein Hauch später kommen würde
d) Zum Sinn: Ich möchte ein FPGA-Logik für ein Businterface
programmieren. Die Steuersignal (z.B. CS) kommen kurz und relativ
selten. Bei direkter Verbindung durch das FPGA mit Debug-LEDs würde ich
die Signale nicht sehen -- deswegen die zeitliche Verlängerung.
Viele Grüsse
Tilman
Tilman schrieb:> d) Zum Sinn: Ich möchte ein FPGA-Logik für ein Businterface> programmieren. Die Steuersignal (z.B. CS) kommen kurz und relativ> selten. Bei direkter Verbindung durch das FPGA mit Debug-LEDs würde ich> die Signale nicht sehen -- deswegen die zeitliche Verlängerung.
Sowas "debuggt" man in der Simulation. Für Testzwecke implementiere ich
immer ein schreibbares Register, was die LEDs auf dem Testboard
ansteuert und ein lesbares, was die Position der evtl. vorhandenen
Schalter/Taster wiedergibt. Dafür braucht man kein Monoflop. Du kannst
dann die LEDs mit einem Schreibbefehl steuern.
> a) das Monoflop muss nicht retrigerbar sein
Es schadet nichts, wenn es retriggerbar ist?
Du willst nur sichergehen, dass du einen einzelnen CS nicht übersiehst.
Wenn aber 100 schnell nacheinander kommen, dann reicht es aus, wenn die
LED 1x aufleuchtet?
Es schadet nicths, wenn es regtriggerbar ist
Derzeit will ich sehen, ob überhaupt ein Signal kommt. Die Anzahl der
Signale ist mehr erstmal nicht wichtig bzw. die kann ich über Lese- und
Schreibzugriffe zeitlich steuern.
Wie wärs dann, wenn du mit dem oben erwähnten Spikedetektor einfach
einen Zähler zurücksetzt, der dann bewirkt, dass solange der Endwert
nicht erreicht ist eine LED leuchtet.