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!
Angehängte Dateien:
-
ICE40Boot.png
65 KB
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
Ich sehe es immer noch nicht: Wo liegt jetzt der Vorteil? Das Umkonfigurieren, das angeführt wurde, machen wir doch mit konventionellen FPGAs auch?
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
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.
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.