Frequenzteiler --> 50Mhz zu 16kHz

@ Master1991 (Gast)

>Ich hab ein FPGA mit 50Mhz Boardtakt und brauch für meine Aufgabe einen
>Frequenzteiler der 2Hz, 16 Hz und 16 kHz als Ausgang hervorbringt.

Kein Probelem.

>Mein Problem ich kann den Ursprungstakt doch immer nur halbieren oder?

Oder. Man kann im einfachsten Fall durch (N+1) teilen, wenn man einen 
Zählen von N bis 0 rückwärts zählen lässt. Oder von 0-N. Danach macht 
man einen synchronenen Reset und es geht von vorn los.

Die fortgeschrittende, dennoch recht einfache Methode heißt DDS. 
Damit kann man nahezu beliebige Teilerfaktoren realisieren, wenn gleich 
nicht vollkommen jitterfrei.

>"Die Leitung freq16khz_o vom Typ std_logic liefert ein periodisches
>Signal von 16 kHz.
>Das Signal ist jeweils für genau eine Periode des Systemtaktes auf „1“
>und ansonsten auf
>„0“. Nach einem Reset geht es zunächst mit der „0“-Phase los."

Taktung FPGA/CPLD.

Master1991 schrieb:
> Was soll das denn heißen das Signal sei für eine Periode des
> Systemtaktes auf '1'? Daraus werd ich gar nicht schlau um 16kHz Bspw zu
> erzeugen brauch ich doch ne ganze Menge an Perioden des Systemtaktes?

Noe, dein Signal geht genau fuer 20ns auf '1' und dann fuer 62.48us auf 
'0'

20ns + 62.48us = 62.5us.

1/62.5us = 16kHz

Du brauchst ein Zaehler der nach 3125 Perioden deines 50MHz Taktes auf 0 
zurueckgesetzt wird.

Master1991 schrieb:
> wie kann ich das mithilfe von Countern erreichen?
> ...
> Was soll das denn heißen das Signal sei für eine Periode des
> Systemtaktes auf '1'?
Siehe dort das letzte Beispiel:
http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html
Die 50MHz werden auf 4Hz heruntergeteilt und dann pro viertel Sekunde 
für 20ns ein Clock-Enable (t) gesetzt.
Und hier wird in einem "Vorteiler" Modul ein Clock-Enable für das 
Lauflicht erzeugt:
http://www.lothar-miller.de/s9y/archives/61-Lauflicht.html

Helmut Lenzen schrieb:
> Du brauchst ein Zaehler der nach 3125 Perioden deines 50MHz Taktes auf 0
> zurueckgesetzt wird.
Der Vorschlag wird von Anfängern dann gern falsch umgesetzt.: 
korrekterweise muss der Zähler nach 3124 Perioden auf 0 zurückgesetzt 
werden, weil auch der Zählerwert 0 ein Zählschritt ist, und 0..3124 
schon die gewünschten 3125 Taktzyklen sind...

Wer das alles nicht selber ausrechnen will, der kann das auch den 
Synthesizer machen lassen. So wie hier der Zählerwert für die Baudrate 
berechnet wird:
http://www.lothar-miller.de/s9y/categories/42-RS232
(Die Sache mit dem einen Zählschritt erkennt man dort am immer wieder 
auftauchenden "-1")

Lothar Miller schrieb:
> Der Vorschlag wird von Anfängern dann gern falsch umgesetzt.:

Stimmt, das beruehmte +-1 Problem :=)

Ja. 0-24.999.999

Ja.

Master1991 schrieb:
> elsif zaehler = '0' then

Das kann auch nicht funktionieren, weil zaehler nicht nur ein einzelnes 
Bit ist, was eben '0' oder '1' sein kann.
Warum verwendest du überhaupt natural?

So synthetisiert es zum Beispiel bei mir, eine Testbench hab ich aber 
noch nicht bemüht. Also keine Ahnung ob es korrekt funktioniert, aber 
ich denke schon.

1

2

entity genFrequenzteiler is

3

generic(teiler: positive := 10);

4

port(

5

clk_i, reset_i :in std_logic;

6

freqXXhz_o: out std_logic

7

);

8

begin

9

--synthesis off

10

assert(teiler >=2) report "Der Teiler ist zu klein" severity failure;

11

--synthesis on

12

end genFrequenzteiler;

13

14

architecture Behavioral of genFrequenzteiler is

15

16

signal zaehler: integer range teiler - 1 downto 0;

17

18

begin

19

  zustandsuebergangsfunktion: process(clk_i)

20

  begin

21

    if rising_edge(clk_i) then

22

      if reset_i = '1' then

23

        freqXXhz_o <= '0';

24

        zaehler <= teiler-1;

25

      elsif zaehler = 0 then

26

        freqXXhz_o <= '1';

27

        zaehler <= teiler-1;

28

      else

29

        freqXXhz_o <= '0';

30

        zaehler <= zaehler - 1;

31

      end if;

32

    end if;

33

  end process;

34

end Behavioral;

Edit: Testbench schaut auch gut aus, denke es sollte so hinhauen.

G.U. schrieb:
> Fabio W. schrieb:
>> assert(teiler >=2) report "Der Teiler ist zu klein" severity failure;
> was soll'n dette sein?
>
> oben auf 10 setzen und dann ein Problem melden?

Ähm, einerseits habe ich nur die relevanten Stellen angepasst, damit es 
synthetisierbar ist, und auf der anderen Seite hat da glaube ich jemand 
noch keine Generics verstanden?
Ich mein ich bin noch Anfänger, aber der Sinn von Generics ist unter 
Anderem, während einer Instanziierung im Generic-Map die 
'Voreinstellung' zu überschreiben.
So kann ich zwar die 10 da stehen lassen, aber wenn ich in der Testbench 
bei der Instanziierung eine 1 überschreibe, läuft der Simulator nicht.

Ein Anfänger, der eine Validierung der Eingangsparameter macht. Gefällt 
mir!

Ralf schrieb:
> D.h. du schreibst Dir per generic etwas Unsinniges rein, um zu prüfen,
> ob Du bei der Programmierung das generic auch überschrieben hast?

Ich bin mir nicht sicher, ob ich dich richtig verstehe. Daher beschreibe 
ich mal, wieso ich solche asserts bei Generics auch einbaue:

HDL Projekte werden in Funktionsblöcke unterteilt. Die einzelnen 
Funktionsblöcke beschreiben unabhängige, einzeln testbare Einheiten die 
eine bestimmte Funktionalität implementieren.
Wie bekannt können Generics dazu genutzt werden, solche Blöcke 
anzupassen bzw. Teilfunktionen weg zu lassen.

Gut getestete Funktionsblöcke möchte man in Zukunft auch in anderen 
Projekten einsetzen. Dabei können Fehler bei der Instantierung auftreten 
(Doku nicht gelesen/nicht vorhanden, anderer Entwickler etc.), diese 
Fehler sucht man dann lange, weil der Code ja älter ist und von jemand 
anderem geschrieben.

Ein assert das den betreffenden Generic überprüft gibt dem Entwickler in 
der Simulation schnell auskunft, dass er diesen Block falsch benutzt.

Ralf schrieb:
> Ich will nicht sagen, dass das falsch ist, aber doch zumindest im Sinn
> konträr, wenn auch innovativ. Machst Du das bei den INIT Werten für
> Signale auch so?

Signale mit Werten zu initialisieren ist nicht Synthesefähig, daher 
erledigt sich diese Frage schon.

Christoph Z. schrieb:
> Signale mit Werten zu initialisieren ist nicht Synthesefähig, daher
> erledigt sich diese Frage schon.

Das war vielleicht vor 20 Jahren mal so.

Christian R. schrieb:
> Christoph Z. schrieb:
>> Signale mit Werten zu initialisieren ist nicht Synthesefähig
> Das war vielleicht vor 20 Jahren mal so.
Naja, bei Lattice ist das gerade mal 5 Jahre her...   ;-)

Mein Studienabschluss ist ca. 6 Jahre her, das müsste damals also schon 
nicht mehr aktuell gewesen sein. Trotzdem wurde mir das an mehreren 
Stellen beigebracht.

Gibt es praktische Beispiele wo initialisierte Signale helfen und im 
Design von anderen auch akzepiert werden?

Christoph Z. schrieb:
> Gibt es praktische Beispiele wo initialisierte Signale helfen und im
> Design von anderen auch akzepiert werden?

Die sind doch in nahezu jedem Design nützlich, Zähler, State-Machines 
usw. und ressourcenschonender als ein (nicht wirklich benötigter) Reset 
sowieso. Selbst viele Beispiel-Codes von Xilinx arbeiten seit langem mit 
initialisierten Signalen. Und wieso sollten die nicht von anderen 
akzeptiert sein? Das ist doch eine wahnsinnige Erleichterung.
Aus dem WP272 von Xilinx:

1

A design implemented in a Xilinx FPGA does not require insertion of a global reset

2

network. For the vast majority of any design, the initialization state of all flip-flops and

3

RAM following configuration is more comprehensive than any logical reset will ever

4

be.

Christoph Z. schrieb:
> Mein Studienabschluss ist ca. 6 Jahre her, das müsste damals also schon
> nicht mehr aktuell gewesen sein.
Um es kurz zu machen: es war damals schon nicht mehr aktuell.

> Trotzdem wurde mir das an mehreren Stellen beigebracht.
Ja, das ist tragisch. Aber leider Realität...

Die Unterstützung der Init-Werte war schon immer mit abhängig davon, 
welches Synthesetool verwendet wurde. Aber ein SRAM-basiertes FPGA kann 
die Initialisierung systembedingt, weil ja soweiso jedes Flipflop beim 
Booten aus einem PROM/FLASH geladen wird.

Ralf schrieb:
> D.h. du schreibst Dir per generic etwas Unsinniges rein, um zu prüfen,
> ob Du bei der Programmierung das generic auch überschrieben hast?

Nein, das muss ja nichts Unsinniges sein, es ist einfach irgendein 
Default-Wert. Und wenn man das Modul dann halt nochmal braucht, aber in 
andere Wortbreite oder was auch immer, verwende ich generic map.
Prinzipiell hat Christoph das ganz gut beschrieben, wie ich das meinte:
Christoph Z. schrieb:
> HDL Projekte werden in Funktionsblöcke unterteilt. Die einzelnen
> Funktionsblöcke beschreiben unabhängige, einzeln testbare Einheiten die
> eine bestimmte Funktionalität implementieren.
> Wie bekannt können Generics dazu genutzt werden, solche Blöcke
> anzupassen bzw. Teilfunktionen weg zu lassen.
>
> Gut getestete Funktionsblöcke möchte man in Zukunft auch in anderen
> Projekten einsetzen. Dabei können Fehler bei der Instantierung auftreten
> (Doku nicht gelesen/nicht vorhanden, anderer Entwickler etc.), diese
> Fehler sucht man dann lange, weil der Code ja älter ist und von jemand
> anderem geschrieben.
>
> Ein assert das den betreffenden Generic überprüft gibt dem Entwickler in
> der Simulation schnell auskunft, dass er diesen Block falsch benutzt.

> Fabio W. schrieb:
>> hat da glaube ich jemand noch keine Generics verstanden?
> Bist du sicher, dass Du den Sinn verstanden hast?
Sicher nicht, aber das was ich bisher so gelesen habe, dachte ich, dass 
es so wäre, wie ich es glaube. Zumal ich keine Ahnung hätte, wozu ich 
generics sonst verwenden soll, außer zu genanntem Zweck. Alles andere 
geht doch mit Konstanten genauso, oder nicht? Ich mein mangels Erfahrung 
kann es auch sein, dass ich irgendetwas wichtiges vergesse...

Lothar Miller schrieb:
> Die Unterstützung der Init-Werte war schon immer mit abhängig davon,
> welches Synthesetool verwendet wurde. Aber ein SRAM-basiertes FPGA kann
> die Initialisierung systembedingt, weil ja soweiso jedes Flipflop beim
> Booten aus einem PROM/FLASH geladen wird.

Hmm, da ich erst ein paar Wochen 'dabei' bin, hab ich da noch keinen 
Überblick, aber warum wurde es denn überhaupt jemals nicht unterstützt 
mit Init-Werten? Waren das dann einfach keine SRAM-FPGAs oder wie? 
Lattice stellt ja glaube ich auch heute noch welche in 
Anti-Fuse-Technologie her, hab ich irgendwo gelesen, liegt das dann 
daran?

Fabio W. schrieb:
> Überblick, aber warum wurde es denn überhaupt jemals nicht unterstützt
> mit Init-Werten? Waren das dann einfach keine SRAM-FPGAs oder wie?

HDLs und die Tools dazu kommen hauptsächlich aus der Disziplin Chip 
Entwicklung. Einen Siliziumchip mit fixer Funktion (Also alles ausser 
FPGA/PLD) muss man nicht nach dem einschalten konfigurieren, man kann 
ihn nur Reseten.
Daher haben das die Synthese Tools auch lange nicht unterstützt, weil 
sie es nicht von Anfang an können mussten.

Darum habe ich das auch so in meiner Ausbildung gelernt, dass das nicht 
geht. Ich hatte nie FPGA spezifischen Unterricht, immer nur 
Digitaltechnik oder ASIC Design. Dann lernt man "ohne Init-Werte dafür 
mit Reset".

Ich habe mir dafür mal ein Modul gemacht, vielleicht ist es das was du 
brauchst:
http://www.mikrocontroller.net/articles/Clockgenerator_in_VHDL


Erst auf 16kHz runter, die anderen Frequenzen dann über Teiler.

Frank schrieb:
> Altera FPGAs haben doch einen (asan)Reset und der kostet auch nicht mehr
> resourcen, meine ich mal gelesen zu haben.
Du solltest dein Wissen updaten. Altera hat zwar ein globales Resetnetz 
in ihren FPGAs. Aber auch Altera empfihelt, den asynchronen Reset erst 
mal einzusynchonisieren und dann erst zu verwenden (= Synchronized 
Asynchronous Reset).
Und spätestens bei der 2. Taktdomäne ist der Vorteil des einen globalen 
Resetnetzes dahin und jedes Flipflop der zweiten Domäne muss vom Router 
extra verdrahtet werden.

> Propagiert Xilinx dies nur, weil sie ihn elimiert haben?
Es ist nur konsequent, etwas einzusparen, was keinen echten Wert hat.

> Wer sagt, dass der nie benötigt wird?
Wenn ich einen Reset benötige, dann nicht für das ganze FPGA. Und wenn 
doch, dann zerre ich kurz an der Programmierleitung und lade das FPGA 
neu...

Xilinx schrieb:
> A design implemented in a Xilinx FPGA does not require insertion of
> a global reset network. For the vast majority of any design,
> the initialization state of all flip-flops and RAM following
> configuration is more comprehensive than any logical reset
> will ever be

Mit der Darstellung gehe ich aus 3 Gründen nicht so 100% konform:

1. Ist das nicht (mehr ?) wirklich eine Besonderheit der Xilinx-FPGAs, 
wobei ich natürlich nicht sicher bin, ob man das als Wettbewerbsvorteil 
herausstellen wollte.

2. Ist das nicht der "logische", sondern der "physische" Reset - 
insbesondere, wenn er asynchon angewendet wird. s.u.

3. Ist das auch kein vollständiger *re*-set, der mit dem eines ASIC 
vergleichbar wäre.

Der einmalige INIT-Vorgang ist schon deshalb funktionell nicht dasselbe, 
wie ein wirklicher (zur Laufzeit) durchfürbarer Reset, weil er nicht in 
einem Takt durchführbar ist, insbesondere dann nicht, wenn er ein 
synchroner ist, was er unter Zuhilfenahme der fabric logic in aller 
Regel ja sein muss - siehe Xilinx-eigene Docu.

Weiters ist nur ein echter Reset in der Lage, alle state machines und 
Register zu initialisieren, ohne dass die Ausgänge auf "Z" gehen, wie 
bei einem reboot-vorgang des FPGAs. Aus FPGA-Sicht mag das logsich 
Dasselbe sein, aus Schaltungssicht aber nicht. Dies gilt speziell dann, 
wenn man Teile der Schaltung logisch resetten will, um Module zu starten 
oder gar im Fall eines irgendwie gearteten (strahlungsbedingten) 
Ausfalls komplett neu initialisieren muss, ohne den Rest anzufassen.

Ganz pauschal in allgemeinen Designs für FPGAs keinen Reset vorzusehen, 
ist daher nicht so zielführend. Wenn Code verschieden genutzt werden 
muss, braucht er eine logischen (für dieses Modul aktiven) Reset in der 
richtigen clock domain (und damit gfs mehrere Resets bei mehreren 
Domains!) und er benötigt zusätzlich auch noch einen asynchronen Reset, 
wenn das VHDL mal ins ASIC wandern soll.

aReset, sReset, lReset und INIT sind jeweils verschiedene Paar Schuhe 
und nur im Spezialfall gegeneinander austauschbar.

Frank schrieb:
> Propagiert Xilinx dies nur, weil sie ihn elimiert haben?
Wenn Xilinx physikalisch in den FPGAs keinen (asynch! Reset) einbaut, 
ist das durchaus richtig so, denn in der Tat wird damit teure Fläche 
verbraten. Das bedeutet aber noch lange nicht, dass man in der 
Beschreibung keinen drin haben darf und muss, denn es gibt auch Designs 
für PLDs, die kein INIT haben.

Dass man bei Xilinx zudem keinen synchronen Reset einbauen muss, weil 
man zur Laufzeit keinen braucht und zur Startzeit ja der INIT alles 
erledigt, ist auch kein heiliger Gral sondern nur eine Option, die genau 
dann gilt, wenn man zur Laufzeit auch wirklich keinen braucht. Das 
aber ist nicht in allen Designs so - siehe "logischer" oder sagen wir 
besser "funktioneller" Reset.

Dieser ist in vielen Designs / Modulen übrigens durchaus enthalten, 
wenngleich meistens implizit, z.B. bei state machines, die von einer 
übergeordneten FSM mit dynamischem timing gesteuert werden: Die werden 
per Signal in einen Startzustand gesetzt oder in einem Haltzustand 
gehalten, um von dort aus loszulaufen. Haben alle Module so ein 
Zustandsverhalten, haben wir eine Art globalen Reset.

Frank Petelka schrieb:
>> Wenn ich einen Reset benötige, dann nicht für das ganze FPGA.
> Aha, dann reicht also doch ein Resetnetz für die wenigen resetwilligen
> FFs, oder?
Das eine Netz würde reichen, wenn alle FF in der selben Taktdomäne 
wären.

> Warum sollte man nicht einen Rest für alle Domänen nutzen können?
Weil ein wirklich asynchroner Reset von keinem FPGA Hersteller als 
sinnvoller Weg beschrieben wird.

> Das ist klar- aus den bekannten Gründen. Trotzdem ist das Resetnetz bei
> Altera ja offenbar eine vorhandene Resource, die - wenn sie genutzt wird
> - keine freien Resourcen verbrät, wie der Reset bei Xilinx ?
Das Resetnetz ist auch bei Xilinx da und wird für den Bootvorgang 
verwendet. Und ich bin mir nicht ganz sicher, ob ich nach dem 
empfohlenen Einsynchronisieren bei Altera wieder so einfach auf das 
Resetnetz komme.

>> Du solltest dein Wissen updaten.
> Daher frage ich ja den FPGA-guru Miller :-)
Ich würde mir nie einfach so glauben. Aber das Alles kann man in 
Datenblättern und Appnotes jedes Herstellers nachlesen...

Frank Petelka schrieb:
> Lothar Miller schrieb:
>> Wenn ich einen Reset benötige, dann nicht für das ganze FPGA.
> Aha, dann reicht also doch ein Resetnetz für die wenigen resetwilligen
> FFs, oder?
Nur was einen asynchronen angeht und das ist der, den man im FPGA 
seltener braucht. Siehe meine Ausführung oben logischer <-> synchroner 
Reset.

>> Und wenn doch, dann zerre ich kurz an der Programmierleitung und lade
>> das FPGA neu...
> hart aber herzlich, ok.
Das wie gesagt geht nur, wenn der FPGA eine Weile "tot" sein darf. Das 
Wiederladen eines FPGAs kann mitunter recht lange dauern und in der Zeit 
ist die Schaltung, die vom FPGA gesteuert wird, ebenfalls tot. Im 
ungünstigsten Fall geht durch die hochohmigen Pins etwas kaputt wie z.B. 
bei einer ungesteuerten Leistungsschaltung bzw bei dem, was dranhängt 
(da hätte ich ein Beispiel) oder aber es verursacht einen Geräteabsturz, 
bzw im Fall einer Triebwerksregelung einen Flugzeugabsturz (auch da 
hätte ich einen Fall parat).

In solchen Fällen muss der FPGA arbeiten, wie ein ASIC: Mit einem Takt 
global in einen definierten Urzustand, von dem aus das gesamte board 
wieder garantiert sauber arbeitet. Dieser Reset ist dann quasi Teil der 
use cases.

Jürgen Schuhmacher schrieb:
> Im ungünstigsten Fall geht durch die hochohmigen Pins etwas kaputt wie
> z.B. bei einer ungesteuerten Leistungsschaltung bzw bei dem, was
> dranhängt (da hätte ich ein Beispiel) oder aber es verursacht einen
> Geräteabsturz, bzw im Fall einer Triebwerksregelung einen
> Flugzeugabsturz (auch da hätte ich einen Fall parat).
Spätestens beim ersten Power-Up muss die Schaltung diesen 
Betriebszustand sowieso aushalten...
Aber einfach mal so zwischendurch an der Resetleitung zu zupfen ist idR. 
von unbrauchbarem Schaltungsverhalten begleitet. Und meist ist ja gerade 
ein Systemabsturz die Ursache für einen Reset. Was hilft es dann dem 
Leistungsteil, wenn die Ansteuersignale zwar gültige Pegel, aber 
sinnlose statische Zustände haben? Oder dem Flugzeugtriebwerk?
(Wobei ich fast glaube, dass im Falle des Flugzeugs noch mehr 
ausgefallen sein musste, denn das Ding fällt ja nicht wie ein Stein vom 
Himmel, wenn mal ein Triebwerk ausfällt...)

Mir ist klar, dass es im einzelnen Fall Gründe für lokale und evtl. 
sogar asynchrone Resets gibt. Diese Spezialfälle zu verallgemeinern und 
zur Regel zu erheben, das finde ich aber sehr gewagt.

FPGA-Progger schrieb im Beitrag #3590311:
> Diskutiert ihr eigentlich noch über die 50MHz zu 16kHz?
> oder übers resetten?
Naja, weil das Thema an sich relativ Anfängerlastig ist, ist es auch 
nicht schlecht, im selben Thread über Clock-Enables, die numeric_std und 
den Reset zu diskutieren...