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
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
:
Bearbeitet durch User
> 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.
:
Bearbeitet durch User
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.
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
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
Angehängte Dateien:
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.
:
Bearbeitet durch User
> 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.
:
Bearbeitet durch User
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
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.
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?
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...
:
Bearbeitet durch User
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 ...
Beitrag #7672237 wurde von einem Moderator gelöscht.
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.
>> 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..
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.