Forum: FPGA, VHDL & Co. Mit welchem FPGA anfangen/einsteigen?


von Marvin K. (m_marvin)


Lesenswert?

Ich entwickle gerade einen Schrittmotor-Impusgeber der Rechtecksignale 
von bis zu 50kHz erzeugen und Zählen muss.
Nach längerem rumprobieren und vielen Diskussionen in einem anderen 
Thread, hab ich das mit einem ATxmegaA3 realisieren können.

Nun bin ich aber auf eine weitere Anforderung für meine Schaltung 
gestoßen, die sich so nicht mit einem AVR allein realisieren lässt.

Kurzgesagt möchte ich meine Schaltung so abändern, dass der AVR nur noch 
für die RS232 Kommunikation und das Bereitstellen der Frequenzen (als 
Wert in irgend einer Form, nicht als Frequenz-Signal) und der 
Schrittzahlen zuständig ist.

Die Frequenzen sollen in einem FPGA erzeugt werden, was mir schonmal in 
dem anderen Thread vorgeschlagen wurde.

Meine Frage ist nun, wo beginne ich am besten, wenn ich noch nie mit 
einem FPGA gearbeitet hab?
Die Funktionsweise hab ich verstanden und auch schon einige 
Entwiklungsboards gefunden.
Auch in einigen Threads hier im Forum hab ich mich schon umgeschaut.

Die 3 wichtigste Fragen die ich habe sind gerade:

A Nach welchen Kriterien wählt man einen FPGA aus?
Bei einem AVR sind es z.B. Taktgeschwindigkeit, IO-Pins, Timer-Anzahl 
usw.

B Mit welchem Entwiklungsboard/"Programmer" sollte ich anfangen ?
Es sollte nicht zu teuer sein (möglichst unter 200€) aber die Pins des 
FPGAs als DIP/Pin-Header bereitstellen so dass ich nicht erst noch 
Adapterboards löten muss und das alles mit Drahtbrücken verbinden muss.

C Welche Entwiklungsumgebung ist für Anfänger am besten geeignet ?
Ich habe schon einige gefunden, aber bisher hat Windows (10) diese 
entweder als "gefährliche Software" eingestuft, oder sie liefen in einer 
VM auf Linux (warum so kompliziert ???) und waren sehr mit Funktionen 
überladen und ohne große Dokumentation.

von Marius (Gast)


Lesenswert?

Ich fand diese tinyFPGAs eigentlich recht witzig gemacht. Wirklich sehr 
kleines Board und man kann relativ schnell mit starten.

Ansonsten würde ich mich evtl. mal noch nach den typischen Xilinx Boards 
umsehen mit Artix o.ä.

von Jens W. (jensw)


Lesenswert?

Hallo,

fang mit Frage B an. Nimm die Boards, die die Pins über normale Pins 
heraus geführt haben. Da wird das Suchergebnis schon deutlich 
eingeschränkt.

Die großen Player sind Xilinx und Altera. Da wirst du dich für einen 
entscheiden müssen. So wie früher die Diskussion PIC oder AVR. Das ist 
eher eine Glaubensfrage, als dass man sich als Neuling damit 
beschäftigt, was die alles im einzelnen können. Unter dem Strich nehmen 
die sich nicht viel.
Für deine ersten Gehversuche sind beide gleichermaßen geeignet.
Sonderexemplare würde ich dir nicht empfehlen. Du willst ja Fragen 
stellen und beantwortet haben beim Lernen. Und bei den beiden Firmen 
oben gibt es einfach die meisten User.
Und für die Größe des Boards kaufst du das größte, das du mit deinem 
Budget bekommst.
Die Entwicklungsumgebung ist damit dann auch schon ziemlich fest.

Achja: um ein Buch für VHDL wirst du nicht drumrum kommen. Das braucht 
man meiner Meinung nach als Nachschlagewerk immer neben der Tastatur.

Ich verwende für meine ersten Versuche Xilinx und ISE Webpack. Beides 
schon veraltet, aber für meine Zwecke komme ich noch an keine Grenze. 
Reicht also vollkommen aus.

Grüße, Jens

von Gustl B. (-gb-)


Lesenswert?

Marvin K. schrieb:
> Kurzgesagt möchte ich meine Schaltung so abändern, dass der AVR nur noch
> für die RS232 Kommunikation und das Bereitstellen der Frequenzen (als
> Wert in irgend einer Form, nicht als Frequenz-Signal) und der
> Schrittzahlen zuständig ist.

Auch das geht wunderbar im FPGA.

Marvin K. schrieb:
> A Nach welchen Kriterien wählt man einen FPGA aus?

Für ein Projekt oder generell zum Lernen?

Für ein Projekt machst du erstmal deine Hardwarebeschreibung am PC und 
dann guckst du wie viele IOs und sonstigen FPGA Ressourcen du brauchst. 
Und dann kaufst du den FPGA in den das Design reinpasst. Aber keinen der 
10 mal "größer" ist.

Zum Lernen kannst du ein beliebiges FPGA Board nehmen das auch eben 
Spielwiesen bietet. Taster, Schalter, LEDs, Display, ADC, DAC, RAM, 
Flash, I2C/SPI Bausteine, ... wichtig ist, dass das von einer aktuellen 
Entwicklungsumgebung unterstützt wird. Denn du willst ja den aktuellen 
Stand lernen.

Marvin K. schrieb:
> B Mit welchem Entwiklungsboard/"Programmer" sollte ich anfangen ?

Ich würde aktuell etwas mit Xilinx 7er Serie nehmen. Also 
Artix7/Spartan7/Zynq7.
Begründung:
Das wird vom aktuellen Vivado unterstützt und ist nicht sooo irre teuer.
Ja, man könnte auch den MAX10 nehmen, aber der MAX10LP wird leider nie 
ordentlichen VHDL2008 Support bekommen. Wenn dir das egal ist dann nimm 
den.

Marvin K. schrieb:
> C Welche Entwiklungsumgebung ist für Anfänger am besten geeignet ?

Naja, Hardwarebeschreibung schreibt man, das geht mit jedem Texteditor, 
dann simuliert man recht viel, dazu gibt es GHDL/Modelsim/... und dann 
muss man das noch auf die Hardware bringen. Und nur für den letzten 
Schritt brauchst du die Software vom Hersteller.

So wie dein Projekt klingt könnte das 
https://github.com/dukelec/cdpga/tree/master/cdpga_h gut passen. Das ist 
aktuell sogar über eBay/Aliexpress recht gut zu bekommen. Ist aber kein 
Lernboard weil das ausser FPGA und Taktgeber nicht viel drauf hat.

von Marvin K. (m_marvin)


Angehängte Dateien:

Lesenswert?

Danke schonmal für die schnelle Antwort, ISE hab ich mir schon 
runtergeladen (Webpack hab ich nirgends gelesen, ist das was anderes ?)
ISE hat aber eine VM mit Linux installiert und läuft nicht unbedingt 
sehr stabil.
Ich werde mich dann erstmal nach einem Board umsehen.

Ich hab mal mein aktuelles Konzept für den (neuen) Impulsgeber als 
Grafik angehängt, ich denke das das die bisher beste Lösung ist die ich 
gefunden habe.

Ziel ist es auf dem Board das ich mit kaufe, diesen FPGA zu realisieren 
und zu testen, es sollte also genug IO Ports haben und der FPGA braucht 
genügend Bausteine für den Oszillator, den Zähler usw.

Genau dieser letzte Punkt hat mich am meisten daran gehindert ein Board 
zu kaufen, ich hab keine Ahnung welche "Werte" der FPGA benötigt.
Bei einem AVR kann ich einfach mal ein Programm schreiben und schauen 
wieviel Flash, welchen CPU Takt usw. ich brauche.

Für den Anfang vielleicht erstmal: Benötige ich für eine solche Aufgabe 
eher einen "größeren" FPGA, oder ist das ein minimal-Fall ?

Bei einem AVR ist das schon eher die obere Grenze gewesen, aber bei 
FPGAs hab ich keine Erfahrung.

Kurze Eckdaten für mein Vorhaben:
8 Kanäle mit Frequenzen bis 50kHz oder optional auch 100kHz.
Laufende Änderung der Frequenz durch den AVR.
Frequenzen stehen als 8 Bit werte bereit, Schrittzahlen als 16 Bit werte 
bereit (vom AVR).
Für eine Kommunikationsart (seriell, parallel, I2C, UART usw.) zwischen 
FPGA und AVR hab ich mich noch nicht entschieden.

von Gustl B. (-gb-)


Lesenswert?

Marvin K. schrieb:
> ich hab keine Ahnung welche "Werte" der FPGA benötigt.

Du kannst dein komplettes FPGA Design auch jetzt schon ohne FPGA 
aufsetzen, simulieren und synthetisieren. Und dann siehst du ganz genau 
was du brauchst. Dann wählst du einen passenden FPGA.
Aber egal, dass passt so ziemlich in das kleinste FPGA.

Marvin K. schrieb:
> Kurze Eckdaten für mein Vorhaben:
> 8 Kanäle mit Frequenzen bis 50kHz oder optional auch 100kHz.
> Laufende Änderung der Frequenz durch den AVR.
> Frequenzen stehen als 8 Bit werte bereit, Schrittzahlen als 16 Bit werte
> bereit (vom AVR).
> Für eine Kommunikationsart (seriell, parallel, I2C, UART usw.) zwischen
> FPGA und AVR hab ich mich noch nicht entschieden.

Ich würde den AVR weglassen. UART kann man auch im FPGA machen. Und 8 
Kanäle sind auch einfach, die Frage ist eger wie genau die Frequenz sein 
muss, also was ist die Frequenzauflösung? Wie schnell muss ein externer 
Takt sein der zur Erzeugung der 8 Signale verwendet wird?
Wenn du auch den UART im FPGA machst dann sparst du Pins und musst dich 
nur um einen Baustein kümmern.
Was noch fehlt:
Welche Spannungspegel sollen die Ausgangssignale haben und müssen sie 
viel Strom liefern können? Normale FPGA IOs können grob 3.3V maximal und 
eher wenig Strom, so um die 10 bis 20 mA.

: Bearbeitet durch User
von Marvin K. (m_marvin)


Lesenswert?

Der Strom ist nicht so hoch, aber es sind 5V-24V (Eingangsbereich des 
Treibers).
Ich habe aber sowieso vor Optokoppler oder Level-Shifter zu nutzen.

Den AVR würde ich gerne behalten, der würde sich dann nämlich um die 
genauen Frequenzabläufe kümmern.
Wie gesagt, die Frequenzen müssen sich laufend ändern können, je nach 
RS232 Befehl.

z.B. eine Rampe von 1-20kHz dann für 10 Sekunden halten, und wieder auf 
1kHz runter (nur ein Beispiel).

Problematisch bei meinem aktuellen Aufbau mit nur dem AVR ist, dass 
keine Rechenleistung dafür übrig bleibt.
Daher würde ich gerne die Freuqenzgenerierung auf einen FPGA verlagern, 
und nur die Frequenzen als veränderlichen Wert bereitstellen.
Ich weis nicht in wie weit es möglich ist solche Abläufe in einem FPGA 
zu programmieren.

Die Frequenzauflösung muss nicht so hoch sein, mindestens 8 Bit (also 
bei max. 50kHz sind das dann 196Hz Schritte), aber wenn es die Hardware 
hergibt, setze ich sie auf das was halt möglich ist hoch.
Das Programm für den AVR hab ich ja schon, ich müsste nur alles was mit 
Timern und Frequenzgenerierung zu tun hat rausnehmen und die Werte über 
ein beliebige Schnittstelle ausgeben.

Die Info das das in einen kleinen FPGA passt, reicht mir erstmal.
Ich werde mich dann mal nach einem Board und der entsprechenden Software 
umschauen.

: Bearbeitet durch User
von Cartman (Gast)


Lesenswert?

> Und dann siehst du ganz genau
> was du brauchst. Dann wählst du einen passenden FPGA.

Was beim Anfaenger auch schon fuerchterlich schief gehen kann.
Fehler in der Beschreibung koennen ganz schnell dazu fuehren,
dass der Aufwand im FPGA "explodiert".

> Aber egal, dass passt so ziemlich in das kleinste FPGA.
Eben.

Vorteil bei Intel/Altera: Die JTAG/Programmieradapter sind
ausgesprochen guenstig zu bekommen und die Software laueft
recht stabil und ohne Macken.
Geeignet waeren, geordnet von jung nach alt:
MAX10, Cyclone 2 und Cyclone 1.
Jeweils in der kleinsten Groesse.
Fue die aelteren Typen braucht man aber auch die aeltere Software.
Solange die auf deinem Rechner laeuft, bedeutet das aber keinen
weiteren Nachteil.

Lass am Anfang die Finger von "Softcores" die auch deine
Software laufen lassen koennten und bleib bei deinen AVRs.











Marvin K. schrieb:

von China promoter (Gast)


Lesenswert?

Tang nano
Der kleine unter 10€. Der grössere 15€.

von Ron T. (rontem)


Lesenswert?

Marvin K. schrieb:
> Problematisch bei meinem aktuellen Aufbau mit nur dem AVR ist, dass
> keine Rechenleistung dafür übrig bleibt

Und Du bist sicher, daß Du deren Möglichkeiten (wie das Event-System) 
schon ausgeschöpft hast? Aufgaben wie Signale bis 50kHz zu erzeugen oder 
als TCA-Event zu zählen sollten doch einen AVR noch vor keine großen 
Probleme stellen.

: Bearbeitet durch User
von Christoph Z. (christophz)


Lesenswert?

Marvin K. schrieb:
> Meine Frage ist nun, wo beginne ich am besten, wenn ich noch nie mit
> einem FPGA gearbeitet hab?

So wie Jens schrieb mit einem Buch.
Ich habe zwei, VHDL Synthese aus dem Oldenburg Verlag für den Einstieg 
und das Golden Reference von Doulos für all die VHDL Details die man 
seltener braucht.

Marvin K. schrieb:
> Kurze Eckdaten für mein Vorhaben:
> 8 Kanäle mit Frequenzen bis 50kHz oder optional auch 100kHz.
> Laufende Änderung der Frequenz durch den AVR.
> Frequenzen stehen als 8 Bit werte bereit, Schrittzahlen als 16 Bit werte
> bereit (vom AVR).

Schon mal die HostMot2 Firmware für die Mesa Karten angesehen?

Kommt aus der LinuxCNC/MachineKit Ecke, ist in Verilog geschrieben, open 
source und bietet Blöcke für noch ein paar weitere typische Dinge in 
Maschinen.

> Für eine Kommunikationsart (seriell, parallel, I2C, UART usw.) zwischen
> FPGA und AVR hab ich mich noch nicht entschieden.

Wenn der AVR daneben stehen bleibt, was ich persönlich nicht so schlecht 
finde, bietet sich SPI an.
Im Lattice MachXO2 ist SPI auch schon fix eingebaut ist aber auch sonst 
nicht zu komplex bzw. als Einstiegsprojekt geeignet.
Lattice Diamond als Entwicklungssoftware ist auch nicht viel anders als 
Vivado oder Quartus.

von Fpgakuechle K. (Gast)


Lesenswert?

Actel (jetzt microsemi?) hat mal eine seiner CPLD/FPGA Serien für 
Motoransteuerung, Powercontrol vermarktet. Da war/ist wohl gleich eine 
kräftigerer Endstufe dabei:

https://www.microcontrollertips.com/fpgas-target-multi-axis-motor-control-tasks/

von Christoph Z. (christophz)


Lesenswert?

Fpgakuechle K. schrieb:
> Actel (jetzt microsemi?)

Du wirst alt. Die heissen jetzt Microchip :-)
https://www.microsemi.com/applications/motor-control

von N. M. (mani)


Lesenswert?

Ron T. schrieb:
> Und Du bist sicher, daß Du deren Möglichkeiten (wie das Event-System)
> schon ausgeschöpft hast? Aufgaben wie Signale bis 50kHz zu erzeugen oder
> als TCA-Event zu zählen sollten doch einen AVR noch vor keine großen
> Probleme stellen.

Dachte ich auch als ich den Artikel gelesen habe. Ich finde nichts was 
ein uC nicht leisten könnte. Also vielleicht nicht der erwähnte. Aber 
der Sprung zu einem anderen uC ist halt deutlich kleiner als zu einem 
FPGA.
Wie willst du denn die uC/FPGA Kommunikation machen? Parallel? Dann 
brauchst du einige Pins. Also eher Seriell... Dann kannst du den uC auch 
gleich ganz einsparen.

Wenn es unbedingt ein FPGA sein soll würde ich mir wahrscheinlich ein 
Max10 oder ähnliches holen. Max1000 war Mal ein Board das es sehr 
günstig gab.
Wenn es denn dann unbedingt ein uC sein muss ein kleiner Softcore rein 
alla NIOS o.ä. und der Drops ist gelutscht.

Letzten Endes spielt der genaue Typ aber eher eine untergeordnete Rolle. 
Den die Aufgabe ist jetzt nicht so fordernd.

von FPGA_ing (Gast)


Lesenswert?

Für Deine Aufgabe reicht ein beliebig kleines FPGA, denn letztendlich 
musst Du ja nur ein Interface zum Empfang der Daten programmieren (SPI, 
RS232 o.ä.) und ein paar Zähler.
Dein interner FPGA Takt bestimmt die Granularität deiner Ausgangsstufen. 
Typische Frequenzen sind 50-100 MHz, d.h. Du könntest Ausgangsseitig 
eine Granularität von 10 ns erreichen, was sicherlich deutlich genauer 
ist, als du es benötigst.

Was die FPGAs angeht, würde ich eher die aktuelleren bevorzugen. Von ISE 
rate ich Dir beispielsweise ab.
Von Xilinx kannst Du die 7er Serie nehmen, z.B. Artix 7
Von Intel/Altera würde ich auf einen Max10 oder Cyclone10 setzen
Von Lattice gibt es für Deine Aufgabe den MachXO3
Von Actel/Microsemi/Microsemi rate ich für den Anfang ab, da die m.E. 
nur kleine Nieschen abdecken.

Die Entwicklungsumgebung ist durch die FPGA Auswahl vorgegeben (Vivado, 
Quartus, Diamond). Neben der Entwicklungsumgebung benötigst Du eine 
Simulationsumgebung, denn FPGAs testet man nicht in Hardware, sondern 
erst einmal durch eine Simulation. Dabei simulierst Du Deine Umgebung 
(beispielsweise das Interface zum AVR) und kannst wesentlich tiefer und 
schneller sehen, was Du implementiert hast. Auch hier findest du auf den 
Seiten der Hersteller die zugehörige Simulationsumgebung (Vivado, 
Modelsim, ActiveHDL)

Als Evalboards sind mir spontan das CYC1000 oder MAX1000 eingefallen. 
Die gibt es für schlankes Geld, man kommt gut an die GPIO (Stiftleiste) 
und Du brauchst keine extra Programmer etc, da diese bereits on board 
sind.

Ansonsten kannst Du auch ohne Hardware bereits anfangen, da Du ja 
anfangs in der Simulationswelt lebst und erst zu einem späteren 
Zeitpunkt auf die Hardware wechselst. Dann fällt es Dir auch leichter, 
eine Größenabschätzung vorzunehmen, da Du die Funktionalität bereits 
weitestgehend implementiert hast. Aber wie schon geschrieben, wird für 
Deine Aufgabe der Platz kein Problem darstellen.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Marvin K. schrieb:
> Ich entwickle gerade einen Schrittmotor-Impusgeber der Rechtecksignale
> von bis zu 50kHz erzeugen und Zählen muss.
Ich würde so eine Aufgabe mit einem MachXO2 erledigen, denn damit 
bekomme ich eine echte Single-Chip-Lösung ohne externen Oszillator und 
aufwändige Stromversorgung hin.

Cartman schrieb:
> Lass am Anfang die Finger von "Softcores"
Ein Softcore ist in etwa die ineffizienteste Art, einen µC aufzubauen. 
Für deutlich über 95% der Fälle dürfte gelten: wenn ich eine Aufgabe mit 
einem Softcore lösen kann, dann kann ich das auch billiger mit einem µC 
von der Stange.

Marvin K. schrieb:
> A Nach welchen Kriterien wählt man einen FPGA aus?
> Bei einem AVR sind es z.B. Taktgeschwindigkeit, IO-Pins, Timer-Anzahl
> usw.
Beim FPGA ist es in etwa das selbe: es muss groß genug sein, es muss 
schnell genug sein und genug von allem haben, was das Design braucht.

Ob ein Anfänger nun ein AMD(Xilinx) oder ein Intel(Altera) oder ein 
Lattice FPGA nimmt, ist halb so wild, denn alle Hersteller kochen hier 
in etwa mit dem selben Wasser. Die Lernschritte sind die gleichen.

Und dann gleich noch eines: fang ganz vorne an bei der blinkenden LED. 
Wenn du bis ins Detail verstanden hast, was da passiert (Stichwort: 
off-by-one), dann geh langsam Schritt für Schritt weiter. Du wirst (wie 
jeder andere vor dir) auf die Nase fallen, wenn du 2 Schritte auf einmal 
machst.

von W.S. (Gast)


Lesenswert?

Gustl B. schrieb:
> Ich würde aktuell etwas mit Xilinx 7er Serie nehmen.

Und das Ganze nur für einen "Schrittmotor-Impulsgeber" ?
Hab grad mal bei Mouser nachgesehen: Die Preise für sowas gehen dort bei 
etwa 16..17 € los, die andere Seite ist eher open end.

Und es kommt mir durchaus etwas eigentümlich vor, wenn jemand von einem 
AVR gleich zu einem FPGA wechseln will. Irgend ein kleinerer 32 Bitter 
für (derzeit) so etwa 3 € würde das problemlos erledigen.

Was also bleibt? Die Not, etwas nur mit einem FPGA realisieren zu können 
jedenfalls nicht. Da bleibt nur noch Hobby und Weiterbildung. Und da 
zählen keine betriebswirtschaftlichen Überlegungen, sondern nur, wieviel 
Geld man für's Hobby ausgeben darf, ohne daß die Gattin die Stirn 
runzelt.

Ich würde da eher erstmal rein theoretisch herangehen, wenn keine 
wirklich sinnvolle Anwendung bzw. Bedarf vorliegt. Also von der 
Programmiersprache bis zur Datei, die ins Konfigurations-Flash kommt. 
Und dazu nachschauen, was man da als Programmiergeschirre benötigt und 
wieviel das kostet. Danach richtet sich die Wahl des Herstellers. Und 
wenn es für's Hobby ist, dann auch danach, ob man einen geeigneten 
Bestücker im Bekanntenkreis hat für BGA oder nicht.

W.S.

von Marvin K. (m_marvin)


Lesenswert?

Mir wäre es auch lieber es nur mit einem AVR zu lösen, aber bisher hat 
jeder gesagt das sei nicht machbar, oder nur unter sehr spezifischen 
Bedingungen.

Aktuell habe ich einen ATxmega196A3, welchen würdet ihr den empfehlen, 
wenn es ohne FPGA sein soll ?

Problematisch ist aktuell das die CPU nicht damit hinterher kommt, die 
Schritte zu zählen und zeitgleich Berechnungen für die Frequenzänderung 
auszuführen, ich lasse die CPU gerade auf 25MHz laufen (hatte keinen 
32MHz Quarzt).

Sobald mehr als 2 Eingänge laufen, werden zu viele Schrittimpulse 
erzeugt, weil die CPU die Interrupts/Impulse verpasst.

Und zu den FPGAs:
Ich hab hier ein Entwiklungsboard gefunden, das einige IO-Pins besitzt, 
und noch ein par Schalter und Lampen.

https://www.reichelt.de/basys-3-artix-7-fpga-trainer-board-digil-410-183-p243337.html?&nbc=1

Es hat einen Xilinx Artix-7 FPGA.
Ich denke das währe ganz gut geeignet, würde aber gerne noch eine zweite 
Meinung einholen.
Bevor ich das kaufe, werde ich mir sowieso wie vorgeschlagen erstmal ein 
Buch zu VHDL zulegen.

Aber wenn das wirklich mit einem AVR umsetzbar ist, würde ich mit FPGAs 
doch nochmal warten bis dieses Projekt abgeschlossen ist.

: Bearbeitet durch User
von Christoph Z. (christophz)


Lesenswert?

Marvin K. schrieb:
> Aktuell habe ich einen ATxmega196A3, welchen würdet ihr den empfehlen,
> wenn es ohne FPGA sein soll ?

TI Sitara mit den PRUs (z. B. auf dem Beagle Bone Black bzw. Green)
Raspberry Pico mit den programmable I/O state machines
Infineon (Cypress) PSoC
...

von Strubi (Gast)


Lesenswert?

Achja, unser aller Lieblingsthema.
Fuer schnelle PWM und Zaehleraufgaben, wo viel Leistung und 
entsprechende Betriebssicherheit eine Rolle spielt, macht ein FPGA Sinn 
(wir haben so eine Sache mit vernetzten billig produzierbaren 
Spartan6-Brettern erschlagen).
Von AVR wuerde ich jetzt persoenlich absehen, v.a. weil man sich auf 8 
Bittern generell gut mit nicht-atomaren effekten ins Knie schiessen 
kann.

Die Unkenrufe gegen SoC/Softcore on-chip kann ich kaum nachvollziehen, 
da man mit diesen Loesungen deutlich schneller zum Ziel kommt und das 
ganze System inkl. Software simulierbar wird, somit einfach zu 
debuggen und verifizierbar.
Den Core und die passende DMA-Engine sollte man sich allerding gut 
aussuchen, da gebe ich aber keine Tips mehr zu ab :-)

Ansonsten: STM32 schon evaluiert?

von Sam .. (sam1994)


Lesenswert?

Strubi schrieb:
> Die Unkenrufe gegen SoC/Softcore on-chip kann ich kaum nachvollziehen,
> da man mit diesen Loesungen deutlich schneller zum Ziel kommt und das
> ganze System inkl. Software simulierbar wird, somit einfach zu debuggen
> und verifizierbar.
> Den Core und die passende DMA-Engine sollte man sich allerding gut
> aussuchen, da gebe ich aber keine Tips mehr zu ab :-)

Kann ich zwar nachvollziehen, aber nicht für einen Anfänger. Da gibt es 
zu viele Fallstricke.

Ich kenne die Randbedingungen nicht, aber es hört sich stark danach an, 
dass ein potenterer Controller das Problem alleine lösen kann. STM32 
wurde schon genannt, ich würde nach einem Cortex M4 schauen.

von Fpgakuechle K. (Gast)


Lesenswert?

Christoph Z. schrieb:
> Fpgakuechle K. schrieb:
>> Actel (jetzt microsemi?)
>
> Du wirst alt. Die heissen jetzt Microchip :-)
> https://www.microsemi.com/applications/motor-control

Ja, das liegt wohl in der Familie, meine Grosseltern haben sogar Tausend 
Jahre Reich komplett überlebt ;-)

--
Es gibt noch einige Möglichkeiten mehr, eine PWM zu erzeugen, der 
Klassiker ist wohl Rechteck mit nachgeschalteten Schmitt-Trigger:
https://www.strippenstrolch.de/1-3-17-opv-als-PWM-Generator.html

Die Schaltung der Schaltschwelle könnte man per Digital Poti machen.

der 555 kann auch seinen beitrag leisten: 
https://www.elektronik-kompendium.de/public/schaerer/pwm555.htm oder 
klassisches TTL-Grab


Statt FPGA geht auch CPLD quasi als Companion, der Controller muß halt 
nicht alles alleine machen, es genügt wenn er die eigentlichen 
Generatoren controlliert.

Natürlich gibt es auch dedizierte PWM-Chips. Oder man nimmt mehrere 
controller, die man zentral synchronisiert. Damit vereinfacht sich das 
Task-scheduling pro mikrocontroller.

Letzlich steht vor dem Coding der Systementwurf - welche parallele 
Prozesse müssen laufen, wohin wird kommuniziert, welche fehlzustände 
sind unbedingt aufzulösen.
Wenn das Konzept steht, ist die konkrete Implementierung schon fast 
zwangsläufig.

von Andreas Rückert (Gast)


Lesenswert?


von Boris (Gast)


Lesenswert?

Es gibt mittlerweile gute offene toolchains für lattice und xilinx. Die 
würde ich jederzeit der aufgeblasenen herstellersoftware vorziehen.

f4pga.org

von Andi (Gast)


Lesenswert?

Nimm doch einen RasPi Pico Prozessor. Der hat 2 CPUs und dazu noch 8 
programmierbare Pin State-Machines. Kostet fast nichts und ist gut 
erhältlich.

Wenn es dann doch ein FPGA sein soll, stellt sich die Frage ob du später 
ein eigenen Print machen willst und den FPGA Chip benötigst. Dann wirst 
du sehen, dass weder aktuelle Xilinx noch Intel noch Lattice FPGAs mit 
genügend Pins lieferbar sind. Eine Alternative ist Efinix, deren Chip 
man bekommt, und es gibt das  günstiges Xyloni Demo/Entwicklungsboard.
Ausserdem würde ich jedem Anfänger dazu raten mit Verilog anzufangen, 
nicht mit VHDL, das ist so viel einfacher und logischer.

Andi

von Lust L. (lust)


Lesenswert?

Andi schrieb:
> Wenn es dann doch ein FPGA sein soll

aus Interesse, mit der Absicht später mehr damit zu machen! Aber sicher 
nicht wegen dieser Anwendung. Wenn das zuviel für einen modernen AVR 
sein sollte (was ich nicht glaube) ist es allemal besser, sich statt in 
FPGAs in die ARM-Technik einzuarbeiten. Damit ist man zukünftig 
wesentlich flexibler.

von Fpgakuechle K. (Gast)


Lesenswert?

Lust L. schrieb:
>  ist es allemal besser, sich statt in
> FPGAs in die ARM-Technik einzuarbeiten. Damit ist man zukünftig
> wesentlich flexibler.

Nope, controller durch einen anderen conroller ersetzen bringt kaum was 
an flexibilität.
Flexibel wird man mit der Anzahl an beherrschten Interface/Peripherals. 
Und insbesonders wenn man diese Peripherals auch selbst 
entwerfen/adaptieren kann.

aber manche scheitern schon daran eine header-datei selbsr anzupassen, 
wenn ein neuer Baustein ein paar controlbits mehr mitbringt.

von JojoS (Gast)


Lesenswert?

Ein STM32F407 hat dafür auch genug Power, incl. Rampen berechnen im 
Interrupt und Display ansteuern:https://youtu.be/poZjMwRAcH8

Ansonsten macht grbl oder eine 3D-Drucker Hardware doch genau so was, 
Befehle über die serielle (beim Smoothieboard auch per Ethernet) 
empfangen und mehrere Achsen steuern, einfach per G-Code.

von J. S. (engineer) Benutzerseite


Lesenswert?

Marvin K. schrieb:
> Timer-Anzahl usw.
hm, wenn jemand nach der Zahl der Timer in FPGAs fragt, dann kann ich 
nur datzu raten, sich mal ganz grundsätzlich mit Digitaltechnik und 
programmierbarer Lokig auseinander zusetzen. Schon allein das Lesen des 
WIKI-Artikels in den ich und anderen Zeit reingesteckt haben, erledigt 
vorne weg 3 hier gemachte Annahmen in diesem thread über FPGAs und was 
man damit macht und wie ...

Cartman schrieb:
> orteil bei Intel/Altera: Die JTAG/Programmieradapter sind
> ausgesprochen guenstig zu bekommen
Die Chinaduplikate beim XI kosten auch nur 15,- :-)

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Marvin K. schrieb:
> Aber wenn das wirklich mit einem AVR umsetzbar ist, würde ich mit FPGAs
> doch nochmal warten bis dieses Projekt abgeschlossen ist.

Also für dich sieht die Alternative so aus: entweder AVR oder wenn das 
nicht reicht, dann ein FPGA.

Hmm... bei dieser Perspektive hast du noch so einiges an Lernstoff vor 
dir.

Wenn es dir jedoch eher um das Erlernen des Umganges mit 
programmierbarer Logik geht, dann fang lieber ohne dein o.g. Projekt mit 
dem Lernen an. Du kannst dir das Leben etwas leichter (und billiger) 
machen, wenn du für's Erste ein paar CPLD's benutzt. Vom Programmieren 
her - egal ob mit Verilog oder VHDL - ist das gleich, aber die CPLD's 
haben zumeist den Konfigurationsspeicher bereits mit drinnen auf dem 
Chip und das erspart dir die Hürde, einen seriellen Flash richtig an ein 
FPGA zu basteln oder dir ein teures Eval-Board zu kaufen und dich dann 
an allem zu orientieren, was da sonst noch auf dem Eval-Board drauf ist.

Bei der Gelegenheit kommt mir ein Bastel-Vorschlag: den ULA aus dem 
ZX-Spectrum durch ein CPLD ersetzen und damit einen ZX Spectrum basteln. 
Da kann man dann deutlich sehen, ob das klappt und es hat dann sogar 
noch einen nostalgischen Spiele-Nutzen.

W.S.

von Martin S. (strubi)


Lesenswert?

Boris schrieb:
> Es gibt mittlerweile gute offene toolchains für lattice und xilinx. Die
> würde ich jederzeit der aufgeblasenen herstellersoftware vorziehen.
>
> f4pga.org

Ahja, symbiflow is now f4fpga. Aendert nichts daran, dass das immer noch 
etwas mehr verspricht, als es ist.
Nennen sollte man eigentlich yosys, was ein beachtlich effektives 
Werkzeug geworden ist. Nichtsdestotrotz ist es eigentlich erst gerade 
seit einigen Wochen (offiziell) mit den Memory-Inference-Reparaturen 
vernuenftig fuer neuere Architekturen (ECP5) nutzbar.
Zum Lernen ist es nett, da man in die Synthese 'reingucken' kann. Aber 
gegen die  timing-optimierenden Mapper von Synplify kommt es nicht an, 
d.h. fuer ernstes High-Speed muss man haendisch optimieren, was man mit 
klassischem VHDL schon mal vergessen kann.

von No Y. (noy)


Lesenswert?

Nimm doch einen Parallax :-)
Oder wie hieß die andere Firma mit dem X welche so "spezial" uC 
anbietet?

von PittyJ (Gast)


Lesenswert?

Wenn ich genaues Timing brauche, dann baue ich öfter FPGAs ein.
Also eine normale kleine CPU (meist ein kleiner Arm), und dazu ein 
passendes FPGA.
Beide kommunizieren über SPI, das FPGA bekommt seine 'Anweisungen' und 
regelt dann alleine weiter.
Bei den FPGAs reicht dann oft eine kleines, mit wenig LUTs (<5000). 
Manchmal ist ein Spartan schon zu gross, dann wirds ein ICE von Lattice.
Mit dieser Trennung bin ich ganz gut gefahren.

Wenn man weiss, was man darin regeln möchte, kann man den FPGA-Code 
synthetisieren. Dann bekommt man mit wieviele LUTs benötigt werden. 
Danach wird eine FPGA-Version gewählt.

von Christoph Z. (christophz)


Lesenswert?

No Y. schrieb:
> Nimm doch einen Parallax :-)

Du meinst einen Propeller. Den gibt es ja netterweise als open source in 
Verilog.

> Oder wie hieß die andere Firma mit dem X welche so "spezial" uC
> anbietet?

Meinst du XMOS?
Sind aber weniger bekannt für Motoren und PWM sondern mehr für Audio, 
I2S, Ethernet AVB,...

von No Y. (noy)


Lesenswert?

Ne es ging darum, dass er ggf. auf den FPGA verzichten kann.

Mit einem Propeller oder mit einem XMOS uC (hier ging es darum, dass die 
ja auch uC mit vielen Cores haben) kann er für jeden seiner Kanäle einen 
eigenen Core "exklusiv" abstellen der sich nur um den einen Kanal 
kümmert.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Die ganzen Vorbehalte gegenüber Softcores kann ich nicht so ganz 
nachvollziehen. Wenn man sich an die durch das Entwurfswerkzeug der Wahl 
empfohlenen Cores hält, dann kann man diese recht einfach integrieren. 
In der Xilinx-Vivado-Welt wäre das dementsprechend ein Microblaze oder 
ein ein Microblaze MCS. Wenn man sich dann auch noch das Gerüst für den 
benötigten AXI-Peripherieblock mit dem entsprechenden Wizard generieren 
lässt, dann hat man schon einmal eine sehr ordentliche Grundlage.

Mein Tipp: den generierten Block nicht als separaten IP-Block verwenden, 
sondern die generierten Quellen als sog. HDL-Module direkt im 
Blockdesign einbinden. Dann kann nämlich alles in einem 
zusammenhängenden Projekt bearbeiten und erspart sich den Aufwand mit 
separaten IP-Projekten.

Das Debugging eines Microblaze funktioniert auch ganz passabel, d.h. die 
gemeinsame Nutzung einer JTAG-Verbindung für das Laden des 
FPGA-Bitstreams, das Hardware-Debugging mittels ILA und 
Software-Debugging mittels Vitis/GDB.

von Michelle P. (Gast)


Lesenswert?

Schau dir doch mal die ICEbreaker FPGA's an, ich denke diese sind 
hervorragend für den Einstieg geeignet. Zudem gibt es gute Open-Source 
Tools dafür, was im VLSI Bereich eher selten ist. 
(https://1bitsquared.com/products/icebreaker)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.