mikrocontroller.net

Forum: FPGA, VHDL & Co. Regelkreis


Autor: Peter Rinas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: **** (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: **** (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Juergen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Rinas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Rinas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: **** (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;


entity exmple is
   generic (
      System_Takt : natural := 32000; -- In kHz
      Bitbreite   : natural := 18;
      -- .. ;
      -- ..
   );

   port (
      CLK           : in  std_logic;
      Ist_Wert      : in  std_logic_vector(Bitreite - 1 downto 0);
      Soll_Wert     : in  std_logic_vector(Bitreite - 1 downto 0);
      Regelgröße    : out std_logic_vector(Bitreite - 1 downto 0);

      Koeffizient1  : in  std_logic_vector(Bitreite - 1 downto 0);
      Koeffizient2  : in  std_logic_vector(Bitreite - 1 downto 0);
      Koeffizient3  : in  std_logic_vector(Bitreite - 1 downto 0);
      --.. ;
      --.. ;
   );
end exmple;


architecture Verhalten of exmple is

   component sld_virtual_jtag
      generic(
         sld_auto_instance_index  : STRING;
       sld_instance_index      : NATURAL;
     sld_ir_width          : NATURAL;
     sld_sim_action          : STRING;
     sld_sim_n_scan          : NATURAL;
     sld_sim_total_length    : NATURAL;
     lpm_type                : STRING
      );

      port(
         ir_out            : IN STD_LOGIC_VECTOR (1 DOWNTO 0);
        tdo            : IN STD_LOGIC ;
     ir_in            : OUT STD_LOGIC_VECTOR (1 DOWNTO 0);
     jtag_state_cdr    : OUT STD_LOGIC ;
     jtag_state_cir    : OUT STD_LOGIC ;
     jtag_state_e1dr  : OUT STD_LOGIC ;
     jtag_state_e1ir  : OUT STD_LOGIC ;
     jtag_state_e2dr  : OUT STD_LOGIC ;
     jtag_state_e2ir  : OUT STD_LOGIC ;
     jtag_state_pdr    : OUT STD_LOGIC ;
     jtag_state_pir    : OUT STD_LOGIC ;
     jtag_state_rti    : OUT STD_LOGIC ;
     jtag_state_sdr    : OUT STD_LOGIC ;
     jtag_state_sdrs  : OUT STD_LOGIC ;
     jtag_state_sir    : OUT STD_LOGIC ;
     jtag_state_sirs  : OUT STD_LOGIC ;
     jtag_state_tlr    : OUT STD_LOGIC ;
     jtag_state_udr    : OUT STD_LOGIC ;
     jtag_state_uir    : OUT STD_LOGIC ;
     tck            : OUT STD_LOGIC ;
     tdi            : OUT STD_LOGIC ;
     tms            : OUT STD_LOGIC ;
     virtual_state_cdr  : OUT STD_LOGIC ;
     virtual_state_cir  : OUT STD_LOGIC ;
     virtual_state_e1dr  : OUT STD_LOGIC ;
     virtual_state_e2dr  : OUT STD_LOGIC ;
     virtual_state_pdr  : OUT STD_LOGIC ;
     virtual_state_sdr  : OUT STD_LOGIC ;
     virtual_state_udr  : OUT STD_LOGIC ;
     virtual_state_uir  : OUT STD_LOGIC
      );
   end component;


   signal Lesen               : std_logic;
   signal Ist_1, Ist_2, ..    : std_logic_vector(Bitbreite - 1 downto
0);

   --.. ;


begin

   Reler: process(CLK)
   begin
      if CLK'event and CLK = '1' then
         if Lesen = '1' then
            Ist_1 <= Ist_Wert ;
         end if;
         -- ??????
      end if;
   end process;


   -- instantiation of the vji mega functionc */
   jtag_inst0: sld_virtual_jtag
   generic map (
    sld_auto_instance_index => "YES",
    sld_instance_index => 0,
    sld_ir_width => 2,
    sld_sim_action => "",
    sld_sim_n_scan => 0,
    sld_sim_total_length => 0,
    lpm_type => "sld_virtual_jtag"
   )

   port map(
    ir_out => "00",              --sample_instr_counter) input to
megafunction
    tdo => tdo,                --input to mega function

       ir_in => ir_in,      -- output from mega function
    tck => tck,        -- output from mega function
    tdi => tdi,      -- output from mgafunction

       virtual_state_cdr => cdr,  -- output from mega function
    virtual_state_e1dr =>e1dr,  --  "
    virtual_state_e2dr =>e2dr,  --   "
    virtual_state_pdr => pdr,  --   "
    virtual_state_sdr => sdr,  --  "
    virtual_state_udr => udr,  --   "

    virtual_state_uir => uir,  --   "
    virtual_state_cir => cir  --  "

   );

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 :-)

Autor: Peter Rinas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: high_speed (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Juergen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ihr Regelspezialisten - jätte mal jemand ein Bespiel eines solchen
Reglers in VHDL ?

Autor: Peter Rinas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: high_speed (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
signal a, b, c : std_logic_vector(31 downto 0);
c <= ( a(31 downto 16) & x"0000") +  b ; 
-- Hier sind für die Rechnung die 4 Hex Stellen mit der kleinsten
Wertigkeit auf Null.

signal a, b, c : std_logic_vector(31 downto 0);
c <= ( x"0000" & a(31 downto 16) ) +  b ;
-- Hier wurden die 16 oberen Bits nach unten verschoben und oben mit
Nullen aufgefüllt.

-- 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

Autor: Peter Rinas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: high_speed (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/fe...
http://www.altera.com/products/devices/cyclone2/ov...

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

Autor: Jürgen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Rinas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: PeterRinas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Rinas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Rinas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.