Hat einer gute Tutorials für FPGA?

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

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

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.

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

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.

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

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

Matthias schrieb:

Cortex A7

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

Duckundwech

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.

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.

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/

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.

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"

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.

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

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

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

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.

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

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

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

  }

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.

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

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.

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

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.

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

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.

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.

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

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

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

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

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

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

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.

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.

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?

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.

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

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

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

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.