Forum: FPGA, VHDL & Co. Hat einer gute Tutorials für FPGA?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Matthias (ahamatta)


Lesenswert?

Fragt mich nicht für was, aber in meiner Bestellwut hab ich mir noch ein 
Tang Nano 9k und ein Cortex A7 + RISC V RV1103 Dev Board besorgt...

: Verschoben durch Moderator
von Matthias (ahamatta)


Lesenswert?

Ich glaube ich weiß für was... um mir unnütz die Zeit mit 
Klosterarbeiten totzuschlagen!

von Vanye R. (vanye_rijan)


Lesenswert?

> Tang Nano 9k

Tja nun, wenn man billig kauft. Bei meinem Einsteigerkit vor xx Jahren 
war noch ein dickes Handbuch dabei das einem alles erklaert hat. War 
zwar in japanisch, aber da muss man sich dann mal etwas anstrengen.

Dafuer ist die chinesische Entwicklungsumgebung immerhin 10x besser und 
10x schneller wie das Zeug von Xilinx und laeuft sogar nativ unter 
Linux!

Vanye

von Peter (pittyj)


Lesenswert?

Wenn man zu viel Zeit hat.
Vielleicht das beste wäre, erst einmal chinesisch zu lernen. Dann kommt 
man mit den Original-Webseiten besser klar, und kann sich mit der 
Community austauschen. Damit ist man schon ein paar Jahre beschäftigt, 
und muss nichts zu Ablenkung kaufen.

Wenn immer noch zu viel Zeit da ist: ich habe noch einen Rasen, der mal 
gemäht werden müßte.

von Vanye R. (vanye_rijan)


Lesenswert?

> Vielleicht das beste wäre, erst einmal chinesisch zu lernen.

Muss man nicht. Programmiert wird ja in Verilog und die Oberflaechen
zwischen Xilinx und der von den Chinesen verwendeten 
Entwicklungsumgebung
sind sich sehr aehnlich. Und wegen der Schwupdizitaet macht das 
rumspielen mit dem chinesischen FPGA richtig spass. Bei Xilinx ist das 
immer wie ein Zahnarztbesuch.

Vanye

von Purzel H. (hacky)


Lesenswert?

Tutorials sollten Bezug auf die Tenologie plus die Programmierung 
nehmen.
Die Technologie ist halt im Fluss. Da hilft das Datenblatt des 
betreffenden Chips, resp das Family Manual,
Im Amerikaischen Raum wird zur Programmierung eher Verilog, und im 
europaeischen VHDL verwendet, beides Hochsprachen zur 
Problembeschreibung.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

Mit dem Zynq-book hat es seit einem Jahrzehnt eine gute Einführung in 
FPGA-SoC mit dem Zynq.

Aber der TO hat sich ja aus Geizgründen für eine andere Architektur und 
Entwicklungskultur entschieden ...

http://www.zynqbook.com/

Reine FPGA-books haben leider keinen Markt, deswegen erscheint da kaum 
noch was. Aber in einer gute Hochschulbibliothek sollte sich zumindest 
für die älteren System brauchbares finden lassen, bspw.: 
ISBN:978-3864901737 .

BTW: Falsches Unterforum
BTW2: 
https://www.google.com/search?q=Tang+Nano+site%3Amikrocontroller.net

: Bearbeitet durch User
von Vanye R. (vanye_rijan)


Lesenswert?

> Aber der TO hat sich ja aus Geizgründen für eine andere Architektur und
> Entwicklungskultur entschieden ...

Es gibt auch fuer die chinesische Entwicklumgebung ein englisches
Handbuch. Wenn man die liesst dann kann man die bedienen!

Und ja fuer Verilog/VHDL sollte man dann schon ein Buch lesen und
nicht glauben das von drei Internetseiten etwas abzuschreiben einen
dann schon erleuchten wird.
Was IMHO eher nicht hilft ist besuchen der Youtube-Universitaet. :-)

Vanye

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Matthias schrieb:
> Cortex A7

Endlich eine Gelegenheit ein eigenes RTOS für einen richtigen 
Prozessor zu schreiben!

Duckundwech

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

Vanye R. schrieb:

> Und ja fuer Verilog/VHDL sollte man dann schon ein Buch lesen und
> nicht glauben das von drei Internetseiten etwas abzuschreiben einen
> dann schon erleuchten wird.

VHDL/Verilog ist höchstens ein Fünftel der FPGA-Kunde, dazu kommt 
Schaltungstechnik und Computerarchitektur. Digitale Signalverarbeitung 
ist auch essentiell, wobei man viel von den grundlagen/Theorien im 
Bedarfsfall zumindest nachlesen kann. Wenn ich mal aus dem Studium die 
(unmittelbar) FPGA-relevanten Themen und ihren Umfang in 
Semesterwochenstunden aufliste:

* Digitale Signalverarbeitung I :      45
* Analoge/Digitale Schaltungen :      210
* Informations- und Codierungstheorie: 30
* Computeror. Num Mathematik I:        60
* Hardware der Personalcomputer:       90
* Digitale Signalverarbeitung II       30
* Digitale Systeme                     60
* Mikrorechentechnik                   45
* Fehlerreduktionssystem               45
* Computeror. Num Mathematik II:       60
* Schaltkreisentwurf                   45

* Systementw. /Hardwarebeschreibung    45

Natürlich überschnitt sich einiges und die Analogtechnik kann man auch 
zum teil aus der Schaltungstechnik rausrechnen. Aber letztlich ist FPGA 
schon ein ziemlicher Know-How-Brocken der eher auf eine 
Hochschul-Ingenieursausbildung passt, als das er sich aus 
Tutorialgeblättere nebenher ergibt.

: Bearbeitet durch User
von Andi (chefdesigner)


Lesenswert?

Bradward B. schrieb:
> Semesterwochenstunden
An dem Begriff habe ich mich immer schon gestoßen!

Was da aufgelistet ist, sind Wochenstunden pro Semester!

Am Ende herauskommen sollten Stunden. Nach der Tabelle etwa ~700.

Veranschlagt man das Selbststudium mit 70% Effizienz -> 1000h Lernen.
Learning by doing = 50% -> 2000h -> 1 Jahr FPGA.

Und dann hat man die Grundlagen drauf.

Bradward B. schrieb:
> Tutorialgeblättere
das ist kein Ersatz, sondern kommt hinzu. Man muss sich in die konkreten 
Chips einlesen.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

A. F. schrieb:
> Bradward B. schrieb:
>> Semesterwochenstunden
> An dem Begriff habe ich mich immer schon gestoßen!
>
> Was da aufgelistet ist, sind Wochenstunden pro Semester!

Es sind die Präsenzstunden also Vorlesung u.ä.. 30 SWS heisst, das im 
Semster Wochenplan eine Doppelstunde (90 min) drinstand. Also ein 
semester = 15 Wochen = 15x Vorlesung. Nicht in diesem Plan steht das 
Selbststudium und Prüfings-, Praktikumsvorbereitung. Dafür kann je nach 
Enthusiasmus ein mehrfaches der Vorlesungsstunden "drauf gehen".


> Veranschlagt man das Selbststudium mit 70% Effizienz -> 1000h Lernen.
> Learning by doing = 50% -> 2000h -> 1 Jahr FPGA.
>
> Und dann hat man die Grundlagen drauf.

Naja, etwas hemdsärmelig aber im Grunde passt so etwa, nach 1 Jahr 
sollte man in der lage sein, selbstständig FPGA_designs fertigzukriegen.

> das ist kein Ersatz, sondern kommt hinzu. Man muss sich in die konkreten
> Chips einlesen.

Eher "einspielen", statt lediglich "einlesen". Also ein paar Testdesigns 
neben dem datasheet-Studium durchimplementieren und mit den Optionen 
rumspielen.
Das geht relativ schnell wenn man einmal einen FPGA-Architektur 
verstanden hat. Kann aber immer noch4-8Wochen dauern um bspw. vonAltera 
auf Xilinx umzusatteln.

: Bearbeitet durch User
von Oliver D. (unixconf)


Lesenswert?

ich mag den TangNano-9K,
schön um mal mit FPGA's zu spielen ohne viel ausgeben zu müssen :)

Toolchain läuft auch unter Linux und ist mit Makefile's nutzbar.


https://learn.lushaylabs.com/tang-nano-series/

https://github.com/sipeed/TangNano-9K-example

https://wiki.sipeed.com/hardware/en/tang/Tang-Nano-9K/Tang-nano-9k.html

https://github.com/lushaylabs/tangnano9k-series-examples


EDIT: achso, ganz wichtig: https://www.fpga4fun.com/

: Bearbeitet durch User
von Jürgen S. (engineer) Benutzerseite


Angehängte Dateien:

Lesenswert?

Bradward B. schrieb:
> Naja, etwas hemdsärmelig aber im Grunde passt so etwa, nach 1 Jahr
> sollte man in der lage sein, selbstständig FPGA_designs fertigzukriegen.
Die Frage ist, WAS man dann kann. VHDL lernt man in 20-50h. Aber in das 
FPGA muss ja auch etwas rein, ansonsten ist das Bastel-Anspruch wie wir 
das  als 10-Jährige mit Elektronik-Steckkästen gemacht haben.

Bradward B. schrieb:
> Nicht in diesem Plan steht das
> Selbststudium und Prüfings-, Praktikumsvorbereitung.
An der Uni nähert man sich dem Thema FPGA und Signalverarbeitung 
eigentlich von zwei Seiten: Mathematik (links) und Elektronik (rechts).
Wenn man die Grundlagen drauf hat, geht es an die Details. FPGAs durchs 
Ausprobieren zu erlernen, halte ich für unproduktiv und nutzlos. Ich 
sehe das tagtäglich, wozu das führt:

Schnell ein SOC zusammengeklickt und fertig ist der Computer. Das ist 
aber oberflächlich und führt zu Wissen, mit dem man wenig anfangen kann 
und das auch wenig Grundlage bietet, um darauf etwas aufzusetzen. Der 
FPGA braucht ja eine Elektronik-Umgebung mitsamt Physik und soll ja auch 
etwas tun.

Meines Erachtens muss man da immer bei den Grundlagen anfangen und nicht 
beim fertigen Rechnersystem.

Richtig wäre es, man beginnt mit Mathe, arbeitet sich über abstrakte 
Modelle zum Berechnen von analogen und digitalen Schaltungen und der 
Messtechnik vor. Über MATLAB, Simulink und pSICE kommt man dann zur 
Signalverarbeitung. Parallel dazu laufen die analogen und digitalen 
Schaltungen, Rechnermodelle und Architekturen und gfs. nach "unten" in 
Richtung Halbleiterphysik sowie nach "oben" in Richtung Microprozessoren 
/ embeeded.

Frühestens dann hat man die Strukturen und Methoden parat,  um etwas 
Wertiges zu erzeugen. Dann kann man auch FPGAs irgendwo reinsetzen, 
anschließen und etwas reinprogrammieren. Das geht aber nicht in 1-2 
Jahren. Das Wissen umfasst von der Menge her etwa das 5-10 fache dessen, 
was man an der Uni lernt und ohne das eine oder andere Fachbuch ist das 
kaum was zu erreichen. Man kann nicht alles selber erfinden - schon 
allein von der Zeit her nicht.

Was FPGAs angeht, gibt es über VHDL hinaus durchaus genug gute Bücher, 
die die Schaltungsmodellierung, die geschickte Simulation und die 
Umsetzung in ASICs und Computer-Systeme beschreiben. (3. Bild links). 
Für den Anfänger würde ich z.B. das Kleitz/Pearson empfehlen.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Das Bild ist stark verkleinert worden, daher:

Lüke "Signalverarbeitung"
Meyer "Signalverarbeitung"
Oppenheim "Zeitdiskrete Signalverarbeitung"
Kammeyer "digitale Signalverarbeitung"
Gonzales Woods "Digital Image Processing"
Woods "FPGA-based implementation of signal processing"

Kleitz "Digital Electronic with VHDL" - Altera Edition / Pearson
Ashenden - System to Silicon - "Designers Guide to VHDL"
TenHagen "Abstrakte Modellierung von Schaltungen"
Gessler / Mahr "Hardware / Software Codesign"

und wer Analoges in VHDL modellieren will:

M Davis "Analyse linearer Schaltung"
und den bekannten Tietze Schenk "HL Schaltungstechnik"

von Veit D. (devil-elec)


Lesenswert?

Hallo,

wenn ich mit FPGA anfangen würde wollen, dann würde ich mir vielleicht 
das Buch + Board kaufen. https://www.bombini-verlag.de/shop/fpga/ Ob das 
am Ende wirklich zum Ziel führt weiß ich nicht, wäre jedoch ein Einstieg 
was ich so sehe. Den Gedanken FPGA zu programmieren hatte ich einmal 
gehabt als Arduino ein FPGA Board herausgebracht hatte. Habe den 
Gedanken aber schnell wieder verworfen.

von Vanye R. (vanye_rijan)


Lesenswert?

> wenn ich mit FPGA anfangen würde wollen, dann würde ich mir vielleicht
> das Buch + Board kaufen.

Also bei mir hat es das. Bloss das dieses Kit ein Geburtatsgeschenk der 
Freundin war und halt in japanisch weil in Japan gekauft :-)
Aber ja das ist etwas hilfreich weil ja alle Beispiele sofort 
funktionieren und der Autor weiss wie die Zielhardware des Lesers 
aussieht.

Nachteilig ist vielleicht das man glaubt am Anfang weniger ueber 
Elektronik allgemein wissen zu muessen. Was eine grosse 
Fehleinschaetzung ist. Das war aber bei mir zum Glueck nicht gegeben 
weil ich lange vorher schon mit diskreten Gattern, Registern usw 
rumgespielt hatte.

> Den Gedanken FPGA zu programmieren hatte ich einmal
> gehabt als Arduino ein FPGA Board herausgebracht hatte. Habe den
> Gedanken aber schnell wieder verworfen.

Das Problem eines FPGAs aus der Sicht eines Bastler der mal irgendwas 
damit machen will, ist eigentlich das es nur wenig, und mit steigender 
Rechnenleistung heutiger Mikrocontroller weiter sinkende, 
Anwendungsmoeglichkeiten gibt. Also woraus will man dann seine 
Motivation ziehen?

In der letzen c't hat Till Harbaum sich ja vom Palmpiloten<BG> der 
Spieleemulation auf FPGAs zugewandt. (ganz interessant) Das ist
gerade auch so eine der wenigen Anwendungen die mir einfallen wuerde.

Und dazu kommt dann noch das fuer alles krasse Signaltheoretische das 
einem noch einfallen will dann halt das Nachrichtentechnikstudium ein 
Teil der notwendigen Grundlagen wird. Das liegt dann aber nicht am FPGA 
als solchem, sondern das halt die Anwendungen wo er unabdingbar wird 
schon sehr komplex sind.

Vanye

von Matthias (ahamatta)


Lesenswert?

Das erscheint mir alles bissl kompliziert.

Ich dachte, man spielt da das Programm auf, was das Teil verschaltet und 
dann schiebt man am Eingang was rein und dann kommt Ausgang was raus??

von Matthias (ahamatta)


Lesenswert?

Also so für den Anfang vllt. die Standard-Logikgatter? Das müsste doch 
in einem Wochenende funktionieren, ohne das jahrelang zu studieren??

von Thomas H. (thomash2)


Lesenswert?

Schwierig wird's wenn man höhere Geschwindigkeiten benötigt und den Chip 
auch preislich optimiert (also das günstigste Teil für die Tätigkeit 
einsetzt).
Dann muss man sich auch mit den Rules auseinandersetzen und den 
verschiedenen Synthesis Software-Versionen. Auch muss man das Verhalten 
im Rest der Schaltung genau testen. Hatte da mit LatticeSemi einige 
Unterhaltungen bezüglich Software-Versionen..
Sich genau in einen Chip und seine speziellen Features und Optionen/auch 
optionen der Design Software einzuarbeiten kann sehr lange dauern.
Die Simulation an sich hilft einen ein bißchen, aber selbst wenn diese 
korrekt ist heißt dass noch nicht dass das Design im Rest der Schaltung 
funktioniert.
Bezüglich der Optimierung hilft es auch wenn man die erzeugte Schaltung 
visuell überprüft (sofern die Software das darstellen kann).

Interessant wird's dann wenn man für die Schaltung Verantwortung 
übernehmen muss also das Projekt in Masse verkauft wird und das Teil OTP 
(one time programmable ist). Dann bloß keinen Fehler haben.

Einfach mal ein einfaches Gatter implementieren schafft man an einem 
Tag.

Habe unter anderem dieses Buch:
https://www.amazon.de/Circuit-Design-Simulation-VHDL-Press/dp/0262014335

es ist nichts besonderes, würde auch sagen dass ich 75% anderswo gelernt 
habe, aber Bücher durchblättern ist auch nicht schlecht je mehr Themen 
sie behandeln desto besser.
Ich denke in dem Buch wird kein Wort über die Rules erwähnt, das Thema 
welches mir am Anfang die größten Probleme bereitet hat.

: Bearbeitet durch User
von Vanye R. (vanye_rijan)


Lesenswert?

> Also so für den Anfang vllt. die Standard-Logikgatter? Das müsste doch
> in einem Wochenende funktionieren, ohne das jahrelang zu studieren??

Ja, solange du nur ein And-Gatter brauchst dann ist das auch so.

Wobei du aber hier schon das Look&Feel der charmanten 
Entwicklungsumgebungen
lernen musst, dich fuer eine Sprache entscheiden musst und ein paar 
Grundlagen ueber analoge Schaltungstechnik drauf haben musst weil FPGAs 
halt rattenschnell sind und entsprechend Wert auf ihre Anschluesse, also 
Leitungslaengen, Terminierung, Ausgangsports, Entkopplung/Groundbounce, 
Logiclevel legen.

Also ja es ist einfach.

Aber sobald du auch nur schon ein Register brauchst musst du dich schlau
machen was getacktet und ungetacktet so bedeutet und warum das wichtig 
ist.


Vanye

von Thomas H. (thomash2)


Lesenswert?

Auch Themen wie CDC / Clock Domain Crossing...
Diesbezüglich steht in dem oben erwähnten Buch überhaupt nichts drinnen.

: Bearbeitet durch User
von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

Matthias schrieb:
> Also so für den Anfang vllt. die Standard-Logikgatter?

Da kannst auch gleich ein Standard-Logikgatter TI 74HX*** statt einen 
FPGA verlöten, es sollte schon was "Getaktetes" sein. Das klassische 
Einstiegsproblem ist eine kleine Statemaschine, eventuell noch mit 
counter -Blinkerschaltung am Ford Thunderbird: 
http://learntechnologytips.blogspot.com/2012/04/fsm-vhdl-lab-code-for-thunderbird-turn.html

Und man sollte nicht nur den Verilog/VHDL Code schreiben sondern auch 
das constraintfile fürs Pinout/IO-Setting und ein kleines 
makefile/tcl-script für die toolchain mit programmierung. Erst dann hat 
man so halbwegs kapiert, was der Unterschied zwischen FPGA und µC ist.

Anbei ein gekürztes built-tcl für Vivado (nur FPGA, kein SoC-Anteil):
1
set ROOT_FLOW_DIR  "./../"
2
3
#working dirs temporary files
4
set WORKDIR_SIM   $ROOT_FLOW_DIR/work/var_sim/work
5
set WORKDIR_SYN   $ROOT_FLOW_DIR/work
6
7
#Directories with VHDL source files and or Netlists
8
#SRC_DIR_VHDL      = $(CVS_DIR)/src_vhdl
9
#cvs depot
10
set SRC_DIR_VHDL    "./../../../.."
11
set SRC_DIR_SPEC    "../src/"
12
13
#directory for USEFUL output files (reports and files for programming)
14
set DIR_RESULTS    $ROOT_FLOW_DIR/results
15
set DIR_REPORTS    $ROOT_FLOW_DIR/reports
16
17
set progDir    "./../programming_file"
18
set outputDir    "./../log"
19
20
# all VHDL files for synthesis
21
proc proc_readallvhdl {} {
22
    variable SRC_DIR_VHDL
23
    variable SRC_DIR_SPEC
24
    
25
        read_vhdl -library work          $SRC_DIR_VHDL/src/vhdl/RAM16X1D.vhd 
26
        read_vhdl -library work                $SRC_DIR_SPEC/clock/dcm_sys.vhd  
27
28
}
29
30
proc proc_regenallip {} {
31
    variable SRC_DIR_VHDL
32
    variable SRC_DIR_SPEC
33
    #clock manager  
34
#                read_ip      $SRC_DIR_VHDL/Core/fifo_15x8.xco
35
  read_ip $SRC_DIR_SPEC/clock/clk_wiz_0.xci
36
    generate_target all [get_ips clk_wiz_0]
37
38
                #fifo (as used in command uart)
39
#    import_ip  -files $src_path/CoresGenerated/fifo256x9_bram/fifo256x9_bram.xci -name fifo256x9_bram
40
#                generate_target all [get_ips fifo256x9_bram]
41
#                synth_ip [get_ips fifo256x9_bram]
42
                #do write *.tlx
43
}
44
45
proc proc_readallxdc {} {
46
    variable SRC_DIR_SPEC
47
    read_xdc $SRC_DIR_SPEC/constraints/Zybo_master.xdc
48
}
49
50
51
#FPGA specific settings#
52
53
#type of fpge chip (family,size,package,speedgrad)
54
set PARTNAME       "XC7Z010-1CLG400"
55
56
#procedures  compilation#
57
58
#Do high level synthesis  
59
proc proc_dosynth {} {
60
  variable DIR_REPORTS
61
  variable PARTNAME
62
63
  #synth_design -top redz0mb1e -part $PARTNAME -verbose  -flatten_hierarchy full
64
    synth_design -top zybo_top -part $PARTNAME -verbose  -flatten_hierarchy full
65
  
66
  write_checkpoint -force $DIR_REPORTS/post_synth.dcp
67
  #just reports
68
  report_timing_summary -file $DIR_REPORTS/post_synth_timing_summary.rpt
69
  report_utilization -file $DIR_REPORTS/post_synth_util.rpt
70
  }
71
72
# STEP#3: run synthesis, write design checkpoint, report timing,
73
# and utilization estimates
74
75
###do final steps after synthesis for implementation
76
proc proc_doimpl {} {
77
    variable progDir 
78
    opt_design
79
#  implement_debug_core
80
81
    #probe list for ila -> *.ltx  
82
#  write_debug_probes -force $progDir/ila_uart.ltx
83
  #power_opt_design
84
    place_design
85
  #phys_opt_design
86
  route_design
87
  }
88
89
proc proc_doreport {} {
90
     variable DIR_REPORTS
91
  #focus on location constraints for all
92
  report_io -file $DIR_REPORTS/report_io_sites.txt
93
94
    #check if IO_pad FF are used
95
  report_datasheet -show_oe_timing -significant_digits 2 -file $DIR_REPORTS/report_io_timing.txt
96
     
97
    #check for free resources (FF, LUT, ..) 
98
  report_utilization -file $DIR_REPORTS/report_utilization.txt
99
100
    #check drc ist mainly used while setting up built flow 
101
  report_drc -file $DIR_REPORTS/report_drc.txt
102
103
  #check for maximum speed 
104
  report_timing_summary -file $DIR_REPORTS/report_timing.txt 
105
}
106
107
108
proc proc_progfiles {} {
109
  variable progDir
110
111
  # *.bit for plain (volatile) fpga programming
112
  write_bitstream  -force  -mask_file $progDir/roic_sim.bit
113
    # *.mcs for flash (non-volatile) programming
114
  write_cfgmem -force  -format mcs -size 32 -interface SPIx4 -loadbit [list up 0x00000000 $progDir/roic_sim.bit ] -file $progDir/roic_sim.mcs
115
  }

: Bearbeitet durch User
von Martin S. (strubi)


Lesenswert?

Matthias schrieb:
> Also so für den Anfang vllt. die Standard-Logikgatter? Das müsste
> doch
> in einem Wochenende funktionieren, ohne das jahrelang zu studieren??

Ja. Typischerweise/leider scheint die einfache Herangehensweise nicht im 
Fokus der klassischen deutschsprachigen Lehre, obwohl es immer mal 
wieder Ansaetze gibt (siehe auch 'VHDP'-Threads).
Wenn du Python/Englisch kannst und mit yosys synthetisierst, gibts 
interaktive Tutorials in Form von Jupyter Notebooks. Da gehts erst mal 
nur darum, Logik zu generieren und das Resultat zu erforschen, sprich 
Syntheseergebnis anschauen, simulieren, in Verilog/VHDL ausgeben, etc.
Teil 1 findest du hier zum angucken (Link mit beschraenkter 
Lebensdauer): 
https://gist.github.com/hackfin/9e24e487c9162d95ca4412a05c89292e

Fuers Interaktive zum Spielen brauchst du den Binder ("launch binder" im 
README hier: https://github.com/hackfin/cyrite.howto/tree/master)

Fuer dein Brettl gibts leider kein fertiges Board Supply Package, aber 
fuer Trockendock-Uebungen mit dem Simulator braucht man eigentlich gar 
keine Hardware.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Matthias schrieb:
> Fragt mich nicht für was, aber in meiner Bestellwut hab ich mir
> noch ein
> Tang Nano 9k und ein Cortex A7 + RISC V RV1103 Dev Board besorgt...

Das sind fuer dich prima Boards, um z.B. bei einem Tisch mit einem zu 
kurzen Bein das Wackeln abzustellen. Geschreddert kannst du sie auch im 
Winter gut als Ersatz fuer Split bei Glatteis hernehmen.
Ich denke mal, irgendwelches tcl-foo bringt dich da nicht so viel weiter 
wie ein solide stehender Tisch oder ein sicher gestreuter Weg vorm Haus, 
das sollte man einfach realistisch sehen.

Gruss
WK

von Oliver D. (unixconf)


Lesenswert?

Dergute W. schrieb:
> Das sind fuer dich prima Boards, um z.B. bei einem Tisch mit einem zu
> kurzen Bein das Wackeln abzustellen.

was ein quatsch, der TangNano ist nicht nur ein super FPGA um mal rein 
zu schnuppern sondern auch produktiv einsetzbar.

Ich habe mehrere CNC's die mit dem TangNano9K laufen, es muss nicht 
immer ein überteuerter US-Chip sein.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Oliver D. schrieb:
> Dergute W. schrieb:
>> Das sind fuer dich prima Boards, um z.B. bei einem Tisch mit einem zu
>> kurzen Bein das Wackeln abzustellen.
>
> was ein quatsch, der TangNano ist nicht nur ein super FPGA um mal rein
> zu schnuppern sondern auch produktiv einsetzbar.
>
> Ich habe mehrere CNC's die mit dem TangNano9K laufen, es muss nicht
> immer ein überteuerter US-Chip sein.

Kleines Problem mit dem Verstehen von Texten?

scnr,
WK

von Oliver D. (unixconf)


Lesenswert?

Dergute W. schrieb:
> Kleines Problem mit dem Verstehen von Texten?

anscheint, klär mich bitte auf :)

für mich hörte es sich so an als wären die teile müll und nur als 
'briefbeschwerer' zu gebrauchen.

von Vanye R. (vanye_rijan)


Lesenswert?

> Ich habe mehrere CNC's die mit dem TangNano9K laufen, es muss nicht
> immer ein überteuerter US-Chip sein.

Ich finde die eigentlich sogar besser als Xilinx/Altera, allerdings 
fragt
man sich ob man, oder jemand anders, die professionell einsetzen 
will/wird und wie es da mit einer laengerfristigen Verfuegbarkeit 
aussieht.
Immerhin, so mein Eindruck, scheinen sich ja die grossen aus dem Markt 
mit kleinen EinsteigerFPGAs eher zurueckzuziehen und dafuer jede Menge 
chinesische Buden und eine aus Koeln da reinzuspringen.

Andererseits, wenn die niemand in Stueckzahlen einsetzt wird es die 
nicht lange geben. Wobei das einem Bastler mit einem Projekt natuerlich 
egal sein kann.

Vanye

von Oliver D. (unixconf)


Lesenswert?

Vanye R. schrieb:
> Ich finde die eigentlich sogar besser als Xilinx/Altera, allerdings
> fragt
> man sich ob man, oder jemand anders, die professionell einsetzen
> will/wird und wie es da mit einer laengerfristigen Verfuegbarkeit
> aussieht.

das problem hat man überall, ich denke mal das die chinesen
gerne unabhängig sind und daher schon genug bedarf an den teilen haben.

Aber ja, für bastler-projekte ist es relativ egal und verilog ist 
erstaunlich plattformunabhängig wenn man nichts spezielles macht,
kann auch jederzeit auf einen anderen FPGA wechseln.

von Sim (Gast)


Lesenswert?

Peter schrieb:
> Wenn immer noch zu viel Zeit da ist: ich habe noch einen Rasen, der mal
> gemäht werden müßte.

Ich guck mal in den Widderstand - Ok, eine Ziege wär noch da, wann?

von Matthias (ahamatta)


Lesenswert?

Oliver D. schrieb:
> Vanye R. schrieb:
>> Ich finde die eigentlich sogar besser als Xilinx/Altera, allerdings
>> fragt
>> man sich ob man, oder jemand anders, die professionell einsetzen
>> will/wird und wie es da mit einer laengerfristigen Verfuegbarkeit
>> aussieht.
>
> das problem hat man überall, ich denke mal das die chinesen
> gerne unabhängig sind und daher schon genug bedarf an den teilen haben.
>
> Aber ja, für bastler-projekte ist es relativ egal und verilog ist
> erstaunlich plattformunabhängig wenn man nichts spezielles macht,
> kann auch jederzeit auf einen anderen FPGA wechseln.

Was habt ihr gegen die Chinesen? Fast mein ganzes Spielzeug kommt aus 
Asien.

von Vanye R. (vanye_rijan)


Lesenswert?

> Was habt ihr gegen die Chinesen? Fast mein ganzes Spielzeug kommt aus
> Asien.

Die Buden sind noch zu neu, man fragt sich ob die fuer eine uebliche
Produktlebensdauer von 10Jahren liefern koennen. Aber okay, bei FPGA
vermutlich sowieso immer etwas kritisch.

Vanye

von Matthias (ahamatta)


Lesenswert?

Vanye R. schrieb:
>> Was habt ihr gegen die Chinesen? Fast mein ganzes Spielzeug kommt aus
>> Asien.
>
> Die Buden sind noch zu neu, man fragt sich ob die fuer eine uebliche
> Produktlebensdauer von 10Jahren liefern koennen. Aber okay, bei FPGA
> vermutlich sowieso immer etwas kritisch.
>
> Vanye

Naja, als die Suchfunzel neu war, wurde auf jede Frage im Forum mit 
LMGTFY geantwortet.

Ähnliches bei den sozialen Netzwerken und neuerdings bei der KI.

Das Argument ist also bissl so hingebogen wie man es gerne hätte...

: Bearbeitet durch User
von Matthias (ahamatta)


Lesenswert?

Sei es drum, wir müssen mal wieder zur Technik zurückkommen.

Mit Politik, Gesetzen und Geschwafel geht es wirtschaftlich ganz sicher 
bergab.

von Foobar (asdfasd)


Lesenswert?

Matthias schrieb:
> Also so für den Anfang vllt. die Standard-Logikgatter? Das müsste doch
> in einem Wochenende funktionieren, ohne das jahrelang zu studieren??

Ein Wochenende reicht für die alten PALs/GALs.  Die waren von der 
Struktur her einfach aufgebaut (etwas Kombinatorik, Ausgangsregister, 
Feedback), die Software (z.B. PALASM) war simpel (Pins zuordnen, eine 
boolsche Gleichung pro Pin, fertig).  Durch die kurzen 
turn-around-Zeiten auch gut zum Experimentieren/Ausprobieren geeignet. 
Die waren als Ersatz für Standard-Gatter gedacht - statt 2-5 TTLs ein 
PAL/GAL.

FPGAs sind aber ein anderes Kaliber - einige Größenordnungen komplexer, 
sowohl von der HW als auch von der SW.  Damit baut man keine 
"Standard-Logikgatter", damit baut man komplexe Systeme - statt 2-5 
Platinen ein FPGA.  FPGAs setzt man ein, wenn es anders nicht mehr geht 
/ sinnvoll ist.

Ich konnte FPGAs nie was abgewinnen: sind/waren schweineteuer, ebenso 
die proprietäre SW (offene/freie gibt es nicht) und sie war grottig 
(schnarchlangsam, komplex, buggy. ein über Jahrzehnte angesammeltes 
Durcheinander verschiedener Tools, die mit TCL mehr oder weniger 
schlecht zusammengehalten werden).  Und jeder Hersteller kochte zwecks 
Kundenbindung sein eigenes Süppchen.  Dazu kommt meine (unqualifizierte) 
Meinung, dass ich VHDL/Verilog als Beschreibungssprache für digitale 
Schaltungen eher ungeeignet/umständlich empfinde - das Cobol der HDLs. 
Zum Glück war ich nie in der Situation, dass FPGAs zwingend notwendig 
waren ...

Beitrag #7672237 wurde von einem Moderator gelöscht.
von Andi (chefdesigner)


Lesenswert?

Veit D. schrieb:
> Buch + Board kaufen. https://www.bombini-verlag.de/shop/fpga/

Das Bombonizeug wurde hier letztens ziemlich verrissen. Ist mehr 
Spielerei. Lieber ein Fachbuch oder ein Seminar bei einem 
Schulungsanbieter.

Das preisgünstige ist immer noch ein Hochschulbesuch.
Gerne auch nebenher.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

>> Buch + Board kaufen. https://www.bombini-verlag.de/shop/fpga/
>
> Das Bombonizeug wurde hier letztens ziemlich verrissen.

Link zu "hier" ist: Beitrag "neues FPGA buch: "FPGA für alle""

IMHO weniger hämisch-diabolischer Verriss als realistsische Einschätzung 
des Buch-Nutzens aus Sicht verschiedener Anwendergruppen.

https://de.wikipedia.org/wiki/Verriss

von Oliver D. (unixconf)


Lesenswert?

Foobar schrieb:
> Ich konnte FPGAs nie was abgewinnen: sind/waren schweineteuer, ebenso
> die proprietäre SW (offene/freie gibt es nicht) und sie war grottig
> (schnarchlangsam, komplex, buggy. ein über Jahrzehnte angesammeltes
> Durcheinander verschiedener Tools, die mit TCL mehr oder weniger
> schlecht zusammengehalten werden).  Und jeder Hersteller kochte zwecks
> Kundenbindung sein eigenes Süppchen.  Dazu kommt meine (unqualifizierte)
> Meinung, dass ich VHDL/Verilog als Beschreibungssprache für digitale
> Schaltungen eher ungeeignet/umständlich empfinde - das Cobol der HDLs.
> Zum Glück war ich nie in der Situation, dass FPGAs zwingend notwendig
> waren ...

Heut zu tage bekommt man FPGA's recht günstig, es gibt freie tools wie 
yosys/nextpnr und wenn man Makefiles nutzt muss man sich auch nicht mit 
den proprietären IDE's auseinander setzten.

von Martin S. (strubi)


Lesenswert?

Foobar schrieb:
> Ich konnte FPGAs nie was abgewinnen: sind/waren schweineteuer, ebenso
> die proprietäre SW (offene/freie gibt es nicht) und sie war grottig
> (schnarchlangsam, komplex, buggy. ein über Jahrzehnte angesammeltes
> Durcheinander verschiedener Tools, die mit TCL mehr oder weniger
> schlecht zusammengehalten werden).  Und jeder Hersteller kochte zwecks
> Kundenbindung sein eigenes Süppchen.  Dazu kommt meine (unqualifizierte)
> Meinung, dass ich VHDL/Verilog als Beschreibungssprache für digitale
> Schaltungen eher ungeeignet/umständlich empfinde - das Cobol der HDLs.

Da hat sich in 20 Jahren einiges getan, mit einer Ausnahme:
- Yosys wurde ja schon genannt
- In meiner Anwendung ist das FPGA halb so teuer wie ein entsprechender 
SoC und hat die bessere Betriebssicherheit.
- Wenns den Chip nicht mehr gibt, steht schon der naechste FPGA-Kandidat 
fest, der das gleiche kann

Nun die Ausnahme: Was die HDL angeht, stimmt deine Analyse wohl. Ich 
wuerde es allerdings so sehen: die V*-Sprachen braucht man allenfalls 
noch zum Interfacing und Transfer nach Sim/Syn. Analog zum bare-metal 
'OS', wo man nach wie vor eine crt0.s in Assembler stricken muss, aber 
nicht mehr der volle Befehlssatz gelernt werden muss.
So sollte es auch sein, damit man sich voll auf Design und Test der HW 
fokussieren kann, anstatt sich mit Unzulaenglichkeiten der Sprache und 
Tools herumschlagen zu muessen.
Das ist dann die Crux der Hochschulen: beim Interview stellt sich bei 
vielen Einserkandidaten raus, dass sie VHDL koennen, aber kein 
Reverse-Engineering/Debugging.

Das liegt u.a. auch an gezieltem Lobbyismus der Industrie, wie an THs 
schon ein gewisses Vendor-Lock-in zu betreiben. Die Berkeley-Tools gehen 
da schon lange einen offeneren Weg, und hier in Europa bricht nun yosys 
hoffentlich die Bastion.

von Foobar (asdfasd)


Lesenswert?

Martin schrieb:
> - Yosys wurde ja schon genannt

Mir scheint, da werden nur relativ alte/einfache/kleine FPGAs 
unterstützt (ICE40, MachXO, etc).

> - In meiner Anwendung ist das FPGA halb so teuer wie ein entsprechender
> SoC

Auch hier mag meine Erfahrung veraltet sein, aber ist es nicht so, dass 
du froh bist, deine synthetisierte CPU mit 100MHz ans Rennen bekommen zu 
haben während der SoC mit 1.5GHz bei einem Bruchteil des Stromverbrauch 
läuft?

von Martin S. (strubi)


Lesenswert?

Foobar schrieb:
> Mir scheint, da werden nur relativ alte/einfache/kleine FPGAs
> unterstützt (ICE40, MachXO, etc).

Der Lattice ECP5 ist jetzt nicht gerade klein und die Kintexe sind nach 
oben ja recht offen.

Foobar schrieb:
> Auch hier mag meine Erfahrung veraltet sein, aber ist es nicht so, dass
> du froh bist, deine synthetisierte CPU mit 100MHz ans Rennen bekommen zu
> haben während der SoC mit 1.5GHz bei einem Bruchteil des Stromverbrauch
> läuft?

Der Stromverbrauch ist unter Vollast niedriger wie beim SoC mit 1.2 GHz: 
150 mA (50mA davon der Ethernet Phy). Ich brauche halt einfach kein 
Linux, was den vollen SoC-Aufwasch erfordern wuerde, runde vielfache von 
27 MHz (...) reichen voll aus.
Der Trick an der ganzen Sache ist, von der klassischen 
Hardware/Software-Denke wegzukommen, d.h. gut verzahntes Coprocessing 
loest eine Menge Probleme, gerade wenn es um Echtzeit und unnoetigen 
SoC-Ballast geht.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Martin S. schrieb:
> Foobar schrieb:
>> ist es nicht so, dass du froh bist, deine synthetisierte CPU
>> mit 100MHz ans Rennen bekommen zu haben, während der SoC
>> mit 1.5GHz bei einem Bruchteil des Stromverbrauch läuft?
>
> Der Stromverbrauch ist unter Vollast niedriger,
> wie beim SoC mit 1.2 GHz: 150 mA

Das kann man so nicht direkt vergleichen, ohne eine Applikation zu 
benennen.

Grundsätzlich ist es aber nicht das Ziel mit dem FPGA eine CPU oder eine 
programmierbare FSM zu bauen und dann sequenzielle Aktionen zu machen. 
Wer das als Vergleichsapplikation ansetzt, wird immer mit der CPU als 
Sieger heraus kommen und zwar was den Strom und auch das Tempo angeht!

Anders sieht es aus, wenn man die FSM pipelined und damit mehrkanalig 
macht: Dann gewinnt der FPGA (auch bei 200 MHz gegen 4GHz) ab einer 
gewissen Kanalzahl das Temporennen, d.h. er schafft eine höhere 
Loop-Geschwindigkeit und damit Bandbreite. Das Stromproblem bleibt.

Wenn man sehr schnelle Signale prozessieren will, z.B. mehrkanalig PDM, 
SPDIF dann gewinnt der FPGA schon mal das Kostenrennen und meistens auch 
das Stromrennen. Mit einem $5 FPGA kann man z.B. 16 PDM ADCs mit 20MHz 
auf kleinstem Raum dezimieren und filtern. Da hält keine MCU/CPU mit.

Noch ärger sieht es aus, wenn man Anwendungen dem FPGA auf das Leib 
schneidert, also genau die Kanalzahl baut, die sich perfekt ins Gefüge 
der Raum-Zeit-Konstellation einpasst. Da sind FPGA schon seit 20 Jahren 
an den CPUs vorbei: http://www.96khz.org/oldpages/fpgaadvantage.htm

von Vanye R. (vanye_rijan)


Lesenswert?

> FPGAs sind aber ein anderes Kaliber - einige Größenordnungen komplexer,
> sowohl von der HW als auch von der SW.

Das stimmt natuerlich, aber es hindert einem ja keiner daran nur
1% vom Inhalt eines FPGA zu nutzen wenn die nur preiswert genug
sind.
Schaut mal: 5.80Euro Mouser Einzelpreis und kein BGA:

https://www.mouser.de/ProductDetail/GOWIN-Semiconductor/GW1N-LV1LQ144C5-I4?qs=wnTfsH77Xs4XqnskL9uWqw%3D%3D

Da kommt man doch ins gruebeln oder?

> Wenn man sehr schnelle Signale prozessieren will, z.B. mehrkanalig
> PDM, SPDIF

Also SPDIF haette ich vor 20Jahren auch noch gesagt, bzw. war das der 
Grund wieso mich damals FPGA interessiert hat. Aber mittlerweile sehe 
ich in erstaunlich vielen MCUs SPDIF integriert wobei gleichzeitig mein 
Interesse an SPDIF stark nachgelassen hat.

Vanye

von Martin S. (strubi)


Lesenswert?

Jürgen S. schrieb:
> Das kann man so nicht direkt vergleichen, ohne eine Applikation zu
> benennen.

Man kann. Es ist eine Streaming-Anwendung bei der Messwerte komprimiert 
und per RTP versendet werden ('netpp node'). Das gleiche System tickert 
in einer IP-Kamera und versendet MJPEG-Videos (Stromverbrauch da etwas 
hoeher).

Die eigentliche CPU ist ziemlich schmalbruestig und macht bloss 
Konfiguration/Fernsteuerung und Event-Handling. Wie gesagt, man muss von 
der Differenzierung in HW/SW weggkommen. Die Rechen-Pipeline ist ein 
sequentiell lesbares Python-'Programm', was daraus generiert wird (Code, 
Microcode, HW-Elemente), entscheidet ein 'HLS'-layer.

Bei Sachen, die sich schlecht in der Hardware clocksynchron (mit dem 
Datenclock) pipelinen lassen, macht die SW-Loesung allerdings in der 
Praxis schon oefters die bessere Nummer, aber auch da kommen dann 
Coprozessoren wie eine VPU zum Zug, damit der ARM nicht zuviel roedelt. 
Die Art der Poweroptimierung ist aber mindestens so aufwendig wie beim 
FPGA, wenns nicht was fertiges aus der 'lib' gibt.

Aber wir driften wieder in OT ab..

von Andi (chefdesigner)


Lesenswert?

Foobar schrieb:
> Ich konnte FPGAs nie was abgewinnen: sind/waren schweineteuer
Was baut ihr denn so für Sachen, wenn ihr ohne FPGAs auskommen könnt???

Vanye R. schrieb:
> Das stimmt natuerlich, aber es hindert einem ja keiner daran nur
> 1% vom Inhalt eines FPGA zu nutzen wenn die nur preiswert genug
> sind.
Wir haben laufen irgendwelche $3,-FPGAs in der Schaltung, schon um 
irgendwelche IOs zu managen und zu multiplexen. Durch die vielen 
Signalstandards in FPGAs kannst du an praktisch jede Peripherie andocken 
und hast Hunderte Pins frei für CPU-IFs.

Vor allem gibt es in FPGAs dann kleine Zwischenspeicher, die den Wert am 
Ausgang halten und einen CPU-Reset überleben und sich selbst auch 
intelligent managen können, wenn die nicht mehr kommen sollte.

Auch I2C-Management, automatisches freiclocken und Abfragen von Sensoren 
geht mit einem einzigen FPGA in maximaler Geschwindigkeit, ohne mit 
einer CPU und irgendwelchen Interrupts herumeiern zu müssen.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Martin S. schrieb:
> Jürgen S. schrieb:
>> Das kann man so nicht direkt vergleichen, ohne eine Applikation zu
>> benennen.
>
> Man kann. Es ist eine Streaming-Anwendung bei der Messwerte komprimiert
> und per RTP versendet werden

Jetzt hast ja doch eine konkrete Anwendung genannt. :-) Und zwar eine, 
die nicht unbedingt perfekt für einen reinen FPGA ist.

Das meinte ich nämlich: Je heterogener eine Anwendung, desto schwieriger 
ist es, einzuschätzen, ob sich der Einsatz eines FPGA überhaupt lohnt.

Martin S. schrieb:
> macht die SW-Loesung allerdings in der
> Praxis schon oefters die bessere Nummer, aber auch da kommen dann
> Coprozessoren wie eine VPU zum Zug, damit der ARM nicht zuviel roedelt.
Was eine SW in vorgegebener Zeit (für eine vorgegebene Anzahl an 
Prozesses = Kanälen) schafft, wird ein FPGA nie toppen. Er ist immer 
teuerer und stromfressender.

Bei dem Thema des TE " Tutorials für FPGA?" Sehe ich aber die 
programmierbare Logik als Ziel. Von daher würde ich das Thema CPU mal 
zur Seite schieben.

Vanye R. schrieb:
> Also SPDIF haette ich vor 20Jahren auch noch gesagt, bzw. war das der
> Grund wieso mich damals FPGA interessiert hat. Aber mittlerweile sehe
> ich in erstaunlich vielen MCUs SPDIF integriert
Das ist bei mir ganz ähnlich. Damals gab es das einfach so gut wie nicht 
und S/PDIF war weit verbreitet. Ich nutze es allerdings heute noch und 
zwar bis zum maximalen, was der FPGA hergibt -> konkret 4 Stereo-Kanäle 
TDM mit 768kHz ("pseudo ADAT") oder 64 S/PDIF-MIDI Kanäle mit je 48kHz - 
jeweils mit einer einzigen LVDS-Leitung zwischen den FPGAs.

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.