Hallo, gibt es eine generische Toolchain um CPLDs mit VHDL unter Linux zu entwickeln? Sowas in der Art wie avr gcc. Ich möchte mir für einfache Schaltungen keine 4 GB Windows IDE antun und wir haben hier auch meistens nur Linuxrechner. Kennt da jemand was gutes?
:
Verschoben durch Moderator
"Project IceStorm aims at reverse engineering and documenting the bitstream format of Lattice iCE40 FPGAs" Ich steige grade erst in CPLD und FPGA ein. Bisher habe ich nur mit attinys und atmegas gearbeitet. Da hat mir sehr gefallen, dass der ganze Assemblercode sauber von Atmel dokumentiert wurde und quasi jeder seine eigene Toolchain schreiben konnte, wenn jemand unbedingt wollte. Das hier liest sich aber eher so, als ob jeder Hersteller alles geheim hält und man entweder mit den IDEs arbeiten sollte, oder es sonst besser bleiben lassen sollte... ???
>gibt es eine generische Toolchain um CPLDs mit VHDL unter Linux zu >entwickeln? Welche CPLDs? >Ich möchte mir für einfache >Schaltungen keine 4 GB Windows IDE antun und wir haben hier auch >meistens nur Linuxrechner. Ihr habt also auch Windows PCs. Warum sollte man die nicht nutzen? 4GB sind auf modernen SSDs doch nur ein Katzenschiss.
Jan schrieb: > Hallo, > > gibt es eine generische Toolchain Generisch geht bei CPLD/FPGA und CO. mal gar nichts. Alles Herstellerspezifisch. > um CPLDs mit VHDL unter Linux zu > entwickeln? Sowas in der Art wie avr gcc. Ich möchte mir für einfache > Schaltungen keine 4 GB Windows IDE antun und wir haben hier auch > meistens nur Linuxrechner. Bleibt halt die Frage ob man ohne Not auf die Features der Windows IDE verzichten will. Will man sicher keine grafische Netzliste (Schaltplan), Floorplan, Device Explorer etc. etc. Ganz abgesehen von einem ordentlichen Simulator? avr-gcc nutzen die meisten Leute ja auch mit einer IDE. Hast du dir die Windows Tools überhaupt angesehen bevor du drauf spuckst? > http://www.clifford.at/icestorm/ Ja das ist halt so ne klassische Linux Sache nech? Ich meine nichts gegen die Kommandozeile und die typische Webseite im Charme der frühen 90er Jahre, aber will man damit WIRKLICH produktiv CPLD entwickeln? Klar das sind keine FPGAs aber trotzdem. > Ich steige grade erst in CPLD und FPGA ein. Fange mit den Windows Tools an. Und wenn du danach wirklich sagst: "Boa DAS würde ich jetzt echt gerne auf der Kommandozeile mit Reverse Engineerten Frickletools machen", dann steige um. Ich denke aber eher du dankst Bill Gates auf Knien für die Windows Tools. >Bisher habe ich nur mit > attinys und atmegas gearbeitet. Da hat mir sehr gefallen, dass der ganze > Assemblercode sauber von Atmel dokumentiert wurde und quasi jeder seine > eigene Toolchain schreiben konnte, wenn jemand unbedingt wollte. Okeeee
:
Bearbeitet durch User
Also die Toolchains von den 3 großen FPGA/CPLD Herstellern, Xilinx, Altera/Intel, Lattice laufen auch unter Linux.
Cyblord -. schrieb: > Ich denke aber eher du dankst Bill Gates auf Knien für die Windows > Tools. Bill Gates danke ich da erstmal gar nicht. Das schönste ist, wenn man unverkennbar sieht, dass eine CPLD-IDE mit darunter liegender Toolchain mal auf einem Unixoiden entwickelt wurde, aber öffentlich nur für Windows angeboten wird. Wegen Kompatibilität und so. Lachhaft.
Herr Torvalds schrieb: > Das schönste ist, wenn man unverkennbar sieht, dass eine CPLD-IDE mit > darunter liegender Toolchain mal auf einem Unixoiden entwickelt wurde, > aber öffentlich nur für Windows angeboten wird. Wegen Kompatibilität und > so. Lachhaft. Und welche soll das sein?
Ich nutze schon seit einpaar Jahren für die XC95 von Xilinx ein "ausgeschlachtetes" WebPack (7.1) welches ungefähr 700MB belegt. Das Verzeichnis habe ich im Laufe der Jahre mittlerweile auf den 4.Laptop kopiert, zusätzlich muss man nur die /etc/ld.so.conf ergänzen und muss ggf. noch ein paar 32-Bit Kompatibilitäts-Bibliotheken über den Paketmanager installieren. Und dazu ein eigenes Script: http://www.jcwolfram.de/projekte/cpldlinux/main.php Das kann man auch via Makefile aufrufen, als Programmer nutze ich aber inzwischen meinen eigenen (UPROG2). Jörg
Cyblord -. schrieb: > Bleibt halt die Frage ob man ohne Not auf die Features der Windows IDE > verzichten will. Will man sicher keine grafische Netzliste (Schaltplan), > Floorplan, Device Explorer etc. etc. > Ganz abgesehen von einem ordentlichen Simulator? Cyblord -. schrieb: > Ich denke aber eher du dankst Bill Gates auf Knien für die Windows > Tools. So ein Blödsinn. Alle namhaften Hersteller bieten Ihre Entwicklungswerkzeuge nicht nur für Windows, sondern auch und gerade für Linux an. Schaut man unter die Haube der Windows-Werkzeuge, findet man bei jedem deutlich "unixoide" Elemente. Jedes mir bekannte solche Tool basiert z.B. entweder auf Cygwin oder benutzt es zumindest irgendwo. Warum man ausgerechnet Bill Gates (der gegen solcherlei Tun immer mal wieder in schmutzige Kriege zog) dafür danken sollte, will mir so gar nicht einleuchten.
Angehängte Dateien:
-
Quartus181_Ubuntu.png
11 KB -
FPGA_Ubuntu1904.png
100 KB
Ich habe vor einem halben Jahr Quartus 18.1 unter Ubuntu installiert. Ein Projekt mit EPM1270 das mit der Windows-Version gelaufen war lief jedenfalls anstandslos durch, mehr habe ich noch nicht probiert. Allerdings hat schon das tar-File 6,6 GByte. In den offiziellen Ubuntu-Paketquellen ist nur das oben genannte icestorm enthalten, hier die Fundstellen von synaptic mit Suchbegriff "FPGA". Für "CPLD" findet es nur den JTAG-Programmer.
Ich kenne keine FPGA toolchain, die nicht unter Linux läuft. Nur muss man oft dafuer die vom Hersteller empfohlen Distribution einsetzen (bei jedem eine andere). Wir haben deswegen alles im Docker container installiert, einmal gemacht, geht es schnell mit Einrichten. Schau mal hier: https://www.reddit.com/r/FPGA/comments/bk8b3n/dockerizing_xilinx_tools/ https://section5.ch/index.php/2017/01/20/669/ https://github.com/Gekkio/docker-fpga/tree/master Nur darf man die Docker images nicht offiziell verteilen. Auf Firmenserver ist es kein Problem.
Noch vergessen: Es gibt Projekte die alles mit Makefile bauen. Da brauchst du die IDE nicht. Such mal auf github.
Viele Programme für Chip- oder FPGA-Entwurf gehen bis in die 80er und 90er zurück und wurden damals für UNIX entwickelt. Erst später als PC so langsam die Leistung von UNIX-Workstationen erreichten wurden diese Programme nach Linux (einfach) und Windows (aufwendig) portiert. Altera verwendet in den aktuellen Quartusversionen Qt5 um leicht Windows und Linuxversionen anbieten zu können. In der neuesten Pro braucht die Nios-Toolchain sogar das Windows Subsystem for Linux aus den neueren W10 Versionen. Andererseits gibts es den Advanced Link Analyzer nur für Windows. Xilinx scheint in der ISE auch Qt zu verwenden. Vivado wahrscheinlich auch. Ebenso Lattice mit ICEcube und Radiant. Microsemi Libero ist ebenfalls für Windows und Linux erhältlich. Gibt es überhaupt irgendwas aus diesem Bereich nur für Windows oder Linux?
Blechbieger schrieb: > Xilinx scheint in der ISE auch Qt zu verwenden. Vivado wahrscheinlich > auch. Korrekt. Blechbieger schrieb: > Gibt es überhaupt irgendwas aus diesem Bereich nur für Windows oder > Linux? Der HDL Simulator von Aldec macht nur Windows mit. Sehr aergerlich wenn man Lattice Diamond unter Linux nutzt, die der integrierte Simulator praktisch von Aldec ist.
Blechbieger schrieb: > Viele Programme für Chip- oder FPGA-Entwurf gehen bis in die 80er und > 90er zurück und wurden damals für UNIX entwickelt. Erst später als PC so > langsam die Leistung von UNIX-Workstationen erreichten wurden diese > Programme nach Linux (einfach) und Windows (aufwendig) portiert. Hab ich anders in Erinnerung, der Linux-Port kam deutlich später als der DOS/Windows-Port, jedenfalls bei Xilinx. Xilinx hat auch die verwendeten GUI-library gewechselt, QT war da nicht der erste Versuch. Auf Windows wie auf Linux ist die Xilinx GUI recht absturzfreudig (gewesen?), bei Pin-Planner hatte man den Eindruck, das der ein 30 minuten Crash timeout fest eingebaut hat. Insgesamt fährt man deutlich besser, wenn man die GUI meidet resp. durch scripte ersetzt.
>Der HDL Simulator von Aldec macht nur Windows mit. Sehr aergerlich wenn >man Lattice Diamond unter Linux nutzt, die der integrierte Simulator >praktisch von Aldec ist. gtkwave als Ersatz ist nicht schlecht: Beitrag "GHDL und gtkwave Grundlagen"
Tobias B. schrieb: > Der HDL Simulator von Aldec macht nur Windows mit. Sehr aergerlich wenn > man Lattice Diamond unter Linux nutzt, die der integrierte Simulator > praktisch von Aldec ist. Diese Aussage ist für den Endnutzer im Prinzip richtig. Lattice liefert als Simulator Active-HDL von Aldec mit, der nur für Windows verfügbar ist. Von Aldec gibt es aber auch den teureren Riviera Simulator der sowohl unter Linux und Windows läuft. Herr Torvalds schrieb: > Das schönste ist, wenn man unverkennbar sieht, dass eine CPLD-IDE mit > darunter liegender Toolchain mal auf einem Unixoiden entwickelt wurde, > aber öffentlich nur für Windows angeboten wird. - ISE benutzt Cygwin - Vivado benutzt MSYS (is a collection of GNU utilities such as bash, make, gawk and grep to allow building of applications and programs which depend on traditionally UNIX tools to be present) - Synopsis Identify RTL debugger (vergleichbar mit Xilinx Chipscope, bei Microsemi Libero SoC dabei) installiert gtkwave :-)
Cyblord -. schrieb: >> http://www.clifford.at/icestorm/ > > Ja das ist halt so ne klassische Linux Sache nech? Ich meine nichts > gegen die Kommandozeile und die typische Webseite im Charme der frühen > 90er Jahre, aber will man damit WIRKLICH produktiv CPLD entwickeln? > Klar das sind keine FPGAs aber trotzdem. Klar sind das FPGAs. Unter Linux ist Icestorm die einfachste und schnellste Art mit ICE40 und ECP5 FPGAs zu arbeiten. Allerdings wird nur Verilog (mit ein paar System-Verilog Erweiterungen) unterstützt. Zur Simulation gibt's Icarus und Verilator, die nicht zu Icestorm gehören.
Es gibt keine offene Toolchain für CPLDs. Für FPGAs gibt es SymbiFlow (https://symbiflow.github.io/) als übergeordnetes Projekt. Das baut auf Yosys, IceStorm etc. auf. Der Rest ist eine Sache des Reverse Engineerings - für Xilinx Artix-7 gibt es auch ein Projekt. Aber das ist durch die Komplexität ein paar Größenordnungen schwieriger als bei den ICE40....
Angeblich kann Yosys schon seit einiger Zeit den Coolrunner-2 CPLD. Ich hab es nie ausprobiert. http://www.clifford.at/yosys/cmd_synth_coolrunner2.html
Carl schrieb: >>Der HDL Simulator von Aldec macht nur Windows mit. Sehr aergerlich wenn >>man Lattice Diamond unter Linux nutzt, die der integrierte Simulator >>praktisch von Aldec ist. > > gtkwave als Ersatz ist nicht schlecht: > > Beitrag "GHDL und gtkwave Grundlagen" Naja, zum Entwickeln taugt das nicht wirklich. Da verwend eich am liebsten von Mentor Questasim. Aber GDHL Im Docker Container fuer automatisierte Unit-Tests sind eine feine Sache. :-) Christophz schrieb: > Diese Aussage ist für den Endnutzer im Prinzip richtig. Lattice liefert > als Simulator Active-HDL von Aldec mit, der nur für Windows verfügbar > ist. Von Aldec gibt es aber auch den teureren Riviera Simulator der > sowohl unter Linux und Windows läuft. Das ist korrekt. Ist zwar schade, aber jetzt kein Neckbreaker um auf Lattice zu verzichten. Ein Vorteil hats: Man bekommt die Vertriebler am Telefon relativ einfach abgewimmelt - "Kein Linux Support? Uninteressant. Aber sonst haette ich mir das gerne angeschaut." ;-)
>Unter Linux ist Icestorm die einfachste und schnellste Art mit ICE40 und >ECP5 FPGAs zu arbeiten. Kann man für die synthetisieren und flashen?: http://www.gnarlygrey.com/?i=1 >Naja, zum Entwickeln taugt das nicht wirklich. Da verwend eich am >liebsten von Mentor Questasim. Wieso nicht? GHDL kompiliert unglaublich schnell, damit entwickelt man kleinere Schaltungen fast wie mit einem C-Compiler/Simulator.
Carl schrieb: > Wieso nicht? GHDL kompiliert unglaublich schnell, damit entwickelt man > kleinere Schaltungen fast wie mit einem C-Compiler/Simulator. Muhahaha, die Compilezeiten sind die geringste Ursache, warum bei C-Programmierer das FPGA-Programmieren Ewigkeiten dauert.
Carl schrieb: > Kann man für die synthetisieren und flashen?: > > http://www.gnarlygrey.com/?i=1 Ja, mit dem Upduino 2 geht das relativ einfach, da dort auch der FTDI Chip mit drauf ist. Hier ein Link mit einfachen Beispielen und Beschreibung zum Einstieg: https://github.com/osresearch/up5k Man ist bei Icestorm und Co nicht unbedingt auf Kommandozeile und Makefiles angewiesen, es gibt z.B. auch das Icestudio, eine IDE bei der man fertige Blöcke grafisch verbindet. Man kann auch eigene Blöcke (=Module) mit Verilog erstellen. https://github.com/FPGAwars/icestudio Allerdings geht nicht ganz alles, was die Lattice Tools bieten, und vor allem sind die Ergebnisse nicht ganz so schnell und benötigen oft mehr LUTs. Dagegen sind mit den OpenSource Tools auch Dinge möglich, die Lattice bewusst verhindert.
Danke für die Links. Andi schrieb: >Allerdings geht nicht ganz alles, was die Lattice Tools bieten, und vor >allem sind die Ergebnisse nicht ganz so schnell und benötigen oft mehr >LUTs. Das klingt beunruhigend. Was geht nicht? >Dagegen sind mit den OpenSource Tools auch Dinge möglich, die >Lattice bewusst verhindert. Das wiederum klingt spannend. Was könnte man den mehr machen, als mit den Tools?
Jan schrieb: > gibt es eine generische Toolchain um CPLDs mit VHDL unter Linux zu > entwickeln? Es gibt keine generischen CPLD's, sondern nur spezielle - und die eigentlich nur von Xilinx. Andere Chips z.B. Mach von Lattice sind m.W. eigentlich FPGA's und keine CPLD's. Und die Altera MAX "CPLD's" sind definitiv keine CPLD's, sondern FPGA's - und sie sind vergleichsweise langsam. Und weil es eben keine generischen CPLD's gibt, gibt es auch keine generischen Toolchains dafür, sondern nur die vom jeweiligen Hersteller. > Kennt da jemand was gutes? Entweder wirst du bei dem von dir gewählten Hersteller fündig oder du muß dir für kleines Geld nen gebrauchten Windows-PC zulegen. Billiger wird's nicht. Ich würde für Xilinx-CPLD's einfach ne ISE-10.x installieren, die läuft stabiler als die noch älteren Versionen und sie ist noch nicht so unsäglich fett wie die späteren ISE's. Für CPLD's reicht sie allemal aus. Und da fast alles in der ISE per TCL gemacht wird, vermute ich mal, daß die ganze ISE auch unter wine läuft. W.S.
W.S. schrieb: > Es gibt keine generischen CPLD's, sondern nur spezielle - und die > eigentlich nur von Xilinx. Andere Chips z.B. Mach von Lattice sind m.W. > eigentlich FPGA's und keine CPLD's. Und die Altera MAX "CPLD's" sind > definitiv keine CPLD's, sondern FPGA's - und sie sind vergleichsweise > langsam. Die Frage ist ob der TO wirklich echte CPLDs möchte, oder ob es einfach nur darum geht mit kleineren / einfacheren Bauteilen in das Thema programmierbare Logik einzusteigen. Wenn es um letzteres geht, würde ich nicht nach echten CPLDs schauen, sondern nach FPGAs. Denn die echten CPLDs sind generell ältere Designs die langsam für neue Designs nicht mehr empfohlen werden. Neu entwickelt werden von den Herstellern eigentlich nur noch FPGAs. Ob die kleineren davon dann von den Marketingabteilungen als CPLDs gelabelt werden oder nicht ist davon unabhängig.
Hans schrieb: > Andi schrieb: >>Allerdings geht nicht ganz alles, was die Lattice Tools bieten, und vor >>allem sind die Ergebnisse nicht ganz so schnell und benötigen oft mehr >>LUTs. > > Das klingt beunruhigend. Was geht nicht? Ich bin mir jeweils nicht sicher, ob es nicht geht, oder einfach die Beschreibung fehlt. Wenn man beim Author nachfragt, hat er meist eine Lösung, oder baut es in die nächste Version ein. Es ist wohl einfach eine Frage der Zeit. Aber was man vermisst sind die einfachen Konfiguriermöglichkeiten der Pins und Wizards für oft verwendete IPs. Auch die Performance hat sich mit dem neuen Place and Route verbessert, erreicht aber noch nicht die von Lattice. >>Dagegen sind mit den OpenSource Tools auch Dinge möglich, die >>Lattice bewusst verhindert. > > Das wiederum klingt spannend. Was könnte man den mehr machen, als mit > den Tools? Zum Beispiel sind die DSP Blöcke im UltraPlus nicht ganz fehlerfrei. Lattice lässt darum nur einige getestete DSP Konfigurationen zu. Mit Icestorm kann man alle Konfigurationsbits einstellen, wie man will, und muss dann halt selber testen ob's auch funktioniert. Und es funktioniert mehr als Lattice meint. Oft verkauft ein Hersteller den selben Chip in verschiedenen Versionen, wobei die kleineren Versionen nur vom Tool künstlich beschränkt werden. Das OpenSource Tool kennt solche marketing-getriebenen Beschränkungen nicht.
Andi schrieb: > Zum Beispiel sind die DSP Blöcke im UltraPlus nicht ganz fehlerfrei. > Lattice lässt darum nur einige getestete DSP Konfigurationen zu. Mit > Icestorm kann man alle Konfigurationsbits einstellen, wie man will, und > muss dann halt selber testen ob's auch funktioniert. Und es funktioniert > mehr als Lattice meint. Nein es scheint lediglich mehr zu funktionieren, als der Hersteller im Rahmen seiner Produkthaftung garantiert. Die kritischen Fällen (alle Betriebsparameter wie Taktung, Spannungslevel an Versorgungungs- und Signal-Pin sowie Temperatur auf Grenze zum Erlaubten) testet der Anwender garnicht. Und wenn dann mal ein Gerät im Feld deswegen Mist baut, zuckt man auch nur mit den Schultern und behebt das Problem per Neustart. Langzeitschäden wäre auch so ein Thema das man mit Antesten von zwangsweise verhinderten Arbeitsmodi nicht erfasst. Ist halt wie Overclocking - you're on your own risk.
Gerd E. schrieb: > Wenn es um letzteres geht, würde ich nicht nach echten CPLDs schauen, > sondern nach FPGAs. > > Denn die echten CPLDs sind generell ältere Designs... Und? So ein NE555 oder 74HCxyz sind auch ältere Designs. Aber neuere FPGA's sind ne bessere Einnahmequelle für deren Hersteller. Die Anwendungsbereiche von FPGA's und CPLD's sind halt unterschiedlich. Dazu kommt, daß gerade bei FPGA's immer wieder das Thema des Konfigurations-Flash's hochkommt und die wenigen FPGA's, wo sowas als Sandwich-Chip eingebaut ist, sind mit ihren Anschlüssen und deren Verwendung auch eher zickig. Da ist ein CPLD unproblematischer in jeder Beziehung. W.S.
W.S. schrieb: > Dazu kommt, daß gerade bei FPGA's immer wieder das Thema des > Konfigurations-Flash's hochkommt und die wenigen FPGA's, wo sowas als > Sandwich-Chip eingebaut ist, sind mit ihren Anschlüssen und deren > Verwendung auch eher zickig. Da ist ein CPLD unproblematischer in jeder > Beziehung. Dieses Thema betrifft nur reine SRAM basierte FPGAs (Intel, Xilinx). Ja, diese zwei Chips in einem Gehäuse (FPGA + Flash) Variante ist eher speziell. Microchip/Microsemi verbaut Flash Zellen für Konfigurationsbits, da brauchts kein externes Flash. Lattice MachXO* bzw. XP2 verwenden zwar SRAM Zellen für Konfigurationsbits bauen aber auf das selbe Die Flashspeicher um diese Zellen beim Einschalten parallel (also im Vergleich schnell) zu laden. Das erlaubt es z. B. dass der FPGA ein Design eingebrannt hat, das immer funktioniert oder das Booten erlaubt und ein externer Prozessor lädt dann später ein anderes Design direkt in die SRAM Konfigurationsbits. Lattice ICE* FPGAs sind one-time-programmable (OTP) -> brauchen in Endgeräten typischerweise auch kein Flash. Während der Entwicklung oder in Systemen mit Prozessor können sie aber auch per Flash Chip oder SPI konfiguriert werden.
Löt dir ein Gatterngrab auf Perfboard. Das ist auf lange Sicht unproblematischer.
Christophz schrieb: > Lattice MachXO* bzw. XP2 verwenden zwar SRAM Zellen für > Konfigurationsbits bauen aber auf das selbe Die Flashspeicher um diese > Zellen beim Einschalten parallel (also im Vergleich schnell) zu laden. Das machen auch die derzeit üblichen "normalen" CPLDs, sogar schon die alten 95er von Xilinx aus dem letzten Jahrtausend. Beim Einschalten wird dort die Konfiguration parallel aus dem Config-EEPROM in die SRAM-Zellen kopiert. Siehe dazu die XAPP440:
1 | CPLDs must reset to a known state and load an internal |
2 | configuration pattern (EPROM) into volatile logic cells (SRAM), |
3 | extremely quickly, to appear "instantaneously on". |
4 | In the case of CoolRunnerTM CPLDs, to save power, internal EPROM |
5 | cells are powered down after configuration. |
6 | Configuration is also performed in XC9500TM, XC9500XLTM, and XC9500XVTM... |
:
Bearbeitet durch Moderator
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.