VHDL und Xilinx CPLDs

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

Reply to
Michael Eggert
Loading thread data ...

|> 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
Reply to
Georg Acher

Hi!

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]

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

Gruß, Michael.

Reply to
Michael Eggert

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

Reply to
Georg Acher

Hi!

Ports

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

Genau das will ich ja, fein.

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.

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.

Naja, es _ist_ ja schon asynchron.

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.

Reply to
Michael Eggert

|> 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
Reply to
Georg Acher

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

Reply to
robka

Hi!

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

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

Reply to
Michael Eggert

: 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 ----------
Reply to
Uwe Bonnes

Hi!

[Versionen bei Xilinx]

Beziehst Du Dich auf die 5.2?

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.

Reply to
Michael Eggert

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

formatting link

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
Reply to
Georg Acher

Hi!

Soweit die Theorie. Schaut man aber hier:

formatting link
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

formatting link
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

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

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

Gruß, Michael.

Reply to
Michael Eggert

|> Soweit die Theorie. Schaut man aber hier: |>

formatting link
|> 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 |>

formatting link
|> 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 |>

formatting link
|> 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
Reply to
Georg Acher

Hi!

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.

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! :-)

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.

Reply to
Michael Eggert

|> >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
Reply to
Georg Acher

Hi!

Ja, nett is das nicht.

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

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

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

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.

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?

einige

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?

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.

Reply to
Michael Eggert

In article , Michael Eggert 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

Reply to
Rainer Buchty

|> 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
Reply to
Georg Acher

: 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 ----------
Reply to
Uwe Bonnes

Hi!

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

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

Gruß, Michael.

Reply to
Michael Eggert

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.