Takt selbst erzeugen

[Thomas (Gast)]

Hallo,

nur eine Verständnisfrage.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity keinQuarz is
    Port
    (
        clk    : in  STD_LOGIC := '0';
        clkOut : out STD_LOGIC := '0'
    );
end keinQuarz;

architecture Behavioral of keinQuarz is
    signal clkCounter : unsigned(31 downto 0) := (others=>'0');
begin
    process (clkCounter) begin
        clkCounter <= clkCounter + 1;
    end process;
    
    process begin
        wait until rising_edge(clk);
        ...
    end process;
    
    clkOut <= clkCounter(15);
end Behavioral;

Wenn die Genauigkeit des Takts keine Rolle spielt, könnte man dann sowas 
machen?
Der clk-Pin wird auf dem PCB mit dem clkOut-Pin verbunden.

Jittert wahrscheinlich ohne Ende, und die ersten 1-2 FFs werden 
wahrscheinlich ständig in irgendwelchen metastabilen Zuständen 
verbringen, müsste aber doch eigentlich gehen, oder?

[Achim S. (Gast)]

Thomas schrieb:
> die ersten 1-2 FFs werden
> wahrscheinlich ständig in irgendwelchen metastabilen Zuständen

dummerweise sehe ich in deinem Counter überhaupt keine (getakteten) 
Flipflops:

Thomas schrieb:
> process (clkCounter) begin
>         clkCounter <= clkCounter + 1;
>     end process;



Es werden nicht nur ein paar LSB Unsinn anzeigen, sondern alle Stellen 
deines Zählers: die niederwertigsten bits werden ja auch direkt für die 
Berechnung der höchstwertigen Bits verwendet.

[bko (Gast)]

Falls du mit FPGA von Xilinx arbeitest, ginge evtl. dies da:
http://www.lothar-miller.de/s9y/categories/29-Ringoszillator
Bei anderen Herstellen heisen die "keep"Attribute möglicherweise
anders.

Hier nochwas:
Beitrag "Re: Selbstlaufende Clock im FPGA"

[Edi M. (Gast)]

So richtig geht das nur mit einem Bit, dass selber toggelt. Danach kommt 
gfs ein Zähler.

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

Thomas schrieb:

 process (clkCounter) begin 
     clkCounter <= clkCounter + 1; 
 end process;

Das könnte abgekürzt genauso auch so beschrieben werden:

 -- process (clkCounter) begin 
     clkCounter <= clkCounter + 1; 
 -- end process;

Und damit auch so:

  clkCounter <= clkCounter + 1;

Und das alles ist letztlich nichts anderes als eine in der Praxis meist 
nutzlose kombinatorische Schleife: 
http://www.lothar-miller.de/s9y/archives/42-Kombinatorische-Schleifen.html

[high tec ing (Gast)]

Würde es denn laufen???

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

Welches es denn?

Ein Zähler basierend auf einer kombinatorischen Schleife würde schon 
"laufen", nur würde er nicht zählen, sondern irgendwas tun. Am ehesten 
könnte man das als "Rauschgenerator" bezeichnen (wenn auch die Qualität 
des erzeugten Rauschens sehr schlecht wäre)...

[Christian R. (supachris)]

high tec ing schrieb:
> Würde es denn laufen???

Willst du jetzt deinen verrauschten externen Takt mit einem intern 
erzeugten aufbessern?

[berndl (Gast)]

Christian R. schrieb:
> high tec ing schrieb:
>> Würde es denn laufen???
>
> Willst du jetzt deinen verrauschten externen Takt mit einem intern
> erzeugten aufbessern?

:o)))))))))))))

[Dr. Schnaggels (Gast)]

Gemeint ist wahrscheinlich

process (clk)
begin
   if rising_edge(clk) then
        clkCounter <= clkCounter + 1;
   end if;
end process;

Dann kann man in der Tat das MSB von clkCounter abgreifen.

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

Dr. Schnaggels schrieb:
> Gemeint ist wahrscheinlich
Du hast den Thread nicht gelesen? Es ist wirklich so gemeint, wie es 
ohne Takt dasteht...
Ich erinnere an die Zeile, die Thomas schrieb:
>>>> Der clk-Pin wird auf dem PCB mit dem clkOut-Pin verbunden.

[Edi M. (Gast)]

Ich habe mir gerade überlegt: Eigentlich könnte es doch laufen. Die 
Zählerei = Addition um 1 wird ja immer mittels JK-FFs realiert. 
Abgebildet auf DFFs braucht es nur einen Übergriff zwischen einem FF und 
seinem Nachbarn. Das ist auch asynchron Hazardfrei. Bleibt nur das 
Problem des Umspringens. Ohne ausdrücklichen Reset und nur mit den FF 
könnte es gehen.

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

E. M. schrieb:
> Die Zählerei = Addition um 1 wird ja immer mittels JK-FFs realiert.
Es gibt in einem FPGA keine JK-Flipflops.

[Edi M. (Gast)]

Lothar Miller schrieb:
> Es gibt in einem FPGA keine JK-Flipflops.
Klar, deshalb sprach ich ja davon, dass man sie auf DFFs abbilden muss. 
Ausschlaggebend ist mit Bezug auf das Thema, dass ein FF immer nur von 
einem Vorgänger gespeist wird und es damit keine diskrepanten 
Interpretationen von Zuständen gibt / geben muss - bis eben auf einen 
Resetfall, den man aber nicht unbedingt braucht.

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

DFF als JKFF?
Kannst du da mal ein funktionsfähiges Beispiel zeigen. Oder wenigstens 
ein Funktionsmodell vorstellen. Ich probiere das dann aus...

[Edi M. (Gast)]

Bitte? Du weisst, wie ein JK-FF funktioniert? Das lässt sich mit etwas 
Logik abbilden.

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

E. M. schrieb:
> Du weisst, wie ein JK-FF funktioniert?
Ja. Du meinst die "Schwingungen", die ein JK-FF (theoretisch) machen 
wird, wenn J=K=1 sind.
> Das lässt sich mit etwas Logik abbilden.
Ja, mach doch. In einem FPGA. Mit LUTs und DFFs. So, dass dahinter ein 
verwertbarer Takt rauskommt (darum geht es letztlich) und nicht 
irgendein "halbanaloges" Signal (das bekommst du nämlich mit üblichen 
kombinatorischen Schleifen)...

Ich habe das nur mit dem Ringoszillator geschafft. Und das war schon mal 
soweit nachvollziehbar, dass Andere das auch hinbekommen haben: 
http://dangerousprototypes.com/docs/CPLD_ring_oscillator