Hallo zusammen, mir ist bewusst wie wichtig die Eintaktung von asynchronen Signalen ist, allerdings ist meine Anwendung zeitkritisch: Ich habe ein 1 Bit Eingangssignal welches ich auf Flanken prüfen muss, um dann schnellstmöglich an den Ausgängen darauf zu reagieren. Bei einer regulären Eintaktung + sync. Flankenerkennung (mittels Schieberegister + Auswertelogik) komme ich auf min 3 Takte Verzug. Bei 100 MHz Taktfrequenz sind das 30 ns, was für meine Anwendung nicht möglich ist. Daher die Frage: ist es möglich die Eintaktung + sync. Flankenerkennung mit einer SerDes-Schnittstelle zu realisieren? Konkret war meine Idee das 1-Bit Eingangssignal mit der SerDes-Schnittstelle abzutasten und diese als Schieberegister zu konfigurieren (wie beim herkömmlichen Ansatz). Beispiel: FPGA-Systemtakt 125MHz SerDes-Takt 500MHz -> 4-Bit Schieberegister als parallele Datenausgabe ins FPGA Jetzt für die Flankenauswertelogik im FPGA Bit 4 + 3 des Schieberegisters verwenden. Damit benötigt die Eintaktung + sync. Flankenerkennung nur noch einen FPGA-Systemtakt statt wie zuvor drei. Liege ich da richtig oder lässt sich das nicht realisieren? Für jegliche Unterstützung bin ich dankbar.
Jens Simon schrieb: > Liege ich da richtig oder lässt sich das nicht realisieren? Das kannst du schon so relaisieren. Aber du gewinnst noch nichts dabei. Denn wenn du das Serdes-Register anschaust musst du ja trotzdem noch einen Takt warten. du kannst also nicht sofort auf das Serdes-Register reagieren, sondern musst das ja erst noch auslesen. Oder dein Design muss > Jetzt für die Flankenauswertelogik im FPGA Bit 4 + 3 des > Schieberegisters verwenden. Und wenn deine Flanke zwischen Bit 2+3 oder zwischen Bit 1+2 des Serdes-Registers passiert? Sieh dir das mal an, das wird gleich schnell regieren können, du musst nur das letzte FF der Kette weglassen: http://www.lothar-miller.de/s9y/archives/19-Kurzer-Spike-in-Puls-umgewandelt.html
:
Bearbeitet durch Moderator
Oder du taktest auf steigende und fallende Taktflanke:
rising_edge_prc: process(clk)
begin
...
if rising_edge(clk) then
s_d0 <= i_signal;
s_d2 <= s_d1;
end if;
end process;
falling_edge_prc: process(clk)
begin
...
if falling_edge(clk) then
s_d1 <= s_d0;
end if;
end process;
s_edge <= s_d2 xor s_d1;
Valko Zapalko schrieb: > s_edge <= s_d2 xor s_d1; Aber Achtung: das verdoppelt bei symmetrischem Takt die Taktfrequenz (weil eben die noch verbleibende Zeit für die Logik halbiert wird) Und die Taktfrequenz wird bei asymmetrischem Takt sogar schnell mal verdreifacht, wenn z.B. der Takt ein 1:3 Tastverhältnis (oder eben ein 2/1 high/low Verhältnis) hat.
Verrate uns doch mal ein bisschen mehr darüber. Vielleicht gibt es ja noch einen anderen Ansatz. Gibt es zu diesem Signal auch einen externen Takt? Was muss mit diesem Signal im FPGA gemacht werden? Vielleicht lässt sich das auch ganz ohne Einsynchronisieren direkt am Pin lösen. Außerdem lässt sich eine Flankenerkennung bei diesen Frequenzen auch noch gut mit 2 FFs realisieren. Also 2 Systemtakte Verzug.
@ Lothar Miller: Vielen Dank, den Denkfehler habe ich erkannt. Allerdings verstehe ich den Typ mit dem async. FF nicht, da das Eingangssignal seinen Pegel definitiv mehrere Takte halten wird. @ Valko Zapalko: Eine solche Taktvervielfachung habe ich direkt ausgeschlossen, da der max. mögliche Systemtakt doch von den Clock-to-Output Zeiten tCO der internen Module abhängt. Will ich in einem Takt zwei FF aufrufe "unterbringen" muss ich auch zwei tCO unterbringen können und begrenze damit wieder den max. Systemtakt. Also habe ich doch nichts gewonnen? @ Schlumpf: Eine Flankenerkennung mit 2 FF? Um damit eine Flanke zu erkennen müsste man ja den Ausgang des ersten FF nutzen. Meine Ansteueung (siehe unten) ist über eine FSM realisiert. Wenn nun das erste FF verdoppelt wird (Fan-Out zu niedrig) ist die Funktion des gesamten Designs nicht mehr sichergestellt. Oder sehe ich das falsch? @ all: Allg zur Anwendung: Ich möchte eine digitale Frequenzregelung im einstelligen MHz-Bereich aufbauen. Die Regelgröße ist die Periodendauer des Stroms (1-10 MHz), der über einen Übertrager auf eine Diodenbrücke gegeben wird. Diese erzeugt nun ein digitales Signal (pos. Stromhalbwelle = '1', neg. Stromhalbwelle = '0'). (=> Also kein externer Takt) Über die Zeit zw. den Flanken kann ich zum einen die Periodendauer ermitteln. Das ist noch relativ unproblematisch, muss aber auch zeitnah geschehen. Des Weiteren müssen bei Auftreten einer Flanke im Eingangssignal möglichst zeitnah die richtigen Signalpegel für die Ansteuerung am Ausgang des FPGAs eingestellt werden. Hier kann ich mir keinen großen Verzug erlauben. Bsp. f_Strom = 10 MHz => 100 ns f_FPGA = 100 MHz => 10 ns Bei einem Eintaktvorgang mit 3 Takten + 1 Takt Verarbeitung im FPGA sind das schon 40 ns. Dazu kommt noch das Prop. Delay der Hardware, welches wesentlich höher ist...
Jens Simon schrieb: > Bei einem Eintaktvorgang mit 3 Takten + 1 Takt Verarbeitung im FPGA sind > das schon 40 ns. Zum Eintakten reicht bei diesen Frequenzen evtl. schon 1 einziges Flipflop. Danach noch eines für die Flankenerkennung. Mehr als 1 Flipflop ist nötig, wenn die Last für dieses Flipflop zu groß wird und Register-Duplication angewendet werden muss. Jens Simon schrieb: > Allerdings verstehe ich den Typ mit dem async. FF nicht Der wird dir hier in der Tat auch nichts helfen. Er ist sogar eher kontraproduktiv, wenn ich mir das nochmal so anschaue...
Jens Simon schrieb: > @ Schlumpf: > Eine Flankenerkennung mit 2 FF? > Um damit eine Flanke zu erkennen müsste man ja den Ausgang des ersten FF > nutzen. Meine Ansteueung (siehe unten) ist über eine FSM realisiert. > Wenn nun das erste FF verdoppelt wird (Fan-Out zu niedrig) ist die > Funktion des gesamten Designs nicht mehr sichergestellt. > Oder sehe ich das falsch? bei diesen Frequenzen ist die Metastbilität des Ausgangs eines FFs mit sehr großer Wahrscheinlichkeit abgeklungen, bevor die nächste Taktflanke kommt. Daher ist zum Zeitpunkt des Auftretens der zweiten Taktflanke der Ausgang stabil und kann in das zweite Register übernommen werden.
1 | ---- ---- |
2 | | | | | |
3 | CLK ---- ---- ---- |
4 | |
5 | D 0000111111111111111111111 |
6 | Q1 0000XX1111111111111111111 |
7 | Q2 0000000000000001111111111 |
8 | Q1XQ2 0000XX1111111110000000000 |
9 | ^ |
10 | Hier wird die Flanke erkannt |
....oder...
1 | ---- ---- ---- |
2 | | | | | | |
3 | CLK ---- ---- ---- |
4 | |
5 | D 000011111111111111111111111111 |
6 | Q1 0000XX000000000111111111111111 |
7 | Q2 000000000000000000000000011111 |
8 | Q1XQ2 000000000000000111111111100000 |
9 | ^ |
10 | Hier wird die Flanke erkannt |
Ich synchronisiere bei Frequenzen kleiner 200 MHz grundsätzlich immer nur mit einem Register ein und hatte noch gar nie Probleme.
:
Bearbeitet durch Moderator
Jens Simon schrieb: > Des Weiteren müssen bei Auftreten einer Flanke im Eingangssignal > möglichst zeitnah die richtigen Signalpegel für die Ansteuerung am > Ausgang des FPGAs eingestellt werden. Hier kann ich mir keinen großen > Verzug erlauben. Bei beiden Flanken oder nur bei einer Flanke? Falls nur bei einer Flanke, könnte die Ausgabe des Signals auch über ein Latch gelöst werden. Das ist natürlich erstmal böse, böse, böse, aber wenn man weiss, was man tut, kann man sowas schon gezielt einsetzen. Das LE wird dann direkt aus dem Eingangssignal abgeleitet Voraussetzung ist aber, dass das intern (synchron) gebildete Ergebnis deiner neuen Steuersignale VOR auftreten der Flanke des Eingangssignals anliegt. Ob das in deinem Fall so geht, muss man sich genau anschauen. Aber Prinzipiell kann man solche "Schweinereien" schon auch machen.
> Hups, jetzt hat es die Striche verschoben Nimm die [ pre ] und [ /pre ] Tags, dann passiert das nicht... Schlumpf schrieb: > Daher ist zum Zeitpunkt des Auftretens der zweiten Taktflanke der > Ausgang stabil und kann in das zweite Register übernommen werden. Aber das geht wie gesagt nur, wenn dieses erste Register nicht schon verdoppelt wird. Denn falls das passiert, hast du zwei Sync-Pfade, die um einen Takt versetzt sein können... So gehts:
1 | |
2 | ^ |
3 | | |
4 | | ____ |
5 | Pin ------------FF1--o----o---FF2----| | |
6 | | | | != |--- Flanke |
7 | | '----------|____| |
8 | v |
So ginge es evtl. schief:
1 | |
2 | |
3 | ^ |
4 | | |
5 | | ____ |
6 | Pin ------o-----FF1--o----o---FF2----| | |
7 | | | | | != |--- Flanke |
8 | | | '----------|____| |
9 | | v |
10 | | |
11 | | |
12 | | ^ |
13 | | | |
14 | | | ____ |
15 | '----FF1'--o----o---FF3----| | |
16 | | | | != |--- Flanke |
17 | | '----------|____| |
18 | v |
Lothar Miller schrieb: > Aber das geht wie gesagt nur, wenn dieses erste Register nicht schon > verdoppelt wird. Denn falls das passiert, hast du zwei Sync-Pfade, die > um einen Takt versetzt sein können... Logisch. Aber nachdem am ersten Register ja ausser dem Eingang des zweiten Registers und dem Eingang des XORs nichts weiter hängt, sollte man davon ausgehen können, dass keine Duplication durchgeführt wird. Aber klar, du hast schon recht.. man muss sich die Stelle anschauen.
Schlumpf schrieb: > Aber nachdem am ersten Register ja ausser dem Eingang des zweiten > Registers und dem Eingang des XORs nichts weiter hängt Naja, wenn ich sowas schreibe:
1 | process (clk) begin |
2 | if rising_edge(clk) then |
3 | if (ff1='1' and ff2='0) then -- steigende Flanke |
4 | Zweihundert_Bit_Vektor <= Zweihundert_Bit_Vektor + 1; |
5 | end if; |
6 | end if; |
7 | end process; |
Dann hängen an ff1 und ff2 schon mal je 200 LUTs... :-o
:
Bearbeitet durch Moderator
Klar, man muss natürlich aufpassen und sich Gedanken drüber machen. Aber hier ging es ja um die generelle Frage, ob es zwingend notwendig ist, immer zweistufig zu synchronisieren. Und diese Frage kann man eben mit NEIN beantworten. In dem von dir gezeigten Fall könnte man z.B. das "Flanke erkannt" Signal über ein Register führen und dieses Register dann auswerten. Ok, dann wäre das Signal auch wieder um einen Takt verzögert, aber mit der eigentlichen Synchronisierung hat es nichts zu tun, sondern man verhindert eben das Problem, das auftreten kann, wenn es zu einer Register-Duplication kommt.
Vielen Dank für die vielen Tipps und Anregungen!
Ich fasse kurz zusammen:
Eine Einsync. + Flankenerkennung kann bei Taktfreq. unter 200 MHz
durchaus mit 2 FF realisiert werden, allerdings muss sichergestellt
sein, dass kein Register Doubling des ersten FF vorgenommen wird.
Ist das bei folgendem Code sichergestellt oder bedarf dies immer einer
Kontrolle im Design?
signal SR : std_logic_vector(1 downto 0); --Schieberegister für
Einsync.
process(CLK)
begin
if rising_edge(CLK) then
SR <= SR(0) & IN_ASYNC;
end if;
end process;
IN_SYNC <= SR(1) xor SR(0); --Einsync. + Flankenerkennung
Hier wird nur der kombinatorisch erzeugte Ausgang IN_SYNC in der
weiteren Schaltung verwendet. Daher sollte ein Register Doubling doch
sicher unterbunden sein oder?
Eine weitere Frage noch:
Die einfachste Möglichkeit das Gesamtdelay des Designs gering zu halten
ist eine hohe Taktfrequenz. Leider habe ich kaum Erfahrung welche FPGAs
bzw. Hersteller in dieser Anforderung führend sind. Aus den
Datenblättern kann man dazu kaum brauchbare Infos extrahieren, da jeder
Hersteller sein Produkt in den Himmel lobt und die dort angegebenen max.
Taktfrequenzen doch nur für ganz einfache Algorithmen gelten und
praktisch nicht erreichbar sind.
Kann mir jemand konkret einen Baustein bzw. Hersteller für hohe
Systemfrequenzen (ich denke an >500 MHz) nennen?
Der Algorithmus ist nicht sehr umfangreich, daher sollten die
Ressourcenanforderungen zweitrangig sein.
Ich habe mich in Hardware und Design Tool von Lattice eingearbeitet,
mittlerweile allerdings erfahren, dass Lattice eher für LowCost
Bausteine steht. Ist das so richtig?
Jens Simon schrieb: > Daher sollte ein Register Doubling doch sicher unterbunden sein oder? Nein, denn genau das SR(0) kann hier problemlos verdoppelt werden. > Hier wird nur der kombinatorisch erzeugte Ausgang IN_SYNC in der > weiteren Schaltung verwendet. Der Name IN_SYNC ist nur eine Hilfestellung für dich. Abhängig von der weiteren Verwendung fliegt er bei der Synthese eh' raus, und wird mit anderen Signalen zusammen in eine LUT gepackt. Der Synthesizer wäre z.B. ja ein recht dummes Tool, wenn er nicht noch bis zu 4 andere Signale mit in eine 6er-LUT packen würde... Jens Simon schrieb: > Eine weitere Frage noch: Die einfachste Möglichkeit das Gesamtdelay des > Designs gering zu halten ist eine hohe Taktfrequenz. Du zäumst hier irgendwie das Pferd von hinten auf... Das "Gesamtdelay" ist vermutlich der falsche Name. Die Verzögerung druch ein System nennt man "Latency". Und hier wirken 2 Dinge mit: die Taktrequenz und die Anzahl der nötigen Takte für die Rechnung. Oft ist Latency nicht mal so sehr störend, wenn man durch eine Pipeline dann mit laufend weitere Daten durchschleusen kann. > Die einfachste Möglichkeit das Gesamtdelay des > Designs gering zu halten ist eine hohe Taktfrequenz. Das ist eher sogar die komplizierteste Möglichkeit. Denn dann müssen alle beteiligten Komponenten auf Geschwindigkeit getrimmt sein. Einfacher ist (wenn möglich) meist eine Parallelisierung. Als kleiner Denkanstoß: ich versorge einen DAC mit einem SPI-Takt von 5 MHz. Das ist recht moderat und einfach zu layouten und umzusetzen. Wenn ich jetzt 20 dieser ADC ansteuern will, dann ist die erste Idee, einfach 100MHz Taktfrequenz zu verwenden. Das ist dann schon "richtige" HF und zudem können die Bausteine das schon nicht mehr. Dann ist es viel einfacher, die eine SPI-Schnittstelle mit 5 MHz auf 15MHz aufzubohren und 7 von diesen Einheiten parallel aufzubauen. Im FPGA ist das recht einfach: nur 7 Komponenten instantiieren und fertig... Jens Simon schrieb: > Kann mir jemand konkret einen Baustein bzw. Hersteller für hohe > Systemfrequenzen (ich denke an >500 MHz) nennen? Schon der alte Spartan 3 "kann" 500MHz. Mit einem Zähler lokal auf ein paar CLB beschränkt. Aber ein "ganzes" Design auf 500MHz laufen zu lassen, das halte ich für verwegen. Das wird nicht ohne arge Einschränkungen gehen. Ein Anfänger schafft es ohne jede Mühe, ein High-End-FPGA zur lahmen Krücke zu machen. Ein kombinatorischer Teiler reicht da aus...
Ich habe dich ja schonmal gebeten, dass du uns mitteilst, was du da genau vor hast. Vielleicht kann man auch einen ganz anderen Ansatz finden, der eine geringe Latenz an den Stellen aufweist, wo es für dich erfoderlich ist und dennoch ohne diese extrem hohen Taktraten auskommt. Einen solchen Ansatz habe ich ja bereits angedeutet.
Jens Simon schrieb: > Kann mir jemand konkret einen Baustein bzw. Hersteller für hohe > Systemfrequenzen (ich denke an >500 MHz) nennen? Schwierig. Hier kann man mal sehen, was mit einem generischen Prozessorcore erreichbar ist: http://repo.or.cz/w/zpu.git/blob_plain/HEAD:/zpu/docs/zpu_arch.html#performance Wenn man den Code sorgfältig optimiert (was oft nicht der Wartbarkeit dient...), kann man (nur geschätzt) noch Faktor zwei rausholen. Damit ist man aber noch lange nicht bei 500 MHz. Schlumpf schrieb: > Ich habe dich ja schonmal gebeten, dass du uns mitteilst, was du da > genau vor hast. Das wäre wirklich viel hilfreicher. Duke
Wie oben schon erwähnt möchte ich eine digitale Frequenzregelung
aufbauen:
Mit einer Endstufe (Wechselrichter) speise ich einen
Serien-Schwingkreis. Der Schwingkreisstrom ist sinusförmig mit einer
Freq. von 2-10 MHz (durch die Kapazität und Induktivität im Schwingkreis
vorgegeben). Um die Schaltverluste in der Endstufe möglichst gering zu
halten muss man die Leistungsschalter möglichst im Stromnulldurchgang
schalten. Dazu müssen diese mit der Frequenz des Stromes (Resonanzfreq.
des Schwingkreises) und der richtigen Phasenlage (nämlich wenn der Strom
gerade durch Null geht) angesteuert werden. Die Strommessung erfolgt
über einen Stromwandler mit Diodenbrücke (Stromimpulsformer) um ein
logisches 1bit Signal zu erzeugen: pos. Halbwelle im Strom = '1', neg.
Halbwelle = '0'
Aus der Zeit zwischen den Flanken kann die Periodendauer des Stroms,
respektive die Frequenz bestimmt werden.
Blockschaltbild:
|----------|
|Versorgung|
|----------|
|
▼
|
|--------| |------------| |----|
|Endstufe|-----►------|Schwingkreis|--►---|Last|
|--------| |------------| |----|
| |
▲Ansteuerung ▼Ermittlung der Periodendauer
| |
|---------------| |-----------------|
|Regelung (FPGA)|---◄---|Stromimpulsformer|
|---------------| | |-----------------|
|
1bit Signal
Ändern sich nun die Schwingkreisparameter (z.B. durch Erwärmung) wird
sich auch die Resonanzfrequenz ändern. Um auch weiterhin im
Stromnulldurchgang zu schalten muss eine Anpassung über oben gezeigte
Regelschleife vorgenommen werden.
Die Regelgröße bildet das aus dem Schwingkreisstrom gewonnene 1Bit
Signal.
Zum einen wird daraus die Periodendauer ermittelt um die Einschaltdauern
der Leistungshalbleiter zu berechnen.
Zum anderen muss auf die Flanken im Signal (=Stromnulldurchgänge)
reagiert werden.
Da es sich bei der Regelgröße um ein 1Bit Signal handelt lässt sich hier
leider nichts parallelisieren.
Damit die Regelung sicher funktionieren kann muss die gesamte
Durchlaufverzögerung der Regelschleife kleiner als die halbe
Periodendauer sein. Die Durchlaufverzögerung setzt sich zusammen aus den
Anteilen von Endstufe (Leistungsschalter benötigen endliche Zeit um den
Kanal aufzubauen), Schwingkreis, Stromimpulsformer (Diodenbrücke
benötigt endliche Zeitdauer zum Umladen von Kapazitäten) und des
Algorithmus im FPGA.
Die Hardwarekomponenten sind bereits geschwindigkeitsoptimiert.
Wie oben schon erwähnt wurde lässt sich die "Latency" des FPGAs durch
Erhöhung der Taktfrequenz sowie Verringerung der Anzahl benötigter Takte
optimieren. Mit der Einsync. + Flankenerkennung des 1Bit Signals mit nur
2 FF sollte wohl auch das Minimum der benötigten Takte erreicht sein.
Damit bleibt nur noch die Optimierung der Taktfrequenz zur weiteren
Verringerung der Latency.
Wenn du sagst, dass z.B. Temperaturänderungen ein Nachregeln erforderlich machen, dann sind das ja eher langsame Veränderungen. Ist es dann unbedingt erforderlich, dass innerhalb jeder Periode ein neuer Sollwert ermittelt wird oder würde es auch ausreichen, den Sollwert z.B. jede zweite Periode zu aktualisieren?
Jens Simon schrieb: > Zum anderen muss auf die Flanken im Signal (=Stromnulldurchgänge) > reagiert werden. Wenn eine Ausgabe des FPGA synchron zu diesem Nulldurchgang erfolgen muss, dann wäre es auch denkbar, die Ausgabe auf diesen Nulldurchgang zu synchronisieren, indem der Nulldurchgang den Takt für ein Ausgangsregister bildet. Ob das in deinem Fall eine Lösung sein könnte, hängt allerdings von den Rahmenparametern ab. Aber grundsätzlich geht sowas. Wenn es darauf ankommt, dass zwischen Auftreten des Nulldurchgangs und Ausgabe des Wertes eine möglichst kurze Latenz liegt, wär das eine gute Möglichkeit.
Da auch spontane Laständerungen nachhgeregelt werden müssen kann leider nicht allgemein davon ausgegangen werden, dass eine Regelung über mehrere Perioden funktioniert. Die Reaktion auf die Signalflanken hat folgenden Hintergrund: Es ist immer eine Periode Verzug im System. Das bedeutet die Ansteuerung während der aktuellen Periode (mit der Periodendauer T_k) erfolgt mit der in der vorherigen Periode ermittelten Periodendauer T_k-1. (Das ist nicht anders möglich, da die aktuelle Periodendauer ja erst nach Abschluss der aktuellen Periode vorliegt) Wenn sich jetzt die vorherige und die aktuelle Periodendauer stark unterscheiden ist es möglich, dass sich beim Abschluss der aktuellen Periodendauer (=Flanke im async. Eingangssignal) die Ansteuerung im falschen Zustand befindet und diesen möglichst zeitnah verlassen soll, um die Schaltverluste weiterhin gering zu halten. Zum anderen wird mit dieser Flanke (+ X Takte für Einsync. + Flankenerkennung) die neue (aktuelle) Periodendauer T_k ermittelt. Daraus berechnet sich wiederum Dauer des neuen Zustands der Ansteuerung. Also muss auch die Periodenermittlung möglichst rasch geschehen. Beide Berechnungen hängen vom Systemtakt ab. Die Takterhöhung für nur eines der beiden Module (Periodenermittlung oder Ansteuerung) bringt keinen Vorteil: Wird nur der Periodendauerzähler höher getaktet wird zwar die Periodendauer feiner aufgelöst, allerdings bringt das nichts für die Ansteuerung, da diese die höher Ausflösung bei der Berechnung der Zustandsdauern nicht verwenden kann. Wird nur die Ansteuerung höher getaktet kann zwar schneller auf eine Eingangsflanke reagiert werden (spontane Zustandsänderung bei starker Abweichung; s.o.), allerdings steht die neu ermittelte Periodendauer erst später zur Verfügung und die Berechnung der Zustandsdauern kann nur verzögert erfolgen.
Jens Simon schrieb: > Ich habe mich in Hardware und Design Tool von Lattice eingearbeitet, > mittlerweile allerdings erfahren, dass Lattice eher für LowCost > Bausteine steht. Ist das so richtig? Ja, das ist so richtig. Darum ist Lattice eigentlich auch die richtige Wahl für die einfachen Dinge die man in der Leistungselektronik normalerweise im FPGA machen will. Sieht bei dir aber anders aus :-) > Die einfachste Möglichkeit das Gesamtdelay des Designs gering zu halten > ist eine hohe Taktfrequenz. Leider habe ich kaum Erfahrung welche FPGAs > bzw. Hersteller in dieser Anforderung führend sind. Aus den > Datenblättern kann man dazu kaum brauchbare Infos extrahieren, da jeder > Hersteller sein Produkt in den Himmel lobt und die dort angegebenen max. > Taktfrequenzen doch nur für ganz einfache Algorithmen gelten und > praktisch nicht erreichbar sind. Ist auch nicht einfach, da etwas vernünftiges anzugeben. Schon mal Benchmarks von Prozessoren oder ähnlichem versucht zu vergleichen? Für diese Frage wirst du nicht darum herum kommen, die Tools von verschiedenen Herstellern zu installieren und verschiedene Bausteine gegeneinander zu vergleichen mit deinem Design. Die Unterschiede in den FPGA Architekturen und den verschiedenen Baurreihen sind zu gross um das einfach so zu sagen. > Kann mir jemand konkret einen Baustein bzw. Hersteller für hohe > Systemfrequenzen (ich denke an >500 MHz) nennen? > Der Algorithmus ist nicht sehr umfangreich, daher sollten die > Ressourcenanforderungen zweitrangig sein. Grundsätzlich läuft das so wie bei anderen digitalen Halbleitern: Alle Kochen mit Wasser (Bei manchen ist das Wasser kleiner als bei den anderen). Die neuesten FPGAs werden in 28 nm Prozessen gefertigt, mit diesen sind grundsätzlich höhere Taktraten machbar als mit 65 nm Prozessen. Es wird sich also nicht lohnen einen Xilinx Spartan3 mit einem Lattice XP2 zu vergleichen (beides 90 nm), die werden näher beieinander sein als wenn du einen modernen Spartan 6 oder sogar mit einem 28 nm FPGA von Xilinx vergleichst. Altera müsste auch schon Produkte bei 28 nm haben, kenne das aber grad nicht auswendig.
Ich bin durch ein anderes aktuelles Thema auf den thread aufmerksam geworden (Duplizierungsproblem des FFs) und hätte eine weitere Idee: Warum oversampelst Du den Eingang nicht einfach mit mehreren parallelen Eingängen ung ermittelst daraus den sub sample offset? Den könntest Du später bei der Reglung per Delay sogar wieder mit ausgeben.
Vielen Dank für die neuen Anregungen! @Jürgen: Das Konzept ist mir nicht ganz klar, könntest du es an einem einfachen Bsp. erläutern?
Man könnte das Problem analog und mit einem "nachlaufenden" Modell des Schwingkreises angehen. Ziel ist also eine möglichst hohe Regelbandbreite zu erreichen, wobei ich glaube dass alles über 1MHz overkill ist, sehr unwahrscheinlich wenn gewisse Massen im Spiel sind dass sich mit solch hohen Frequenzen Parameter des Schwingkreises ändern und die Amplitude der Änderungen ist begrenzt ergo die Änderngsrate ergo der Regelfehler. Dazu erfasst man Strom und Spannung, z.B. mit 100MHz/8Bit abgetastet, 2.5 Pipeline delay also 25ns vom A/D, ermittelt aus den Differenzen zum Modell wie sich die Induktivität im Modell ändern müsste, regelt damit die Induktivität des Modells mit den Messgrößen nach. Evtl. ist es komplexer als dass, weil sich noch mehr als die Induktivität der Schwingkreises ändert oder weil das Ersatzschaltbild etwas komplexer ist, aber das Prinzip bleibt. Die Einschaltdauer und Position des Treibers daraus abzuleiten ist ein leichtes und präzise. Ganz grob 1-5MHz Regelbandbreite (Regelfehler 50%) sollten da machbar sein, auch abhängig von der Latenz des Inverters. Gleichzeitig könnte man evtl. noch Meßgrößen über die Art und das Material des Werkstücks ermitteln. Mir scheint hier wird versucht ein altes Design eher ungeschickt mit einem FPGA zu "modernisieren". Schnellere und billigere Flankendetektoren baut man mit einzelnen Logikgattern, DSP ist was heute einen FPGA wirklich nützlich macht.
Jens schrieb: > Das Konzept ist mir nicht ganz klar, Das einzelne Signal wird auf mehrere Pins gegeben, die eintrainiert sind und dann mit einem PLL-Offset betrieben werden. Aus einer PLL kann man leicht 8 Signale gewinnen und damit die Auflösung entsprechend steigern. Die so gewonnenen Sub-Sample-Information wird auf das Ausgangsdelay übertragen und somit dafür gesorgt, dass sich der FPGA defacto auf die Flanke synchronisiert. Die andere Option wäre, Teile des FPGAs mit dem Signal selbst zu takten.
:
Bearbeitet durch User
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.