Digitales MonoFlop

[Tilman (Gast)]

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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> 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?

[Tilman (Gast)]

>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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Du willst also asynchron ein FF sofort mit der steigenden Flanke eines 
externen Signals setzen, und nach 2 Takten wieder zurücksetzen?
Analog zur Impulsgewinnung von 
http://www.lothar-miller.de/s9y/archives/19-Kurzer-Spike-in-Puls-umgewandelt.html 
schlage ich das mal vor:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity Monoflop is
    Port ( clk : in  STD_LOGIC;
           input : in  STD_LOGIC;
           output : out  STD_LOGIC);
end Monoflop;

architecture Behavioral of Monoflop is
signal sr0    : std_logic := '0';
signal sr1    : std_logic := '0';
signal sr2    : std_logic := '0';
signal merkin : std_logic := '0';
begin
   -- Merker-FF -- so funktioniert das bombensicher, 
   -- allerdings ist der Eingang für 1 Takt blind: solange sr2='1' ist
   process (sr2, input) begin
      if (sr2 = '1') then 
         merkin <= '0';
      elsif rising_edge(input) then 
         merkin <= '1'; 
      end if;
   end process;

   -- Asynchrones Merker-FF eintakten
   process begin
      wait until falling_edge(clk);
      if(sr2='1') then 
         sr0 <= '0'; 
         sr1 <= '0'; 
         sr2 <= '0'; 
      else
         sr0 <= merkin; 
         sr1 <= sr0; 
         sr2 <= sr1; 
      end if;
   end process;
   
   -- Monoflop-Impuls ausgeben
   output <= merkin;
end Behavioral;

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?

[Tilman (Gast)]

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

[Christian R. (supachris)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> 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?

[Tilman (Gast)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[Tilman (Gast)]

Hallo Lothar

Der obige Code funktioniert gut (jedenfalls bisher :-))

Vielen Dank erstmal
Tilman