Forum: FPGA, VHDL & Co. FPGA fuer die es Open Source Toolchains gibt


von topos (Gast)


Lesenswert?

Hi,

gibt es FPGA fuer die man Open Source Synthesizer, Mapper, Place & Route 
Tool
und Serializer kriegt?

von Klaus F. (kfalser)


Lesenswert?

Open Source, nein.
Gratis, ja.

von gast (Gast)


Lesenswert?

XILINX ist doch enorm low-cost-freundlich...

von Uwe Bonnes (Gast)


Lesenswert?

Stephen Williams Icarus Verilog (www.icarus.com) hat zumindestens einen 
Syntheziser fuer die Virtex Familie. Was man dait anfangen kann, ist 
aber ein anderes Blatt.

von Joerg (Gast)


Lesenswert?

Hallo,

freie, benutzbare synthese tools scheint es tatsaechlich nicht zu geben.

Ich bin allerdings letztens über das Signs Projekt [1] der Uni Stuttgart 
gestolpert -- das scheint mit zZ das vielversprechenste.

Ansonsten: Icarus Verilog wuerde ja schon genannt.

   j.



[1] 
http://www.iti.uni-stuttgart.de/~bartscgr/signs/wiki/index.php/Main_Page

von VHDL_Mensch (Gast)


Lesenswert?

Synthesetools mag es geben. Das Place&Route geben Altera, Xilinx & Co. 
aber nicht frei.

von Tom (Gast)


Lesenswert?

Hm gabs da nicht mal was von Niklaus Wirth für die Xilinx XC6000 Serie? 
Wobei die Chips mittlerweile mehr als schwierig aufzutreiben sein 
dürften.

von Falk (Gast)


Lesenswert?

Was soll den das Rumgekrampfe mit "Open Source Toolchain"? Von allen 
namhaften Herstellen sind kostenlose und qualitativ gute Toolchains 
verfügbar. Problem gelöst.

MfG
Falk

von Joerg (Gast)


Lesenswert?

Falk, Hallo,

"Problem gelöst" -- sehe ich nicht ganz so. Ich will mich jetzt nicht 
lange ueber einzelne Macken einzelner Tools auslassen -- weil solche 
Macken gäbe es selbstverständlich auch wenn alles OSS waere. Aber nur 
zwei Beispiele die mich im Moment an ISE nerven, und die ich 
tatsaechlich mal einfaech fixen wuerde, wenn ich koennte:

* binaere Projektdateien: Das ist sehr hinderlich, wenn man ein 
Versionsmanagement (CVS/Subversion) benutzt und mit mehr als einer 
Person an einem Projekt arbeitet.
Begruendung laut Xilinx: "1. Performance" (Eine Textdatei zu parsen 
sollte ein PC von nach 2000 IMHO doch noch schaffen)
"2. Atomare Aenderungen wenn mehrere Tools gleichzeitig darauf schreiben 
wollen" (WTF?! Heisst das die Tools fummeln an den Projektdateien rum 
ohne zu gucken ob sie gerade alleine sind?)

* Wenn man sein Design via Skript baut: par liefert keinen Errorcode 
wenn die timing-constrains failen. D.h. ich muss im Textoutput nach "not 
met" suchen um zu sehen ob alles Ok ist.


Aber die wirkliche stärke eines OSS Toolschains waere wohl Cross-Vendor 
support: Ich benutze gerade Xilinx und Altera Bausteine parallel. Und es 
macht nicht sonderlich viel Spass Dateien von der einen IDE in die 
andere IDE zu übertragen und sich auf die Eigentuemlichkeiten beider 
Tools einstellen zu muessen.

Gcc+binutils sehe ich tatsaechlich als leuchtendes Beispiel. Es schmerzt 
nicht sonderlich seine CPU Architektur zu wechseln.

Die Hemmschwelle mal ein neues Frontend (MyHDL) zu schreiben wuerde auch 
deutlich gedrueckt. Und sei es zunaechst nur ein 
plattformuebergreifender
schematic-Input.


  j.


von Falk (Gast)


Lesenswert?

@Joerg

>* binaere Projektdateien: Das ist sehr hinderlich, wenn man ein
>Versionsmanagement (CVS/Subversion) benutzt und mit mehr als einer
>Person an einem Projekt arbeitet.
>Begruendung laut Xilinx: "1. Performance" (Eine Textdatei zu parsen
>sollte ein PC von nach 2000 IMHO doch noch schaffen)

VORSICHT! Bei kleinen/mittleren FPGAs mag das noch angehen, bei grossen 
1M Gates ++ ist damit schnell Sense. Schau dir mal an was Xilinx für PCs 
vorschreibt um die grossen Virtex4 bzw. Virtex5 zu bearbeiten. Das nenn 
ich mal Wahnsinn (zweistellige Zahl Gbyte RAM). Ausserdem sollte es 
heutzutage auch kein Problem sein, Binärdateien im Projektmanagement zu 
verwalten.

>"2. Atomare Aenderungen wenn mehrere Tools gleichzeitig darauf schreiben
>wollen" (WTF?! Heisst das die Tools fummeln an den Projektdateien rum
>ohne zu gucken ob sie gerade alleine sind?)

Das klingt wirklich nach Murks.

>* Wenn man sein Design via Skript baut: par liefert keinen Errorcode
>wenn die timing-constrains failen. D.h. ich muss im Textoutput nach "not
>met" suchen um zu sehen ob alles Ok ist.

Historisch gewachsene Schwäche. Hmmm.

>Aber die wirkliche stärke eines OSS Toolschains waere wohl Cross-Vendor
>support: Ich benutze gerade Xilinx und Altera Bausteine parallel. Und es

Das interessiert sowohl Xilinx als auch Altera wenig. Ausserdem gibt es 
käufliche VHDL-Compiler bzw. IDEs die das können. $$$.

>macht nicht sonderlich viel Spass Dateien von der einen IDE in die
>andere IDE zu übertragen und sich auf die Eigentuemlichkeiten beider
>Tools einstellen zu muessen.

Musst du mehr oder weniger sowieso, da die Architekturen nicht Identisch 
sind (BRAMS, PLL/DLL etc.).

>Gcc+binutils sehe ich tatsaechlich als leuchtendes Beispiel. Es schmerzt
>nicht sonderlich seine CPU Architektur zu wechseln.

Kann man nicht 100%ig vergleichen.

Ausserdem ist die Ganze P&R Geschichte a) nicht ganz trivial und b) will 
sich da niemand in die Karten schauen lassen.

Realistisch kann die User-Community wohl nur Druck machen, dass Xilinx & 
Co. seinen Tools ein wenig mehr professionellen Schliff verleiht (mehr 
Scripting-Fähigkeiten, Returncodes etc.)

MfG
Falk

von Joerg (Gast)


Lesenswert?

Falk, Hallo,

>>* binaere Projektdateien: Das ist sehr hinderlich, wenn man ein
>>Versionsmanagement (CVS/Subversion) benutzt und mit mehr als einer
>>Person an einem Projekt arbeitet.
>>Begruendung laut Xilinx: "1. Performance" (Eine Textdatei zu parsen
>>sollte ein PC von nach 2000 IMHO doch noch schaffen)
>
>VORSICHT! Bei kleinen/mittleren FPGAs mag das noch angehen, bei grossen
>1M Gates ++ ist damit schnell Sense. Schau dir mal an was Xilinx für PCs

Haette mich klarer ausdrucken muessen -- Ich meinte die 
Projektbescheibungsdatei *.ise.

Das die intermediaeren Netzlisten etc. als Binary vorliegen stört mich 
nicht. Die werden ja immer komplett neu generiert -- daher moechte ich 
die normalerweise auch nicht in meinem Subversion verwalten. Und falls 
doch: mergen möchte ich die mit Sicherheit nicht :)


>>Aber die wirkliche stärke eines OSS Toolschains waere wohl Cross-Vendor
>>support: Ich benutze gerade Xilinx und Altera Bausteine parallel. Und es
>
> Das interessiert sowohl Xilinx als auch Altera wenig. Ausserdem gibt es
> käufliche VHDL-Compiler bzw. IDEs die das können. $$$.

ACK. Ausserdem wuerde die Existenz von guten freien P&R Tools die 
Einstiegshuerde fuer neue FPGA Anbieter senken. Klar, dass die grossen 
daran kein Interesse haben.
Ich sehe schon div. Diplomarbeiten, bei denen jemand einen eigenen 
Interconnect (in VHDL) entwickelt vor vor meinem geistigen Auge 
vorbeiziehen :)

>>Gcc+binutils sehe ich tatsaechlich als leuchtendes Beispiel. Es schmerzt
>>nicht sonderlich seine CPU Architektur zu wechseln.
>
>Kann man nicht 100%ig vergleichen.

Da muss ich dir zustimmen. Vermutlich muss man hier zwischen Synthese 
und P&R unterscheiden.

Was die Synthese angeht sehe ich aber schon deutliche Analogien. 
Insbesondere ist das dafuer notwendige Know-How (soweit ich das 
überblicke, bin darin kein Experte) kein Voodoo, sondern in der 
wissenschaftlichen Fachliteratuer wohldokumentiert.

Die Möglichkeit spezielle HDLs zu haben um zB SoPC Komponenten 
zusammenzuknoten, und ein einheitliches Build-Environment sind schon 
sehr verlockend. Ich koennte mir auch vorstellen, dass zumindest die 
etwas kleineren FPGA Hersteller hier selber noch Vorteile wittern.

>Ausserdem ist die Ganze P&R Geschichte a) nicht ganz trivial und b) will
>sich da niemand in die Karten schauen lassen.

Ja. :(

Was aber nicht heisst, dass es nicht fuer uns Kunden besser waere.


Etwas off-topic, aber woran ich gerade denken muss: Ich habe mir mal 
sagen lassen, dass P&R an und fuer sich ein hochgradig 
parallelisierbares Problem ist. Man also Teile des Algos. wunderbar mit 
FPGAs beschleunigen koennte.

Das sind natuerlich Baustellen die uns vollkommen verwehrt sind solange 
man keine freien Tools hat. (Nicht dass ich die Zeit/Durchblick fuer ein 
solches Projekt haette).


  j.

von Alban (Gast)


Lesenswert?

@ Joerg

>* binaere Projektdateien: Das ist sehr hinderlich, wenn man ein
>Versionsmanagement (CVS/Subversion) benutzt und mit mehr als einer
>Person an einem Projekt arbeitet.
>Begruendung laut Xilinx: "1. Performance" (Eine Textdatei zu parsen
>sollte ein PC von nach 2000 IMHO doch noch schaffen)

Ich nutze eine Makefile und das alte text-basierte Projektfile von ISE 
und das funktioniert prima. Hab das gerade letztens mit 8.1 laufen 
gelassen. 9.1 hab ich noch nicht getestet.

von Uwe Bonnes (Gast)


Lesenswert?

@Alban:

Koennntest Du bitte mal so ein Makefile als Beispiel posten? Ich waere 
fuer ein (dokumentiertest) Beispiel dankbar.

Tschuess

von Rick Dangerus (Gast)


Lesenswert?

Unter http://www.xess.com/appnotes/makefile.html gibt es ein Makefile 
und eine kleine Doku dazu. Prinzipiell hab ich sie unter ISE 8.2/ubuntu 
zum Laufen bekommen, mußte aber einige Variablen von Hand setzen.

Rick

von Jonathan S. (psihodelia)


Lesenswert?

Rick Dangerus wrote:
> Unter http://www.xess.com/appnotes/makefile.html gibt es ein Makefile
> und eine kleine Doku dazu. Prinzipiell hab ich sie unter ISE 8.2/ubuntu
> zum Laufen bekommen, mußte aber einige Variablen von Hand setzen.
>
> Rick

Unter ISE 9.1i geht es nicht.

Bitte 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
Noch kein Account? Hier anmelden.