VHDL und Xilinx CPLDs

[Michael Eggert]

Moin!

Habe mein VHDL-Buch leider auf Arbeit liegen und stehe momentan etwas
auf dem Schlauch. Das Problem: Ich möchte den Ausgangswert von
Flipflops, welche auf Ausgänge des CPLD treiben, zurückkoppeln. Also
was in der Art:

if (CLOCK'event and CLOCK = '1') then ADRESS <= ADRESS + X"1"; end if;

Ist ADRESS ein Port "out std_logic_vector", so funktioniert die
Rückkopplung nicht, weils eben nur ein Ausgang ist. Eine weitere Reihe
Flipflops und die damit verbundene Verzögerung wollte ich mir sparen.

Nun die Frage: Muss ich ADRESS jetzt als "inout" definieren, oder war
das für bidirektionale Ausgänge? Ich will ja nix von außen einlesen,
sondern nur des Ausgangswert zurückkoppeln.


Das zweite Problem:
Ich nutze gerade das Xilinx Webpack 4.2 WP3. Naja, genau genommen bin
ich immer noch dabei, mich einzuarbeiten. Also, im CPLD ist noch ein
bissl Luft, und so denke ich mir, vielleicht verzichte ich aufs
optimale interne Routing und lege mir dafür lieber die I/O-Pins so,
wie ich sie von außen am liebsten hätte. Nur wo kann ich das vorgeben?

Gruß,
Michael.

 

[Georg Acher]

In article <0s6o10h2k6d9ufhgnm6iboasacab2oea17@4ax.com>,
Michael Eggert <m.eggert.nul@web.de> writes:

|> Nun die Frage: Muss ich ADRESS jetzt als "inout" definieren, oder war
|> das für bidirektionale Ausgänge? Ich will ja nix von außen einlesen,
|> sondern nur des Ausgangswert zurückkoppeln.

Entweder nimmst du als mode "buffer" her, oder du definierst ein internes
Signal, auf das alle Zuweisungen gehen (und auch gelesen werden kann) und weist
den Ausgang in einem Conurrent Statement auch damit zu.

Das Problem (das wohl jeder schon mal hatte) soll in VHDL'92 irgendwie behoben
sein, hab nur grad vergessen, wie.

|> Das zweite Problem:
|> Ich nutze gerade das Xilinx Webpack 4.2 WP3. Naja, genau genommen bin
|> ich immer noch dabei, mich einzuarbeiten. Also, im CPLD ist noch ein
|> bissl Luft, und so denke ich mir, vielleicht verzichte ich aufs
|> optimale interne Routing und lege mir dafür lieber die I/O-Pins so,
|> wie ich sie von außen am liebsten hätte. Nur wo kann ich das vorgeben?

Das geht mit einem ucf-File, entweder hat das Webpack einen Constrainteditor
dafür (hab's schon lang nicht mehr ausprobiert) oder du bastelst es von Hand
zusammen.

--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[Michael Eggert]

On 31 Jan 2004 22:07:42 GMT, acher@in.tum.de (Georg Acher) wrote:

Hi!

|> Nun die Frage: Muss ich ADRESS jetzt als "inout" definieren, oder war
|> das für bidirektionale Ausgänge? Ich will ja nix von außen einlesen,
|> sondern nur des Ausgangswert zurückkoppeln.

Entweder nimmst du als mode "buffer" her, oder du definierst ein internes
Signal, auf das alle Zuweisungen gehen (und auch gelesen werden kann) und weist
den Ausgang in einem Conurrent Statement auch damit zu.

Hab ich jetzt nicht ganz verstanden. Bildet

"entity ... is Port (ADRESS: buffer std_logic_vector (..))"

jetzt ein Flipflop mit Ausgang zum Pin, das ich auch zurücklesen kann?
Oder bildet es nur einen (nicht flipfloppenden Ausgangstreiber mit
Pin, den ich an ein vorhandenes (mit "signal" definiertes) Flipflop
klemme?

[Pins zuweisen]

Das geht mit einem ucf-File, entweder hat das Webpack einen Constrainteditor
dafür (hab's schon lang nicht mehr ausprobiert) oder du bastelst es von Hand
zusammen.

Danke! Wenn man nur weiß, wonach man suchen muss, wird man auch fündig


Gruß,
Michael.

 

[Georg Acher]

In article <kubo10p67v972h926gc2o79dmcl1c58obu@4ax.com>,
Michael Eggert <m.eggert.nul@web.de> writes:

|> Hab ich jetzt nicht ganz verstanden. Bildet
|>
|> "entity ... is Port (ADRESS: buffer std_logic_vector (..))"
|>
|> jetzt ein Flipflop mit Ausgang zum Pin, das ich auch zurücklesen kann?
|> Oder bildet es nur einen (nicht flipfloppenden Ausgangstreiber mit
|> Pin, den ich an ein vorhandenes (mit "signal" definiertes) Flipflop
|> klemme?

Flipflops erzeugst du sowieso nur mit dem "if clk'event"&Co-Schablonen, die Ports
haben damit nichts zu tun, das sind immer nur Treiber. BUFFER hat im Vergleich zu
OUT die Möglichkeit, dass man den ausgegebenen Wert intern zurücklesen kann, es
ist aber kein Eingang (wie INOUT, der dafür "innen" dann immer ein 'Z' zugewiesen
bekommen muss). Der Wert geht quasi noch intern wieder zurück, bevor nach aussen
kommt.

Allerdings hat buffer im Zusammenspiel mit mehreren Komponentenhierarchien AFAIK
ein paar Probleme, daher macht man üblicherweise die zweite Variante, also in
etwa:

entity ... port (xadress: out ...) end...

architecture ....
signal adress: ...;
begin
xadress<=adress;

process...
adress<=...

Das könnte aber wieder potentiell Probleme in der Simulation machen (wg.
delta-delay), allerdings auch nur, wenn man asynchron damit weiterwurschtelt.
Schliesslich gibt es jetzt einen winzigen Zeitunterschied zw. adress und xadress
(in den meisten Simulatoren sieht man den nicht mal).

--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[Michael Eggert]

On 31 Jan 2004 23:28:23 GMT, acher@in.tum.de (Georg Acher) wrote:

Hi!

Flipflops erzeugst du sowieso nur mit dem "if clk'event"&Co-Schablonen, die Ports
haben damit nichts zu tun, das sind immer nur Treiber.

Ääh ja, ist schon spät am morgen Ich hatte wohl übersehen, daß
"out" selbst ja auch nur ein Treiber ist. Und automatisch ein Flipflop
vorgeschaltet bekommt, wenn ich es innerhalb clk'event anspreche.

BUFFER hat im Vergleich zu
OUT die Möglichkeit, dass man den ausgegebenen Wert intern zurücklesen kann, es
ist aber kein Eingang

Genau das will ich ja, fein.

Allerdings hat buffer im Zusammenspiel mit mehreren Komponentenhierarchien AFAIK
ein paar Probleme,

Hab ich nicht. Ist ein simpler Zähler (19 bit) mit ein paar kleinen
Spielereien wie "springe 100 vorwärts", sonst hätt ichs gar diskret
aufgebaut.

daher macht man üblicherweise die zweite Variante, also in etwa:

entity ... port (xadress: out ...) end...

architecture ....
signal adress: ...;
begin
xadress<=adress;

process...
adress<=...

Also außerhalb der clk'event auf die Ausgänge schalten. Ginge
natürlich auch. Nur innerhalb der clk würde ich es ungern tun, da das
zusätzliche delay um einen Takt doch von außen gesehen etwas stören
würde.

Das könnte aber wieder potentiell Probleme in der Simulation machen (wg.
delta-delay), allerdings auch nur, wenn man asynchron damit weiterwurschtelt.

Naja, es _ist_ ja schon asynchron.

Schliesslich gibt es jetzt einen winzigen Zeitunterschied zw. adress und xadress
(in den meisten Simulatoren sieht man den nicht mal).

Nun frage ich mich allerdings, ob denn in programmierter Hardware
wirklich ein Unterschied bestehen würde:
Die letzte Version gibt ein FF, dahinter die Rückfühung und der
Ausgangstreiber, beide am FF.
Die erste Version, also ein Buffer, der innerhalb der clk'event
gesetzt wird, ist ein Ausgangstreiber mit FF davor und einer
Rückführung. Die Frage ist nur, wo die Rückführung sitzt: vor oder
hinter dem Treiber? Ich schätze ja mal, der Compiler wird schon
merken, daß der Treiber nur treiben soll, und die Rückführung zur
Reduzierung unnötiger Laufzeiten vor den Treiber setzen (ans FF).

Gruß,
Michael.

 

[Georg Acher]

In article <eiho109t18g9cpc97lt102b01fsd0t3tr1@4ax.com>,
Michael Eggert <m.eggert.nul@web.de> writes:

|> Also außerhalb der clk'event auf die Ausgänge schalten. Ginge
|> natürlich auch. Nur innerhalb der clk würde ich es ungern tun, da das
|> zusätzliche delay um einen Takt doch von außen gesehen etwas stören
|> würde.

Nein, ausserhalb hast du keine Verzögerung, "Concurrent Statements" ausserhalb
von Prozessen werden sofort erledigt. Von daher gibt es keinen Unterschied zur
Variante ohne Zwischensignal.

|> >Das könnte aber wieder potentiell Probleme in der Simulation machen (wg.
|> >delta-delay), allerdings auch nur, wenn man asynchron damit weiterwurschtelt.
|>
|> Naja, es _ist_ ja schon asynchron.

Aber anders asynchron ;-) Die Probleme kommen nur dann, wenn man das Signal als
Takt verwenden will und andere Einheiten auf dem Ursprungssignal getaktet werden.
Eigentlich müsste ja durch die Zuweisung alles ein Signal sein (ist es nach der
Synthese auch), in der Simulation ist das Ursprungssignal aber infinitesimal
früher dran. Das kann bei Nutzung als Takt manchmal zu Verwirrungen führen. Aber
solche Möglichgkeiten für Probleme hat man man mit CPLDs sowieso eher selten...

|> >Schliesslich gibt es jetzt einen winzigen Zeitunterschied zw. adress und xadress
|> >(in den meisten Simulatoren sieht man den nicht mal).
|>
|> Nun frage ich mich allerdings, ob denn in programmierter Hardware
|> wirklich ein Unterschied bestehen würde:
|> Die letzte Version gibt ein FF, dahinter die Rückfühung und der
|> Ausgangstreiber, beide am FF.
|> Die erste Version, also ein Buffer, der innerhalb der clk'event
|> gesetzt wird, ist ein Ausgangstreiber mit FF davor und einer
|> Rückführung. Die Frage ist nur, wo die Rückführung sitzt: vor oder
|> hinter dem Treiber? Ich schätze ja mal, der Compiler wird schon
|> merken, daß der Treiber nur treiben soll, und die Rückführung zur
|> Reduzierung unnötiger Laufzeiten vor den Treiber setzen (ans FF).

Beide sind nach der Synthese identisch, es ist nur ein Unterschied in der
Beschreibung. Echte Treiber gibt's eh nur nach aussen, und die werden
automatisch von der Synthese eingebaut. Nur mit INOUT könnte man den
Aussenzustand wieder einlesen.

--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[robka]

Hallo,

die Tipps die hier diskutiert worden sind sind voll OK, ich möchte
jedoch zwei Sachen noch los werden:

1. der Tipp, den Ausgang als BUFFER zu definieren ist richtig, hat
jedoch einen kleinen Hacken: wenn dein Ausgang ADRESS in der Top-Ebene
des CPLD liegt (sprich, es ist ein Ausgangspin) und du soetwas wie ein
"postfit simulation model" für eine Postlayout-Simulation erzeugst,
dann geht es schief. Es gibt im VHDL-File des Postfit-Model *keinen*
Porttyp BUFFER, denn daraus wird ein OUT. Und alle Datentypen werden
auch durch STD_LOGIC(_VECTOR) ersetzt. Wenn du dann versuchst, dein
Postlayot-Model zu übersetzen und zu simulieren, motzt dein Simulator
(wahrscheinlich ModelSim), dass dein Postlayout-Model nicht zur
bestehenden Testbench passt, was du dann in mühsamer Handarbeit
beheben musst. Mein Tipp: BUFFER nur für *rein* funktionale
Simulationen benutzen, für die Timing-Simulationen (Postlayout) OUT
nehmen und ein Zwischensignal definieren, das du dann zurücklesen
kannst:

ENTITY xxxx IS
PORT(
...
ADRESS : OUT std_logic_vector(a DOWNTO b)
);

ARCHITECTURE yyyy OF xxx IS
SIGNAL ADRESS_int: unsigned(a DOWNTO b); -- dein Buffer

BEGIN
PROCESS (clk, ...)
...
IF clk = '1' AND clk'event THEN
ADRESS_int <= ADRESS_int + 1; -- ieee.numeric_std nicht
vergessen!
END IF;
...
END PROCESS;
ADRESS <= std_logic_vector(ADRESS_int);

END yyyy;

so )

und 2. die XILINX (ob ISE oder WebPACK) Version 4.2 ist die
schrottigste, die jemals existiert hat. Lass lieber deine Finger von
der! Version 5.2 + SP3 ist viel besser, die 6er gibt's inzwischen
auch, ich hatte aber bis jetzt keine Zeit, mich mit der auseinander zu
setzen.

Gruß und viel Erfolg mit dem CPLD!

Robert Koch

 

[Michael Eggert]

On 1 Feb 2004 02:14:00 -0800, R_Koch@gmx.de (robka) wrote:

Hi!

Feinen Dank für die Tipps mit den Ausgängen.

und 2. die XILINX (ob ISE oder WebPACK) Version 4.2 ist die
schrottigste, die jemals existiert hat. Lass lieber deine Finger von
der! Version 5.2 + SP3 ist viel besser, die 6er gibt's inzwischen
auch, ich hatte aber bis jetzt keine Zeit, mich mit der auseinander zu
setzen.

Äähm, ist alles nur Hobby, drum benutze ich natürlich die freie
Version. 4.2 ist unbegrenzt, die 5er war 90Tage, als es die 6er noch
nicht gab. Vielleicht ist die 5er ja jetzt auch frei.

Allerdings: Das ganze passt locker in ein 9536. Wird der in Versionen
nach 4.2 überhaupt noch unterstützt?

Gruß,
Michael.

 

[Uwe Bonnes]

Michael Eggert <m.eggert.nul@web.de> wrote:
: On 1 Feb 2004 02:14:00 -0800, R_Koch@gmx.de (robka) wrote:

: Hi!

: Feinen Dank für die Tipps mit den Ausgängen.

: >und 2. die XILINX (ob ISE oder WebPACK) Version 4.2 ist die
: >schrottigste, die jemals existiert hat. Lass lieber deine Finger von
: >der! Version 5.2 + SP3 ist viel besser, die 6er gibt's inzwischen
: >auch, ich hatte aber bis jetzt keine Zeit, mich mit der auseinander zu
: >setzen.

: Äähm, ist alles nur Hobby, drum benutze ich natürlich die freie
: Version. 4.2 ist unbegrenzt, die 5er war 90Tage, als es die 6er noch
: nicht gab. Vielleicht ist die 5er ja jetzt auch frei.

Das ist die Vollversion als Evaluierung. Allerdings kannst Du laut der
Lizenz ein einmal angefangenes Projekt auch noch nach den 90 Tagen
bearbeiten.

Webpack hat eine unbegrenzte Lizenz. Kann aber nicht die ganze alten und
ganz grossen Bausteine.

: Allerdings: Das ganze passt locker in ein 9536. Wird der in Versionen
: nach 4.2 überhaupt noch unterstützt?

Ja!

Bye
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Michael Eggert]

On Sun, 1 Feb 2004 12:20:45 +0000 (UTC), Uwe Bonnes
<bon@elektron.ikp.physik.tu-darmstadt.de> wrote:

Hi!

[Versionen bei Xilinx]

Das ist die Vollversion als Evaluierung. Allerdings kannst Du laut der
Lizenz ein einmal angefangenes Projekt auch noch nach den 90 Tagen
bearbeiten.

Beziehst Du Dich auf die 5.2?

Webpack hat eine unbegrenzte Lizenz. Kann aber nicht die ganze alten und
ganz grossen Bausteine.

Ach, ich steig da eh nicht mehr durch. Webpacks, ISEs, Updates, Sevice
Packs, Service Releases, ISE Classic, Classic Webpacks,...
Und da soll man als Anfänger überblicken, was für einen das passende
ist? Zumal man gerade ganz andere Sorgen hat, nämlich CPLDs/FPGAs zu
verstehen und VHDL zu lernen.

Apropos andere Sorgen:
Ich bräuchte mal ne Empfehlung fürn Downloadkabel:

- Möglichst einfach aufgebaut
- Muss nicht schnell sein
- Sollte mit möglichst wenigen Pins am CPLD auskommen

Serielle Schnittstelle und PrinterPort sind vorhanden.
Wenn ich einen XC95..XL (intern 3.3V, extern 3.3V oder 5V) schreiben
möchte, muss ich dann die I/Os des CPLD mit 5V versorgen bzw brauche
ich einen Pegelwandler, oder geht das auch so?

Gruß,
Michael.

 

[Georg Acher]

In article <e0jq10hitk5ig5rid7jk66ghmt9hppbgmv@4ax.com>,
Michael Eggert <m.eggert.nul@web.de> writes:

|> Ach, ich steig da eh nicht mehr durch. Webpacks, ISEs, Updates, Sevice
|> Packs, Service Releases, ISE Classic, Classic Webpacks,...

Wieso? Webpack ist das, was nix kost. Einschränkungen: Keine grossen Chips, kein
FPGA-Editor und sonstiger Schnickschnack (Interfaces zu anderen EDA-Tools).
Dafür gibt's immerhin einen kostenlosen VHDL-Simulator.

ISE kostet Geld (dafür bekommt man CDs und AFAIR auch ein Downloadkabel), hat
alle Chips und Gimmicks. ISE Foundation ist all-in-one, ISE Alliance hat noch
Libraries für Synopsys und Co dabei.

Das Classic-Zeug (XACT/M1...) sind alte Releases, damit Leute, die das Pech
haben, einen inzwischen nicht mehr unterstützen Chip (zB. 3K/4K/5K/6K) bearbeiten
zu müssen, noch was zum Spielen haben.

|> Und da soll man als Anfänger überblicken, was für einen das passende
|> ist? Zumal man gerade ganz andere Sorgen hat, nämlich CPLDs/FPGAs zu
|> verstehen und VHDL zu lernen.

Haddu Geld: ISE. Haddu kein Geld: Webpack ;-)

|> Apropos andere Sorgen:
|> Ich bräuchte mal ne Empfehlung fürn Downloadkabel:

Das Kabel III gibts da:

http://toolbox.xilinx.com/docsan/2_1i/data/common/hug/fig13.htm

Sollte eigentlich auch mit 3.3V gehen.

--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[Michael Eggert]

On 1 Feb 2004 20:55:48 GMT, acher@in.tum.de (Georg Acher) wrote:

Hi!

|> Ach, ich steig da eh nicht mehr durch. Webpacks, ISEs, Updates, Sevice
|> Packs, Service Releases, ISE Classic, Classic Webpacks,...

Wieso? Webpack ist das, was nix kost. Einschränkungen: Keine grossen Chips, kein
FPGA-Editor und sonstiger Schnickschnack (Interfaces zu anderen EDA-Tools).
Dafür gibt's immerhin einen kostenlosen VHDL-Simulator.

ISE kostet Geld (dafür bekommt man CDs und AFAIR auch ein Downloadkabel), hat
alle Chips und Gimmicks. ISE Foundation ist all-in-one, ISE Alliance hat noch
Libraries für Synopsys und Co dabei.

Soweit die Theorie. Schaut man aber hier:
http://www.xilinx.com/webpack/classics/spartan_4k/index.htm
So landet man bei "Spartan and XC4000 series device family software -
ISE 4.2i Service Pack 3 level of support. Download file size is 153Mb.
Supports Spartan, Spartan XL, XC4000E, EX, L, XL, XLA"

Steht groß "ISE", nicht "WebPack" drauf und ist trotzdem frei.


Auf
http://www.xilinx.com/webpack/classics/wpclassic/index.htm
Hingegen findet man die "Classic Webpacks", und dort gibt es neben den
anderen prähistorischen Versionen ebenfalls eine 4.2WP3. Diese
unterstützt _nicht_ die alten Spartan und _nicht_ die 4000er.


Wenn man in dem Wust nicht zufällig auf die Tabelle
http://www.xilinx.com/webpack/classics/wpclassic/parts_list.htm
stößt, in der ein paar Versionen und die unterstützten ICs aufgelistet
sind, kann man sich meiner Meinung nach schon ziemlich schnell
verirren. Zum einen, weil eben _nicht_ konsequent WebPack=frei,
ISE=kostet durchgehalten wird. Und weil die Bezeichnung "Classic
WebPacks" für alle älteren Versionen contra "ISE Classic" für die
nicht ganz so alte, dafür die ältesten ICs unterstützende Version
ziemlich verwirrend ist.

Das Kabel III gibts da:

http://toolbox.xilinx.com/docsan/2_1i/data/common/hug/fig13.htm

Sollte eigentlich auch mit 3.3V gehen.

Ei fein, dankeschön!
Und das lässt sich dann direkt vom WebPack-impact ansprechen?

Gruß,
Michael.

 

[Georg Acher]

In article <5rtq10p8olnnk11prqc63mtvqne74q6q75@4ax.com>,
Michael Eggert <m.eggert.nul@web.de> writes:

|> Soweit die Theorie. Schaut man aber hier:
|> http://www.xilinx.com/webpack/classics/spartan_4k/index.htm
|> So landet man bei "Spartan and XC4000 series device family software -
|> ISE 4.2i Service Pack 3 level of support. Download file size is 153Mb.
|> Supports Spartan, Spartan XL, XC4000E, EX, L, XL, XLA"
|>
|> Steht groß "ISE", nicht "WebPack" drauf und ist trotzdem frei.

Ja, aber es ist alter Schrott ;-) Das nimmt keiner mehr freiwillig, ausser er
muss noch Updates für was altes produzieren. Genauso hat Borland ja auch alte
Turbo-{C|Pascal}-Compiler im "Museum" rumliegen.

|> Auf
|> http://www.xilinx.com/webpack/classics/wpclassic/index.htm
|> Hingegen findet man die "Classic Webpacks", und dort gibt es neben den
|> anderen prähistorischen Versionen ebenfalls eine 4.2WP3. Diese
|> unterstützt _nicht_ die alten Spartan und _nicht_ die 4000er.

Webpack war immer eingeschränkt, von daher fällt das nicht aus der Reihe.
Wahrscheinlich war die Bauteilauswahl so, dass immer ihre neuesten Evalboards
unterstützt wurden und sonst nichts ;-) Früher gabs dann auch für die
Bezahlvarianten "Base" und "Standard", bei Base haben auch die grösseren Chips
gefehlt.

|> Wenn man in dem Wust nicht zufällig auf die Tabelle
|> http://www.xilinx.com/webpack/classics/wpclassic/parts_list.htm
|> stößt, in der ein paar Versionen und die unterstützten ICs aufgelistet
|> sind, kann man sich meiner Meinung nach schon ziemlich schnell
|> verirren. Zum einen, weil eben _nicht_ konsequent WebPack=frei,
|> ISE=kostet durchgehalten wird. Und weil die Bezeichnung "Classic
|> WebPacks" für alle älteren Versionen contra "ISE Classic" für die
|> nicht ganz so alte, dafür die ältesten ICs unterstützende Version
|> ziemlich verwirrend ist.

Classic heissen alle alten Versionen, die es _jetzt_ kostenlos gibt. Das
schliesst die schon immer kostenlosen Webpacks auch mit ein. Das mit den Chips
ist verwirrend, aber auch nur, wenn man die beiden "Produktpfade" ISE und
Webpack vermischt.

|> Ei fein, dankeschön!
|> Und das lässt sich dann direkt vom WebPack-impact ansprechen?

Sollte eigentlich schon.

--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[Michael Eggert]

On 1 Feb 2004 22:34:02 GMT, acher@in.tum.de (Georg Acher) wrote:

Hi!

|> Soweit die Theorie. Schaut man aber hier:
|> http://www.xilinx.com/webpack/classics/spartan_4k/index.htm
|> So landet man bei "Spartan and XC4000 series device family software -
|> ISE 4.2i Service Pack 3 level of support. Download file size is 153Mb.
|> Supports Spartan, Spartan XL, XC4000E, EX, L, XL, XLA"
|
|> Steht groß "ISE", nicht "WebPack" drauf und ist trotzdem frei.

Ja, aber es ist alter Schrott ;-) Das nimmt keiner mehr freiwillig, ausser er
muss noch Updates für was altes produzieren. Genauso hat Borland ja auch alte
Turbo-{C|Pascal}-Compiler im "Museum" rumliegen.

Schrott hin oder her - manch einer nimmt bestimmt noch gern die alten
Spartan. Weil sie einfach ausreichen, weil sie mit 5V laufen, weil es
sie im PLCC gibt, weil man sie sogar bei Reichelt kaufen kann. Genau
die Leute wahrscheinlich, die das nur fürs Hobby wollen, und die sich
nie die Software kaufen würden, weils ihnen das einfach nicht wert
ist. Genau die Leute sind dann auf den "Schrott" angewiesen, weil die
Spartan von keiner anderen freien Version unterstützt werden. Soll
jetzt keinerlei Kritik sein, wollte das nur mal anmerken.

Nur den Vergleich mit Borland versteh ich nicht recht. Borland
verdient seine Brötchen mit Software, Xilinx mit Hardware.

Webpack war immer eingeschränkt, von daher fällt das nicht aus der Reihe.
Wahrscheinlich war die Bauteilauswahl so, dass immer ihre neuesten Evalboards
unterstützt wurden und sonst nichts ;-)

Ja, das Gefühl hab ich auch. Ich würd auch am liebsten den
allerneuesten Chip nehmen, da brauchen ich dann auch nur einen
einzigen fürs ganze Projekt, hab genug Platz drin und genug Anschlüsse
auch. Preislich wärs bestimmt nicht so schlimm, immerhin spart man
dadurch ja an anderen Enden. Nur dumm, daß ich kein BGA löten kann.
Und irgendwie hab ich auch kein Bock, je einen Spannungsregler für 5V,
3.3V, 2.5V, 1.8V,... draufzusetzen. Aah moment, so langsam durchblicke
ich die Strategie: BGA heißt professionelle Fertigung. Das bedeutet,
ich muss mein Hobbyprojekt von vornherein als mindestens Kleinserie
(über ebay zu verticken) anlegen, damit ich die Kosten für den
Prototypen (den ich ja eigentlich nur will) wieder reinbekomme -> mehr
Absatz für Xilinx. Mensch, hätten die das doch gleich gesagt, so
machen wirs!

Classic heissen alle alten Versionen, die es _jetzt_ kostenlos gibt. Das
schliesst die schon immer kostenlosen Webpacks auch mit ein.

Ja moment mal, das klingt aber so, als gäbe es _mehrere_ Classic =
freie Versionen vom ISE. Ich seh da aber _nur_ den ISE 4.2i, der auch
_nur_ die alten Spartan und 4000er unterstützt, nichtmal 9500er.
Alles andere heißt ISE WebPack. Jetzt sag nicht, daß das aktuelle
Webpack nur Webpack heißt und die aktuelle ISE später zur ISE Webpack
wird, während die alten eingeschränkten nur-Webpack dann rausgenommen
werden, um Jahre später als Classic im Museum bei Borland.. ääh....

Gute Nacht,
Michael.

 

[Georg Acher]

In article <v60r109kqbal2vmq4ef246f26fo00r732k@4ax.com>,
Michael Eggert <m.eggert.nul@web.de> writes:

|> >Ja, aber es ist alter Schrott ;-) Das nimmt keiner mehr freiwillig, ausser er
|> >muss noch Updates für was altes produzieren. Genauso hat Borland ja auch alte
|> >Turbo-{C|Pascal}-Compiler im "Museum" rumliegen.
|>
|> Schrott hin oder her - manch einer nimmt bestimmt noch gern die alten
|> Spartan. Weil sie einfach ausreichen, weil sie mit 5V laufen, weil es
|> sie im PLCC gibt, weil man sie sogar bei Reichelt kaufen kann. Genau
|> die Leute wahrscheinlich, die das nur fürs Hobby wollen, und die sich
|> nie die Software kaufen würden, weils ihnen das einfach nicht wert
|> ist. Genau die Leute sind dann auf den "Schrott" angewiesen, weil die
|> Spartan von keiner anderen freien Version unterstützt werden. Soll
|> jetzt keinerlei Kritik sein, wollte das nur mal anmerken.

Für die Haltung (die alten 4K/Spartans so langsam auslaufen zu lassen) bekommt
Xilinx genug Kritik. Allerdings ist der Anwendungsbereich der 5V-Chips
tatsächlich eigentlich nur noch auf Bastler zusammengeschrumpft. Wenn das
FPGA/CPLD nicht ganz "allein" ist und ein paar andere höher integrierte Chips
anspricht, kann man 5V kaum noch nutzen. Ich bin gespannt, wie lange die
3.3V-IO-Kompatibilität der jetzigen Chips noch anhält...

|> Nur den Vergleich mit Borland versteh ich nicht recht. Borland
|> verdient seine Brötchen mit Software, Xilinx mit Hardware.

Echt? Das ist mir neu ;-) Wie ich mein erstes Xact von Xilinx gekauft habe (war
so um 1994), hat das in der Basisversion ohne die grossen Chips 5000 Ocken
gekostet, die jährlichen Wartungskosten waren auch nicht ohne. Und da war auch
"nur" ein Schematic Entry dabei, von Hochsprachen war da noch nichts zu sehen,
die Xilinx-eigene XST-Engine ist recht neu. Erst seit dem Webpack kann man als
Normalsterblicher da mitmachen, und das ist auch noch nicht so lang her...

<...>
|> dadurch ja an anderen Enden. Nur dumm, daß ich kein BGA löten kann.
|> Und irgendwie hab ich auch kein Bock, je einen Spannungsregler für 5V,
|> 3.3V, 2.5V, 1.8V,... draufzusetzen. Aah moment, so langsam durchblicke
|> ich die Strategie: BGA heißt professionelle Fertigung. Das bedeutet,

Dachte ich auch mal. Such mal in Google "bgas selber einlöten" und nimm den
ersten Treffer

|> >Classic heissen alle alten Versionen, die es _jetzt_ kostenlos gibt. Das
|> >schliesst die schon immer kostenlosen Webpacks auch mit ein.
|>
|> Ja moment mal, das klingt aber so, als gäbe es _mehrere_ Classic =
|> freie Versionen vom ISE. Ich seh da aber _nur_ den ISE 4.2i, der auch
|> _nur_ die alten Spartan und 4000er unterstützt, nichtmal 9500er.

Alles andere ist zu neu. 5.1 ist ja wirklich noch benutzbar, es kann sogar einige
Designs besser als 6.x. AFAIR gab es kein ISE3, es ging gleich mit 4 los. Das
Package hiess vorher M1, noch älter Xact.

|> Alles andere heißt ISE WebPack. Jetzt sag nicht, daß das aktuelle
|> Webpack nur Webpack heißt und die aktuelle ISE später zur ISE Webpack
|> wird, während die alten eingeschränkten nur-Webpack dann rausgenommen
|> werden, um Jahre später als Classic im Museum bei Borland.. ääh....

Xilinx' Wege sind unerforschlich.

--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[Michael Eggert]

On 1 Feb 2004 23:24:15 GMT, acher@in.tum.de (Georg Acher) wrote:

Hi!

Für die Haltung (die alten 4K/Spartans so langsam auslaufen zu lassen) bekommt
Xilinx genug Kritik.

Ja, nett is das nicht.

Allerdings ist der Anwendungsbereich der 5V-Chips
tatsächlich eigentlich nur noch auf Bastler zusammengeschrumpft.

Ich verstehe aber auch nicht, warum man hier wohl den Bastler abhängen
will. Erklärung später...

Wenn das
FPGA/CPLD nicht ganz "allein" ist und ein paar andere höher integrierte Chips
anspricht, kann man 5V kaum noch nutzen. Ich bin gespannt, wie lange die
3.3V-IO-Kompatibilität der jetzigen Chips noch anhält...

Eben. In meiner jetzigen Anwendung mags vielleicht gehen, aber ich
will ja durchaus noch weiter damit arbeiten.

|> Nur den Vergleich mit Borland versteh ich nicht recht. Borland
|> verdient seine Brötchen mit Software, Xilinx mit Hardware.

Echt? Das ist mir neu ;-)

Okay, da hab ich mich wohl getäuscht
Ich dachte echt, 100000er Chargen an Hardware würden mehr bringen als
eine verkaufte Entwicklungsumgebung.

Wie ich mein erstes Xact von Xilinx gekauft habe (war
so um 1994), hat das in der Basisversion ohne die grossen Chips 5000 Ocken
gekostet, die jährlichen Wartungskosten waren auch nicht ohne. Und da war auch
"nur" ein Schematic Entry dabei, von Hochsprachen war da noch nichts zu sehen,
die Xilinx-eigene XST-Engine ist recht neu. Erst seit dem Webpack kann man als
Normalsterblicher da mitmachen, und das ist auch noch nicht so lang her...

Vielleicht dachte man, man könne ja an den Hobbyisten auch noch ein
bissl verdienen. Scheint aber wirklich nur als "Abfallprodukt" vom
großen Markt gesehen zu werden.

Ich verstehs einfach nicht. Ich meine, wenn ich mir fürs Hobby jetzt
einen Einblick verschaffe ins Produktspektrum von Xilinx, und mich in
die Software von Xilinx einarbeite - dann ist es doch logisch, daß ich
dann wenn ich "auf Arbeit" mal programmierbare Logik nehme, auch von
Xilinx kaufe. Einfach, weil die Einarbeitung wegfällt und time-to-
market reduziert ist, das freut den Chef und Xilinx auch, wenns ne
größere Serie wird. Nein, wo ich arbeite, wird nix verkauft. Aber wäre
ja möglich. Nun frag ich mich, ob _ich_ diesen Effekt überschätze oder
ob Xilinx ihn unterschätzt.

Dachte ich auch mal. Such mal in Google "bgas selber einlöten" und nimm den
ersten Treffer

Ja kenne ich doch, bin doch auch schon länger hier. Nur mal ehrlich:
Hättest Du das getan, wenn Du irgendeine Alternative gehabt hättest?
Wieviele Leute kennst Du, die mit programmierbarer Logik arbeiten, und
wieviele, die das BGA-Löten nachgemacht haben?

|> Ja moment mal, das klingt aber so, als gäbe es _mehrere_ Classic =
|> freie Versionen vom ISE. Ich seh da aber _nur_ den ISE 4.2i, der auch
|> _nur_ die alten Spartan und 4000er unterstützt, nichtmal 9500er.

Alles andere ist zu neu. 5.1 ist ja wirklich noch benutzbar, es kann sogar einige
Designs besser als 6.x. AFAIR gab es kein ISE3, es ging gleich mit 4 los. Das
Package hiess vorher M1, noch älter Xact.

Letztendlich läufts darauf hinaus, daß man mehrere Versionen auf dem
Rechner hat. Die ISE Classic 4.2i für Spartan und 4000. Und was ist
brauchbar für 9500er? 5.1? 5.2?

|> Alles andere heißt ISE WebPack. Jetzt sag nicht, daß das aktuelle
|> Webpack nur Webpack heißt und die aktuelle ISE später zur ISE Webpack
|> wird, während die alten eingeschränkten nur-Webpack dann rausgenommen
|> werden, um Jahre später als Classic im Museum bei Borland.. ääh....

Xilinx' Wege sind unerforschlich.

Hach danke, auf diese Zustimmung hab ich doch all meine letzten
Postings nur gewartet und gehofft

Wie siehts denn mit Alternativen aus? Lattice? Altera? Hatte Atmel
nicht auch mal welche? Schauts da irgendwo von der Politik besser aus?
Also Bastler-kompatible Chips in lötbaren Gehäusen, 5V, viele
Makrozellen auch in ICs mit wenig Pins, brauchbare Entwicklungs-
umgebung zum schenk-ichs-Dir-jetzt/kaufts-dein-Chef-später Deal?

Gruß,
Michael.

 

[Rainer Buchty]

In article <at3r109lj2n0radme77f6nv86pr3fdgir9@4ax.com>,
Michael Eggert <m.eggert.nul@web.de> writes:
|> Wie siehts denn mit Alternativen aus? Lattice? Altera? Hatte Atmel
|> nicht auch mal welche? Schauts da irgendwo von der Politik besser aus?
|> Also Bastler-kompatible Chips in lötbaren Gehäusen, 5V, viele
|> Makrozellen auch in ICs mit wenig Pins, brauchbare Entwicklungs-
|> umgebung zum schenk-ichs-Dir-jetzt/kaufts-dein-Chef-später Deal?

Du meinst "verursacht hohe Kosten in der Fertigung, darf aber den -- sowieso
keine Stückzahlen abnehmenden -- Endkunden darüberhinaus nichts kosten?"

Soweit ich weiß, hat die Heilsarmee noch keine Fab

Rainer

 

[Georg Acher]

In article <at3r109lj2n0radme77f6nv86pr3fdgir9@4ax.com>,
Michael Eggert <m.eggert.nul@web.de> writes:

|> Vielleicht dachte man, man könne ja an den Hobbyisten auch noch ein
|> bissl verdienen. Scheint aber wirklich nur als "Abfallprodukt" vom
|> großen Markt gesehen zu werden.
|>
|> Ich verstehs einfach nicht. Ich meine, wenn ich mir fürs Hobby jetzt
|> einen Einblick verschaffe ins Produktspektrum von Xilinx, und mich in
|> die Software von Xilinx einarbeite - dann ist es doch logisch, daß ich
|> dann wenn ich "auf Arbeit" mal programmierbare Logik nehme, auch von
|> Xilinx kaufe. Einfach, weil die Einarbeitung wegfällt und time-to-
|> market reduziert ist, das freut den Chef und Xilinx auch, wenns ne
|> größere Serie wird. Nein, wo ich arbeite, wird nix verkauft. Aber wäre
|> ja möglich. Nun frag ich mich, ob _ich_ diesen Effekt überschätze oder
|> ob Xilinx ihn unterschätzt.

Dafür gibt es das Xilinx-University-Programm (XUP). Da gibts SW, Chips und Boards
billiger und teilweise (auf Antrag) auch kostenlos. Eine Uni ist ein besserer
Multiplikator als ein Einzelbastler.

Unverständlich ist für mich eher, warum es im Xilinx-E-Shop nur CPLDs gibt. Das
sind ja gerade die Teile, die man eh' fast überall bekommt. Spartan2 oder gar
Virtex bekommt man nur vom Distributor, und das auch nur mit Glück in kleinen
Stückzahlen und ohne Mondpreise.

|> Ja kenne ich doch, bin doch auch schon länger hier. Nur mal ehrlich:
|> Hättest Du das getan, wenn Du irgendeine Alternative gehabt hättest?

Sagen wir mal so: Gejuckt hat's mich schon lange, die Anforderungen (>160IOs)
waren ein passender Anlass, das mal zu probieren.

|> Wieviele Leute kennst Du, die mit programmierbarer Logik arbeiten, und
|> wieviele, die das BGA-Löten nachgemacht haben?

Ich kenn ja schon kaum Leute, die was mit programmierbarer Logik machen ;-) Gut,
liegt evtl. auch am Umfeld (fast alles so Weichei-Informatiker...)

|> Letztendlich läufts darauf hinaus, daß man mehrere Versionen auf dem
|> Rechner hat. Die ISE Classic 4.2i für Spartan und 4000. Und was ist
|> brauchbar für 9500er? 5.1? 5.2?

Webpack 6.1i soll noch XC95 können.

--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[Uwe Bonnes]

Michael Eggert <m.eggert.nul@web.de> wrote:

: Okay, da hab ich mich wohl getäuscht
: Ich dachte echt, 100000er Chargen an Hardware würden mehr bringen als
: eine verkaufte Entwicklungsumgebung.

Nicht, wenn man fuer jede Softwarelizenz an externe Firmen fuer extern
eingekaufte Programme richtig Geld abdruecken muss.

Erst ab ISE sind alle Programme Xilinx Eigenentwicklung oder zumindestens
Eigentum. Dann kann man damit anders umgehen. Und die Synthese von XST
(Eigenentwicklung) kann halt nicht die alten Bausteine...

Bye
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Michael Eggert]

On Mon, 2 Feb 2004 10:14:08 +0000 (UTC),
buchty@atbode100.informatik.tu-muenchen.de (Rainer Buchty) wrote:

Hi!

|> Also Bastler-kompatible Chips in lötbaren Gehäusen, 5V, viele
|> Makrozellen auch in ICs mit wenig Pins, brauchbare Entwicklungs-
|> umgebung

Du meinst "verursacht hohe Kosten in der Fertigung, darf aber den -- sowieso
keine Stückzahlen abnehmenden -- Endkunden darüberhinaus nichts kosten?"

Nein, eher "lassen wir die alten und bewährten Produktionsstraßen, die
inzwischen gegen alle Kinderkrankheiten immun sind, und deren
veraltete Technik wir eh für nix neues nehmen können, doch noch ein
wenig weiterlaufen und verkaufen die inzwischen längst überholten ICs
trotzdem zu dem gleichen Preis, mit dem wir früher nicht nur fette
Gewinne gefahren, sondern auch noch die Entwicklungskosten
rausbekommen haben."

Soweit ich weiß, hat die Heilsarmee noch keine Fab

Warum gibts dann überhaupt noch bedrahtete Bauelemente? Sind
SMD-Bestückungsroboter immer noch teurer als 1000 flinke Kinderhände?

Gruß,
Michael.