Hallo, ich hab gerade einen Taktteiler gebaut mit 50% Tastverhältnis! nun wollte ich den verwenden. Allerdings dachte ich, dass man immer nur nach der Flanke des Haupttaktes abfragt also: if (CLK'event and CLK = '1') then ...... und der Abgeleitete Takt nur als Enable-Signal verwendet wird, damit nachher auf dem Chip alles taktmäßig ordentlich geroutet wird? also if (CLK'event and CLK = '1') then if CLK2 ='1' then -- CLK2 als Enable-Signal ..... und nicht den neuen CLK2 alleinig abfragt wie hier if (CLK2'event and CLK2 = '1') then natürlich ist klar, dass der CLK2 als Enable-Signal nicht das Tastverhältnis von 50% haben darf, sondern nur einen Haupttakt lang gesetzt ist!?!?!
naja die Frage ist, ob es sinnvoll ist ein Takt zu generieren und dann später nur dieses Signal abzufragen statt ein Clockenable zu generieren und dieses gemeinsam mit dem Haupttakt abzufragen?
In FPGAs wird sinnvollerweise nur mit Clockenables gearbeitet. Dann ist man immer schön synchron zu dem Ausgangstakt. Durch (sequentielle) Logik generierte Signale sollte man möglichst nicht direkt als Takteingang sequentieller Elemente wie FF verwenden. Du liegst also mir deiner Vermutung genau richtig.
wusst ich doch, dass das so sonst "sch*****" ist, hab ich doch was bei Herrn Reichardt gelernt! Aber warum gibt es denn überhaupt so viele Beispiele, in denen Taktteiler vorgestellt werden statt Takt-Enable-Generatoren???
Gerd M. schrieb: > Aber warum gibt es denn überhaupt so viele Beispiele, in denen > Taktteiler vorgestellt werden statt Takt-Enable-Generatoren??? Weil das mit VHDL möglich ist. Und viele Bücher über die /Syntaxelemente von VHDL/ geschrieben wurden, aber nur wenige über /VHDL für FPGAs/. Und weil es schön einfach nachvollziehbar ist. Und weil die Simulation das locker packt. Und weil viele gleich ihre ersten Ergüsse ins Netz stellen müssen. Und weils bei ASICs durchaus möglich ist, so einen neuen Takt zu erzeugen. Und ....
Lothar Miller schrieb: > Weil das mit VHDL möglich ist. > Und viele Bücher über die /Syntaxelemente von VHDL/ geschrieben wurden, > aber nur wenige über /VHDL für FPGAs/. > Und weil es schön einfach nachvollziehbar ist. > Und weil die Simulation das locker packt. > Und weil viele gleich ihre ersten Ergüsse ins Netz stellen müssen. > Und weils bei ASICs durchaus möglich ist, so einen neuen Takt zu > erzeugen. > Und .... Und weil ein Taktteiler und ein "Taktenablegenerator" exakt das gleiche ist. Entscheidend ist, wie das erzeugte Signal verwendet wird.
Da Dieter schrieb: > Und weil ein Taktteiler und ein "Taktenablegenerator" exakt das gleiche > ist. Entscheidend ist, wie das erzeugte Signal verwendet wird. Gilt natürlich nur für einen Teiler durch 2. Ansonsten ist es natürlich nicht das gleicht ;-)
Lothar Miller schrieb: > Und weils bei ASICs durchaus möglich ist, so einen neuen Takt zu > > erzeugen. in FPGAs ist das auch möglich, nur halt nicht vorgesehen und damit schwer zu handhaben. Das geht dann in richtung low level design, das oft unnötig und nicht selten schlechter ist. Taktteiler im FPGA und manuel erzeugte Takte sind in FPGAs nur in seltenen Fällen sinnvoll. Abgeleitete Takte mit anderen Frequenzen sind immer aus PLLs / DCMs zu beziehen, weil die physikalischen Strukturen das genau so vorsehen.
Robert schrieb: > Taktteiler im FPGA und manuell erzeugte Takte sind in FPGAs nur in > seltenen Fällen sinnvoll. Um z. B. die elektrische Leistung zu verringern ... Solange die kürzeren Takte nirgends weiter verwendet werden, macht es daher schon gelegentlich Sinn, herunterzuteilen, bevor es in die Clock-Netze geht. > Abgeleitete Takte mit anderen Frequenzen sind immer aus PLLs / DCMs zu > beziehen, weil die physikalischen Strukturen das genau so vorsehen. Das "immer" gilt z. B. nicht für Raumfahrtanwendungen, wo PLLs & Co. gar nicht verwendet werden können, da diese Teile viel zu SEU-empfindlich sind und es dort i. d. R. keine TMR-Architektur gibt. Die Auswahl an Space-FPGA ist aber ohnehin stark eingeschränkt.
> wo PLLs & Co. gar nicht verwendet werden können Doch, gibt's und werden verwendet, zB. im ATC18RH-Prozess: http://www.atmel.com/images/doc4261.pdf
Ich hänge mich mal hier an den Thread. Ich hab das mit Clock Enable zwar schon verstanden, aber mit dem Ergebnis bin ich unzufrieden. Und zwar mit den sich ergebenden Timings. Ich habe ein externes Taktsignal von 32 MHz. Ich verarbeite Daten in einem mit diesem Clock-Signal getakteten Prozess. Ich will einen zweiten, internen Takt von 8 MHz für einen zweiten Prozess erhalten. Der zweite Prozess enthält viel kombinatorische Logik, daher kann dort die Taktfrequenz auch nicht sehr hoch werden, 8 MHz muss ich aber trotzdem erreichen. Wenn ich jetzt wie im Wiki "Taktung FPGA/CPLD" beschrieben vorgehe, und einen 2 Bit-Zähler implementiere, erhalte ich eine maximale Taktfrequenz von unter 30 MHz für meinen ersten Prozess nach der Synthese und PAR. Lasse ich den Taktzähler und CE weg und nehme stattdessen einen (eigentlich nicht vorhandenen) externen Takt von 8 MHz für meinen zweiten Prozess, habe ich keine Timingprobleme und beide Prozesse werden für Taktraten >32 resp. 8 MHz synthetisiert. Ist das normal, und gibt es für dieses Verhalten eine Lösung?
Chris2k schrieb: > Ist das normal, Ja. > und gibt es für dieses Verhalten eine Lösung? Nimm Multi Cycle Constraints. Damit kannst du dem Synthesizer sagen, dass er für die langsamen Pfade jeweils 4 Takte Zeit hat...
Danke für das Stichwort. Hab jetzt etwas herumprobiert, gegoogelt und PDFs gelesen, aber funktionieren tut nichts. Naja, ich widme mich erstmal anderen Problemen :)
Georg A. schrieb: >> wo PLLs & Co. gar nicht verwendet werden können > > Doch, gibt's und werden verwendet, zB. im ATC18RH-Prozess: > > http://www.atmel.com/images/doc4261.pdf Es ging auch um FPGAs, nicht um ASICs. RT- und RH-FPGAs haben überwiegend alle Elemente ihrer "Normal"-Pendants. Dennoch sind davon einige, wie Memory-Blöcke und PLLs, mit größerer Vorsicht zu genießen. Die SEL-Schwelle und die total-dose liegen zwar ohne zusätzliche Abschirmmaßnahmen schon im Verträglichen, aber die SEU-Empfindlichkeit variiert untereinander immer noch um Größenordnungen. Das gab es bereits seit der ersten RH-FPGA-Generation (z. B. Actel A1020-RH, später A1280-RH u. s. f), so dass man sequentielle Logik selbst noch z. B. durch TMR absichern musste. Kombinatorische Zellen waren ok. Inzwischen wird bei den RH-FPGA überwiegend TMR schon auf S-Zellbasis zur Verfügung gestellt (3 FFs plus voter). Bei analogen Schaltungsteilen funktioniert das aber nicht so einfach. Hin und wieder gibt es auch noch eine Reihe anderer Einschränkungen zu beachten. Es ist auf keinen Fall so, dass man einen RH-FPGA einsetzt und meint, alles ginge wie immer, nur dazu noch trittfest. Statt PLLs setzen wir, wenn nötig, entsprechend hohe Eingangstaktraten ein und teilen ggf. herunter für langsamere Schaltungsteile. Synchronisieren kann man als Alternative immer noch zwischen verschiedenen Clock-Domänen, z. B. mit asynchronen FIFOs (Gray-coded). Summa summarum ergibt das u. U. einen geringeren Leistungsbedarf, obwohl nur die Clocknetze selbst betroffen sind. Für die Anzahl an Umladungen in der eigentlichen Logik macht es ja keinen Unterschied, ob der Clock geteilt ist oder ein Enable-Signal anliegt. Das Enable-Signal muss allerdings auch noch verteilt werden, ist aber bereits so langsam, wie der geteilte Clock. Die Review-Boards sehen allerdings auch lieber ein völlig synchrones Design, wenn möglich. Die WCAs sind übersichtlicher, da man nicht alles gegen alles abschätzen muss. Allerdings spielt elektrische Leistung immer noch eine große Rolle. Einen Lüfter kann man halt nicht mitnehmen. Es ging mir eigentlich nur darum, dass behauptet wurde, PLLs würden IMMER eingesetzt werden. Bevor wir seit einigen Jahren CPUs nur noch als Cores in RH-FPGA (aber auch RH-ASICs) verbaut hatten, gab es übrigens auch schon einige RH-CPU-Ansätze. Bei denen durften dann die Caches nicht verwendet werden u. s. w. Das sprengt jetzt aber das Thema komplett. Sry für die kurze Störung DF1AS
> Es ging auch um FPGAs, nicht um ASICs. Für die PLLs macht das prinzipiell keinen Unterschied ;) Aber es stimmt natürlich, dass PLLs in dem Anwendungsbereich mit etwas mehr Analyse eingesetzt werden... > Sry für die kurze Störung Ach wo... Die meisten wissen doch gar nicht, dass in der ach so modernen "Raketentechnologie" quasi Steinzeit-Technologie eingesetzt werden muss...
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.