Hi, habe nun schon ein paar Beiträge zum Thema Frequenzteiler gefunden aber so richtig helfen tun die mir bei meinem Problem nicht. 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. Mein Problem ich kann den Ursprungstakt doch immer nur halbieren oder? So komme ich aber nicht auf die gesuchten Frequenzen... wie kann ich das mithilfe von Countern erreichen? Außerdem, steht als "Zusatzangabe" in meiner Aufgabe sowas: "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." 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?
@ 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")
:
Bearbeitet durch Moderator
Lothar Miller schrieb: > Der Vorschlag wird von Anfängern dann gern falsch umgesetzt.: Stimmt, das beruehmte +-1 Problem :=)
Achso, ich glaub nun ist der Groschen gefallen. Die '0' und '1' Zeiten des geteilten Taktes müssen nicht gleichlang sein, ich dachte das wäre für den Takt vorraussetzung. Dann versteh ich das auch mit dem Zähler...danke war sehr hilfreich :)
Also brauch ich für 2 Hz einen Zähler der nach 25 Millionen Schritten Synchron auf 0 zurückgesetzt wird? Bzw halt -1 wg der führenden 0?
Vielleicht könnt ihr mir auch hierzu kurz sagen was ich falsch gemacht
hab,
bin leider noch nicht sonderlich fit in VHDl und hab mitlerweile echt
viel Probiert, er sagt mir nun immer das ich die Operation mit zaehler
im if nicht durchführen kann:
"entity genFrequenzteiler is
generic(teiler: positive);
port(
clk_i, reset_i :in std_logic;
freqXXhz_o: out std_logic
);
begin
--synthesis off
assert(teiler >=2) report "Der Teiler ist zu klein" severity failure;
--synthesis on
end genFrequenzteiler;
architecture Behavioral of genFrequenzteiler is
signal zaehler: natural range teiler - 1 downto 0;
begin
zustandsuebergangsfunktion: process(clk_i)
begin
if rising_edge(clk_i) then
if reset_i = '1' then
freqXXhz_o <= '0';
zaehler <= zaehler'high;
elsif zaehler = '0' then
freqXXhz_o <= '1';
zaehler <= zaehler'high;
else
freqXXhz_o <= '0';
zaehler <= zaehler - 1;
end if;
end if;
end process;
end Behavioral;"
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.
:
Bearbeitet durch User
Ah okay in Anführungszeichen ist also immer Bitweise ... gut wieder was gelernt. Danke dir
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?
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!
D.h. du schreibst Dir per generic etwas Unsinniges rein, um zu prüfen, ob Du bei der Programmierung das generic auch überschrieben hast? Fabio W. schrieb: > hat da glaube ich jemand noch keine Generics verstanden? Bist du sicher, dass Du den Sinn verstanden hast? 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?
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".
Christoph Z. schrieb: > ASIC Design. Dann lernt man "ohne Init-Werte dafür > mit Reset". Dito. Das muss man dann halt jeweils unterscheiden, was man bauen will und wofür.
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.
Sind das nun richtige Takte oder einfach einables? Wozu braucht man da ein komplexes Modul? Nochmal was hierzu: Christian R. schrieb: > Zähler, State-Machines usw. und ressourcenschonender als ein > (nicht wirklich benötigter) Reset sowieso. Wer sagt, dass der nie benötigt wird? > Selbst viele Beispiel-Codes von Xilinx arbeiten seit langem mit > initialisierten Signalen. Ob Xilinx der Massstab ist? Altera FPGAs haben doch einen (asan)Reset und der kostet auch nicht mehr resourcen, meine ich mal gelesen zu haben. Propagiert Xilinx dies nur, weil sie ihn elimiert haben?
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...
Lothar Miller schrieb: > 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. Daher frage ich ja den FPGA-guru Miller :-) > Altera hat zwar ein globales Resetnetz in ihren FPGAs Also war mein Wissen doch so falsch nicht :-) > Aber auch Altera empfihelt, den asynchronen Reset erst mal > einzusynchonisieren und dann erst zu verwenden 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 ? > 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. Warum sollte man nicht einen Rest für alle Domänen nutzen können? Wenn das aus nicht geht, würde es auch nur die FFs der Sonderdomäne betreffen und ein Verteil in der Hauptdomäne bestünde immer noch, oder? > 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? > Und wenn doch, dann zerre ich kurz an der Programmierleitung und lade > das FPGA neu... hart aber herzlich, ok.
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...
:
Bearbeitet durch Moderator
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.
Lothar Miller schrieb: >> Daher frage ich ja den FPGA-guru Miller :-) > Ich würde mir nie einfach so glauben. der war gut ,,, Diskutiert ihr eigentlich noch über die 50MHz zu 16kHz? oder übers resetten?
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...
FPGA-Progger schrieb im Beitrag #3590311: > oder übers resetten? Das hier ist die obligatorische Reset-Diskussion, die minestens einmal pro Jahr stattfindet :-)))
Die gesamte Diskussion wurde ohnehin nur wieder in Gang gesetzt, weil der TE von "Taktteilung" spricht. Vermutlich tut er das, weil es in seiner Hausaufgabe, die es ja offensichtlich ist, auch so drin steht. In digitalen Schaltungen wie FPGAs, (Basteldesigns, alte Bautechnik mit 74er und Gespiele mal aussen vor gelassen) werden keine Frequenzteiler benutzt, um Schaltungen zu treiben sondern je Taktdomain ein einziger Takt, bei möglichst wenigen Domains. Alles geht über enables die vorher passend gesetzt werden müssen. Das Resultat ist eine vollsynchrone Schaltung mit Zustandswechseln nur zum Taktzeitpunkt und nicht innerhalb von Taktperioden. Es gibt keine ge"gate"eten clocks und auch keine latches, die Zwischenschaltzeitpunkte erzeugen. Würden die Lehrherren das den Jungdigitalos mal klar und deutlich verabreichen, wären 90% der Fragereien in Digitalforen unnötig.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.