Hallo,
Ich beschäftige mich gerade mit Verilog und hatte mir die frage gestellt
obman FPGA's auch ohne gigabyte große IDE's wie quartus und co
programmieren kann. Zb. mit opensource tools wie iverilog.
Hat jemand damit erfahrung?
beste Grüße
Wozu? Quark!
Und wer soll eine open source Software produzieren, wenn die Hersteller
freie Software liefern? Heute ist Di und nicht Fr.!
Außerdem solltest Du mit dem Begriff "Programmieren" vorsichtig sein.
Viele alte Hasen aus der Hardwareecke sind allergisch gegen den Begriff.
Weltbester FPGA-Pongo schrieb im Beitrag #4684949:
> Viele alte Hasen aus der Hardwareecke sind allergisch gegen den Begriff.
Und noch viel allergischer bin ich gegen den Deppenapostroph... :-/
Weltbester FPGA-Pongo schrieb im Beitrag #4684949:
> wenn die Hersteller> freie Software liefern?
Du solltest mal mit dem Begriff "Freie Software" vorsichtig sein. Wenn
das die Übersetzung von "Freeware" seien sollte ist diese falsch. Die
Software ist nicht frei sondern kostenlos.
Da die Hersteller natürlich die Interna der FPGAs nicht herausrücken,
kommt man mit unabhängigen Tools höchstens bis zur Netzliste. Spätestens
dann musst du auf die Tools der Hersteller zugreifen.
verilogfreund schrieb:> Ich beschäftige mich gerade mit Verilog und hatte mir die frage gestellt> obman FPGA's auch ohne gigabyte große IDE's wie quartus und co> programmieren kann.
Klar bei xilinx kannst die IDE (ISE) weglassen und mit dem command line
Tools wie xst, map und par arbeiten arbeiten. Allerdings gibt es nur ein
Installationspaket für command line und IDE.
Christian R. schrieb:> Da die Hersteller natürlich die Interna der FPGAs nicht herausrücken,> kommt man mit unabhängigen Tools höchstens bis zur Netzliste. Spätestens> dann musst du auf die Tools der Hersteller zugreifen.
Ausser der Bitstream wird "reverse engineered" wie beim Projekt
Icestorm. Siehe Link im 3. Beitrag.
Die ICE40 FPGAs sind genug einfach aufgebaut so dass die Bedeutung all
der Konfigurationsbits entschlüsselt werden konnte.
Die OpenSource Toolchain enthält einen Verilog Compiler, ein Place &
Route Tool und den Bitstream Lader. Auch Timing Analyse ist möglich. Ein
VHDL Frontend ist in Arbeit.
Aufgrund der Verfügbarkeit dieser Toolchain wurden einige OSHW FPGA
Boards dafür entwickelt, siehe z.B. Olimex oder Icoboard.org.
Funktioniert aber auch mit Lattice Entwicklungsboards wie Icestick und
ICE40-Breakout.
Der Nachteil ist natürlich dass die ICE40 Bausteine eher kleine FPGAs
sind (max 8k LUTs) und nur wenig BlockRam haben. Auch DSPs sucht man
vergebens (die Ultra Serie wird noch nicht unterstützt).
Andi
Mir erschließt sich der Sinn noch nicht so ganz, warum da etwas reverse
engineered werden muss. Das System ist doch kaum ausgebaut, wird von
existenten Plattformen leicht getoppt!
Die meisten Xilinx FPGAs lassen sich mit XC3SPROG programmieren.
http://xc3sprog.sourceforge.net/
Der Vorteil hier, es werden mehre Programmer unterstützt.
René D. schrieb:> Die meisten Xilinx FPGAs lassen sich mit XC3SPROG programmieren.
Na ja, damit kannst die BIT Daten ins FPGA programmieren. Aber hier
gehts darum die BIT Datei zu erzeugen mit OpenSource Tools. Das
'programmieren' im Thread-Titel ist etwas irreführend, gemeint is mehr
Synthetisieren usw..
Thomas U. schrieb:> Mir erschließt sich der Sinn noch nicht so ganz, warum da etwas reverse> engineered werden muss. Das System ist doch kaum ausgebaut, wird von> existenten Plattformen leicht getoppt!
Ein paar Gründe die mir einfallen:
- Die Toolchain ist viel kleiner und Place and Route viel schneller.
- Man kann damit z.B. auch auf dem Rasperry Pi FPGA Entwicklung
betreiben.
- Man kann es als legales Backend für eigene HDL Sprachen oder grafische
Eingaben oder z.B. ein SOC Konfigurations-Tool nutzen.
- Funktioniert auch noch wenn der FPGA Hersteller plötzlich Geld
verlangt, oder Konkurs geht (gut, dann gibts die FPGAs auch bald nicht
mehr :-)
Andi
Thomas U. schrieb:> Mir erschließt sich der Sinn noch nicht so ganz, warum da etwas reverse> engineered werden muss. Das System ist doch kaum ausgebaut, wird von> existenten Plattformen leicht getoppt!
Es gibt da einige neuartige Ansätze, die es nicht mehr erfordern, über
schwerfällige Synthesetools oder VDHL/Verilog als Transfersprachen zu
gehen.
Das wird vor allem dann bei dynamischer Rekonfiguration interessant. Das
geht zwar m.W. mit den ICE40-Plattformen nicht, aber ich lass mich gerne
(auch was andere Hersteller angeht) eines besseren belehren.
Wird generell mal Zeit, dass die Bastion der P&R-Platzhirsche fällt,
damit die FPGA-Entwicklung mal den Fortschritt erfährt, der der
uC-Entwicklung nach GCC zugute kam.
Strubi schrieb:> Thomas U. schrieb:>> Mir erschließt sich der Sinn noch nicht so ganz, warum da etwas reverse>> engineered werden muss. Das System ist doch kaum ausgebaut, wird von>> existenten Plattformen leicht getoppt!>> Es gibt da einige neuartige Ansätze, die es nicht mehr erfordern, über> schwerfällige Synthesetools oder VDHL/Verilog als Transfersprachen zu> gehen.> Das wird vor allem dann bei dynamischer Rekonfiguration interessant. Das> geht zwar m.W. mit den ICE40-Plattformen nicht, aber ich lass mich gerne> (auch was andere Hersteller angeht) eines besseren belehren.> Wird generell mal Zeit, dass die Bastion der P&R-Platzhirsche fällt,> damit die FPGA-Entwicklung mal den Fortschritt erfährt, der der> uC-Entwicklung nach GCC zugute kam.
klingt wie N24
Strubi schrieb:> Wird generell mal Zeit, dass die Bastion der P&R-Platzhirsche fällt,> damit die FPGA-Entwicklung mal den Fortschritt erfährt, der der> uC-Entwicklung nach GCC zugute kam.
Das hat nur geklappt, weil der GCC schon zuvor auf dem PC sehr weit
verbreitet war und es da sicher Millionen Entwickler gibt die den GCC
einsetzen (und ggf. Bugs finden und melden).
Dementsprechend viele Entwickler+Firmen arbeiten am GCC...
FPGAs sind im Vergleich dazu ein absolutes Nischenprodukt (insb. was die
Zahl der Entwickler angeht) - aber die Entwicklung eines brauchbaren
"FPGA-GCCs" wäre ungleich komplexer...
Kontroller schrieb:> FPGAs sind im Vergleich dazu ein absolutes Nischenprodukt (insb. was die> Zahl der Entwickler angeht) - aber die Entwicklung eines brauchbaren> "FPGA-GCCs" wäre ungleich komplexer...
So isses! Man kann eigentlich froh sein, daß die Hersteller überhaupt
noch kostenlose tools rausrücken, die einigermassen funktionieren. Sowas
wie XST ist zwar nicht das Gelbe vom Ei, aber immerhin liefert es
brauchbare Ergebnisse. Wenn ich mir vorstelle, ich müsste mit open
source Produkten arbeiten, sehe ich schwarz.
GCC ist eine absolute Aussahme. Der meiste OS Kram ist so buggy wie nur
was!
Strubi schrieb:> Das wird vor allem dann bei dynamischer Rekonfiguration interessant. Das> geht zwar m.W. mit den ICE40-Plattformen nicht, aber ich lass mich gerne> (auch was andere Hersteller angeht) eines besseren belehren.
Kommt drauf an was du genau darunter verstehst. Die ICE40 HX können
unter mehreren Konfigurationen im externen Flash auswählen bei einem
"Warmboot". Die Bitdaten im Flash können durchaus vom FPGA selbst
überschrieben werden und dann eine Neukonfiguration ausgelöst werden.
Dabei entsteht aber ein kleiner Unterbruch von ein paar ms bis die neue
Konfiguration aktiv ist.
Bei ungültigen Bitdaten wird wieder die primäre Konfiguration geladen.
Andi
Moin,
Andi schrieb:> Strubi schrieb:>> Das wird vor allem dann bei dynamischer Rekonfiguration interessant. Das>> geht zwar m.W. mit den ICE40-Plattformen nicht, aber ich lass mich gerne>> (auch was andere Hersteller angeht) eines besseren belehren.>> Kommt drauf an was du genau darunter verstehst. Die ICE40 HX können> unter mehreren Konfigurationen im externen Flash auswählen bei einem> "Warmboot". Die Bitdaten im Flash können durchaus vom FPGA selbst> überschrieben werden und dann eine Neukonfiguration ausgelöst werden.> Dabei entsteht aber ein kleiner Unterbruch von ein paar ms bis die neue> Konfiguration aktiv ist.> Bei ungültigen Bitdaten wird wieder die primäre Konfiguration geladen.>
Den Unterbruch möchte ich halt eher nicht, sondern z.B. was wie zwei
unabhängig voneinander laufende Sektoren, wo Sektor A weiterlaufen kann,
während Sektor B neu konfiguriert wird. D.h. eine direkte
Neukonfiguration einzelner Zellen wie bei manchen Architekturen per
JTAG-Hack.
Was den "FPGA-GCC" angeht: Ich würde behaupten, dass die Entwicklung
weniger komplex wäre als ein optimierender Compiler, aber: Ich würde die
Finger vom GCC-Code lassen und eher LLVM angehen.
Prinzipiell kann aber die RTL des GCC auch HDL ausgeben. Habe ich schon
ausprobiert.
GCC macht halt nur da Sinn, wo jemand unbedingt High Level Synthese von
C Routinen nach FPGA möchte. Da auf OpenSource-Basis was zu machen, sehe
ich leider als recht aussichtslos, bisherige Projekte sind immer an den
div. Hochschulen verwaist.
Wo Opensource was zu reissen ist, ist an der Python-Front mit MyHDL und
Erweiterungen.
Apropos OpenSource: Wer sich mit VHDL rumschlägt und komplett
VHDL-Standardkonform simulieren möchte, kennt sicher GHDL und weiss es
zu schätzen. Es gibt also durchaus eine Menge OpenSource-Tools, die
weitaus robuster und brauchbarer sind als so einige
Hersteller-"Freeware".
Grüsse,
- Strubi
Weltbester FPGA-Pongo schrieb im Beitrag #4690907:
> Man kann eigentlich froh sein, daß die Hersteller überhaupt> noch kostenlose tools rausrücken, die einigermassen funktionieren.
Solange es Actel und Lattice gibt, müssen Altera und Xilinx in jedem
Fall wenigstens ihre kleinen FPGAs dem Markt zu konkurrentfähigen
Preisen verfügbar halten und das geht abseits des VK-Preises nur über
eine günstige tool chain: In den meisten Firmen, die ich kenne wird z.B.
Xilinx oft deshalb eingesetzt, weil den Entwicklern die tool chain
bekannt ist und das ist sie, weil sie in der Anfangszeit kostenlos damit
arbeiten konnten. Die allermeisten älteren erfahrenen Entwickler kennen
Xilinx, bei Altera sind es vielleicht noch 70%, mit Lattice haben
weniger, als 30% Erfahrung - von Actel ganz zu schweigen. Das sind
Exoten! Viele würden gerne manchmal z.B. Lattice einführen, bekommen
aber mit ihren eigenen Leuten Probleme, weil die das erst lernen müssen
und dann für 2 oder 3 toolchains das Knowhw halten müssen. Zudem kostet
das Einführen einer Software und neuer Bausteine einen gewissen
Qualifikationsaufwand und mindert die Stückzahl, was wieder die Kosten
hochtreibt.
Wer dem anderen was abgraben möchte, muss sich um Studenten und Anfänger
bemühen und darf keine Hürden in den Weg stellen. Das Beispiel von
Altera zeigt, dass der Weg funktioniert: Bei den jüngeren Entwicklern
ist Altera genau so gut bekannt und bei kleinen Firmen, die vor Kurzem
erst mit FPGAs angefangen haben, ist Altera mindestens so präsent wie
Xilnx. Und ein Grund ist, daß man seit Jahren bei Altera einen Modelsim
und einen Logic-Analyzer mit dabei hat.
Xilinx muss da gegenhalten und solange es einer tut, müssen es die
beiden auch!
Eine Gefahr sehe ich allerdings durch die Tendenz, die tools immer
mächtiger zu machen und viele embedded Themen und SOPC-Funktionen mit zu
integrieren. Ein so mächtiges tool ist noch so ohne Weiteres zu wechseln
von daher steigt die Abhängigkeit und wenn die Hersteller beginnen, die
Grenze zwischen dem, was man mit freien Versionen machen kann und dem,
wo es nicht mehr geht, nach unten zu verschieben, werden viele Firmen
mitgehen und lieber bezahlen, als zu wechseln. Es kann sein, dass sich
die Landschaft dann so langsam ausdünnt und Firmen dazu tendieren
werden, sich auf einen Hersteller zu konzentrieren.
Andererseits wollen die Hersteller ja mit ihren embedded FPGAs den
Prozessoren Konkurrenz machen. Wenn z.B. ein Vivado mit embedded
Unterstützung zu teuer wird, dann lohnt gfs. das Einführen einer
Zynq-Plattform nicht, oder die Hürde ist zu groß. Ich erwarte in naher
Zukunft nicht, daß die Hersteller die SW stärker kostenpflichtig machen.
Im Gegenteil: Momentan ist es ja eher so, daß die Möglichkeiten mit den
kostenlosen Versionen relativ wachsen!
> GCC ist eine absolute Aussnahme. Der meiste OS Kram ist so buggy wie nur> was!
Ein Problem ist, weil viele Softwareentwickler mal schnell was aus einer
Begeisterung heraus was zusammenklicken und eine Weile munter nach vorne
rennen, um das Projekt dann, wenn es schwieriger wird und in Details
geht, verwaisen zu lassen. Da muss man sich nur mal sourceforge und open
cores ansehen, was es da an unvollendeten Projekten gibt.
Andi schrieb:> Die Bitdaten im Flash können durchaus vom FPGA selbst> überschrieben werden und dann eine Neukonfiguration ausgelöst werden.
Das geht mit anderen FPGAs aber auch, solange das Flash
programmiertechnisch am FPGA hängt.
Eine andere Sache ist natürlich das hier:
uwe schrieb:> Reconfigurable computing, bei dem der Bitstream sich dynamisch selber> verändern kann je nach ergebnis des vorherigen Konfigurations bzw.> Berechnungszyklus.
Erinnert mich sehr an meine Assemblerprogramme aus den 80ern, die sich
selber verändert haben und richtig speedy waren. Tolle Sache das! Als
ich dann später in den Firmen angfangen haben, ASM zu tunen hat man mir
auf die Finger gehauen, weil das a) keiner verstand, b) keine pflegen
wollte und (als so in den 2000ern das Thema Qualifikation aufkam)
niemand zugelassen hätte.
Ähnlich sehe ich es mit den FPGAs:
Auch hier gibt es einen gestiegenen Qualifikationsaufwand und dieser
verhindert allein schon bei vielen "normalen" Methoden in Software (ich
sehe hier die FPGA-Funktion ausdrüclich als Software) eine industrielle
Verwendung - zumindest, was sicherheitskritische Bereiche angeht. Da
möchte sich erfahrungsgemäss keiner was ans Bein binden. Eher schon
werden FPGAs in ASICs gegossen und Checksummen geprüft, um
sicherzustellen, dass sich ja nix verändert und die Config korrekt
geladen wurde.
Ein Umkonfiguration im Betrieb erfordert ein permanent störungsfreies
Laden der Informationen und schafft daher massenweise zusätzliche
Spalten und Absätze in der Test-SPEC und der FMEA :-( Und Validierung
und Test sind ein oft vernachlässigter Aspekt bei Entwicklungen.
Technisch ist das natürlich eine feine Sache. Gerade bei der Umstellung
von Filtern, komplexeren Abläufen und auch Anpassung an Betriebsmodi
ginge da Einiges, besonders, wenn man an Resourcen-Limits kommt.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang