mikrocontroller.net

Forum: FPGA, VHDL & Co. Ideen für FPGA-Projekte?


Autor: Marius S. (lupin) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Habe in meiner Thesis die Huffman-Dekodierung für einen MP3 Player in 
VHDL gebaut. Das war schon mal ganz interessant und ich suche jetzt nach 
einer Idee, was man noch so mit VHDL/FPGAs anstellen kann.

Ich könnte natürlich das MP3-Dekoder Projekt weiter verfolgen, aber ist 
unwahrscheinlich, dass ich damit in absehbarer Zeit fertig werde.
Realisiert sind im Grunde bisher nur der Huffman Dekoder und die 
Synthese-Filterbank. Daraus könnte man auch ein Community-Projekt 
machen, aber glaube nicht das da viel bei rum kommt.

Ich hatte auch mal die Idee einen Sigma-Delta DAC komplett im FPGA zu 
bauen.
Habe mir dazu mal die delta sigma toolbox von Matlab angeschaut 
(http://www.mathworks.com/matlabcentral/fileexchang...).
Hier gibt es auch ein Paper, wo sowas schon mal gemacht wurde:
http://www.ee.usyd.edu.au/people/philip.leong/User...
Aber irgendwie ist das auch nicht mal eben so zum Basteln geeignet - 
viel Signalverarbeitung, da qualmt der Kopf wieder so.... :-)
Ansonsten würde ich das super interessant finden.

Idealerweise sollte noch irgend ein Nutzen aus dem Projekt zu ziehen 
sein. Also entweder, das man es wirklich als "Produkt" nutzen kann 
(hatte auch schon an eine (Binär)-Uhr mit CPLD gedacht, ist aber eher 
nicht besonders anspruchsvoll) oder das es einen "akademischen" nutzen 
hat (wie z.B. der delta sigma DAC - ich habe bisher noch keinen mit 
höherer Ordnung als Open Core gefunden).

Interessant würde ich halt Signalverarbeitungs-Themen finden.
Ein Radio-Empfänger mit IQ Demodulation als Direktempfänger wäre auch 
interessant. Wollte z.B. mal eine DCF77 Antenne bauen, das Signal 
sampeln und weiter verarbeiten (also Phase und Amplitude raus ziehen und 
irgendwie auswerten).

Oder Projekte bei welchen die Vorzüge eines FPGAs (Parallel-Verarbeitung 
und Geschwindigkeit) genutzt und auch tatsächlich benötigt werden. Jetzt 
zwanghaft ein Projekt mit FPGA zu realisieren ist nicht nötig, habe auch 
Mikrocontroller hier rum fliegen...


Vielleicht hat ja jemand auch weiter führende Infos/Quellen zu den oben 
genannten Themen, die das ganze ein wenig einfacher machen.

Autor: Holger Harten (holger-h-hennef) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
-2 lesenswert
nicht lesenswert
Marius S. schrieb:
> Oder Projekte bei welchen die Vorzüge eines FPGAs (Parallel-Verarbeitung
> und Geschwindigkeit) genutzt und auch tatsächlich benötigt werden. Jetzt
> zwanghaft ein Projekt mit FPGA zu realisieren ist nicht nötig, habe auch
> Mikrocontroller hier rum fliegen...

Na super !
Tip:
Evtl eine "WIFI Mobile" BAT Driven FPGA "Low Power Anwendung" , die man 
am Handgelenk tragen kann. Mit einem Wifi Chip noch dazu.
  Microcip --> Chip: MRF24WBOMB  for Wifi .
Damit geht es via Handy Kopplung ins WEB.
Das ist eine Weltneuheit Mobile FPGA Wifi Internet (PHONE) Kopplung.
Das ist die Backplane von der Mobil Platine.
Marius S. schrieb:
> (hatte auch schon an eine (Binär)-Uhr mit CPLD gedacht, ist aber eher
> nicht besonders anspruchsvoll) oder das es einen "akademischen" nutzen
> hat (wie z.B. der delta sigma DAC -
Der DAC am Handgelenk fürs Prüffeld mit Dokumentation über Wifi
Gruss Holger.
PS.
Das ist die Front-Plane von der Mobil Platine.
> (hatte auch schon an eine (Binär)-Uhr mit CPLD gedacht,
JA so ganz aus GLAS {[{[{[{[ Bild zur WEB-UHR
Beitrag "Lattice MachXo2 Bat.Powerd Stand Alone Soc"

 Microcip --> Chip: MRF24WBOMB  for Wifi .LINK
Beitrag "MIDI over WIFI ( RF Bluethoot Dect USB ) Homemade Interface"
Und der ist über die Busleiste andock_bar als MODUL. 
"MACH_XO2_PACTRON.PNG"

: Bearbeitet durch User
Autor: Holger Harten (holger-h-hennef) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Marius S. schrieb:
> Vielleicht hat ja jemand auch weiter führende Infos/Quellen zu den oben
> genannten Themen, die das ganze ein wenig einfacher machen.
MP3 Ref+ Low Power von Peter Sieg. mit ALTERA MP3 Sourcen
(Arrow Elecronics FPGA Ref-Designs)
Beitrag "ALTERA The Low Power Reference Platform (LPRP) = 19,99€!!"
------------------------------------------------------------------------ 
---
Zum anlesen
Hier nur mal als Beispiel für den Wifi Chip die Com-Kopplung

http://www.basic4ppc.com/android/help/serial.html

Gruss Holger.
TIP:
------------------------------------------------------------------------
>Idealerweise sollte noch irgend ein Nutzen aus dem Projekt zu ziehen
>sein. Also entweder, das man es wirklich als "Produkt" nutzen kann
Z.B ein X-Bee oben auf dem Board is ein 6 Pol-Connect Slot, damit kannst
du den Data-Streem via dem Decoder Abgreifen, und lauscht damit alles
ab, was rein und raus geht, also dein eigener PHY-FPGA Anschluss.
------------------------------------------------------------------------ 
--

: Bearbeitet durch User
Autor: FPGA-Projektor (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Wie wäre es mit einem neuen Telespiel a la FPGA Arcade für eines der 
aktuellen eval-boards?

Autor: Holger Harten (holger-h-hennef) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Link: Professor Bruce Land
http://www.cornell.edu/search/?q=fpga&submit=go&tab=
Da sind 100 Projecte-  mit Project-Bildern + Doku. + Source Code.
Fast alles Altera.
Professor Bruce Land cornell.edu
Schau mal rein bitte, da findest du sicher was, weil halt das ganz gut
beschrieben ist, finde ich.

Gruss Holger.

Professor Bruce Land in youtube. Da sind auch Vorlesungen zum
Wolfson Chip via MP3, I2C-Bus >--> 2Channel.. Wolfson MP3-Interface
---------------------------------------------------------------------
Das MP3 ist in meinem obigen Link nur mit dem
ALTERA Cyclon II FPGA gemacht. Die Source ist von "Arrow Electronics".
######################################################################
Title: Sound Bite
Link:
https://instruct1.cit.cornell.edu/Courses/ece576/F...
######################################################################
Auch Netzwerk-FPGA Karten, nur den (+/-)--PHY -- rest [FPGA]--RAM-IF.

: Bearbeitet durch User
Autor: Mark W. (kram) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wie waers mit einem kompletten Computer samt Compiler und 
Betriebssystem? :-)

http://www.projectoberon.com

Da bin ich kuerzlich drueber gestolpert.

Mark

Autor: FPGA-Projektor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, gleich nen ganzen Rechner? Es gibt ja schon Projekte dieser Art in 
Massen unter anderem auch das 8Bit Projekt von Josef hier im Forum.

Was das Obereon Projekt angeht, sehe ich nocht nicht, auf welcher HW das 
läuft. Habe mir das HW PDF angesehen und auch das Daugtherboard-PDF.

Wo ist die Hauptplatine? Ein Spartan Eval board?

Ehrlich gesagt bin ich skeptisch mit solchen Projekten wo man auch auf 
dem zweiten Blick noch nicht erkennnt, wie es grundsätlich aussieht. 
Solche halbgut dokumentierten Projekte mag ich ganz besonders :-(

Das ist aber meistens genau das, was aus solchen "Ich hau mal schnell 
was raus"-Ideen wird. Eine Art Selbstbefriedigung für den Erfinder, mit 
begrenztem Wert für andere User.

Autor: Mark W. (kram) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Also fuer mich war es das erste mal, dass ich nen kompletten Rechner 
inclusive Graphischen Betriebssystem gesehen habe.
Hier gibts ein Bild.
http://www.schleibinger.com/bilder/oberon.jpg
Dss ganze laeuft auf einem Spartan III Board.

Mark

Autor: Holger Harten (holger-h-hennef) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
FPGA-Projektor schrieb im Beitrag #3575389:
> Wie wäre es mit einem neuen Telespiel a la FPGA Arcade für eines der
> aktuellen eval-boards?
Das is 3D Vector Equipment, aber sehr lange Ladezeit. Da sind von 
Grundlagen bis zum Kompexen X-Dim Vector-Array alles drin.

FPGA Arcade Haberer

Haberer suche ich noch raus, der baut Spiel(e)-Konsolen aus FPGAs, 
haupsächlich mit ALTERA (Cyclone II)
------------------------------------------------------------------------
Link: Für die Mathematik ...-->

http://aranna.altervista.org/data2/3d_game_program...
------------------------------------------------------------------------ 
-

Gruss Holger.

: Bearbeitet durch User
Autor: Marten W. (goldmomo) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst dir evtl. auch mal mein Projekt ansehen, vielleicht findest du 
einige brauchbare Ideen.

<Werbung>
Beitrag "FPGA basierendes System"
http://www.goldmomo.de
</Werbung>

Autor: Christoph Z. (christophz)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Vor Weihnachten wurde für den RaspberryPi und den BeagleBone ein FPGA 
Erweiterungsboard angekündet:
http://www.heise.de/newsticker/meldung/LOGi-FPGA-A...


Da kam auch schnell die Frage auf, was wäre ein Beispielhaftes "Killer 
Feature" das so eine Erweiterung rechtfertigt.

Nach etwas Überlegung kam mir dann diese Idee:

Aus der Kombination eines BeagleBone black mit zusammen mit dem FPGA 
Erweiterungsboard könnte eine sehr kompakte, performante CNC Steuerung 
gebaut werden.

Dazu müssen zwei bestehenden OpenSource Projekte auf diese Plattform 
portiert werden.

LinuxCNC gibt es schon für den RaspberryPi, dass heisst für den 
BeagleBone müsste sich das mit abschätzbarem Aufwand auch portieren 
lassen. LinuxCNC setzt auf die Echtzeit-Kernel Erweiterung Xenomai die 
es auch für ARM gibt:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RaspbianX...

Das Zweite wäre, das HostMot2 FPGA Design portieren auf den LOGi und ab 
geht die Post:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HostMot2

HostMot2 wird sonst mit den AnyIO Karten von Mesa Electronics 
eingesetzt. Damit werden Signale für Schrittmotoren generiert, PWM 
Signale für Servo Steuerungen, Encoder Signale Ausgewertet etc.

Denkbare Erweiterungen im FPGA reichen von Watchdog/Hartbeat Überwachung 
über weitere Sensorschnittstellen (Analoge Ein-/Ausgänge mit delta-Sigma 
:-) ), Feldbusanbindungen, Temperaturüberwachung etc.

Autor: Hanno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FPGA-Projektor schrieb im Beitrag #3575946:
> Naja, gleich nen ganzen Rechner? Es gibt ja schon Projekte dieser
> Art in
> Massen unter anderem auch das 8Bit Projekt von Josef hier im Forum.

Was aber eher zu den abschreckenden Beispielen gehört...

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute,
all die Sachen, die man besser mit nem µC machen kann, sollte man auch 
mit nem µC machen. Also nix mit Komplettrechner, CNC-Steuerung und so.

Aber es gibt ein riesiges Feld, wo ein µC überfordert ist: die digitale 
Signalverarbeitung.

Vorschlag 1: SDR, also erstmal KW-Empfänger, dann KW-Transceiver.
Vorschlag 2: ebenfalls SDR: Breitband-Empfänger, sagen wir mal 30 MHz 
bis 3 GHz, mit Dekodern für alles, was einem da begegnet, incl. DAB+ 
usw.

Vorschlag 3: Wettersat-Empfänger mit Dekoder für HRPT usw.

W.S.

Autor: Tippgeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also es gibt durchaus Felder, bei denen man mit UCs arbeiten könnte und 
dennoch FPGAs eingesetzt werden. Eine CNC gehört jetzt nun nicht gerade 
dazu, aber PLCs werden in inzwischen mit FPGAs realisiert, z.B. von 
Phönix Contact. Altera hatte da mal ein Seminar, wo sie uns deren App 
als Beispiel für NIOS verklickert haben.

Weiters ergeben sich hochperformante Versionen von existierenen 
DSP-Aplikationen im Consumerbereich, die aufgrund des Kostendrucks mit 
reduzierter Leistung gegenüber dem Machbaren verkauft werden, um einen 
Markt zu haben. Consumer Audio ist das ein Punkt.

Mir ist da ein Projekt von der embedded in Erinnrung, wo einer eine 
komplette Filterbank zur Klangbearbeitung für Studios aufgebaut hat, so 
wie sie früher für analoge Synthesizer benutzt wurde. Und dann gibt es 
ja die Synthesizer selber, die seit Neuestem in FPGAs gepresst werden, 
wie der hier in FPGAs, die noch gar nicht lieferbar sind:
http://fpgasynth.beepworld.de/cyclone.htm

Das Beste sind natürlich die SDR-Projekte für die Heimanwendung, aber da 
kommt gleich soviel Aufwand bei raus, dass es richtig ins Geld geht. Ein 
SDr-Projekt mit Antennen und HF-Design und pipapo täte ich mir jetzt 
garnicht alleine zutrauen. Dafür habe ich meine HF-Konstruktionsheinis, 
die mir das basteln :-D

Aber vielleicht könnte man sowas auf Langwelle mit FPGAs machen, so als 
virtuellen Schwingkreis. Oder gleich einen Knallfunkensender a la 
Marconi mit GTP-Transceivern für die Musikübertragung in den Garten, wie 
Gustel Buheitl.

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Leute,
> all die Sachen, die man besser mit nem µC machen kann, sollte man auch
> mit nem µC machen. Also nix mit Komplettrechner, CNC-Steuerung und so.

Du meinst "billiger" statt "besser". Ein FPGA kann locker die Aufgaben 
eines 8/16 bit uC übernehmen und dazu ein Mehrfaches an Ports und 
peripherieansteuerung. Digitale Filter, Graphikdisplayansteuerung, mehr 
Interrupts nachrüsten - kein Problem. Anders sieht es bei den embedded 
Prozessoren in Smartphones aus, mehrere Cores im GHz bereich - da sieht 
ein FPGA alt aus.

Retrocomputing - also der nachbau älterer Computer wie die Homecomputer 
der Achtziger ist m.E. ein lehrreiches FPGA-projekt. Schau mal: 
Retrocomputing auf FPGA

MfG

Autor: Christoph Z. (christophz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tippgeber schrieb:
> Also es gibt durchaus Felder, bei denen man mit UCs arbeiten könnte und
> dennoch FPGAs eingesetzt werden. Eine CNC gehört jetzt nun nicht gerade
> dazu, aber PLCs werden in inzwischen mit FPGAs realisiert

Für das Protokoll, da es oben schon anders geschrieben wurde:

Die CNC Steruerung selber läuft beim obigen Vorschlag auf einem 1 GHz 
ARM Cortex-A8 von TI. Als Basis dient ein Linux mit Echtzeiterweiterung. 
LinuxCNC übernimmt auch das Benutzerinterface mit Monitor/Tastatur/Maus. 
Trajektorien berechenungen und PID Regler für die Achspositionierung 
läuft auch auf dem ARM.

Was dieser ARM aber nicht kann (und viele andere schnelle Prozessoren 
auch nicht) ist das Ausgeben von mehren (>5) PWM Kanälen bzw. 
Step/Direction Signalen und das einlesen von mehreren (>5) Encoder 
Signalen (Quadratur, Sin/Cos) dafür braucht der Prozessor Hardware 
unterstüztung (z. B. per FPGA), dafür steht das OpenSource FPGA Design 
HostMot2 zur Verfügung.

Bisher waren solche Steuerungen gleich ganze PCs mit PCI Einsteckkarten. 
Mit dem BeagleBone und dem erwähnten FPGA Board würde das ganze auf die 
Grösse einer Festplatte zusammen schrumpfen.

Autor: Technicker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die CNC Steruerung selber läuft beim obigen Vorschlag auf einem 1 GHz
> ARM Cortex-A8 von TI. Als Basis dient ein Linux mit Echtzeiterweiterung.
Also ein richtig performanter Microcontroller, der mit einem 
Multitaskingsystem so richtig schon abgebremst- , dann mit einer RTE 
wieder etwas datendurchsätziger gemacht wird, um dann mit C einfach und 
schnell arbeiten zu können. Und das soll jetzt in einen FPGA?

Autor: Christoph Z. (christophz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Technicker schrieb:
> Und das soll jetzt in einen FPGA?

Nein, das soll in den ARM. Aktuell gibt es nur Entwicklungsversionen für 
den Raspberry Pi, das ist noch nicht fertig.

Aktuell läuft das alles auf einem x86 Prozessor.

Technicker schrieb:
> Multitaskingsystem so richtig schon abgebremst- , dann mit einer RTE
> wieder etwas datendurchsätziger gemacht wird, um dann mit C einfach und
> schnell arbeiten zu können.

Schick mal eine Bewerbung an meinen Chef, der wird dich mögen. Er 
versucht gerade auf einem 1 GHz ARM ohne OS, ohne Scheduler, ohne C++, 
ohne Trace Debugger etc. einen additiven Synthesizer mit 80 kHz update 
Rate, ein TCP/IP Interface mit LXI Unterstützung und einen EtherCat 
Master zu Implementieren, so dass sie gleichzeitig laufen und sich nicht 
in die Quere kommen.

Ich bin froh, dass ich ihm dabei nicht helfen muss.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanno schrieb:
> FPGA-Projektor schrieb im Beitrag #3575946:
>> Naja, gleich nen ganzen Rechner? Es gibt ja schon Projekte dieser
>> Art in
>> Massen unter anderem auch das 8Bit Projekt von Josef hier im Forum.
>
> Was aber eher zu den abschreckenden Beispielen gehört...

Begründung?

Autor: Hardwarespezi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh,Oh, da fühlt sich jemand getroffen :-) Also meine Meinng zu Josefs 
Projekt ist eher positiv, wenn ich auch nicht sehe, wer das einsetzen 
sollte ...

... wenn schon die Soft-CPUs, die turnusmässig Verwendung finden (oder 
fanden?) als Hw ausgelegt werden, wie ich lesen darf:

Christoph Z. schrieb:
> versucht gerade auf einem 1 GHz ARM ohne OS, ohne Scheduler, ohne C++,
> ohne Trace Debugger etc. einen additiven Synthesizer mit 80 kHz update
> Rate, ein TCP/IP Interface

nun, die ersten Musiksynthesizer hatten auch kein OS und liefen 
prächtig. Ok, sie hatten kein TCP/IP Interface aber wer braucht das?

Da hat sich Dein Chef in jedem Fall was Ordentliches vorgenommen. Wenn 
er es hier liest, sei ihm mein Respekt ausgesprochen. Allerdings würde 
ich ihn fragen, wozu er ausgerechnet 80kHz Rate braucht. Müssten das 
nicht 48 oder 96 sein?

Autor: W.S. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Fpga Kuechle schrieb:
> Du meinst "billiger" statt "besser". Ein FPGA kann locker die Aufgaben
> eines 8/16 bit uC übernehmen und dazu ein Mehrfaches an

Du irrst.

Ich meine tatsächlich BESSER.

Die allermeisten Aufgaben, die so für einen µC anstehen, kann ein FPGA 
nämlich überhaupt nicht besser, sondern nur schlechter oder allenfalls 
gleichgut, dann aber zu wesentlich höheren Kosten - und zu wesentlich 
höherem Entwicklungsaufwand. Hast du einen wirklich guten USB-Core oder 
Ethernet-Core oder DSP-Core oder sonstige Peripheriecores (SDRAM, DDRAM, 
SD-Card usw) in deinem Portfolio? Wohl eher nicht, du müßtest dir das 
alles zukaufen.


Ich geb dir mal ein paar Beispiele:
a) ein simpler 4 Bit Controller, der im Audioverstärker die 
Kanalumschaltung, die Lautstärke und die IR-Bedienung erledigt und nur 
ein paar Pfennige (oder Yen) gekostet hat

b) eine 300 MHz Mips im DVDplayer (ESS-Chips), mit SDRAM, Farbgrafik, 
chipinternem 64 Bit Signalprozessor, 208er Gehäuse was noch für 
zweilagige LP taugt - und für den Preis eines FPGAs von einer Größe, wo 
sowas hineinpassen würde, könnte man 3 komplette Player kaufen.

c) ein heutzutage üblicher µC, z.B. ein LPC4088, den es für ca. 8..9 
Euro fertig zu kaufen gibt. Schau dir mal an, was der alles drin hat, 
von Gleitkomma-Rechenwerk über TFT-Controller, USB, Ethernet, 
SDRAM-Anschluß, riesiger interner Flash, recht großer interner RAM und 
und und... Glaubst du, mit einem überhaupt erschwinglichen FPGA das 
alles nachbilden zu können?

Also: einen richtigen µC per FPGA ersetzen zu wollen, ist Mumpitz, weil 
man nie und nimmer an das Preis/Leistungs-Verhältnis herankommt und 
alerhöchstwahrscheinlich auch die auf dem Chip verbauten Cores nie und 
nimmer durch was Eigenes ersetzt kriegt.

Es gibt nur eine Ausnahme: Wenn ein tolles Ing-Büro Auftragsarbeiten 
macht und die Innereien ihres Werkes auf keinen Fall preisgeben will, 
wäre ein FPGA ne geeignete Hardware, um Rechte an dem darin verbauten 
Gehirnschmalz zu erheben. Aber das ist kein technisches Kriterium.

W.S.

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Also: einen richtigen µC per FPGA ersetzen zu wollen, ist Mumpitz, weil
> man nie und nimmer an das Preis/Leistungs-Verhältnis herankommt und
> alerhöchstwahrscheinlich auch die auf dem Chip verbauten Cores nie und
> nimmer durch was Eigenes ersetzt kriegt.
>
> Es gibt nur eine Ausnahme: Wenn ein tolles Ing-Büro Auftragsarbeiten
> macht und die Innereien ihres Werkes auf keinen Fall preisgeben will,
> wäre ein FPGA ne geeignete Hardware, um Rechte an dem darin verbauten
> Gehirnschmalz zu erheben. Aber das ist kein technisches Kriterium.

+1

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, ein paar mehr Gründe gibt es schon, FPGAs statt eines fertigen 
Controllers zu nehmen, als da wären:

- Supportverpflichtungen, Lieferbarkeit und Absicherung gegen 
Abkündigung. Es gibt mehr als eine Firma, die alte Prozessoren und deren 
FW mit FPGA Code absorbiert, um dem nachzukommen und immer wieder parat 
zu haben

- Resistenz gegenüber nachträglich gemeldeten bugs in den Prozessoren, 
die man im Feld nur per FPGA updaten kann,

- minimale Modifikationen der Funktion, um ein Alleinstellungsmerkmal zu 
erzielen

- nötige Änderungen der Funktion, um kundenspezifische Optimierungen zu 
erwirken

... wobei die letzten beiden Punkte kein 1:1 replacement wären.

Grundsätzlich hat W.S. natürlich Recht: Was mit einem Prozessor zu 
machen ist, sollte mit einem solchen gemacht werden. Allerdings ist das 
insofern eine etwas luftige Diskussion, als dass Prozessoren in grossen 
Massen ja für all die Fälle verfügbar gemacht werden, die Standard sind 
und viele Applikationen abdecken, während FPGAs eben für das genaue 
Gegenteil erdacht wurden. Der ständige Vergleich FPGAs <-> MCs ist also 
ein müßiger.


Ich habe mithin den Eindruck, dass in nicht wenigen Applikationen ein 
Softcore oder eine Software auf einem Hardcore nur deshalb eingesetzt 
werden, weil sie eben da sind oder weil die Software da war oder weil 
der Bearbeiter einen Softwarehintergrund hat und sich damit sicherer 
fühlt.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ W.S. (Gast)

>Du irrst.

>Ich meine tatsächlich BESSER.

Stimmt.

>Die allermeisten Aufgaben, die so für einen µC anstehen, kann ein FPGA
>nämlich überhaupt nicht besser, sondern nur schlechter oder allenfalls
>gleichgut, dann aber zu wesentlich höheren Kosten - und zu wesentlich
>höherem Entwicklungsaufwand.

Stimmt, wobei man dabei klar betonen muss "die so für einen µC 
anstehen". Und es ist logisch, dass es unsinnig ist, einen ASIC wie so 
einen uC in einem FPGA nachzubauen. Das ist bestenfalls eine akademische 
Fingerübung.

>a) ein simpler 4 Bit Controller, der im Audioverstärker die
>Kanalumschaltung, die Lautstärke und die IR-Bedienung erledigt und nur
>ein paar Pfennige (oder Yen) gekostet hat

Klar.

>b) eine 300 MHz Mips im DVDplayer (ESS-Chips), mit SDRAM, Farbgrafik,

>c) ein heutzutage üblicher µC, z.B. ein LPC4088, den es für ca. 8..9
>Euro fertig zu kaufen gibt. Schau dir mal an, was der alles drin hat,

>Also: einen richtigen µC per FPGA ersetzen zu wollen, ist Mumpitz, weil
>man nie und nimmer an das Preis/Leistungs-Verhältnis herankommt und

Stimmt. Eine Aufgabe, für die es einen gut geeigneten uC/ASIC gibt, löst 
man am besten mit eben diesem (technisch wie ökonomisch).

Aber für Aufgaben, für die es leistungsmässig oder funktional keinen 
passenden uC gibt, braucht man ein FPGA. Sei es wegen des hohen 
Datendurchsatzes oder wegen eher mittelschneller oder sogar langsamer 
Gluelogic, die durchaus mal ein mittleres FPGA füllen kann.

Autor: Ingenieur offline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Idee zum Thema: Wie wäre es mit einem Konfigurationstool für FPGAs? 
Wir haben nach wie vor keine sinnvolle FPGA-spezifische 
Versionsverwaltung, Entityverwaltung und Packageverwaltung.

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Fpga Kuechle schrieb:
>> Du meinst "billiger" statt "besser". Ein FPGA kann locker die Aufgaben
>> eines 8/16 bit uC übernehmen und dazu ein Mehrfaches an
>
> Du irrst.
>
> Ich meine tatsächlich BESSER.
>
> Die allermeisten Aufgaben, die so für einen µC anstehen, kann ein FPGA
> nämlich überhaupt nicht besser, sondern nur schlechter oder allenfalls
> gleichgut,

Nö, I2c, SPI, Timer und die übliche uC-Aufgaben kann jeder FPGA in 
(fast) beliebiger Anzahl und mit (fast) beliebigen Parametern). 4 UARTS, 
2x I"C Slave, 1I2C Master und 3x McBSP parallel kein Problem für einen 
FPGA.

>
>  Hast du einen wirklich guten USB-Core oder
> Ethernet-Core oder DSP-Core oder sonstige Peripheriecores (SDRAM, DDRAM,
> SD-Card usw) in deinem Portfolio?

USB und Ethernet lagert man schon wegen der speziellen Signalpegel in 
externe IC's aus, FPGA-Memorycontroller sind Standard, die gibts als 
Soft- und zuweilen auch als Hardcore gratis dazu, ebenso DSP-Cores 
(Filter).

> Wohl eher nicht, du müßtest dir das
> alles zukaufen.

Nö, nix Zukauf; vieles  gibts geschenkt (siehe unten); das meiste 
schreibt man selbst.

> Ich geb dir mal ein paar Beispiele:
> a) ein simpler 4 Bit Controller, der im Audioverstärker die
> Kanalumschaltung, die Lautstärke und die IR-Bedienung erledigt und nur
> ein paar Pfennige (oder Yen) gekostet hat

Das ist billiger, nicht besser.

> b) eine 300 MHz Mips im DVDplayer (ESS-Chips), mit SDRAM, Farbgrafik,
> chipinternem 64 Bit Signalprozessor, 208er Gehäuse was noch für
> zweilagige LP taugt - und für den Preis eines FPGAs von einer Größe, wo
> sowas hineinpassen würde, könnte man 3 komplette Player kaufen.

das ist keine 8/16bit mikrocontroler-Anwendung

> c) ein heutzutage üblicher µC, z.B. ein LPC4088, den es für ca. 8..9
> Euro fertig zu kaufen gibt. Schau dir mal an, was der alles drin hat,
> von Gleitkomma-Rechenwerk über TFT-Controller, USB, Ethernet,
> SDRAM-Anschluß, riesiger interner Flash, recht großer interner RAM und
> und und... Glaubst du, mit einem überhaupt erschwinglichen FPGA das
> alles nachbilden zu können?

Auch das ist billiger und nicht besser, 96 kbyte onboard SRAM sind 
heutzutage kein problem mehr für einen FPGA. Bspw. hat der XC6SLX25 
bereits 100 kbyte. Dazu 2 Hardware-Memorycontroller und genügend 
Logik-Resourcen für mehrere Displaycontroller oder 
Numerik-Coprozessoren. Nicht zu vergessen die 38 DSP-Blöcke, von denen 
jeder einzelner einen Hardware-Multiplizierer mitbringt. Soviel Flash 
hat ein FPGA zwar nicht, aber dafür ist dank der Gigabit-Tranceiver die 
es inzwischen auch in den preiswerternen FPGA's gibt auch eine 
SATA-Silicon Disc angeschlossen -> rasant schneller Flash zum Abwinken

> Also: einen richtigen µC per FPGA ersetzen zu wollen, ist Mumpitz, weil
> man nie und nimmer an das Preis/Leistungs-Verhältnis herankommt

wurde ja auch nicht behauptet

> und
> alerhöchstwahrscheinlich auch die auf dem Chip verbauten Cores nie und
> nimmer durch was Eigenes ersetzt kriegt.

Nö, stimmt für die kleinen Mikrocontroller nicht. Bspw. ist ein PCI-Core 
schon fast üblich für ein FPGA, das gibt es erst bei der Klasse der 
embedded Prozessoren. Komplett selber schreiben ist meist auch nicht 
nötig, schau mal auf http://opencores.org/projects was da so alles 
verschenkt wird. Nicht zu vergessen was für die Hauseigenen Softcores an 
Periepheriecontrollern samt SDK mitgeliefert wird.

Oder die Nachbauten an 16 bit computern die sich schon mit den ältlichen 
Spartan3 - FPGA realisieren lassen, inklusive der CPU. Das hab ich noch 
auf keinem mikrocontroller gesehen.

Es gibt kaum Anwendungen die ein uC wirklich "besser" kann als ein FPGA. 
Ein uC ist ein billige Generealist, ein FPGA ein Spezialist der seinen 
Preis hat, dafür aber den 0815 Kram eines Generalisten nebenher 
mitmacht.
Deshalb integrieren immer mehr FPGA-Anwendungn den IO-uC im FPGA, 
anstatt einen externen uC dazuzupacken (Microblaze, NIOS).

MfG

: Bearbeitet durch User
Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ingenieur offline schrieb:
> Eine Idee zum Thema: Wie wäre es mit einem Konfigurationstool für FPGAs?
> Wir haben nach wie vor keine sinnvolle FPGA-spezifische
> Versionsverwaltung, Entityverwaltung und Packageverwaltung.

Da hast du ein wunden Punkt aufgedeckt.
Ich hatte immer mal ein Auge auf ein Tool.
http://sourceforge.net/projects/kactus2/

Habe es aber gerade aus dem Auge verloren, wie weit die Entwickler sind.
Wenn jemand weiterführende Info hat, auch an mich.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Fpga Kuechle (fpgakuechle) Benutzerseite

>Nö, I2c, SPI, Timer und die übliche uC-Aufgaben kann jeder FPGA in
>(fast) beliebiger Anzahl und mit (fast) beliebigen Parametern). 4 UARTS,
>2x I"C Slave, 1I2C Master und 3x McBSP parallel kein Problem für einen
>FPGA.

Reichlich Verschwendung für ein FPGA ;-)


>> a) ein simpler 4 Bit Controller, der im Audioverstärker die
>> Kanalumschaltung, die Lautstärke und die IR-Bedienung erledigt und nur
>> ein paar Pfennige (oder Yen) gekostet hat

>Das ist billiger, nicht besser.

Muss man WIRKLICH auif so ein billiges Beispiel anspringen?

>> b) eine 300 MHz Mips im DVDplayer (ESS-Chips), mit SDRAM, Farbgrafik,
>> chipinternem 64 Bit Signalprozessor, 208er Gehäuse was noch für
>> zweilagige LP taugt - und für den Preis eines FPGAs von einer Größe, wo
>> sowas hineinpassen würde, könnte man 3 komplette Player kaufen.

>das ist keine 8/16bit mikrocontroler-Anwendung

>Auch das ist billiger und nicht besser, 96 kbyte onboard SRAM sind
>heutzutage kein problem mehr für einen FPGA. Bspw. hat der XC6SLX25
>bereits 100 kbyte. Dazu 2 Hardware-Memorycontroller und genügend
>Logik-Resourcen für mehrere Displaycontroller oder
>Numerik-Coprozessoren. Nicht zu vergessen die 38 DSP-Blöcke, von denen
>jeder einzelner einen Hardware-Multiplizierer mitbringt. Soviel Flash
>hat ein FPGA zwar nicht, aber dafür ist dank der Gigabit-Tranceiver die
>es inzwischen auch in den preiswerternen FPGA's gibt auch eine
>SATA-Silicon Disc angeschlossen -> rasant schneller Flash zum Abwinken

Alles schön und gut und heute erstaunlich billig, aber die 
Silikoneffizienz von FPGAs ist nun mal prinzipbedingt schelchter als die 
von ASICs.

>Oder die Nachbauten an 16 bit computern die sich schon mit den ältlichen
>Spartan3 - FPGA realisieren lassen, inklusive der CPU. Das hab ich noch
>auf keinem mikrocontroller gesehen.

Klar, gab es auch schon, ARM-Emulator auf dem AVR ;-)
Schöne Speilerei, sicherlich auch ein gutes Lernobjekt, aber keine 
Praxisanwending.

>Es gibt kaum Anwendungen die ein uC wirklich "besser" kann als ein FPGA.

Ach komm schon, hast du wirklich sooo einen FPGA-Tunnelblick?

>Ein uC ist ein billige Generealist, ein FPGA ein Spezialist der seinen
>Preis hat, dafür aber den 0815 Kram eines Generalisten nebenher
>mitmacht.

Mit goldenen Bits ;-)

>Deshalb integrieren immer mehr FPGA-Anwendungn den IO-uC im FPGA,
>anstatt einen externen uC dazuzupacken (Microblaze, NIOS).

Alles hat seinen Platz, aber billiger ist es nicht immer.

Autor: Christoph Z. (christophz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hardwarespezi schrieb:
> Christoph Z. schrieb:
>> versucht gerade auf einem 1 GHz ARM ohne OS, ohne Scheduler, ohne C++,
>> ohne Trace Debugger etc. einen additiven Synthesizer mit 80 kHz update
>> Rate, ein TCP/IP Interface
>
> nun, die ersten Musiksynthesizer hatten auch kein OS und liefen
> prächtig. Ok, sie hatten kein TCP/IP Interface aber wer braucht das?
>
> Da hat sich Dein Chef in jedem Fall was Ordentliches vorgenommen. Wenn
> er es hier liest, sei ihm mein Respekt ausgesprochen. Allerdings würde
> ich ihn fragen, wozu er ausgerechnet 80kHz Rate braucht. Müssten das
> nicht 48 oder 96 sein?

Er hat sich das nicht "vorgenommen" das ist sein aktueller Job, mir wäre 
es völlig egal, wenn er so in seiner Freizeit programmiert.
TCP/IP steht im Pflichtenheft, 80 kHz weil die Leistungselektronik so 
schnell taktet (Keine Musik sondern Leistungselektronik für Prüflabore).

Das Problem ist nicht, das es nicht geht. Sondern das mit dem gewählten 
Ansatz es so gut wie unmöglich ist, dass mehr als ein Entwickler daran 
arbeitet, dass die Fehlersuche und das einhalten der Harten-Echtzeit mit 
der Länge des Codes immer schwieriger wird (Weil keine Partitionierung 
und zu wenig Kontrolle der Prioritäten).

Autor: Alexander F. (alexf91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Josef G. schrieb:
> Hanno schrieb:
>> FPGA-Projektor schrieb im Beitrag #3575946:
>>> Naja, gleich nen ganzen Rechner? Es gibt ja schon Projekte dieser
>>> Art in
>>> Massen unter anderem auch das 8Bit Projekt von Josef hier im Forum.
>>
>> Was aber eher zu den abschreckenden Beispielen gehört...
>
> Begründung?

Hunderte Signale, die in ca. 50 Prozessen miteinander in Verbindung 
stehen, dazu 2 Takte, vermutlich haufenweise Latches.
Das sollte Begründung genug sein, ansonsten gibt es ja noch unzählige 
andere Threads, wo dein Projekt kritisiert wird.
Respekt, dass du es durchgezogen hast, aber es ist wirklich ein 
abschreckendes Beispiel.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Alexander F. schrieb:
> vermutlich haufenweise Latches.
Vielleicht eine handvoll, und die sind bewusst eingebaut.
> noch unzählige andere Threads,
Ich kenne nur zwei. Siehe meine Benutzerseite.

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander F. schrieb:
> Josef G. schrieb:
>> Hanno schrieb:
>>> FPGA-Projektor schrieb im Beitrag #3575946:
>>> Was aber eher zu den abschreckenden Beispielen gehört...
>>
>> Begründung?
>
> Hunderte Signale, die in ca. 50 Prozessen miteinander in Verbindung
> stehen, dazu 2 Takte, vermutlich haufenweise Latches.
> Das sollte Begründung genug sein, ansonsten gibt es ja noch unzählige


Also mich schreckt eher ein Design ab, in dem es nur einen einzigen 
Prozess gibt. FF nach Funktionsgruppen in dedizierte Prozesse zu packen 
ist Kernelement eines strukturierten designs - "Divide et impera".

Und eine CPU braucht eben mehr interne Steuersignale als ein simpler 
counter. Sind halt Tausende Gatter die verschaltet werden wollen.

Mehr als einen Takt ist heutzutage auch Stand der Technik: Core Takt umd 
Mem-IO Takt.

MfG,

Autor: Paul B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> vermutlich haufenweise Latches
Vermutungen sind an der Stelle schlecht. Besser wäre es, sie zu 
lokalisieren und dem Erzeuger einen Tipp zu geben, dort nachzubessern - 
so es welche gibt und diese stören.

> Mehr als einen Takt ist heutzutage auch Stand der Technik:
> Core Takt umd Mem-IO Takt.
Gehört der Speichertakt zur CPU?
wie löst man das am Saubersten?

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marius S. schrieb:
> ich suche jetzt nach einer Idee, was man noch so mit VHDL/FPGAs anstellen
> kann.

Ich find die Seite hier recht schick:

http://www.fpga4fun.com/

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Petelka schrieb:

>> Mehr als einen Takt ist heutzutage auch Stand der Technik:
>> Core Takt umd Mem-IO Takt.
> Gehört der Speichertakt zur CPU?
> wie löst man das am Saubersten?

Core Takt umd Mem-IO Takt ist hier ein von mir gewähltes beispiel das so 
nix mit dem 8Bit Projekt von Josef zu tun haben muß.

Ich denk da an PC-CPU#s mit Core Takt im GHz-Bereich und DDR-RAM takt 
deutlich drunter. Dazwischen ist der cache. Der memory takt kann vom 
CPU-Takt abgeleitet sein oder auch nicht. Dann nimmt man hald 
DualPortSpeicher oder FiFO's mit seperaten Takt für Speicher und 
CPU-Seite. So was hat heute ein FPGA schon "an Bord" siehe BlockRAM.

MfG,

Autor: FPGA-Progger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
René D. schrieb:
> Ingenieur offline schrieb:
>> Eine Idee zum Thema: Wie wäre es mit einem Konfigurationstool für FPGAs?
>> Wir haben nach wie vor keine sinnvolle FPGA-spezifische
>> Versionsverwaltung, Entityverwaltung und Packageverwaltung.
>
> Da hast du ein wunden Punkt aufgedeckt.
> Ich hatte immer mal ein Auge auf ein Tool.
> http://sourceforge.net/projects/kactus2/
>
> Habe es aber gerade aus dem Auge verloren, wie weit die Entwickler sind.
> Wenn jemand weiterführende Info hat, auch an mich.
Es dröppelt vor sich hin, wie so viele sourceforge Projekte. Wenn es 
keinen Projektleiter gibt, gibt es keine Ergebnisse. Ob VHDL oder 
Software ist egal. Und daran kranken die Projekte. Allesamt.

Und es fehlt an der -kritikfähigkeit, wenn unsereins denen was schreibt 
und sie beraten will ...

Autor: Elektrotechniker im Urlaub (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit einem FPGA lassen sich Daten in Echtzeit beobachten, damit eignen 
sie sich meines Dafürhaltens für die Datenanalyse. Könnte man mit einem 
FPGA eine Echtzeitbeobachtung für Ethernet und andere Protokolle bauen?

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar, wieso auch nicht? Ist vermutlich nicht so ganz einfach weil du 
dann irgendwie die Packete zerlegen wollen wirst. Ich würde dafür 
Wireshark nehmen, das kann das auch und viele Switches können Ports 
spiegeln.

Autor: Elektrotechniker im Urlaub (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, aber das Problem ist, das WS nur gültige Pakete empfangen kann und 
man nicht weiss, was los ist, wenn es NICHT geht.

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so, ja stimmt. Klar das wäre ein Projekt, aber eher ein 
arbeitsintensives. Ich habe von Netzwerken kaum Ahnung, aber ich würde 
die Auswertung nicht in VHDL machen, dafür würde ich eine CPU nehmen. 
Netzwerkkarten gibt es auch schon fertig und echt günstig. Also dafür 
würde ein normaler PC reichen, das im FPGA zu machen ist zwar vermutlich 
sehr lehrreich, aber extremst komplex.

Wober ... es kann natürlich sein, dass die ganzen ferigen Netzwerkkarten 
nur Packete mit richtiger Checksumme akzeptieren. Wenn du also alles 
empfangen willst kannst du mit einem FPGA dieses Teilstück bauen, also 
das Teil das einfach alles was über die Netzwerkbuchse reinkommt an 
Software weiterreicht und eben nicht vorher prüft.
Man könnte das auch dahin erweitern, dass man in der Software dann 
Filter einstellen kann also für Packettypen - und das dann im FPGA 
gemacht wird.

Autor: Moby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon reichlich mühsam die Suche nach sinnvollen Anwendungen, was? Aber 
hier steht wohl eher der Spaß an komplizierter Technik im Vordergrund ;)
Nehmt im konkreten Projekt aber dann nen simplen AVR/PIC und gut ist...

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also das kommt sehr auf die Datenrate an. Also komplettes Gigabit macht 
so ein AVR nicht mit. Aber FPGA und AVR geht vermutlich. Der AVR stellt 
im FPGA den Filter ein welche (wenigen) Packete der durchlassen soll, 
und diese kann der AVR dann auswerten. Aber auch sonst wäre es 
eigentlich hybsch mal mit FPGA Netzwerk zu machen und das dann über PCIe 
an den Computer zu übergeben. Da lernt man bestimmt einiges.

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Elektrotechniker im Urlaub schrieb:
> Mit einem FPGA lassen sich Daten in Echtzeit beobachten, damit eignen
> sie sich meines Dafürhaltens für die Datenanalyse. Könnte man mit einem
> FPGA eine Echtzeitbeobachtung für Ethernet und andere Protokolle bauen?

paket parsing 400 Gbit/s mit Virtex-7:
http://www.xilinx.com/innovation/research-labs/con...

Bloom filter:
http://test.algo-logic.com/~jwlockwd/publications/...

Deep Paket Inspection with Hardware support:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EE...

MfG,

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Elektrotechniker im Urlaub schrieb:
> Ja, aber das Problem ist, das WS nur gültige Pakete empfangen kann und
> man nicht weiss, was los ist, wenn es NICHT geht.

Das ist nicht das Problem von Wireshark.

Das hängt von der darunterliegenden lib und der verwendeten 
Netzwerkkarte ob alle Pakete durchgeleitet werden. Es gibt verschieden 
Stellen wo Pakete ausgefilter werden.

Es gibt da so eine Möglichkeit. Ich hatte es mal versucht, aber alle bei 
mit verbauten Netzwerkkarten konnten da nicht. Man sieht aber bei ei er 
Punkt zu Punkt Verbindung ohne Last an der LED ob sinnlose Paket auf den 
Ether sind.

Autor: Martin K. (mkmannheim) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tippgeber schrieb:
> Und dann gibt es
> ja die Synthesizer selber, die seit Neuestem in FPGAs gepresst werden,

das habe ich auch verfolgt ja. Für mich wären solche Projekte sehr 
interessant, weil ich auch Musik mache und mit einer Band auch Geld 
damit verdiene. Ich habe auch schon öfters überlegt und Ideen gehabt, 
was man so bauen könnte, aber:

Ich bin nicht so sicher, ob es wirtschaftlich ist, einen Audioprozessor 
oder einen Synthesizer komplett in VHDL zu bauen. Ok, es gibt da einige, 
die das gemacht haben - die bekanntesten sind sicher der FPGA-Synth von 
Chris Stellis oder die Schaltungen von Theo van Elst. Die sind aber alle 
irgendwo stecken geblieben und es gibt keine wirklichen Anwendungen 
davon, was wohl daran liegt, dass die Meisten, die so etwas bauen, keine 
richtigen Musiker sind und die Kiste dann nicht wirklich verwenden.

Andere wiederum, die es verwenden könnten, sind aber nicht dazu in der 
Lage, das weiter zu bauen, weil sie keine FPGA-Entwickler sind.

Von daher sind die FPGAs für Musikproduktion technisch vielleicht ganz 
interessant, weil sie eine gigantische Klangqualität und Stimmvielfalt 
ermöglichen und man sogar eigene Geräte bauen könnte, aber das, was es 
bisher gibt, ist musikalisch nicht unbedingt nützlich oder nicht 
praktikabel. Es gibt nur wenige Musiker, die wirklich programmieren und 
die nehmen sich dann lieber eine fertige DSP-Plattform wie den Nord 
Lead. Da kann man virtuell am Bildschirm verkabeln. Das kapieren die 
Meisten noch, wobei ich sagen muss, dass unser Keyboarder da auch nicht 
mehr viel macht: Einmal ein Setup eingestellt, wird es verwendet. 
Rumgespielt wird nur bei der Suche nach neuen Klängen.

Der einzige FPGA-Synthesizer, der wohl auch in Musikproduktionen 
eingesetzt zu werden scheint, ist der Pyratone von Jürgen Schuhmacher 
(user engineer), aber den wird man nicht so einfach nachbauen oder 
umbauen können, zumal der Code nicht offen ist. Blieben noch die open 
projects, wie man sie auf Github und open cores findet, aber da ist die 
community klein. Oft werden sie entwickelt und mit großem Enthusiasmus 
als open source angekündigt, dann aber geht es nicht mehr voran. Bei dem 
vor einem Jahr angekündigten Cylone-IV-Synth von Rolf Sassinger , siehe 
oben, hat sich nicht mehr viel getan.

Noch ärmer sieht es bei den vielen Abschlussarbeiten aus: Bald jede 
Hochschule hat jährlich irgendein Projekt mit einem 
FPGA-MIDI-Synthesizer, aber die Produzieren nichts, was es nicht schon 
in den 70ern besser gab und heraus kommen nur ein paar Dudeltöne. Das 
ist überhaupt nicht zu gebrauchen und hat auch mit Musik nichts zu tun.

Für einen richtigen FPGA-Synthesizer-Prozessor bräuchte es nach meiner 
Meinung dann auch irgendeine Art von Baukasten, mit dem der Nutzer auch 
klarkommt. Auf VHDL als Musikprogrammiersprache zu setzen, halte ich für 
eine Sackgasse. Ich möchte nicht in Bergen von Code suchen, wo ich 
Schnittstellen finden kann, um etwas eigenes einzufügen und mich 
umständlich in Spezialarchitekturen hineindenken. Genau genommen, will 
ich das nicht mal für C-Software tun.

Allenfalls das Projekt von Rene Böllhof (user theMason) ist frei 
verfügbar und wäre in Software zu programmieren. Da ginge was, denke 
ich, weil man in C oder ASM nun mal leichter denken kann und nicht 
gezwungen ist, die Hardware zu ändern, wenn man nicht will. Es käme aber 
darauf an, eine Hardware zu haben, die Musikschnittstellen hat, die man 
kaufen und direkt einsetzen kann. Daran scheitert es ja meistens. Und 
dann braucht es eine gute Doku und ein modulares Design, das auf den 
ersten Blick verständlich ist.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich richtig informiert bin, dann ist in "neuem" KURZWEIL Forte ein 
FPGA untergebracht. Mich juckt es in den Fingern das Teil zu kaufen und 
auseinander zuschrauben... :-)

Du hast aber Recht, dass kein Musiker in VHDL was machen möchte. Das 
komplette System muss Open Source sein. Dazu muss das FPGA Design 
ausgegorren sein UND die Software drumherum dazu (GUI um zu 
experementieren). Kein Debugger oder JTAG USB Blaster, sondern einfach 
schön mit einer APP oder über USB. Dazu muss es viele (Sound)Beispiele 
geben.

Um das alles zu bewerkstelligen braucht man Leute, viele Leute. Und das 
ist genau das Problem. Damit jeder so eine Entwicklungsplattform hat, 
muss es irgendwas Arduino-/RPi mäßiges geben, mit Audioschnittstellen 
und dann auch noch preiswert. Wieviele sind bereit dafür Geld 
auszugeben? Mit 50 Euro ist man vielleicht gerade so beim 
Selbskostenpreis, wenn man Glück hat. Um auf diesen Preis zu kommen 
müsste man vielleicht 500-1000 Stück verkaufen. Es werden sich aber 
maximal 10-20 finden, und diese Leute werden auch noch unterschiedliche 
Wünsche haben: "ich möchte bessere DACs", "ich brauche Xilinx", "ich 
brauche zwei Stereo-Eingänge, statt einen"...

Tja, es ist nicht einfach...

Grüße
Kest

Autor: musicker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Roland hat hat glaube Ich auch einen Synthy im portefolio. Scheint eine 
Art von Tb303 clone zu sein.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
musicker schrieb:
> Roland hat hat glaube Ich auch einen Synthy im portefolio. Scheint eine
> Art von Tb303 clone zu sein.

Roland hat generell viele Synthesizer im Portfolio. Hat einer davon 
speziell etwas mit diesem Thread zu tun?

Autor: musicker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja. war es. Der AIRA hat wohl einen solchen Fpga drin.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
musicker schrieb:
> Der AIRA hat wohl einen solchen Fpga drin.

Ja, es gibt einige, die FPGAs drin haben und dies zu unterschiedlichen 
Zwecken. Nicht alle machen damit ausschließlich oder überhaupt 
Klangsynthese und die, welche es tun, z.T. auch aus Gründen der 
langfristigen Kosteneinsparung, in dem sie bestimmte Funktionen später 
in einen digitalen ASIC packen. So macher FPGA-Synth der momentan 
rumlungert, dürfte eine Art Prototyp sein.

Musik mit FPGAs ist ziemlicher Luxus und nur gerechtfertigt, wenn hinten 
auch eine angemessene Qualität rauskommt, was ich bei keinem der mir 
bekannten derzeitigen Produkte beobachte. Die sind - auch wegen der 
Schnittstellen MIDI rein und Audio raus, immer noch limitiert. Selbst, 
wenn 192kHz rauskommen sollen und USB-MIDI verarbeitet wird, was schon 
das höchste der Gefühle ist, kann man auch auf Prozessoren setzen. Mit 
einer Handvoll DSPs lässt sich das alles viel billiger bauen, 
stromsparender betreiben und vor allem leichter pflegen und ich stimme 
zu, dass bei einem Selbstbausystem die Pflege, Modularität etc das 
Entscheidende ist.

Als ich vor über 10 Jahren begann, FPGAs herzunehmen, waren die 
Prozessoren und Interfaces einfach noch nicht so weit und auch die 
Qualität der VA-Synths nicht wirklich virtuell analog. Das hat sich ja 
nun schon geändert. Von dem her ist es umso interessanter, dass nun 
einige Hersteller damit anfangen. Einige rühmen sich sogar, die jeweils 
ersten gewesen zu sein, die FPGAs eingesetzt haben wollen, aber bei 
genauerer Betrachtung sind das genau die, die es in den letzten 10 
Jahren verpennt haben, Innovationen an den Start zu bringen und nun 
probieren, ihre alten Analogkisten neu zu vermarkten, indem sie sie in 
Hardware gießen :-)

Nun gut, schauen wir, wie groß der Markt dafür ist. In Zeiten, in denen 
man für kleines Geld einen Blofeld kaufen kann, sehe ich keine große 
Chance für FPGA-Synthesizer, jedenfalls nicht, für hochkarätige. Der 
Bedarf an hoher Klangqualität ist einfach nicht da.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Martin K. schrieb:
> Für einen richtigen FPGA-Synthesizer-Prozessor bräuchte es nach meiner
> Meinung dann auch irgendeine Art von Baukasten, mit dem der Nutzer auch
> klarkommt.

Deine und Kests Forderung kann ich nachvollziehen, aber sie widerspricht 
ja gerade der flexiblen und auch effektiven Nutzung von FPGA-Hardware. 
Alles, was es in einem Baukasten gibt, müsste definiert und 
vorgearbeitet werden und es müsste standardisierte Schnittstellen 
zwischen den Modulen geben.  Welche Module und Strukturen soll man 
anbieten? Nur eine flexible, selber definierte, also offene Struktur, 
schafft Raum. Dass da nicht alles mit allem zu verheiraten ist, liegt in 
der Natur des Sache.

All das reduziert auch die Möglichkeiten, in einem FPGA wirklich etwas 
SCHNELL zu machen - vor allem eine pipeline lässt sich damit nur 
statisch aufziehen und nicht dynamisch, wie ich es mache. Damit werden 
die FPGAs langsam und unwirtschaftlich.

Aus meiner Sicht ist das nicht nötig, weil "analog" dazu betrachtet, 
auch bei den klassischen Synthesizern immer Kabel gezogen werden. In 
meinem Fall werden sie eben virtuell gezogen. Damit muss man sich 
auseinandersetzen.

Zudem gibt es ja mit Simulink und anderen Tools schon Optionen, Cores 
zusammenzuklicken. Aber das, was damit geht, gibt es in Synthesizern 
schon.

Interessant ist ja eben das, was es in anderen Geräten NICHT gibt.

Alles weitere dazu in diesem thread:
Beitrag "Suche Mitwirkende für Universal-FPGA board"

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander F. schrieb:
> ansonsten gibt es ja noch unzählige
> andere Threads, wo dein Projekt kritisiert wird.

Es wird kritisiert, aber fast immer unsachlich und ohne Begründung.
Oder kannst du mal eine stichhaltige Begründung zitieren?

Beitrag "8bit-Computing mit FPGA"

Autor: FPGA-Projektor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> sehe ich keine große
> Chance für FPGA-Synthesizer, jedenfalls nicht, für hochkarätige.

Nun, die Firma Roland scheint ja wohl Bedarf für FPGA-Synthesizer zu 
sehen und die sind ja offenbar "hochkarätig" :-)

Josef G. schrieb:
> kannst du mal eine stichhaltige Begründung zitieren?

Meine Begründung wäre, dass die Zeit für 8bit-Computer vorbei ist. Das 
ist Technologie aus den 80ern, die niemand mehr sinnvoll einsetzen kann. 
Im Übrigen gilt dies hier schon oben Gesagte:
Beitrag "Re: Ideen für FPGA-Projekte?"

Kest schrieb:
> Mit 50 Euro ist man vielleicht gerade so beim
> Selbskostenpreis, wenn man Glück hat. Um auf diesen Preis zu kommen
> müsste man vielleicht 500-1000 Stück verkaufen

Bei einer Platine mit einem leistungsfähigen FPGA kannst Du soviel 
verkaufen, wie Du willst und wirst niemals auf 50,- kommen. Da muss man 
anders rangehen:

1) Marktanalyse
2) Bedarfsanalyse
3) Kostenschätzung
4) Entwicklungsschätzung
5) time-to-market
6) Gewinn und Rendite
7) Entscheidung

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
FPGA-Projektor schrieb im Beitrag #4447628:
> Nun, die Firma Roland scheint ja wohl Bedarf für FPGA-Synthesizer zu
> sehen und die sind ja offenbar "hochkarätig" :-)

Ohne auf die Details der Roland-Architektur abzuheben, stelle ich doch 
mal in Frage, ob hier ein FPGA wirklich zur Klangsynthese nötig war und 
warum.

Generell:

Richtig ist, dass man mit FPGAs für eine dedizierte Grenzfrequenz eine 
genügende gute Granularität darzustellen in der Lage ist, um die 
"analogtypischen" Effekte, also die Einflüsse von Ungenauigkeiten, 
Nichtlinearitäten und Rauschen im Zeitbereich, also auf der Basis 
physikalischer Ereignisse in die Rechnung einfließen lassen zu können, 
ohne sie erst abstrakt-mathematisch durch Gleichungen abbilden zu 
müssen, wodurch man zu einem natürlichen Verlauf der 
Oszillatoramplituden und -phasen mit all den real entstehenden 
Oberwellen, Transienten und Offsets etc gelangt. Dies gelingt bei einem 
typischen Aufbau der zur Realisation der DGL 2.Ordnung nötigen Elemente 
samt Einflussoptionen im FPGA ohne Taktung oder Pipeline bis etwa 1/10 
der Abtastfrequenz, d.h. der so erzeugte selbstschwingende Generator 
kehrt nach minimal 10 Takten zu seinem Anfangswert zurück. Will man das 
jetzt analog genau, also auf praktisch rund 100dB genau machen, braucht 
es entweder eine sehr hohe Y-Auflösung, die dann im FPGA wieder einige 
FF-Takte zusätzlich nach sich zieht oder man akzeptiert eine geringe 
Grenzfrequenz - hat also sozusagen eine höhere Abtastfrequenz.  Will man 
zudem eine quasi Synchronität zwischen Einfluss und Wirkung, muss man 
wenigsten über 2 Loops hinweg denken. Realistisch sind da also 1/20/2 
etc = 1/40 der Frequenz. Das ist ein guter trade off zwischen Abtastung 
und Bedarf an Rechenelementen wegen der Genauigkeit.

Bei meinem ersten Versuch dieser Art hatte ich ein 10 MHz PLD zur 
Verfügung und gelangte folgerichtig zur "analogen" Rate von rund 500kHz. 
Diese ist schon absolut fein genug, um sie mit 44kHz, 48kHz oder was 
auch immer unsynchronisiert abtasten- und dennoch sauber abbilden zu 
können, wenn sie digital ausgegeben werden soll. Da damit aber nur 
Frequenzen bis maximal 20kHz Oberwelle produziert werden, waren die 
entsprechend hypergenau.

Aber:

Heute sind wir bei zwar bei der 4-fachen Abtastrate, haben aber effektiv 
20mal schnellere FPGAs. Die DSPs und Prozessoren sind auch erheblich 
schneller und vor allem genauer geworden.

Wozu man also 1. bei der heutigen Prozessortechnologie überhaupt- und 2. 
im konkreten Fall unbedingt FPGAs braucht, um (wörtlich der 
AIRA-Beschreibung entnommen) "4 fette Oszillatoren" zu erzeugen, ist mir 
nicht schlüssig.

Meine VAs sind vielleicht nicht so komplex wie die vom Grossen R, aber 
im pipeline-Betrieb generieren sie je nach Abtastrate / Taktfrequenz 
mehrere Tausend Stimmen gleichzeitig per Architekturelement.

Dazu folgende Betrachtung:

Die "Fettigkeit" von Oszillatoren äußert sich bei FPGAs ja "lediglich" 
in der Komplexität der Schaltung und damit der Länge der Rechenpipeline 
und selbst bei einem überfetten Oszillator mit 100 Parametern, 
Einflussgrössen, Rückkopplungen und Prozessschritten, liefe diese bei 
einem 200MHz-FPGA noch mit Faktor 2MHz im Loop. Das wären also 40 
virtuelle Oszillatoren in einer normalen 2D-pipeline mit 48kHz. Im 
aktuell kleinsten Artix bekommt man geschätzt 10-30 solcher 
Architekturen hinein. Macht bei mir an die 1000 virtuelle 
Monster-Oszillatoren auf der typischen Abtastrate von 48kHz, die in 
einem FPGA machbar sind. In einer 3D-pipeline liessen sich sie 100 
Latenzschritte noch verwerten und man landet schon bei einer Architektur 
bei wieder ff/fs = 200MHz/192kHz = 1000 Oszillatorkanälen.

Ich glaube eher, daß wir da Marketingaspekte als Ursache sehen müssen.

In Anlehnung dessen, was Du zu der "Technologie aus den 80ern" selbst 
schreibst, soll da wohl etwas aus Nostalgiegründen hochgehalten werden.

Vielleicht haben sie aber auch die gesamte Stromversorgung, samt 
schnuddeligem Netzteil, die interne Verkabelung mit EMI-Einfluss und die 
Potiunlinearitäten sowie die prellenden Schalter modelliert. Die waren 
ja durchaus klanggebend. :D

: Bearbeitet durch User
Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander F. schrieb:
> Josef G. schrieb:
>> Hanno schrieb:
>>> FPGA-Projektor schrieb im Beitrag #3575946:
>>>> ... unter anderem auch das 8Bit Projekt von Josef hier im Forum.
>>>
>>> Was aber eher zu den abschreckenden Beispielen gehört...
>>
>> Begründung?
>
> Hunderte Signale, die in ca. 50 Prozessen miteinander in Verbindung
> stehen, dazu 2 Takte,

Die Aussage "dazu 2 Takte" gilt nur noch eingeschränkt. Siehe meinen
Beitrag vom 24.02.2016 im Thread "8bit-Computing mit FPGA".

Link funktioniert möglicherweise nur für unangemeldete Benutzer
Beitrag "Re: 8bit-Computing mit FPGA"

Autor: Mar. Wa. (elektrowagi78) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine spontane Idee für ein FPGA-Progjekt kommt mir gerade in den Sinn, 
wo ich das so lese:

Wie wäre es mit einem Co-Prozessor-Core für komplexe Rechnungen, zum 
Lösen von Gleichungen, eine Art Gauß-Algorithmus oder 
Determinantenberechnungen?

Sowas kann man doch immer gebrauchen.

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Markus W. schrieb:

> Wie wäre es mit einem Co-Prozessor-Core für komplexe Rechnungen, zum
> Lösen von Gleichungen, eine Art Gauß-Algorithmus oder
> Determinantenberechnungen?

Macht man heute mit Grafikkarten für ein paar hundert Euro:
http://ta.twi.tudelft.nl/nw/users/mmbaumann/projec...
https://www.tu-ilmenau.de/fileadmin/media/simulati...

Man kann auch uC mit einem FPGA/CPLD beschleunigen Problem ist 
allerdings die Daten zwischen beiden auszutauschen. Sinn macht das erst 
wennprozessor und coprozessor auf den gleichen Speicher zugreifen was 
heutzutage auch nicht einfach ist.

füt einen Softcore wie den ublaze könnte man noch neben den FPU's 
weitere coprozessoren designen die werden aber wohl nur eine sehr 
speziellen Anwendungsbereich haben.

MfG,

Autor: Strubi (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Markus W. schrieb:
> Eine spontane Idee für ein FPGA-Progjekt kommt mir gerade in den
> Sinn,
> wo ich das so lese:
>
> Wie wäre es mit einem Co-Prozessor-Core für komplexe Rechnungen, zum
> Lösen von Gleichungen, eine Art Gauß-Algorithmus oder
> Determinantenberechnungen?
>
> Sowas kann man doch immer gebrauchen.

Moin,

gebrauchen, oh ja.
Das Problem, bzw. die meiste Arbeit macht schlussendlich die Toolchain.
Die Frage ist immer, machst Du es dediziert für genau ein 
Projekt/Aufgabe oder generisch, so dass es andere nutzen können. Dann 
ist der logische Schritt letzerer Aufgabe immer ein Prozessor, für den 
du entweder Microcode oder gar richtige Assemblermnemonics designst. Das 
wird dann meist so aufwendig, dass man es fürs Projekt eben doch meist 
hart codiert.
Da gibt es auch so einige Ansätze, wie HiCoVec, usw. - die sehen mir 
jedoch alle nicht sonderlich weiterverfolgt aus.

Mit den DSP-Toolboxen aus der Python-HDL-Welt lässt sich da allerdings 
einiges beschleunigen. Das geht dann meist auch in die Richtung der 
nvidia-Recheneinheiten. Für skalare Zerlegung habe ich mal eine Engine 
gebastelt, mit der z.B. DCT geht (JPEG-Encoder). Mit der Host-CPU (auf 
dem FPGA) lädt man VLIW-Microcode in das kurze (16 Befehle) 
Programm-Memory der jeweiligen Unit. Das ist aber für den Anwender u.U. 
kryptisch, dass sich nicht mal ein externer Assembler rechnet. Wer 
vielleicht den Blackfin kennt: Dessen Parallelprogrammierung haben trotz 
toll lesbarem Assembler nicht sonderlich viele Nutzer ausgelotet. 
Schlussendlich läufts fast immer auf eine Library hinaus, die der 
Anwender aus seinem Programm aufruft.
Das grösste Problem schlussendlich stellt sich jedoch oft an einer ganz 
anderen Stelle, bei der die DSP-Konzepte so richig knifflig werden:
- Wie kommen die Daten rein?
- Müssen sie ev. umsortiert werden und wie?
- Wie integriert man den Beschleuniger effektiv in seinen bestehenden 
SoC?

Zu letzerem gibt's einige nette Tricks mit Opcode-Windows um bestehende 
Befehlssätze aufzubohren, aber das geht mit uBlaze und Konsorten 
natürlich nicht.

Vermutlich wird der Trend immer mehr in Richtung HLS gehen (ob mit C 
oder Python sei dahingestellt) und das super-versatile Tool ein 
In-House-Tool bleiben oder wie manche 8-Bit-CPU-Spielereien unter 
erheblichen Akzeptanzschwierigkeiten leiden.

Gruss,

- Strubi

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Das Problem mit den HighLevelSynthesis-Ansätzen ist, dass FPGA doch sehr 
viel low Level Beschreibung benötigt, was die Beschreibungsebenen weit 
auseinander zieht und verkompliziert. Je mehr Tools dann im Spiel sind, 
desto schneller geht die Kompatibilität flöten. Nimm mal einen 
HL-Codegenerator wie MATLAB und ein SOPC-System vom Hersteller und 
bringe dann noch einen externen Simulator sowie Synthesizer ins Spiel. 
Irgendwo knackt es immer.

Autor: Martin K. (mkmannheim) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmals zu dem Thema SoftCores:

Wie weit sind denn auf dem FPGA-Sektor eigentlich die Compiler? Kann man 
davon ausgehen, ähnliche Qualität und Komfort zu bekommen, wie auf den 
Controller-Plattformen? Oder wird die Software extern für einen 
Controller gemacht und verfiziert und dann nur draufgesteckt? Ist so ein 
virtueller AVR in einem FPGA voll kompatibel? Ich denke von den intern 
verbauten ARMs kann man das erwarten nehme ich an(?)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Martin K. schrieb:
> von den intern verbauten ARMs kann man das erwarten nehme ich an(?)
Der Prozessorkern selbst natürlich schon. Der Trick ist immmer die 
Peripherie und die EA. Und da ist ein ARM von ST mit dem anderen von NXP 
auch nicht "kompatibel"...

Autor: Strubi (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Moin,

>
> Wie weit sind denn auf dem FPGA-Sektor eigentlich die Compiler? Kann man
> davon ausgehen, ähnliche Qualität und Komfort zu bekommen, wie auf den
> Controller-Plattformen? Oder wird die Software extern für einen
> Controller gemacht und verfiziert und dann nur draufgesteckt?

Das hängt halt wieder etwas von der Architektur ab und wie entsprechend 
das Zusammenspiel verifiziert wurde. Im Schnitt ist es recht gut. Kann 
nur zu folgenden was sagen:

- Microblaze: Gut getestet, breiter Support für OS, dasselbe gilt 
offenar auch für NIOSII, da schenkt sich nix.
- MIPS32/16: Sehr robust (modulo Core-Eigenheiten), da Architektur gut 
etabliert
- Lattice mico32: Ist etwas her, ansich eine schöne (mips-alike) 
Architektur, aber das Ding flog in die Ecke, u.a. wegen einigen Bugs im 
GCC, die eine saubere Portierung verhinderten.
- ZPU: Ziemlich robust für einen freien Core, gut verifizierbar, 
allerdings kein Support in GCC 4.x (nur alte 3er Toolchain)

Wie die Board-Supply-Packages (für die jeweiligen HW-Varianten mit 
unterschiedlicher Peripherie) dann jeweils ausschauen, ist eine andere 
Geschichte, da macht man meist viel selber.

Wo es bei den meisten Cores hapert, sind die Debugging-Features, das 
bewegt sich bei den meisten - wenn überhaupt - auf OpenOCD-Schema: 
Manchmal stabil, manchmal nicht. Aber dazu kann man einen anderen Thread 
aufmachen :-)

Im Prinzip - wenn man sich den Aufriss mit der Testbench gibt - sind 
manche Softcores sogar deutlich fehlerfreier und beweisbarer als z.B. 
ein ARM7 und der eigentliche Clue ist: Als User kannst du die Fehler 
selber finden. Bei einem harten-Core dauert es Monate, bis die 
Hersteller überhaupt mal einen Bug zugeben :-)

Grüsse,

- Strubi

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Strubi,

möchtest Du nicht mal eine deiner MIPS Versionen mit
Debugger Support veröffentlichen?

Viele Grüße,
Michael

Autor: Kameramann (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Sowas wäre mal ein nettes Projekt: Ein fetter Core mit einem fixen und 
gut ausgebauten Debug-Port mit kompletter Tool Chain, an der sich 
mehrere Leutchen beteiligen.

Autor: Strubi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Michael schrieb:
> Hallo Strubi,
>
> möchtest Du nicht mal eine deiner MIPS Versionen mit
> Debugger Support veröffentlichen?
>
> Viele Grüße,
> Michael

Hi Michael,

ich bin vom MIPS etwas weggekommen, da er nicht auf die kleinen 
Plattformen (wie MachXO2) passt, ausserdem ist das Ding zu komplex 
geworden, um es für eine Community a la OpenSource zu supporten.
Aber ich überlege noch, mein SoC-Environment mit der Zealot (OpenSource) 
bzw. ZPUng (meine beschleunigte Variante) teilweise offenzulegen. Im 
Prinzip liegt die Debugger-Anbindung schon eine Weile offen in div. git 
repos rum. So ein paar Infos gibts auf http://tech.section5.ch/news/, 
gab auch mal hier nen Thread "Neue CPU Aspekte" o.ä. Nur habe ich bzgl. 
OpenSource und HDL nicht grade die besten Erfahrungen gemacht.

Kameramann schrieb:
> Sowas wäre mal ein nettes Projekt: Ein fetter Core mit einem fixen und
> gut ausgebauten Debug-Port mit kompletter Tool Chain, an der sich
> mehrere Leutchen beteiligen.

Gibt's doch alles (OrSoC, Leon, usw.).
Nur an der minimaleren Ecke sieht's halt mau aus. D.h. 'fett' sollte es 
gerade eben nicht, aber trotzdem 32 bit, GCC und JTAG-Debugger und 
DSP-Extensions. Das schafft die ZPU-Architektur mit Bravour und hat 
dabei den kompaktesten Code für einen 32-Bitter.

Grüsse,

- Strubi

Autor: Mar. Wa. (elektrowagi78) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fpga K. schrieb:
> Macht man heute mit Grafikkarten für ein paar hundert Euro:
Dies erfordert einen PC, ich meinte eher sowas wie einen VHDL Core zum 
reinwerfen in bestehende FPGA-Designs.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade jetzt wurde der Thread interessant.

Das Debuggen ist ein heißer Punkt.
Ich habe bei mir den GDB als Software Stub laufen und der Debugger ist 
als Software in der CPU.
Als Breakpoint wird ein Opcode hinterlegt, der ein Interrupt wirft.

Autor: Mar. Wa. (elektrowagi78) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin auch für das Thema Debugging offen! Definitv!

Autor: Mar. Wa. (elektrowagi78) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das Thema nun unerwartet eingeschlafen?

Autor: Martin K. (mkmannheim) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schaut wohl so aus, ja. Ich war auch eine Weile nicht aktiv. Für mich 
wäre das interessant gewesen, wenn es mit FPGAs ein einfacher Weise 
gelänge, Funktionen zu realisieren, die mit DSPs zu langsam sind.

Autor: abc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
System Generator for DSP.
Oder etwas von Altera oder Labview.

Autor: Kamil Rezer (kamil_rezer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich über die Vorteile von FPGAs wie Parallelisierung nachdenke, 
stelle ich mir Multisensorsysteme/Arrays vor. Ich halte einige 
Anwendungen für möglich, die z.B. Arrays aus Hall-Sensoren zum 
Visualisieren von statischen und beweglichen Magnetfeldern einsetzen. 
Zudem ist es sicherlich interessant und nützlich Ultraschalsensor-Arrays 
zu bauen, die z.B. ein "2D/3D-Abtasten" von der Umgebung für 
Sehbehinderte erleichten würden. Oder, wenn man halt Spass haben will, 
könnte man über Bau eines grobkörnigen 3D-Scanners mit Photodioden-Array 
und kodiereten Beleuchtungsfeld nachdenken.

Autor: Martin K. (mkmannheim) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abc schrieb:
> System Generator for DSP.
> Oder etwas von Altera oder Labview.

Das hört sich aber nicht mehr so einfach an. Soweit mir bekannt, will 
MATHWORKS auch Geld für seine Produkte. Labview ist schon mal nicht 
umsonst und ein Entwickler in unserer Firma hat mir davon abgeraten, 
damit FPGAs zu machen.

Bei mir wäre es auch in erster Linie Video.

Autor: abc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin K. schrieb:
> abc schrieb:
>> System Generator for DSP.
>> Oder etwas von Altera oder Labview.
>
> Das hört sich aber nicht mehr so einfach an. Soweit mir bekannt, will
> MATHWORKS auch Geld für seine Produkte. Labview ist schon mal nicht
> umsonst und ein Entwickler in unserer Firma hat mir davon abgeraten,
> damit FPGAs zu machen.
>
> Bei mir wäre es auch in erster Linie Video.

Gab es nicht schon Bild-Filter, als das Teil noch "System Generator" 
hieß?

Es hängt eben davon ab, mit wieviel Kenntnissen und Fähigkeiten welche 
Funktionsumfänge realisiert werden sollen. Im Detail hängt es auch von 
den Performanz-Anforderungen ab.

Mit dem Systemgenerator habe ich bereits Softwaretechniker größere 
Systeme samt FFTs für den FPGA erstellen lassen. Die Erfahrung war 
positiv. Mit Labview habe ich so etwas noch nicht gemacht.

Speziell für Video gibt es auch noch weitere, kleinere Firmen, die 
graphisch gestützte Tools (ggf auch mit Möglichkeit zur Eingabe von 
Scripten) für die Bild/Videoverarbeitung anbieten. Das Design wird dann 
auf den FPGA oder DSP synthetisiert.

Natürlich kosten die Tools etwas. Dafür kommt man mit weniger Expertise 
im Haus schneller zu brauchbaren Ergebnissen. Es hängt eben davon ab, 
was man hat und was man möchte. Ggf. besteht die Möglichkeit, die Tools 
zu testen. Ebenso kann man sich in den Videos/Tutorials einen Eindruck 
verschaffen.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FFTs und Ähnliche Sachen, sind auch nicht so das Problem, weil die ja 
als Core existieren. Der System Generator schaltet die letztlich auch 
nur als Grafik zusammen. Entscheidender ist der Aufbau der image pipe an 
sich, vor allem Funktion und Umsetzung und deren Parallelisierung nimmt 
einem ja niemand ab.

Kamil R. schrieb:
> Ich halte einige Anwendungen für möglich, die z.B. Arrays aus
> Hall-Sensoren zum Visualisieren von Magnetfeldern einsetzen.
Das wird schon gemacht und nicht nur mit Hallsensoren. Hatte in meiner 
Anfangszeit mal eine APP, die sogar über DSPs lief. Dann: In jedem MRT 
werden Magnetfelder 3-dimensional erfasst und verrechnet, auch und vor 
allem mit FPGAs.

Zweidimensional gibt es das sogar als Messsystemzubehör für Oszilloskope 
von Agilent: Man legt eine Platine auf ein DIN A4-Brett und kann sich 
grafisch wie in einem Wärmebild die EMV ansehen.

> Zudem ist es sicherlich interessant und nützlich Ultraschalsensor-Arrays
> zu bauen, die z.B. ein "2D/3D-Abtasten" von der Umgebung für
> Sehbehinderte erleichten würden.
Auch das wird gemacht, wenn auch in meinem Fall nicht für die 
Sehbehinderten, sondern die automatische Pbjekterkennung. Ob man da 
Blinden helfen kann, ist eher zweifelhaft, weil die Ortsauflösung von 
Ultraschall nicht so hoch ist. Wenigstens nicht in Luft. Mit FPGAs kann 
man aber sehr schon 1-BIT-DA-Wandler bauen, die ohne Wandler über viele 
Pins viele analoge Sensoren abtasten.

https://www.mikrocontroller.net/articles/Analog-IO...

Damals waren es bis zu 256 Kanäle in einem Spartan 3E. Sehr 
platzsparend. Im MEMS-Zeitalter geht das heute freilich digital rein.

: Bearbeitet durch User
Autor: abc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> FFTs und Ähnliche Sachen, sind auch nicht so das Problem, weil die ja
> als Core existieren. Der System Generator schaltet die letztlich auch
> nur als Grafik zusammen. Entscheidender ist der Aufbau der image pipe an
> sich, vor allem Funktion und Umsetzung und deren Parallelisierung nimmt
> einem ja niemand ab.

Die FFTs waren händisch zusammen gebaut.
Der System Generator hat folgende  Vorteile:
. aufgrund der graphischen Gestaltung leicht verständlich
. Submodule per Click
. Voller Funktionsumfang, dh, es ist prinzipiell alles realisierbar;
. Parallelität und Design-Struktur "graphisch erkennbar"
. Es lässt sich nur "sinnvolles" zusammenklicken.
. Es gibt weniger Syntaxfehler und auch Sematikfehler.
. Waren sogar VHDL-Module einbindbar?
. Komfortables HIL

Nachteile:
Preis, Abhängigkeit

Autor: abc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 2D-FFTs waren das

Autor: Kamil Rezer (kamil_rezer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
>...weil die Ortsauflösung von
>Ultraschall nicht so hoch ist. Wenigstens nicht in Luft.

Ich denke, dass herkömmliche Radare in der Tat besser für die Aufgabe 
geeignet wäre. Doch der Kostenfaktor, wie bei im Tread erwähntet 
Privatprojekten, schätze ich höher für Radar- als für 
Ultraschal-Sensoren. Wie sieht es mit Kosten für Infrarotsensoren aus?

Jürgen S. schrieb:
>Auch das wird gemacht, wenn auch in meinem Fall nicht für die
>Sehbehinderten, sondern die automatische Pbjekterkennung. Ob man da
>Blinden helfen kann, ist eher zweifelhaft...

Könnte gerade dies für Sehunterstützung-Anwendung interessant sein: Das 
Gerät erkennt Objekt und seine Position, dann "leitet/sagt/mitteilt" es 
an die Person weiter.

Jürgen S. schrieb:
> Zweidimensional gibt es das sogar als Messsystemzubehör für Oszilloskope
> von Agilent: Man legt eine Platine auf ein DIN A4-Brett und kann sich
> grafisch wie in einem Wärmebild die EMV ansehen.

Das ist sehr interessant für mich, hast Du vielleicht mehr Information 
dazu?

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kamil R. schrieb:
> Könnte gerade dies für Sehunterstützung-Anwendung interessant sein: Das
> Gerät erkennt Objekt und seine Position, dann "leitet/sagt/mitteilt" es
> an die Person weiter.
Möglich ist das definitiv. Es gibt ja sogar in den USA Trainingscenter, 
wo Leute lernen, mit der Zunge zu schnalzen und anhand des Echos die 
Umgebung zu erkennen.

> Das ist sehr interessant für mich, hast Du vielleicht mehr Information
> dazu?

Kann sein, dass ich Agilent fälschlicherweise ins Spiel gebracht hatte: 
Was ich selber gesehen habe war das DATATEC EMSCAN:
http://www.datatec.de/nocache/App-Note-EHX-EMV-Sca...

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abc schrieb:
> . aufgrund der graphischen Gestaltung leicht verständlich
Trotz graphischer Gestaltung nicht verständlich, weil die Vorteile 
grafischer Gestaltung, nämlich farbliche Markierung, Kenntlichmachung 
von Signal- und Netzeigenschaften nicht oder nur unzureichende genutzt 
wird und ferner faktisch wichtige Dinge in anonymisierten Symbolen 
versteckt werden.

> . Submodule per Click
Sofern verfügbar und funktionabel. Vorhandene Submodule als VHDL können 
mit COPY und PASTE genau so leicht eingesetzt werden

> . Voller Funktionsumfang, dh, es ist prinzipiell alles realisierbar;
Keineswegs. Im Sysgen sind mitnichten alle Cores akutell verfügbar, die 
man beim Coregen direkt erhält und auch die decken nicht alles ab.

> . Parallelität und Design-Struktur "graphisch erkennbar"
Nur zweidimensional und welches Komplexe Design in schon 
zweidimensional?
Ein einfaches generisches Beschreiben von mehrdimensionalen 
Modulstrukturen ist faktisch unmöglich.

> . Es lässt sich nur "sinnvolles" zusammenklicken.
Das stimmt nicht. Da kann man alles mit allem kombinieren, wenn der Port 
passt, auch wenn die Funktion keinen Sinn gibt. Umgekehrt verhindern 
bestimmte Einschränkungen einfache Dinge, die in VHDL einfach zu 
formulieren sind. Da habe ich tonnenweise Beispiele.

> . Es gibt weniger Syntaxfehler und auch Sematikfehler.
Ich wüsste nicht, wie man bei einem HDL-Design einen Sema(n)tikfehler 
einbauen könnte, der persistent bliebe - und Syntaxfehler compilieren 
nicht. Falsch interpretierte Signale durch das Simulinksystem aber sehr 
wohl.

Ich erinnere mich noch wie gestern an einen Fall, wo es schlicht 
unmöglich war, aus einfachen Grafikelementen eine dumme PWM-Ausgabe 
hinzubekommen. Es compilierte, funktionierte aber nicht. Fehler war 
trotz einschalten von Mathworks sowie eines erfahrenen Simulink-Nutzers 
der Nachbarabteilung nicht zu lösen.

> . Waren sogar VHDL-Module einbindbar?
Ja, das geht und das war die Rettung: Grafikgespiele raus, embedded 
Matlab rein und an den HW-nahen Stellen die Logikblöckchen, die 
angeblich zählen können, durch VHDL ersetzt.

Es gäbe noch weitere Punkte - habe das damals mal genauer 
aufgeschlüsselt, wo das System überall muckt. Massivster Ärger waren 
Signale die nicht und falsch im WAVE Window angezeigt wurden, 
verschwanden und verwechselt wurden. Eine Systemvalidierung ist damit 
schlicht unmöglich.

> . Komfortables HIL
Das ist der einzige Punkt, in dem Ich Dir zustimme. Warum auch immer, 
hat man es geschaft, ein Design in einen wrapper reinwerfen zu können, 
der dann auf dem FPGA asynchron läuft und die Simulation massiv 
beschleunigt.

Das wäre ein echter und wichtiger Vorteil des Systems. Die Nachteile 
wiegen den für tpyische Entwicklungen aber meistens auf! Wer nicht 
unbedingt mit MATLAB arbeiten muss, um sein System hinzustellen, lässt 
im Zweifel lieber die Finger davon.

> Nachteile:
> Preis, Abhängigkeit
Der Preis ist eigentlich egal, bei den Kosten für Entwickler, die 
Modellieren, Simulieren, Rechnen und physikalisches Testen.

Man muss im Gegenteil eher veranschlagen, dass das Entwickeln mit dem 
System länger dauert, weil MATLAB den Rechner komplett blockiert, 
während man mit einer offenen toolchain ModelSIM, Synthese, Editing und 
Dokumentieren parallel erledigen kann.

Abhängigkeit ist schon ein Punkt. Einmal verfasste Grafiken können nicht 
uneingeschränkt in die nächste Version portiert werden und zu einem 
anderen Hersteller schon gleich gar nicht.

Die ärgerlichste und gefährlichste Abhängigkeit ist aber die vom Tool 
selber: Was an Macken drin ist, ist nicht zu beheben.

Teamwork ist ein Thema. Es ist praktisch unmöglich an demselben design 
zu arbeiten. Versionskontrolle bei Grafik ist auch nicht so prickelnd.

Autor: abc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> abc schrieb:
>> . Voller Funktionsumfang, dh, es ist prinzipiell alles realisierbar;
> Keineswegs. Im Sysgen sind mitnichten alle Cores akutell verfügbar, die
> man beim Coregen direkt erhält und auch die decken nicht alles ab.
>
>> . Parallelität und Design-Struktur "graphisch erkennbar"
> Nur zweidimensional und welches Komplexe Design in schon
> zweidimensional?

Der Synopsys RTL Viewer schafft es auch, jedes Design in 2D 
darzustellen. Nur kann man da die Grafiken nicht editieren und es ist 
auch nicht so übersichtlich.

> Ein einfaches generisches Beschreiben [...] ist faktisch unmöglich.

ja.

>> . Es lässt sich nur "sinnvolles" zusammen klicken.
> Das stimmt nicht. Da kann man alles mit allem kombinieren, wenn der Port
> passt, auch wenn die Funktion keinen Sinn gibt. Umgekehrt verhindern
> bestimmte Einschränkungen einfache Dinge, die in VHDL einfach zu
> formulieren sind. Da habe ich tonnenweise Beispiele.

If reset=1 and rising_edge(reset)...

> Ich erinnere mich noch wie gestern an einen Fall, wo es schlicht
> unmöglich war, aus einfachen Grafikelementen eine dumme PWM-Ausgabe
> hinzubekommen. Es compilierte, funktionierte aber nicht. Fehler war
> trotz einschalten von Mathworks sowie eines erfahrenen Simulink-Nutzers
> der Nachbarabteilung nicht zu lösen.

Gut, dass jemand auch negative Erfahrungen berichtet.

...irgendwie ging das mit der Teamwork am selben Design. 
Validierung/Test haben wir ganz sicher nicht mit dem WAVE-Editor 
gemacht. Vielleicht nicht mal getestet. Eher unnötig gerade mit einem 
solchen Tool.

Eine DSP-Chain ist schnell zusammen geklickt und kann auch komplexer 
sein. Darüber hinaus können viele Entwickler ohne HDL-Kenntnisse relativ 
schnell produktiv tätig sein. Dabei typische Stolperfallen und Aufwände 
nimmt es einem in beiden Fällen ab.

Es ist nicht für HDL-Coder, nicht als VHDL-Ersatz und auch nicht zum 
Beschreiben großer state machines, Komponenten mit "vielen" 
Steuersignalen, CPUs oder ganzer SoCs geeignet. Dafür hatte ich es hier 
auch nicht empfohlen.

Wenn man bei jedem Fehler im Synthesetool oder Silicon hinschmeißen 
würde, dürfte man gar nichts mehr machen. Gut, ihr hattet mehr Fehler. 
In welchem Jahr war das?

Autor: Thomas U. (thomasu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abc schrieb:
> Der Synopsys RTL Viewer schafft es auch, jedes Design in 2D
> darzustellen.
Vollommen unlesbar und ohne jeden Nutzen. Das widerspricht eher einer 
Übersicht, die Durchblick durch die Schaltung schaffen könnte.

> Eine DSP-Chain ist schnell zusammen geklickt und kann auch komplexer
> sein. Darüber hinaus können viele Entwickler ohne HDL-Kenntnisse relativ
> schnell produktiv tätig sein.
Ich habe momentan so einen Fall, wo sich mehrere Entwickler scheinbar 
produktiv um ein Thema tummeln, sich um die Lizenzen und Vorgehensweisen 
prügeln. Das schnelle Zusammenklicken führt nach meiner Beobachtung nur 
dazu, dass die Thematik von vielen Projektleitern noch weiter 
unterschätzt wird, als es ohnehin schon der Fall ist.

Autor: abc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas U. schrieb:
>> Eine DSP-Chain ist schnell zusammen geklickt und kann auch komplexer
>> sein. Darüber hinaus können viele Entwickler ohne HDL-Kenntnisse relativ
>> schnell produktiv tätig sein.
> Ich habe momentan so einen Fall, wo sich mehrere Entwickler scheinbar
> produktiv um ein Thema tummeln, sich um die Lizenzen und Vorgehensweisen
> prügeln. Das schnelle Zusammenklicken führt nach meiner Beobachtung nur
> dazu, dass die Thematik von vielen Projektleitern noch weiter
> unterschätzt wird, als es ohnehin schon der Fall ist.

Und? Soll Deine Einzelfall-Beobachtung irgendetwas über die 
Allgemeinheit oder die prinzipielle Nützlichkeit bei sinngemäßer 
Anwendung aussagen? Oder ist das ein Job-Angebot?

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abc schrieb:
> Thomas U. schrieb:
>>> Eine DSP-Chain ist schnell zusammen geklickt und kann auch komplexer
>>> sein. Darüber hinaus können viele Entwickler ohne HDL-Kenntnisse relativ
>>> schnell produktiv tätig sein.
>> Ich habe momentan so einen Fall, wo sich mehrere Entwickler scheinbar
>> produktiv um ein Thema tummeln, sich um die Lizenzen und Vorgehensweisen
>> prügeln. Das schnelle Zusammenklicken führt nach meiner Beobachtung nur
>> dazu, dass die Thematik von vielen Projektleitern noch weiter
>> unterschätzt wird, als es ohnehin schon der Fall ist.
>
> Und? Soll Deine Einzelfall-Beobachtung irgendetwas über die
> Allgemeinheit oder die prinzipielle Nützlichkeit bei sinngemäßer
> Anwendung aussagen? Oder ist das ein Job-Angebot?

Ich fürchte, dass das keine Einzelfälle sind :-)
Die Threads über grafisches Programmieren sind hier schon geradezu 
inflationär. Unterm Strich gelten leider doch immer wieder die 
Naturgesetze: Der Europäer ist prinzipiell eher Sprachenmensch als 
Bildermensch (bei den Japanern mag das etwas anders sein). Deswegen war 
dashierzulande mit grafischem Entwickeln noch nie so richtig nachhaltig, 
abgesehen vom fehlenden Standard und fehlenden Testbenches.

Autor: R. Freitag (rfr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich schlage vor, dass du einen BPSK-Transceiver entwickelst. Der soll 
per USB an den PC gekoppelt werde und dessen Ausgang an eine Antenne.

Ein weiterr Ausgang für die Steuerung einer magnetischen Antenne wäre 
für meine Verhältnisse äusserst hinfreich.

Unter Linux sollte es ein geeignetes Programm geben, welches die 
Abwicklung einer Kommunikation steuert.

Und falls das noch nicht reicht: es gibt weitere digitale Betriebsarten: 
alle FSK, Pactor, (..............)

Falls du das auf einen Spartan3 packst, könnte ich das auf vorhandenem 
Inventar nutzen. PC mit Linux ist bereits vorhanden  :-)

Gruss

Robert

Autor: Thomas U. (thomasu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es müsste etwas sein, was es noch nicht gibt, aber was möchte man mit 
FPGAs noch groß tun? Es sind in aller Regel die typischen Hobbyprojekte 
und die beziehen sich immer irgendwie auf die Sinne des Menschen:

1. Hören
2. Sehen
3. Fühlen
4. Riechen

Beim Hören gibt es die Tonerzeugung und die Bearbeitung, beim Sehen ist 
es irgendwie Dasselbe, riechen kann man FPGAs, wenn sie zuviel Strom 
abgekriegt haben - nur das Fühlen kommt etwas zu kurz! Bliebe etwas im 
Bereich Reizstrom oder Magnetfelderzeugung, die man in den Muskeln 
spüren kann.

Was wirklich interessant wäre, sind Decoder, die der geplanten 
Manifestierung von Bezahldiensten durch Kopierschutz entgegenwirken. 
Soweit ich weiß gibt es schon Premieredecoder. Wie sieht es denn z.B. 
aus mit dem DVB-T2 Format? Das Signal muss irgendwie zu entschlüsseln 
sein, damit man ohne irgendwelche Karten oder Bezahlcodes mitschauen 
kann.

Nach einem jüngsten Urteil sind die ja zu privaten Zwecken erlaubt, 
sofern man die entwickelte Software nicht weitergibt.

Autor: R. Freitag (rfr)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Es reicht, wenn der Entwickler die Software betreibt und die Ergebnisse 
ins Netz stellt.  :-)

Robert

Autor: Thomas U. (thomasu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, die Sofware ist vielleicht schon da und braucht nur noch die 
richtige Videoplattform?

Beitrag "Re: Suche Mitwirkende für Hochleistungs-FPGA board"

:-)

Autor: Thomas U. (thomasu)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Strubi schrieb:

> Ich fürchte, dass das keine Einzelfälle sind :-)
Das ist der Regelfall. Zu den Einzelfällen zähle ich eher die, welche 
nach umfassender Erfahrung mit den grafischen Werkzeugen dies als 
Königsweg einschätzen.

> dashierzulande mit grafischem Entwickeln noch nie so richtig nachhaltig,
> abgesehen vom fehlenden Standard und fehlenden Testbenches.
Ich glaube eher nicht, daß es was mit Nationaöitäten zu tun hat. Das 
sind schon durchaus pragmatische Gründe.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum "grafischen Entwickeln" fällt mir noch was ein, was Ich schon 
mehrfach mal probieren wollte, aber aus Zeitgründen nie angegangen bin:

Eine Toolbox mit VHDL-Modellen für Elektroniksimulation. Ursprünglich 
mla mit den ISE-Blocksymbolen ausprobiert, müsste sich das mit dem in 
Vivado inzwischen stabiler darstellenden Blockdesign zu machen sein:

Es gibt eine Reihe von Symbolen, hinter denen sich Analogmodelle 
verbergen und die wie in einem Netzwerk zusammengeschaltet werden. Das 
VHDL kann dann das Verhalten im Zeitbereich simulieren. Per Skalierung 
wird das Thema der Zeitauslösung erledigt.

Ich denke da z.B. an analoge Filter, Bauelemente mit Verlusten und 
parasitären Effekten. Schaltungen bis zu einigen Kiloherz liessen sich 
damit sogar in Echtzeit betreiben.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich komme nochmals zurück zu dem Thema weiter oben:

W.S. schrieb:
> c) ein heutzutage üblicher µC, z.B. ein LPC4088, den es für ca. 8..9
> Euro fertig zu kaufen gibt. Schau dir mal an, was der alles drin hat,
> von Gleitkomma-Rechenwerk über TFT-Controller, USB, Ethernet,
> SDRAM-Anschluß, riesiger interner Flash, recht großer interner RAM und
> und und... Glaubst du, mit einem überhaupt erschwinglichen FPGA das
> alles nachbilden zu können?

Das kann man nur unterstützen! Nachzubilden ist mit einem FPGA so 
ziemlich gar nichts, was es zu kaufen gibt. Das ist aber nicht wirklich 
die Frage.

Der Task ist "Neubilden", als Prototypen zu bauen von Schaltungen und 
Funktionen, die es noch nicht gibt. Dort benötigt man Modelle der 
Interfaces, deren Funktionen und Dinge, die man nicht in Echtzei in 
einem Controller realisieren kann.

Den Kostenvergleich Microontroller und FPGA wird der FPGA immer 
verlieren.

Kommen wir mal zu einem konkreten Beispiel und damit einer Idee für ein 
FPGA-Probjekt:

Eine Überwachungsschaltung für Microcontroller mit eingebautem 
Assembler, der versteht, was der Controller tut und nachvollziehen kann, 
was er macht und Echtzeitsysteme zu tracken.

Wer möchte?

Autor: Lothar (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5189422:
> Überwachungsschaltung für Microcontroller

Gibt es doch schon: Lock-Step Dual-Core

http://www.ti.com/content/dam/ticom/images/product...

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den kenne Ich, allerdings möchte Ich mehr tun. Ich komme da später 
nochmals drauf zu sprechen und stelle das genauer vor.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>
> Eine Überwachungsschaltung für Microcontroller mit eingebautem
> Assembler, der versteht, was der Controller tut und nachvollziehen kann,
> was er macht und Echtzeitsysteme zu tracken.
>
> Wer möchte?

Also ich habe dein Problem nicht ganz verstanden. Was du unter 
Überwachungsschalter verstehst?
Ich habe einen Mikrocotroller als Softcore, der die MIPS-I Befehle 
ausführt. Da bin ich bereits so weit, dass ich auch C Programme 
ausführen kann und diese auch mit dem GDB über eine UART 
Zweidrahtleitung debugen kann.

weitere Watchdogs oder Werteüberprüfer sollten kein Problem in VHDL 
sein.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5189422:
> Eine Überwachungsschaltung für Microcontroller mit eingebautem
> Assembler, der versteht, was der Controller tut und nachvollziehen kann,
> was er macht und Echtzeitsysteme zu tracken.
>
> Wer möchte?

Ha, ha. Dir ist aber schon klar, was das für ein Aufwand ist?
Manche Firmen stecken da locker einige 100k rein.
Und du meinst sicher Disassembler...
Der Sinn für 'Safety-Computing' erschliesst sich mir allerdings nicht 
ganz, eher noch für Reverse-Engineering, oder FPGA als Trace-Debugger. 
Da machen viele ihr eigenes Ding und geben nix raus.

Wenn's um Safety und Verhinderung bösartiger Attacken geht:
Mehr Sinn macht für mich, auf eine Softcore-Architektur aufzubauen, die 
eine elegante Einbindung effektiver Watchpoint-Units erlaubt, wie z.B. 
gewisse Stackmaschinen. In meiner ZPUng mit WPU habe ich z.B. 
Checkpoints im Programm an gewissen kritischen Stellen, die 
deterministisch angefahren werden (müssen), da ist der Wert eines 
gewissen Registers (verwursteter SP und PC) immer jeweils identisch mit 
einer "nonce". Der Vergleich damit ist natürlich das kritische 
Element, egal wie redundant der ausgelegt ist. Trotzdem deutlich 
robuster als z.B. ein 0815 ARM, aber nur, was Programmablauf angeht, 
redundante ALU ist nicht drin.

Die Frage ist immer, was du grundsätzlich haben willst: eine Schaltung, 
die jeden Fehler möglichst hochwahrscheinlich erkennt und Alarm schlägt, 
oder eine die möglichst irgendwie weiterläuft und versucht, zu 
korrigieren.
Ich denke mal, jeder fängt mit ersterem an und macht bei v2 unter 
Umständen nochmal alles neu von vorne. Letzteres geht mit einer 
Stackmaschine nur bedingt gut.

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.

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