CPLD unter Linux

"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.

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.

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:
> 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.

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

>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.

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.