An alle Schlauen und VHDL Experten Vorab: Bitte nur Fachbeiträge und keine (wenn auch gutgemeinten)Ratschläge nach der Art "Kurs besuchen, Buch lesen, ausprobieren, Projekt zu groß für Dich,solltest Du besser mit einem DSP machen etc", weil diese nicht wirklich weiterhelfen. Starte momentan ein größeres Profekt und möchte einen ganzen Regelkreis in einem FPGA unterbringen. Als Hardware Oldie kenne ich mich zwar mit Digitaltechnik (und Regelungstechnik) aus, bin aber VHDL Anfänger. Momentan befinde ich mich noch in der Designphase. Ich habe ein paar Verständnisprobleme. Der Regelkreis besteht aus mehreren (unabhängigen) und parallel laufenden Programmteilen wie z.B. Meßdatenerfassung und Vorverarbeitung der Meßwerte, Sollwertgenerierung, Regler, Stellgrößenausgabe. 1.Problem Wie wird der Reglertakt aus dem FPGA Clock erzeugt (über Zähler/Frequenzteiler oder gibt es eine andere (direkte) Methode. Der Regler soll FPGA unabhängig mit 20...40(Wunsch)kHz laufen. Gibt es eine Möglichkeit, den FPGA Takt irgendwie in den Code mit einbinden, um immer das gleiche Timing zu bekommen (z.B. laufen Zählschleifen bei einem schnelleren FPGA schneller ab.Daraus generierte Zeiten stimmen dann nicht mehr) 2. Problem Die Programme laufen parallel und tauschen asynchron Statusmeldungen aus und Daten zur Signalverarbeitung. Damit der Regler rechnen kann, braucht er Daten vom Sollwertgenerator als auch von der Meßdatenerfassung. Beide Daten müssen gleichzeitig anliegen. Die Rechnung soll generell in Gleitpunktarithmetik erfolgen. Ich möchte alle Programme unabhängig voneinander haben, d.h. keine Zwangsverheiratung über globale Clocks (mit Ausnahme des FPGA Taktes natürlich, ich meinte eher User definierte Clocks). Das feste Timing brauche ich nur für die Meßdatenerfassung, alle anderen Programme reagieren auf die Datenausgabe vom Meßdatenerfassungsprogramm. Vorschläge für die generelle Datenschnittstelle zwischen den Programmen (TwoPorts? Register?). Oder doch lieber die Synchronisation über einen Takt und direkten Austausch über Signalleitungen (Hinweis: der Signalaustausch zwischen den einzelnen Programmen kann einige Bytes ausmachen) Alle Programme brauchen Parameter, die auch Online verändert werden können. Auf der anderen Seite hat jedes Programm auch Statusmeldungen und evtl. Meßwerte an ein übergeordnetes PC-Programm zu übermitteln. Ich habe da an zwei große TwoPort RAM-Blöcke gedacht, eins, wo nur von den Programmen gelesen (und vom PC geschrieben) wird und der andere Block, auf den die Programme schreiben.Ich möchte also asynchron von mehreren Programmen unabhängig auf einen Speicher zugreifen. Vorschläge hierzu? 3. Problem Ich brauche für den Regelkreis auch Filter (Tiefpass, Hochpass, Bandpass/Bandsperre. Bisher habe ich noch keine Lösung über die Algorithmen und das Berechnung der FilterKoeffizienten. Die Vorgabe für die Filter ist üblicherweise Ordnung, Eckfrequenz, wobei man sich die Filterwirkung selbst über die Beziehung (20 db/Dekade Dämpfung pro Ordnung)ableiten kann. Achtung: Da sich die Filter im Regelkreis befinden, ist die Phasendrehung durch die Filter unbedingt zu beachten! Deshalb ist die gewünschte Filterwirkung immer ein Kompromiss zwischen Eckfrequenz und Filterordnung (bei hoher Filterordnung muß die Eckfrequenz entsprechen weit von meiner Regelfrequenz entfernt sein, damit der Regelkreis nicht instabil wird) 4.Problem Ich möchte die Regelgröße umschalten können. Bei fünf Regelgrößen möchte ich (wenn's machbar ist) also fünf komplette Regelkreise im FPGA unterbringen und zwischen diesen Regelkreisen umschalten. Das wäre die einfachste und eleganteste Methode (wozu hat man schließlich einen FPGA mit massiver Parallel-Verarbeitungsmöglichkeiten!).Das Umschalten muß innerhalb eines Reglertaktes passieren. Wenn das nicht machbar ist, wird die Sache dann (glaube ich) um einiges schwieriger, weil ich a)den kompletten Parametersatz z.B. beim Sollwertgenerator und beim Regler austauschen muß und b) noch einige programminterne Statussignale entweder auf Null oder auf einen definierten Wert setzen muß, umd die Regelkontinuität zu gewährleisten.Das alles muß ebenfalls innerhalb eines Reglertaktes passieren. Frage an euch: welche Lösung läßt sich besser und eleganter in VHDL umsetzen und wie sehe diese in groben Zügen aus? Schlußwort: Natürlich habe ich mir Gedanken gemacht, ob nicht besser ein DSP einzusetzen wäre. Manche Dinge sind damit leichter zu realisieren. Auf der anderen Seite gibt es beim Regelkreis viele parallele Strukturen, die wiederum für einen FPGA sprechen. Last bust not least: 40 kHZ Reglerabtastfrequenz sind kein Pappenstiel (für den Regler selbst natürlich nicht, aber es gibt ja noch die Kommunikation mit dem PC, der mit den riesigen Datenmengen umgehen muß (verarbeiten,auswerten und speichern), die in der Vergangenheit dazu geführt haben, daß höchstens 10 kHz Abtastfrequenz erreicht wurden.(trotz DSP)
Wer am Anfang gleich so etwas in seine Anfrage schreibt bekommt keine nützliche Antwort. Vorab: Bitte nur Fachbeiträge und keine (wenn auch gutgemeinten)Ratschläge nach der Art "Kurs besuchen, Buch lesen, ausprobieren, Projekt zu groß für Dich,solltest Du besser mit einem DSP machen etc", weil diese nicht wirklich weiterhelfen.
Ein nicht hilfreicher Tipp nach deiner Meinung. In einem FPGA laufen keine Programme!! Buch kaufen und lesen. z.B.: VHDL-Synthese Um eine sequenzielle Verarbeitung zu erreichen musst du dir Zustandsautomaten bauen. Bleib lieber bei den DSPs, ansonsten erst mal mit kleineren Projekten Erfahrungen sammeln. Aber dass alles wolltest du ja nicht wissen!!
Scheint als sind FPGAs Neuland fuer dich, entgegen deiner Annahme bleibt dir nichts anderes uebrig als dich vorher in die Materie einzuarbeiten, online Foren wie dieses sind dazu sehr hilfreich. Aber dennoch solltest du ein paar Buecher ueber VHDL und FPGAs - speziell logic design in deren lesen - FPGAs sind keine ueberdimensionale Spielwiese fuer TTL Grab designs. Du hast schon eine etwaige Vorstellung aus welchen Komponenten deine Loesung bestehen soll, so kannst du mal mit den einfachen Anfangen. In deinem Projekt is ModelSim your friend. d.h. du wirst sehr spaet Versuche mit einem richtigen FPGA machen. Zwischendurch empfielt sich bei Neulingen den run durch eine Synthese da es genuegend Konstrukte gibt welche sich nicht in HW abbilden lassen. Filter und Regler willst du evtl in Matlab oder Simulink beschreiben und testen. Von der Performance her musst du dir weniger sorgen machen, richtig eingesetz bist du mit einem FPGA an der pole position. Wenn dein Projekt in absehbarer Zeit fertig sein soll, nimm einen DSP. Ansonsten steig ein in die FPGA Welt, aber sei gefasst, dass du nach etwa einem Jahr dein erster VHDL code vermutlich neuschreiben willst, aber dann dafuer vorne mit dabei bist. Cheers, Roger
Ich finde die Bemerkung am Anfang gar nicht so falsch, den Pauschale Antworten bringen ihm doch wirklich nichts. Zu oben: In FPGAs laufen - je nach Auffassung - durchaus Programme ab, zumindest FSMs lassen sich so interpretieren. @Peter: Du brauchts eine globale Steuerung als Schleife, welche den Datentransport zwischen den Modulen regelt, die zunächst mal so aufgebaut werden müssen, daß sich ein sinvoller Systemtakt für das FPGa ergibt. Der Reglertakt definiert sich dann später dadurch, daß aus der letzten Stufe das Ergebnis raustransportiert wird. Soll dieser einstellbar sein, muss wie vermutet ein Zähler her, der wartet und die Ausgabe verzögert. Auf diesen Takt sind die Regelvariablen und Zeitkonstanten auszulegen. Bei den angestrebten 40kHz bleiben Dir als bei einer angenommenen Systemfrequenz des FPGA von z.B. 40MHz etwa 1000 Clks, um die komplette Aufgabe abzuarbeiten. Bei einem Multiplier kann ein Clk veranschlagt werden, Divider und Wurzelbilder brauchen 5-10 je nach Breite. Deine Aufgabe besteht nun darin, die gesamte Regelgleichung so langzuziehen, daß mehrfach benötigte Zwsichenergebnisse möglichst früh aufbereitet werden können. Ferner ist der worst case zu durchdenken und in die Simulation einzuprägen, um die 1000 Clks gegenzuchecken. Deine Bedenken hinsichtlich Umschaltung und Parallelität sind unbegründet: Je FPGA-Takt können mit MUX jederzeit Datenströme umgelenkt werden, ohne dass inkonsistente Daten entstehen. Dies geht erst recht mit dem Regeltakt. "40 kHZ Reglerabtastfrequenz sind kein Pappenstiel " Sofern die Daten synchron angeliefert und übernommen werden können, und es keine Probleme bei der Ausgabe gibt, ist das gar kein Problem. Will man jedoch eine Zerolatenz im FPGA, so müsste man mit deutlich weniger Clks auskommen, damit die Latenz infinitisimal gegen den Takt bleibt. So, wie ich es oben gerechnet habe, vergeht genau ein Regeltakt zwischen Aufnahme und Ausgabe der Daten (wie eigentlich i.d.R. benötigt) "Bei fünf Regelgrößen" hat man im Prinzip 5x dasselbe Schaltwerk, allerdings könnte es sein, daß man Ein-/Ausgänge multiplexen kann, um die Rechenkette zu switchen. Z.B. könnte man 2 Kanäle nacheinander prozessieren, um nur 3 Schaltwerke (2+2+1) zu haben. Am einfachsten ist es, den Regelablauf in ein Flussdiagramm zu übersetzen, (C-ähnlich) und nach jedem Rechenschritt oder einem Entscheidungsschritt ein Register zu planen, dasselbe gilt für die Inputs und outputs der einzelnen Blöcke. Die globale Steuerung sorgt per enable-Leitungen dafür, daß ein Folgeblock DANN ein Ergebnis eines Vorblocks erhält, sobal dieses gültig ist. (Clocks vergehen lassen) Was die Filter angeht, so gibt es da einiges an Designbedarf. Dual-ported-RAMS braucht es zwischen den Verabeitungsstufen erstmal nicht. Allerdings: Sollte die Rechnerei zu aufwändig werden, dann muss die gesamte Architektur als pipeline aufgebaut werden, die im Regeltakt läuft. Dann wird alle 40kHz ein neues Datum in die Schaltung "eingeworfen". Dies ist insofern schwieriger, da nun valide von invaliden Daten in den Registern zu unterscheiden sind. Eine solche Architektur entspräche dann aber in etwa dem, was man aus diskreten Bausteinen aufbauen würde.
Hallo ihr alle, die es gut mit mir meint Als Ingenieur mit 20jähriger Berufserfahrung brauche ich nun wirklich keine Ratschläge mehr, wie ich ein Projekt angehe. Ich habe zu Hause einige Kilo VHDL Literatur rumliegen, vieles davon schon etwas eingehender studiert. Ich habe auch mit Lattice ISPLever und CPLD's gearbeitet (allerdings nur Schaltplaneingabe). Wie ein FPGA aussieht und was man damit machen kann, weiß ich auch. Also noch einmal: Keine allgemeinen Ratschläge, denn die habe ich schon mehr wie genug bekommen.(Danke an Roger trotzdem für den gutgemeinten Rat) An den unbekannten Dummschwätzer: Ich poste hier mit meinen vollen Namen, wenn Du etwas zu sagen hast, dann tue es ebenfalls, ansonsten behalte Deine Belehrungen lieber für Dich! Ob ich den VHDL-Code (darf man das sagen?) Programm nenne oder nicht, ist in diesem Zusammenhang außerdem vollkommen irrelevant, denn jeder weiß, worum's geht.
Hallo Jürgen endlich mal eine fundierte Antwort, über die man miteinander reden kann. Ähnliche Gedanken habe ich mir auch schon gemacht. Wenn ich ein Riesenrechenwerk baue, wie Du vorgeschlagen hast, wird es dann (bei geschätzten mehreren hundert Seiten Code nur für einen Reglerkreis!) nicht ein bißchen unübersichtlich? Ich denke, wenn ich kleinere, unabhängige Codeeinheiten wie z.B. einen Regler generiere, den ich außerdem noch sehr gut und mit vertretbarem Aufwand simulieren kann, tue ich mich bei der Fehlersuche der gesamten Schaltung leichter. Die gesamte Schaltung würde dann im Endeffekt aus vielen kleinen ausgetesteten Blackboxes bestehen, die unabhängig voneinander (bzw. nur über den FPGA Takt miteinander verbunden) und zu verschiedenen Zeiten miteinander kommunizieren. Ich muß nur die Kohärenz zwischen meinen Eingangssignalen und der Stellgröße sicherstellen. Man kann z.B. Sollwertgenerierung und Meßdatenerfassung durchaus gleichzeitig starten und den Regler dann einen ReglerTakt später, um den Takt besser auszunutzen. Die entstehende Totzeit läge dann bei etwas mehr wie 1/2 To, bei 40 kHz Abtastrate und max. 1000Hz Regelbereich absolut kein Beinbruch, und wenn ich mit meinen Reglertakt noch höher komme, umso besser... Noch einmal zurück zu meiner Frage: Ist es strategisch günstiger, ein großes Schaltwerk zu bauen (handelt man sich dabei weniger Probleme ein), oder sollte man nicht doch besser kleinere Schaltungen entwerfen. Wenn ja, wie müßten diese miteinander kommunizieren. Wie stark wäre dann die Abhängigkeiten von den verschiedenen Taktraten der FPGAs. Müßte ich für jede Taktrate ein neues Redesign machen oder zumindest neu austesten? Das wollte ich mir eigentlich ersparen. Die Schnittstellen nach draußen (AD/DA-Wandler, Display-Ausgabe, RS232 etc. erfordern ein definiertes Timing, welches (in den Beispielen, die ich habe) auf einen bestimmten Takt ausgelegt ist. Setzt man dann einen anderen FPGA ein, sind zumindest die Schnittstellen alle neu zu entwerfen und auszutesten, eine Horrovorstellung für jeden, der (wie Ich selbst) die ganze Entwicklung auf eigener Kappe macht. Du wirst dann mit der Entwicklung nie fertig, der Tod für jedes Projekt! Da wäre es dann allerdings gescheiter, doch einen DSP einzusetzen, wo ich an der Front Ruhe habe. Also: Hast Du oder irgendjemand Vorschläge, wie man ein Design wasserdicht kriegt, d.h. das Timing weitgehend unabhängig vom FPGA Takt macht bzw. vom Takt ableitet oder ist das gar unmöglich?
Hallo Peter > Wenn ich ein Riesenrechenwerk baue, wie Du vorgeschlagen hast, wird es dann (bei geschätzten mehreren hundert Seiten Code nur für einen Reglerkreis!) VHDL ist viel abstrakter, so dass nicht alle Einzelheiten beschrieben werden brauchen. A <= B + C beschreibt einen Addierer. Deine Regler sind vom Aufbau gleich. Die Koeffizienten kannst du in Register schreiben, so dass du sie schnell ändern kannst. Zum Beschreiben der Register würde sich vielleicht eine kleine CPU anbieten, die als softcore mit in den FPGA integriert wird. Für die Anbindung an den PC währe ein USB-FIFO-Chip nicht schlecht. > Wenn ja, wie müßten diese miteinander kommunizieren. Stelle dir eine Entity wie ein IC vor. Die Ports sind die Anschlüsse. Für die Kommunikation musst du dir schon selber Schnittstelle ausdenken. Aber meist hast du sowieso nur Busse und einzelne Signale. > Wie stark wäre dann die Abhängigkeiten von den verschiedenen Taktraten der FPGAs. Müßte ich für jede Taktrate ein neues Redesign machen oder zumindest neu austesten? Die Taktfrequenz des FPGAS richtet sich nach der Wahl des Quarzes und der Einstellungen der PLL (falls benutzt). In der Generic kannst du unter anderem Ändermöglichkeiten für verschiedene Taktraten vorsehen. Das währe zum Beispiel verschiedene Ladewerte für den Taktzehler. Die Generic kannst du im Übrigen in der übergeordneten Entity in der Komponenten- Einbindung überschreiben.
1 | library IEEE; |
2 | use IEEE.STD_LOGIC_1164.all; |
3 | use IEEE.STD_LOGIC_ARITH.all; |
4 | use IEEE.STD_LOGIC_UNSIGNED.all; |
5 | |
6 | |
7 | entity exmple is |
8 | generic ( |
9 | System_Takt : natural := 32000; -- In kHz |
10 | Bitbreite : natural := 18; |
11 | -- .. ;
|
12 | -- ..
|
13 | );
|
14 | |
15 | port ( |
16 | CLK : in std_logic; |
17 | Ist_Wert : in std_logic_vector(Bitreite - 1 downto 0); |
18 | Soll_Wert : in std_logic_vector(Bitreite - 1 downto 0); |
19 | Regelgröße : out std_logic_vector(Bitreite - 1 downto 0); |
20 | |
21 | Koeffizient1 : in std_logic_vector(Bitreite - 1 downto 0); |
22 | Koeffizient2 : in std_logic_vector(Bitreite - 1 downto 0); |
23 | Koeffizient3 : in std_logic_vector(Bitreite - 1 downto 0); |
24 | --.. ;
|
25 | --.. ;
|
26 | );
|
27 | end exmple; |
28 | |
29 | |
30 | architecture Verhalten of exmple is |
31 | |
32 | component sld_virtual_jtag |
33 | generic( |
34 | sld_auto_instance_index : STRING; |
35 | sld_instance_index : NATURAL; |
36 | sld_ir_width : NATURAL; |
37 | sld_sim_action : STRING; |
38 | sld_sim_n_scan : NATURAL; |
39 | sld_sim_total_length : NATURAL; |
40 | lpm_type : STRING |
41 | );
|
42 | |
43 | port( |
44 | ir_out : IN STD_LOGIC_VECTOR (1 DOWNTO 0); |
45 | tdo : IN STD_LOGIC ; |
46 | ir_in : OUT STD_LOGIC_VECTOR (1 DOWNTO 0); |
47 | jtag_state_cdr : OUT STD_LOGIC ; |
48 | jtag_state_cir : OUT STD_LOGIC ; |
49 | jtag_state_e1dr : OUT STD_LOGIC ; |
50 | jtag_state_e1ir : OUT STD_LOGIC ; |
51 | jtag_state_e2dr : OUT STD_LOGIC ; |
52 | jtag_state_e2ir : OUT STD_LOGIC ; |
53 | jtag_state_pdr : OUT STD_LOGIC ; |
54 | jtag_state_pir : OUT STD_LOGIC ; |
55 | jtag_state_rti : OUT STD_LOGIC ; |
56 | jtag_state_sdr : OUT STD_LOGIC ; |
57 | jtag_state_sdrs : OUT STD_LOGIC ; |
58 | jtag_state_sir : OUT STD_LOGIC ; |
59 | jtag_state_sirs : OUT STD_LOGIC ; |
60 | jtag_state_tlr : OUT STD_LOGIC ; |
61 | jtag_state_udr : OUT STD_LOGIC ; |
62 | jtag_state_uir : OUT STD_LOGIC ; |
63 | tck : OUT STD_LOGIC ; |
64 | tdi : OUT STD_LOGIC ; |
65 | tms : OUT STD_LOGIC ; |
66 | virtual_state_cdr : OUT STD_LOGIC ; |
67 | virtual_state_cir : OUT STD_LOGIC ; |
68 | virtual_state_e1dr : OUT STD_LOGIC ; |
69 | virtual_state_e2dr : OUT STD_LOGIC ; |
70 | virtual_state_pdr : OUT STD_LOGIC ; |
71 | virtual_state_sdr : OUT STD_LOGIC ; |
72 | virtual_state_udr : OUT STD_LOGIC ; |
73 | virtual_state_uir : OUT STD_LOGIC |
74 | );
|
75 | end component; |
76 | |
77 | |
78 | signal Lesen : std_logic; |
79 | signal Ist_1, Ist_2, .. : std_logic_vector(Bitbreite - 1 downto |
80 | 0); |
81 | |
82 | --.. ;
|
83 | |
84 | |
85 | begin
|
86 | |
87 | Reler: process(CLK) |
88 | begin
|
89 | if CLK'event and CLK = '1' then |
90 | if Lesen = '1' then |
91 | Ist_1 <= Ist_Wert ; |
92 | end if; |
93 | -- ??????
|
94 | end if; |
95 | end process; |
96 | |
97 | |
98 | -- instantiation of the vji mega functionc */
|
99 | jtag_inst0: sld_virtual_jtag |
100 | generic map ( |
101 | sld_auto_instance_index => "YES", |
102 | sld_instance_index => 0, |
103 | sld_ir_width => 2, |
104 | sld_sim_action => "", |
105 | sld_sim_n_scan => 0, |
106 | sld_sim_total_length => 0, |
107 | lpm_type => "sld_virtual_jtag" |
108 | )
|
109 | |
110 | port map( |
111 | ir_out => "00", --sample_instr_counter) input to |
112 | megafunction
|
113 | tdo => tdo, --input to mega function |
114 | |
115 | ir_in => ir_in, -- output from mega function |
116 | tck => tck, -- output from mega function |
117 | tdi => tdi, -- output from mgafunction |
118 | |
119 | virtual_state_cdr => cdr, -- output from mega function |
120 | virtual_state_e1dr =>e1dr, -- " |
121 | virtual_state_e2dr =>e2dr, -- " |
122 | virtual_state_pdr => pdr, -- " |
123 | virtual_state_sdr => sdr, -- " |
124 | virtual_state_udr => udr, -- " |
125 | |
126 | virtual_state_uir => uir, -- " |
127 | virtual_state_cir => cir -- " |
128 | |
129 | );
|
130 | |
131 | end Verhalten; |
PS: Hättest du die Bemerkung oben weggelassen hättest du auch keine dumme Antwort bekommen. So etwas schreibt man nicht vorsorglich. :-) Frieden :-)
Gruß an alle Na ja, langsam entwickelt es sich. Die eine oder andere Anregung werde ich mal überdenken. Noch etwas zum Umfang des Projektes: Im DSP-Assembler wären das (ebenfalls von mir geschätzt für heutige Prozessoren, Erfahrung liegen nur für ältere Texasprozessoren vor) über 1MB Code. Wenn einer schon mal Assembler programmiert hat, dann weiß er wie lange man daran sitzt. Den Softcore Prozessor habe ich mir schon mal vorgemerkt, Xilinx stellt da einen 8Bit Proz. (PicoBlaze) kostenlos zur Verfügung, den habe ich mir angeschaut. Ich denke für die Meßdatenerfassung wäre der nicht schlecht, für den Regler vielleicht auch, obwohl ich da die Befürchtung habe, daß er dann zu langsam wird (der PicoBlaze braucht zwei Takte pro Instruktion, bei 50MHz Takt für den Spartan 3 (Xilinx) sind das 40ns. Ich will in jedem Fall wegen der Genauigkeit mit Gleitpunktarithmetik arbeiten, da werden dann leicht 300-400 Instruktionen für den Regler fällig. Übrigens bin ich noch in der Designphase, d.h. die Struktur des Regelkreises liegt fest, es fehlt die Umsetzung in VHDL. Da es verschiedene Konzepte und Philosophien für die Umsetzung gibt, dachte ich, daß ich das mal poste, bevor ich anfange. Aus der Schaltungstechnik weiß ich, daß sich nicht zwei Signale zur gleichen Zeit bei einem Gatter ändern dürfen, damit man keine Glitches oder Spikes am Ausgang bekommt, welche die nachfolgende Schaltung dann aus dem Tritt bringen kann. Das ist ja bei einer Schaltung schon schwierig rauszumessen, wie soll es dann erst mit dem FPGA werden? Sind Glitches überhaupt ein Thema bei VHDL und FPGAs? Gibt es diesbezüglich irgendwelche Erfahrungen von Eurer Seite? Ich kann es mir nicht erlauben, irgendwelche Aspekte unberücksichtigt zu lassen, die helfen, ein Design "sicherer" zu machen, weil ich selber mit meiner Patte (Portomanee) dafür gerade stehe. Der absolute Hooror sind sporadische Abstürze beim Kunden vor Ort -der garantierte Weg in den Ruin... Peter
Hallo Peter Mit den Glitches könntest du Probleme bekommen, wenn du die externen Signale nicht sauber eintaktest. Am besten 2 Flip-Flops hintereinander, die mit dem Systemtakt getaktet werden. Ansonsten sollte man auf ein Synchrones Design achten. Je nach Datenquelle kann man aber auch auf die Eintaktung verzichten. Wenn der ADC von dem FPGA getaktet wird und so sichergestellt werden kann, das an seinen Ausgangs-Flip-Flops sich die Signale nicht innerhalb der Setzeit der FPGA internen Flip-Flops verändern. Den Regler solltest du schon in VHDL integrieren. Für die Steuerung einen kleinen Prozessor, der über einen Daten und Adressbus die Koeffizientenregister lädt. In neueren FPGA findet man meist fertige 18x18 Bit Multiplizierer, die in einem Takt rechnen. Für deine Fließkommerberechnung musst du noch erstmal etwas entwickeln oder schaue mal auf http://www.opencores.org Vielleicht doch erstmal mit festem Komma arbeiten? Im Anhang mal ein Beispiel-Code (ohne Regler). MfG Holger
Zum hierarchischen Design: Selbstredend wird man die HDL-Struktur so aufsetzen, daß alle Partitionen als Komponenten formuliert werden und dann mehrfach genutz werden, schonmal wegen der Tatsache, daß du alles 5x brauchst. Ich würde auch jeden einzelnen Filter und Datenerfassungsblock in einem eigenen HDL-file halten -auch wenn's sehr klein wird und man viele files samt Verdrahtungsuafwand erhält. Diese kompakten Files lassen sich dann gut testen und einzeln simulieren. Am Besten baust Du erstmal einen kleinen Proportinalregler auf und hängst nur diesen ins FPGA um ein Gefühl für die Strukturierung zu erhalten. Dann muss rasch eine ABschätzung her, mit vielen Clocks man ionsgesamt zu rechnen hat und wie man das mit den Anforderungen verheiratet. Einen Softcore braucht man eigentlich nicht. Das, was man für einen embedded Proz an code formulieren müsste, lässt sich mit ähnlichem Aufwand auch in HDL schreiben. Zum timing: Wichtig ist die IO-Anbindung und das Absamplen der Signale. Hat man das erstmal drin, läuft alles über internes timing, das sich mit den Design- und Synthesetools leicht handhaben lässt.
Hallo Jungs Bin ja richtig begeistert über die Response und die fundierten Beiträge. An Holger: Festkomma ist immer so eine Sache. Ich habe mir das auch überlegt, allerdings ist der Aufwand wg. der Bitschieberei auch nicht so klein (habe mal einen Regler in 8 Bit Assembler geschrieben -vor langer Zeit...) und die Genauigkeit muß bei 16 BitWandlern um einiges höher liegen iwe 16 Bit,wg. der Rundungseffekte. Die Routinen für die Fließkommaberechnung habe ich übrigens alle aus einem Buch,wie die Umwandlung von Fest auf Fließkomma (und vice versa)auch, so daß ich hier auf funktionierenden Code zugreifen kann. Werde ansonsten Eure Ratschläge beherzigen. Grüße Peter
Hallo Peter Noch einen gut gemeinten Rat. Du ziehst öfters Parallelen zwischen Hardwarebeschreibung und Programmiersprachen. Bei der Hardwarebeschreibung musst du komplett anders denken. Die Schleifenstrukturen in VHDL werden benutzt, um bestimmte Logisstruktur mehrfach zu erzeugen. In der Hardware gibt des keine sequenzielle Verarbeitung, den nötigen Funktionsautomaten muss man schon selber schreiben / oder generieren lassen. Verschieben brauchst du die Bits auch nicht, du nimmst einfach einen Ausschnitt.
1 | signal a, b, c : std_logic_vector(31 downto 0); |
2 | c <= ( a(31 downto 16) & x"0000") + b ; |
3 | -- Hier sind für die Rechnung die 4 Hex Stellen mit der kleinsten
|
4 | Wertigkeit auf Null. |
5 | |
6 | signal a, b, c : std_logic_vector(31 downto 0); |
7 | c <= ( x"0000" & a(31 downto 16) ) + b ; |
8 | -- Hier wurden die 16 oberen Bits nach unten verschoben und oben mit
|
9 | Nullen aufgefüllt. |
10 | |
11 | -- Das Signal a wird nicht verändert!
|
Wenn man aus den Bereich der Prozessorprogrammierung kommt, kann man am Anfang über solche Sachen schell stolpern. Mit Fließkomma kann man schon rechnen. Für eine Multiplikation währe dass ein Multipizierer für die Zahl und ein Addierer für die Mantisse. Das addieren wird dann aber schwieriger. Achte mal darauf, wie viel Logik dafür draufgeht. 18-Bit-Multipizierer hast du schon mal fertig im FPGA zur Verfügung. Für 36 Bit braucht man 4 Multiplizierer und einen Addierer, der aus Logik-Zellen generiert wird. Je nach Umfang deines Projekts müsstest du den Multiplizierer mehrfach multiplexen. Ein Multipizierer benötigt viel Chipfläche, deswegen gibt es davon auch nicht viele. Zeit hast du ja genug, bis das Ergebnis anliegen muss. Dann könnte man die Multiplikationen auch in Schritte aufteilen. A (17 downto 0) * B (17 downto 0) A (17 downto 0) * B (35 downto 18) A (35 downto 18) * B (17 downto 0) A (35 downto 18) * B (35 downto 18) Und anschließend die Summe bilden. Dafür müsste ein kleiner Zustandsautomat reichen. Für jedes Registerbit rechne mal mit einer Logikzelle und dann noch ein paar für logische Verknüpfungen. MfG Holger
Hallo Holger Bin wie gesagt noch in der Designphase und mache mir zur Zeit noch grundsätzliche Überlegungen, zu denen Eure Kommentare und Erfahrungen(auch von Jürgen Schumacher und anderen) für mich sehr wertvoll sind. Die Entscheidung zwischen Fließ und Festkomma ist eher eine Designentscheidung, die ich aber noch nicht getroffen habe. Damit wir beide die gleiche Sprache sprechen, hier noch eine Kurzübersicht über den Regelkreis: Der Regelkreis (für hydr. Prüfmaschinen) besteht aus Sollwertgenerator mit Auf/Abblendfunktion, Abschwächern, Sinus/Dreieck/Rechteckgenerator, diversen Steuerungsfunktionen. Spitzenwertregler (PI), der den Sollwert auf die gewünschte Amplitude regelt (Vorgabe ist üblicherweise Sinus) dem PID-Grundregler, (bei Kaskadenregelung aus zwei PID-Regler), der Stellgrößenausgabe mit evtl. Ventilregler (für große Servoventile) Für die Spitzenwertregelung muß ich aus dem kontinuierlichen Datenstrom die einzelnen Perioden "ausschneiden", die Werte vorglätten z.B. mit gleitender Mittelwertbildung, den Min/Maxwert aus den vorhandenen Werten pro Periode berechnen, auf Über/Unterschreitung eines Levels kontrollieren und diverse andere Steuerungs- und Überwachungsfunktionen. Die AD-Erfassung und die DA-Ausgabe hat üblicherweise noch eine Kal.funktion (Gain + Offset)pro AD/DA-Kanal(muß der FPGA machen!) Alles in allem kommen da einige Multiplikationen und Additionen pro Reglertakt zusammen. Dazu kommt noch die hohe Genauigkeit. Der Regler muß auch das letzte Digit noch sauber ausregeln (wir haben manchmal Signale, die bewegen sich im Millivoltbereich (10-20 mV, max. sind 10 Volt!). Außerdem brauchen wir einen hohen Dynamikbereich (-40 ...+60 dB)des Reglers. Ach ja, und Filter bräuchte ich eigentlich auch noch... Da kommt eine Menge Holz zusammen. Also durchaus möglich, daß Festkomma die bessere Lösung ist (bzgl Geschwindigkeit). Dann müßte ich aber generell mit 32 Bit rechnen, um die hohen Dynamik und Genauigkeitsanforderungen erfüllen zu können. Meine Schwierigkeiten mit VHDL kommen daher, weil sich viele Sprachkonstrukte eben nicht in Hardware modellieren lassen und in einer Hardwarebeschreibungssprache nach meinem Verständnis eigentlich nichts zu suchen haben. Es ist dieser Mißmatsch aus synthetisierbarem Code und reinem Simulationscode in einer Sprache, die einen Hardwerker wie mich durcheinanderbringen. Ich denke mir, das es auch den anderen mit Hardwarebackground so geht. Noch eine Verständnisfrage: Wie modelliere ich in VHDL Zeiten? Wie stelle ich sicher, daß Signal A z.B. 20 ns eher kommt wie Signal B? Wie stelle ich sicher, daß mein VHDL-Code, den ich auf einen FPGA mit 50 MHZ-Clockfrequenz geschrieben habe, auch auf einen FPGA mit 100 MHZ läuft (Kritisch sind ja die zeitabhängigen Schnittstellen). In den Büchern, die ich habe, wird dieses Thema gar nicht behandelt. An Frank: Wenn ich mit meinem Regler fertig bin, kannst Du den PID-ReglerCode haben. Das kann aber noch ein Weilchen dauern, weil ich noch mit anderen Dingen beschäftigt bin und die Entwicklung momentan nur nebenbei machen kann. Grüße an alle Peter
Hallo Peter Zu der Zeit, wo VHDL entwickelt wurde, wurde sie zur Spezifikation von Hardware benutzt. So stehen auch Sprachelemente zur Verfügung, die zeitliche Veränderungen beschreiben. Zur Synthese benutzte man damals noch Netzlisten, mit denen dann Großrechnern das Chip-Design erstellen. (Cray - Vektorrechner) Da es in FPGAs keine entsprechenden Elemente gibt, können diese Sprachteile nicht synthetisiert werden. Für zeitliche Verzögerungen muss man auf Zustandsautomaten zurückgreifen. [In VHDL-Synthese haben sich Reicherdt und Schwarz auf den synthetisierbaren Sprachteil beschränkt.] Dein Projekt ist ja nicht ohne. Der kleinste Cyclone II (EP2C5) hat 13 18x18-Bit, die in zwei 9x9-Bit aufgeteilt werden können. http://www.altera.com/products/devices/cyclone2/features/multipliers/cy2-multipliers.html http://www.altera.com/products/devices/cyclone2/overview/cy2-overview.html Für einen 32x32-Bit Multiplizierer gehen vier Multiplizierer drauf, oder du brachst vier Takte. Von den Herstellern gibt es auch Tools, mit denen man DSP-Verschaltungen aus zum Beispiel Simulink erzeugen kann. > Wie stelle ich sicher, daß mein VHDL-Code, den ich auf einen FPGA > mit 50 MHZ-Clockfrequenz geschrieben habe, auch auf einen FPGA mit > 100 MHZ läuft In einem FPGA gibt es mehre Clock-Netze. Auf eines kann man von der PLL den Takt von 50MHz legen und auf ein anderes die 100MHz. Ein Signal aus dem anderen Takt-Bereich muss dann natürlich eingetaktet werde. Wenn die Takte von der selben PLL sind, sind sie auch mit ihrer Phase verknüpft, so dass man auf das Eintakten verzichten kann. Vor der Synthese legst du fest, wie schnell die einzelnen Eingangssignale sind. Nach der Synthese sagt dir das Synthesetool, welche Taktraten zu erreichen sind. Wenn du Glück hast liegt die erzielte maximale Taktrate über der von dir benötigten, ansonsten muss du etwas an deinem Code ändern , die Syntheseeinstellungen verändernoder oder die Zeiteinstellungen noch mal überprüfen. MfG Holger
Das mit den Multiplizieren stimmt so nur, wenn man alle Ergebnisbits benötigt, da die Synthese nicht benötigte Signale wegnimmt und die Multiplier so verteilt, daß sie optimal genutzt werden. Die temporär größeren Ergebnisse müssen nichtmal zwischengespeichert werden. Zudem gibt es bei besagtem Cyclone / Quartus die option des Resource sharings, sodass die embedded multiplier zeitlich versetzt eingeblendet werden können, so dies möglich ist. Die Synthese kann dies ja leicht feststellen. Man muss nur die Multiplikation / Addition mit einer state machine steuern, daß z.B. immer nur eine von 2 Multiplikationen gleichzeitig läuft. Die Formulierung erfolgt ganz einfach als "x" und "+". Dass dort innen mehr oder weniger MULS benötigt werden oder man mehrer Teilergenisse addieren muss, braucht nicht zu kümmern. Das macht das Tool! egal was es ist: Sofern es die innere Struktur der Architektur hergibt, optimiert das Tools das schon recht ordentlich. Dasselbe gilt für Speicher und Register, die nahe zugleiche Inhalte haben: Alles, was redundant ist, wird wegsynthetisiert, ohne dass man es ausdrücklich vorgeben muesste. Zum Timing: Der kleinste Step ist in der Regel der Systemtakt. Bei zeitfixen Applikationen muss noch auf einen äusseren Takt getriggert werden. Dies ist meist ein asynchroner Datentakt oder bei Dir der Reglertakt. Das macht man so, daß man das gesamte Schaltwerk eben nur alle Taktzyklen lang mit neuen Daten füttert und diese nach der Durchlaufzeit abholt. Das ist dasselbe wie die Laufzeit in einem Chip, der schneller ist, als eine alte Technologie: Die Laufzeit ist kleiner, aber die Taktrate von aussen bleibt in der Schaltung dieselbe. Dein FPGA braucht also einen Datentakt von aussen oder muss diesen generieren. Dazu muss natürlich die Systemfrequenz bekannt sein. Latenz: Eine Gain-Offsetkorrektur (s.o.) mit ADD + MUL geht in zwei Clocks mit maximalem System speed! Hängt man die beiden Teile hintereinander in einen Clock, ist es von der Verdrahtung und dem Rest abhängig, wie schnell das geht. 80 MHz funktionieren bei einem Cyclone II! Du kannst mir ja mal einen konkreten Algorithmus oder einen Teil mit ein paar Variablen senden und ich programmiere es Dir mal.
Hallo Jürgen Klasse Idee. Ich sende Dir mal den Algorithmus des Reglers selbst zu. Am besten auch gleich mit Ablaufsteuerung, so wie man ihn in der Praxis einsetzt. Das werde ich aber zeichnen müssen, und das kann ein paar Tage dauern, weil ich die nächsten Tage außer Haus bin. Die Zeichnung versuche ich einzuscannen und als PDF-File zu schicken. Hinweis: der Algorithmus -also die PID-Struktur- ist nur der kleinste Teil des gesamten Reglers. Dazu kommen noch diverse Überwachungsaufgaben und Ablaufsteuerungen, weil man den Regler in einer Regelkette nicht so einfach ein-und ausschalten kann. Der Regler wird ja immer zusammen mit der Energiezufuhr eingeschaltet und beim Abschalten der Energiezufuhr wieder ausgeschaltet, wobei er dabei noch ein paar Sekunden weiterregeln muß, weil ja die Energie im System noch für ein paar Sekunden gespeichert sein kann. Das Ein- und Ausschalten soll dabei möglichst stoßfrei geschehen.Stellgröße auf Null beim Ausschalten ist bei Hydraulik tödlich, weil die Hydraulikspeicher noch Öl enthalten können und der Zylinder durch den Ventiloffset vollen Hub machen kann, ohne daß man das in irgendeiner Weise beeinflussen kann! Ein ziemlich komplexes Gebilde.Es reicht aber, wenn Du nur den PID-Regler selbst programmierst -so Du magst. Der Rest ist nur zur Info. Du müßtest mir dann bei Gelegenheit mal Deine Email-Adresse geben. Gruß Peter
Hallo Peter, auch wenn Du es vielleicht nicht so gerne hörst, aber mir scheint, dass Du doch noch nicht die richtigen Vorstellung davon hast, was man mit einem FPGA machen kann oder machen sollte. Timing und Glitches : Ein Design auf einem FPGA sollte immer voll synchron laufen, d.h. alle Schaltungsteile werden mit einen (oder mehreren) Clocks getaktet. Damit gibt man eine maximale Signallaufzeit zwischen einem FF und dem nächsten vor. Nur dadurch erhält man ein portables (von einem FPGA-Typ oder Hersteller zum anderen) Design, das man auch verifizieren kann. Innerhalb eines Schaltungsteils mit einem bestimmten Takt sind damit Glitches kein Problem. Wenn man mehrere Clocks verwendet, muß man an den Übergängen zwischen diesen "clock domains" auf Metastabilität achten. Wenn man zwischen Signalen Verzögerungen braucht, so können diese nur ein Vielfaches der Taktrate sein und können mit einem Zähler implementiert werden. Regler : Ein FPGA hat gegenüber einem DSP den großen Vorteil, daß man Algorithmen parallelisieren kann. Dazu wird der Algorithmus in Stufen aufgeteilt (Pipeline) und der Durchsatz erhöht. Je mehr Stufen, umso mehr Resourcen des FPGA's benötigt man. Für eine Steuerung, welche Verzögerungen von mehreren Sekunden realisieren soll, ist ein FPGA eigentlich eine Verschwendung. So wie Du das Ganze beschreibst, scheint dafür ein Prozessor die bessere Wahl zu sein. Wenn das ganze wirklich in einem FPGA realisiert werden soll, dann solltest Du die Schaltung aufteilen : - für die langsamen Teile eine Prozessor Core wie Pico-Blaze - für die zeitkritischen Teile, welche der Prozessor nicht in Echtzeit schafft, eine mehrstufige HW-Implementierung. Grüße Klaus
Hallo Klaus Vielleicht hast Du die Diskussion bis hierher nicht mitverfolgt. Der Regler selbst soll mit 40 Khz arbeiten. Ich will einen ganzen Regelkreis im FPGA unterbringen, mit Sollwertvorgabe und anderem. Die Sache ist schon ein bißchen umpfangreicher, weil es ja nicht nur um den reinen Algorithmus geht, wie ich versucht habe zu erklären. Es geht also um ein komplexes Zusammenspiel von vielen Schaltungsteilen, die teilweise parallel arbeiten können, teilweise aber voneinander abhängig sind. Meine Erfahrungen mit FPGA's sind Null. Daher auch meine vielleicht nicht immer sehr klugen Fragen. Es braucht keiner mit seiner Meinung hinterm Berg zu halten, solange noch verwertbare Informationen dabei herauskommen. Ich bin nicht so empfindlich. In dieser Hinsicht: Danke für deinen Kommentar. Grüße Peter
Hallo Peter, die 40 KHz sind genau der Punkt, weswegen mir vorkommt, dass du vielleicht falsche Erwartungen in ein FPGA setzt. 40 KHz sind für ein FPGA nämlich schneckenlangsam, ein FPGA schafft normalerweise mehr als 100 MHz. Im Unterschied zu einem Prozessor, wo man mit höherer Taktrate mehr Instruktionen ausführen kann, kann man bei einem FPGA dieses 2000:1 Leistungsverhältnis nur in besonderer Art nutzen. Bei einem FPGA ergibt sich die Taktrate durch die Verzögerungszeiten zwischen einem Flip-Flop und dem nächsten, also von der Komplexität der kombinatorischen Logik zwischen den FFs. Diese kombinatorische Logik wird im FPGA aus Grundelementen (z.B Lookup Table = LUT) aufgebaut. Jede LUT schafft nur eine gewisse Komplexität. Erfordert das Design eine höhere Komplexität, dann muss der VHDL Compiler mehrere LUTs hintereinanderschalten. Üblicherweise hat so ein FPGA Verzögerungszeiten von einigen ns. Bei 40 KHz könnte man sich eine Verzögerungszeit von 25 us leisten, man könnte also so komplexen Kode schreiben, daß der VHDL Compiler ca. 2000-5000 LUTs hintereinanderschalten darf. Diesen Weg beschreitet aber meines Wissens niemand. Erstens sind die Werkzeuge (Compiler) nicht dafür ausgelegt, mit so komplexen Logiken umzugehen, und zweitens sind auch die Resourcen eines FPGAs begrenzt. Angenommen Du speicherst Deine Regelgröße in einem 32 Bit Register, dann braucht Du nur dafür ein FPGA mit 32 x 5000 = ~150000 Luts. Damit bist Du in der Größenordung eines mittleren Xilinx Virtex Bausteins um 500-1000 USD. Die Schnelligkeit eines FPGAs kann man nur nutzen, wenn man es schafft den Algorithmus so zu formulieren, daß ein Block mit 40 KHz Eingangsdaten bekommt, damit ca. 2000 Taktzyklen zu 10 ns lang arbeitet, und nach diesen 2000 Zyklen ein gültiges Ergebnis auswirft. Dies setzt aber irgendwie voraus, daß der Algorithmus iterativ formulierbar ist, wie z.B. ein FIR-Filter oder eine FFT, sonst braucht man wiederum zu viele Resourcen. Wenn Dein Regelkreisalgorithmus sich in Schleifen formulieren läßt, dann kann er sich für die Implementierung mit einem FPGA eignen, wenn er aber vielfach aus Vergleichsoperationen und Sprüngen besteht, dann ist er bei einem generischen Zustandsautomaten ( = Prozessor) besser aufgehoben. Ein Wort auch zur Verwendung von Gleitkommazahlen. Obwohl VHDL diese kennt, lassen sich diese nicht synthetisieren. Du brauchst also eine Bibliothek für Gleitkommaoperationen. In Hardware sind selbst einfache Operationen, wie z.B. die Addition zweier Gleitkommazahlen nicht ohne, und benötigen zumindest eine Menge Resourcen. Denk an die Komplexität eines Mathematik Coprozessors. Zum Schluß eine Gewissensfrage : Was erwartest Du Dir wirklich von der Verwendung eines FPGA's gegenüber eines DSP's? Wenn der Algorithmus am DSP so groß wird, dann wird er auch im FPGA gewaltig komplex werden und vielleicht ein FPGA zu 1000 USD benötigen. Wenn Du aber denkst, daß sich der Algorithmus in VHDL schneller oder einfache schreiben läßt als in DSP Assembler, dann wirst Du dich wahrscheinlich täuschen. Für die Synthese ist VHDL letztentlich nur eine, ein bischen mächtigere Schaltplaneingabe (damit bist Du ja vertraut) und stellt Dir nicht automatisch Hochsprachenkonstrukte wie Gleitkommaoperationen usw. zur Verfügung. Ganz ehrlich, ich denke, ein DSP mit C-Compiler ist dafür, wie Du deine Anwendung beschreibst, das beste. Grüße Klaus
Ich denke, daß sein Ansatz nicht falsch ist, mehrere Komponenten paralle nutzen zu können. Was aber einen Regler angeht, so muss -wie von mir und Klaus beschrieben, die Bedarfszeit für den Durchlauf einer kompletten Operation inklusive aller Filter genügend klein sein, um auf die benötigte Datentaktrate zu kommen. Klappt das, so hat das FPGA folgende Vorteile: Das FPGA kann eingangsseitig übertaktet werden, daß heisst, es können mehr als durch den Reglertakt vorgegene Daten eingeworfen werden, da alles Funktionen physikalisch exisitieren. Es bleibt aber die Latenz. Die so gewonnenen "Schaltkreise" könenn mehrfach ausgebaut werden und führen nicht zu einer Verfünftelung der DSP-Kapazität. Dafür muss das FPGa aber gross genug sein. Das wird ein Problem bei den vielen geplanten Filtern! Umgekehrt argumentiert, muss das FPGA aber die 5fache Hardware aufweisen, als der DSP! - Routingresourcen und prinzipielle Nachteile bei der Nachbildung von Rechenfuntionen nicht eingerechnet. Ob das eine, oder das andere besser ist, ist eine Frage der Schaltungsstruktur: Je rechenlastiger, desto eher sind die DSPs noch ausreichend. Je hardwarelastiger, desto mehr wird beim DSP durch aufwändige Formulierung einfacher Schaltungfuntionen verplempert. Es ist nicht so easy, mehere HIGH-speed AD-Wandler parallel auszulesen und einige Grundfunktionen so rasch zu bearbeiten, daß für alle Kanäle eine hohe Reaktionszeit erreicht wird. Ein Beispiel für ein kritisches Medizingerät: Auch für 16 Datenkanäle erreicht man nach (und unter pipeline-Betrachtung schon WÄHREND) der Datenaquise inklusive einer Linearitätskorrektur schon unterhalb von 10 clks eine Schnellabschaltung infolge von spikes oder Datenfehlern - ein DSP braucht dafür mindestens 15 Befehle je Kanal. (Einige Programmspeicher und RAM-Zugriffe sowie Entscheidungen). Ein Vergleich kam auf ca 400 clks, im Falle eines parallelen Eintreffens mehrerer Fehlerereignisse gleichzeitig Wenn die APP aber über ein FPGA wächst und verteilt werden muss,dann sollte man sich fragen, ob 5 DPSs nicht billger kommen.
Hallo Klaus, Hallo Jürgen Die Entscheidung FPGA oder DSP ist Philosophie. Beide haben ihre Vorzüge und Nachteile. Welches die bessere technische Lösung ist, läßt sich aber m.E. vorher nicht sagen, da man beim FPGA noch keine Lösung hat bzw Teillösungen existieren. Der FPGA hat aber dem DSP einen (großen) Vorteil voraus: Da das ganze in Hardware abläuft, kann auch keine Software abstürzen. Bei einer High Speed Regelung in Industrieumgebung nicht zu unterschätzen. Zudem haben FPGA's ja schon teilweise fertige ROM/RAM-Blöcke und Hardwaremultiplizierer, die die Sache erleichtern. Die lokale Speicherung von Daten könnte man in einem RAM-Block unterbringen. Register wären da viel zu aufwendig. Falls die Sache beim FPGA zu komplex wird, habe ich aber immerhin noch Ausweichmöglichkeiten. Ich könnte ja einen FPGA mit Hardwareprozessor einsetzen (z.B. Xilinx Virtex 2 Pro)und dort einen Teil der Logik unterbringen. Ich könnte auch Softwareprozessoren verteilt auf dem FPGA einsetzen, die mir den Teil mit der Entscheidungslogik abnehmen. Die Schaltung könnte man sicherlich auch so abspecken, daß man nur die Teile nimmt, die sich parallelisieren lassen und keine Entscheidungslogik enthalten. Diese könnte ich beispielsweise auch im Treiber auf dem PC unterbringen und das FPGA nur mit Zustandsflags steuern etc. Ich sehe beim FPGA noch Potential. Ich bin auch nicht der erste, der eine Regelung in einem FPGA unterbringt. Habe auf der Homepage von Xilinx einen Kommentar einer Firma zum Softwareprozessor PiciBlaze gelsen. Die haben vier parallele Regelkreise mit 32 Bit Auflösung und 10 kHz Abtastrate in einem FPGA untergebracht unter Benutzung dieses Softwareprozessors. Vollen Respekt von mir zu dieser Leistung! In dem Projekt sind auch noch andere involviert. Die Entscheidung pro FPGA ist gefallen. Wir haben auch schon einigen Aufwand darin gesteckt, so daß sich die DSP-Frage nicht mehr stellt. Es geht jetzt also darum, wie man am besten und schnellsten zu Potte kommt. Last but not least: Mich reizt das FPGA deshalb, weil ich mich damit in einer Technologie einarbeiten kann, die ich auch für andere Zwecke gut nutzen könnte. Nun zur weiteren Vorgehensweise: In einem Monat habe ich die fertige Reglerlösung auf dem Papier ausgearbeitet (allerdings erst mal ohne Filter). Dann kann man weitersehen. Grüße an alle Peter
Im Bespiel des Regelkreises im Virtex dürfte C-Code zum Einsatz kommen. Das ist nicht schneller als im DSP! Man muss schon ein wenig hardwareorientiert bauen, um aus einem FPGA deutlichmehr rauszuholen: Damit Du eine Vorstellung von der Speed des FPGA bekommst: Ich baue gerade ein privates DSP-Projekt so um, daß eine Vorarbeitung in einem FPGA stattfinden kann. Die grundlegende Eingangsfilterung und Glättung, sammt Peek- und Lgitchdetektion mit Gain- und Biaskorrektur läuft in weniger als 20 clks! Das sit die effektive pipelin-Latenz bis zu diesem Punkt. Dabei sind Multiplikationen und Additionen schon so aufgeteilt und teilparallelisiert, das sie jeweils in einem Clock laufen können! Das Design synchronisiert laut Quartus derzeit mit 200MHz und clocked mit 100. Geplant sind 160/80. Das durchgeschleifte Signal ergibt wieder 160MHz Datenrate -> an Folgestufe. Bei der aktuellen Latenz liesse sich eine Datenrate von immerhin 20 MHz eininterpretieren, d.h. ich kann 5Meg gut absamplen. Das reicht sogar für Videoapplikationen - der DSP, der das im Moment macht, rennt selber zwar auch mit 100MHz, braucht aber schon für einen Kanal alleine über 30 Befehlsschritte in C, die mit gemessenen 250-300 clks reinhauen, da der Prozzi noch INTs ausführen muss. Daher reicht es bei 32 Kanälen auch nur zu Audio@96kHz! (56303). Der FPGA kann viele dieser einfachen Vergleiche und Signalumschaltungen in einem Schritt erledigen, zumdem laufen viele Prozesse pipelined parallel und eine Erweiterung des FPGA auf 32 Kanäle kostet nur 32 clks für den MUX.
Hallo Jürgen Das ist ja toll, daß Du schon ein paar Sachen realisiert hast, die ich gut gebrauchen könnte wie z.B. Eingangsfilterung und Glättung sowie Peakdetection. Für die Filter hätte ich gerne gewußt, welche Algorithmen Du verwendest und wer die Berechnung der Koeffizienten übernimmt. Lassen sich bei den Filtern Eckfrequenz und Filterrate irgendwie einstellen? Ist es möglich, daß Du mir den Code überläßt?Wenn die Sachen bei mir zum Einsatz kommen, kann man sicherlich auch üner eine Aufwandsentschädigung sprechen. Die Regelung mit AD/DA-Wandlung und Meßdatenvorverarbeitung (wie z.B. Filterung/Glättung, Meßdatenreduktion) sollen bei mir schon im FPGA laufen und nicht im Prozessor vom Virtex. Im Prozessor selbst soll eigentlich nur die Schnittstelle zum PC laufen und ein Befehlsinterpreter, um die Regelung samt Sollwertgenerator zu starten. Die Meßdaten, die ja in Bits vorliegen, müssen auch noch irgendwo in Volts oder technische Einheiten (Kraft, Weg, Dehnung etc.) umgerechnet werden. Ob das auch der Proz. machen soll, weiß ich noch nicht. (Bei 40 kHz Abtastrate und 5 Meßkanälen sind das immerhin 200k Meßwerte, die im worst case umgerechnet werden müssen; in der Regel sind es natürlich weniger. Man braucht nicht unbedingt jeden Meßwert, und wenn dann nur für einen single shot. Daher auch die Meßdatenreduktion auf einzelne Zyklen (ein Zyklus ist eine komplette Sinusperiode)) Gruß Peter Rinas
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.