mikrocontroller.net

Forum: FPGA, VHDL & Co. FPGA's programmieren mittels open source software


Autor: verilogfreund (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: foobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... :-/

Autor: Gustl B. (-gb-)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas U. (thomasu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die meisten Xilinx FPGAs lassen sich mit XC3SPROG programmieren.

http://xc3sprog.sourceforge.net/

Der Vorteil hier, es werden mehre Programmer unterstützt.

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Strubi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Tim (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Kontroller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Andi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas U. (thomasu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe es immer noch nicht: Wo liegt jetzt der Vorteil? Das 
Umkonfigurieren, das angeführt wurde, machen wir doch mit 
konventionellen FPGAs auch?

Autor: uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reconfigurable computing, bei dem der Bitstream sich dynamisch selber 
verändern kann je nach ergebnis des vorherigen Konfigurations bzw. 
Berechnungszyklus. Da gab es dann map tool mit source und placing tool 
mit source und JBits einen dynamischen Java Netzlistengenerator. Die 
konnten halt in einem Teil des FPGAs oder auf einem extra µC oder PC 
laufen und das FPGA ständig umkonfiguriere die Ergebnissse aus dem 
Bitstream zurücklesen und die Netlisten bzw funktion ständig anpassen.
Damit haben manche eine gewisse "Evolution" erzeugen wollen.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.5349&rep=rep1&type=pdf
Ist aber schon sehr akademisch...
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1227280&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F8700%2F27544%2F01227280.pdf%3Farnumber%3D1227280
http://www.iro.umontreal.ca/~feeley/papers/BergeronFeeleyDaigneaultDavidNEWCAS08.pdf
http://www.doc.ic.ac.uk/~tbecker/papers/iee06.pdf
https://www.computer.org/csdl/proceedings/fccm/2001/2667/00/26670251.pdf

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.