Günstiger Echtzeiteinplatinenrechner

[Olaf Kaluza]

Joerg <notthisjoergsch@removethispacbell.net> wrote:

In Firmen kommt da allerdings eine Menge bei rum.

Das ist klar, meinte ich aber nicht.

Die meisten FPGA sind ziemliche
Schluckspechte, fuer Batteriebetrieb daher ungeeignet und manche
sind in

Aber laengst nicht alles ist fuer Batteriebetrieb gedacht, oder
braucht dann eine lange Laufzeit.

Sachen Power Sequencing echt die Prinzessin auf der Erbse.

Digikey hat auch noch einen TPS75003RHLR der alles aus einer Hand
liefert. Aber ich geb zu, das drumherum also erstmal drei Spannungen
zu erzeugen und dann noch das Plattformflash anzubinden ist ein wenig
abtoernend.


Olaf

 

[Olaf Kaluza]

Frank Buss <fb@frank-buss.de> wrote:

Ja, die sind schon schön. Kosten aber immer noch recht viel und die
Verfügbarkeit ist auch manchmal ein Problem.

Naja, ich hab die Preise ja hier genannt. Ich finde das eigentlich
nicht teuer.

Hatte da mal bei Altera einen
preiswerten gefunden und nachgefragt, aber die konnten nicht mehrere Jahre
garantieren und der nächstgrößere, bei dem die Verfügbarkeit besser war,
kostete dann ein mehrfaches davon, wie das mit konventioneller Logik (plus
IO-Expander usw.) zu lösen.

Alles richtig, aber ich rede hier von privater Nutzung. Fuer die Firma
wuerde ich FPGAs auch etwas kritischer sehen.

Bei einem FPGA muss man sich erstmal in eine komplexe IDE und Umbgebung
einarbeiten,

Dafuer gibt es jede Menge Seiten im Internet die sich damit
beschaeftigen. Ich geb zu die Oberflaeche von Xilinx ist was komfort
und Geschwindigkeit angeht debil/grenzwertig, aber an Anleitungen
mangelt es nicht. Ich hab sie mir jetzt aber unter Linux installiert
und werde das ganze wohl in Zukunft mit einem makefile machen.

eine neue Sprache lernen, die nur oberflächlich
Gemeinsamkeiten mit C (Verilog) oder Pascal (VHDL) hat und ansonsten eher
deklarativ ist, wie XSLT oder SQL, was bei einer

Da wird es etwas komplizierter, besonders weil der FPGA manchmal nicht
das macht was man da als Source hinschreibt. Aber da liegt ja auch
gerade der Reitz des neuen. Sonst koennte ich ja auch
Kreutzwortraetzel loesen.

Aber wenn man es braucht, z.B. viele schnelle Signale routen und
verarbeiten, dann gibt es kaum Alternativen.

Mich beeindruckt vor allem die muehelose Geschwindigkeit bei seriellen
Anbindungen. Ich hab da gerade zu Testzwecken ein SM5807 und ein
PMC60P dran (aus defektem CD-Player) und schwupp hab ich 2x16Bit
DA-Wandler und erzeug mir da einen Sinus mit DDS.

Olaf

 

[Johannes Bauer]

Heiko Nocon schrieb:

Nein, gehört sie nicht. Du sprichst offenbar lediglich von preemtiven
Multitasking

Natürlich. Bei jedem anderen Konzept stellt nicht das Betriebssystem das
Echtzeitverhalten sicher, sondern ausschließlich die Tatsache, daß
_alle_ Anwendungen fehlerfrei und kooperativ sind. Schon eine einzelne
Anwendung, die das nicht ist, schickt das ganze Konstrukt in den Garten.

Und genau so ist das eben bei vielen Echtzeit-Betriebssystemen. Du
scheinst offenbar eine sehr enge Definition eines Betriebssystems zu
haben. Hast du schonmal mit OSEK oder AutoSAR gearbeitet? Auch dort kann
nicht ausschließlich das Betriebssystem das Echtzeitverhalten
sicherstellen, da der Programmierer trotzdem fehlerfreie Anwendungen
dafür schreiben muss. Beispielsweise muss der Programmierer allokierte
Resourcen immer zurückgeben, um undefiniertes Verhalten zu vermeiden und
solche Sachen. Auch mit Preemtion kannst du nichts mehr retten, wenn der
Programmierer schlecht ist.

Das ist Unsinn. Die meisten üblichen ľC sind geeignet, weil sie eine
Antwortzeit garantieren können, sofern die darauf laufende Anwendung
korrekt ist.

Genau das habe ich geschrieben. Es sind Echtzeit-Anwendungen damit
möglich, aber es kann eben kein Echtzeit-OS darauf laufen.

Und genau das habe ich bestritten. Es kann sehrwohl auf einem AVR ein
OSEK laufen, das ist ein Echtzeit-OS. Echtzeitbetriebssysteme im
Embedded-Bereich laufen viel häufiger ohne MMU, Speicherschutz und
Privilegierung als du dir vorstellen kannst.

Viele Grüße,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electronics <47fa8447$0$11545$9b622d9e@news.freenet.de>

 

[Albrecht Mehl]

Albrecht Mehl schrieb:

Rafael Deliano schrieb:
RTOS-UH und Pearl
Pearl-Vereins gibts noch ?

Nicht als Verein. Die Nachfolge hat eine Fachgruppe innerhalb der
Gesellschaft für Informatik übernommen, siehe

http://www.real-time.de/

Zu RTOS-UH möchte ich

http://www.irt.uni-hannover.de/rtos/

zu der Echtzeithochsprache PEARL, die um einiges handlicher als
die C-Familie ist,

http://www.irt.uni-hannover.de/pearl/

nachtragen.

A. Mehl
--
Albrecht Mehl |eBriefe an:mehl bei freundePunkttu-darmstadtPunktde
Schorlemmerstr. 33 |Tel. (06151) 37 39 92
D-64291 Darmstadt, Germany|sehenswert - ungefähr 'Wir einsam im All'
http://www.phrenopolis.com/perspective/solarsystem/index.html

 

[Gerhard Hoffmann]

On Fri, 01 Aug 2008 17:08:49 -0700, Joerg <notthisjoergsch@removethispacbell.net> wrote:

Das ist genau das Problem und die Hersteller raffen das seit 20 Jahren
nicht. Selbst fuenf Jahre waere fuer meine Kunden nicht akzeptabel.

Danach kommt was kommen muss: Das gute alte FPGA gibt es eines schoenen
Tages nicht mehr, nach Murphy passiert das natuerlich im Mai, wo alle

... grausige Geschichten vom Krieg, ja damals in den Ardennen ....

Es gibt alte xc3000 und xc4000-Designs von mir, die meine Kunden immer
noch bauen.
Die Chips sind noch zu haben, wenn auch etwas teurer als zu ihren Mainstream-Zeiten.
Das 3020 war immerhin ein Zeitgenosse des 80286 und in ein Virtex5
passt 1000 * so viel wie in ein 3090.

Die historischen Tools gibt's im Xilinx-Museum noch zum Download.
Das Problem dürfte eher sein, einen Rechner bereitzuhalten mit DOS 5,
memory extendern und ET4000-VGA. XACT machte damals 100 mal/Sekunde
einen Rücksturz in den Real-Mode des Prozessors damit der Maustreiber lief.

Drucken ist allerdings kein Problem, weil DOS-Orcad schon PostScript konnte.


Gruß, Gerhard

 

[Rafael Deliano]

Mich interessieren aber mehr Kommentare zu der angekündigten Ausstattung
des Rechners. Daher wären Hinweise und Vergleiche mit Konkurrenzprodukten
willkommen.

Roher Einplatinencomputer: da war der PowerPC ( den Freescale inzwischen
Power Architecture genannt haben will um von der PC-Flop-Ecke
wegzukommen ) nie sehr gängig. Es gibt schmale Nischen wie rad-hard wo
er sich noch halten wird, weil der Entwicklungszyklus dort viel länger
ist.

Einplatinencomputer mit vorinstallierter Software: da ist RTOS-UH/Pearl
kaum ein großes Zugpferd ausserhalb des bestehenden Anwenderkreises
( der aber nicht in dieser newsgroup versammelt ist ).
Technisch war und ist bei Ada ( vgl das vor sich hin dümpelnde AVR-Ada )
und Pearl das Problem daß die Erfindung des 8 Bit Mikroprozessors
nicht verdaut wurde. FORTH in Sparversion paßt in DIL40 8 Bit
Controller: http://www.embeddedforth.de/GP32/GP32info.html
Was nicht besagt daß dafür viel mehr Nachfrage existiert. Aber es gibt
halt viel mehr kleine Applikationen wo ein experimentierfreudiger
Einzelanwender mit kleinem Budget Gehversuche machen will und dann auch
was exotisches ins Auge faßt.

MfG JRD

 

[Klaus Rotter]

Gerhard Hoffmann schrieb:

Die historischen Tools gibt's im Xilinx-Museum noch zum Download.

Wo findet man denn das Xilinx Museum?

Grüße, -Klaus

--
Klaus Rotter * klaus at rotters dot de * www.rotters.de

 

[Gerhard Hoffmann]

On Sat, 02 Aug 2008 10:53:26 +0200, Klaus Rotter <klaus.removeme@rotters.de> wrote:

Gerhard Hoffmann schrieb:
Die historischen Tools gibt's im Xilinx-Museum noch zum Download.

Wo findet man denn das Xilinx Museum?

http://www.xilinx.com/ise/logic_design_prod/classics.htm

 

[Helmut Sennewald]

"Gerhard Hoffmann" <dk4xp@hoffmann-hochfrequenz.de> schrieb im Newsbeitrag
news:e45894tt09qed2e7jiggqmdbn5jrqseubn@4ax.com...

On Fri, 01 Aug 2008 17:08:49 -0700, Joerg
notthisjoergsch@removethispacbell.net> wrote:

Das ist genau das Problem und die Hersteller raffen das seit 20 Jahren
nicht. Selbst fuenf Jahre waere fuer meine Kunden nicht akzeptabel.

Danach kommt was kommen muss: Das gute alte FPGA gibt es eines schoenen
Tages nicht mehr, nach Murphy passiert das natuerlich im Mai, wo alle

... grausige Geschichten vom Krieg, ja damals in den Ardennen ....



Es gibt alte xc3000 und xc4000-Designs von mir, die meine Kunden immer
noch bauen.
Die Chips sind noch zu haben, wenn auch etwas teurer als zu ihren
Mainstream-Zeiten.
Das 3020 war immerhin ein Zeitgenosse des 80286 und in ein Virtex5
passt 1000 * so viel wie in ein 3090.

Die historischen Tools gibt's im Xilinx-Museum noch zum Download.
Das Problem dürfte eher sein, einen Rechner bereitzuhalten mit DOS 5,
memory extendern und ET4000-VGA. XACT machte damals 100 mal/Sekunde
einen Rücksturz in den Real-Mode des Prozessors damit der Maustreiber
lief.

Drucken ist allerdings kein Problem, weil DOS-Orcad schon PostScript
konnte.


Gruß, Gerhard

Hallo,

noch ein kleiner Hinweis. Ich erinnnere mich daran,
dass die Software für dei XC3000,4000 nur bis
Prozessoren mit 450MHz noch einigermaßen stabil lief.
Je schneller dann die Prozessoren wurden, um so
häufiger stürzte die Xilinx Software ab.

Rein aus Neugier, auf welchem Rechner laufen bei
dir die alten Tools? Auch auf einem aktuellen GHz-PC?
Gibt es da einen Trick damit die SW auch auf schnellen
Rechnern läuft. Man weiß ja nie ob man es nicht doch
nochmal braucht.

Gruß
Helmut

 

[Gerhard Hoffmann]

On Sat, 2 Aug 2008 11:47:40 +0200, "Helmut Sennewald" <helmutsennewald@t-online.de> wrote:

noch ein kleiner Hinweis. Ich erinnnere mich daran,
dass die Software für dei XC3000,4000 nur bis
Prozessoren mit 450MHz noch einigermaßen stabil lief.
Je schneller dann die Prozessoren wurden, um so
häufiger stürzte die Xilinx Software ab.

Rein aus Neugier, auf welchem Rechner laufen bei
dir die alten Tools? Auch auf einem aktuellen GHz-PC?
Gibt es da einen Trick damit die SW auch auf schnellen
Rechnern läuft. Man weiß ja nie ob man es nicht doch
nochmal braucht.

Ich habe das etwa bis zum Pentium-Pro so gehandhabt. 300 MHz?
Das waren, wie gesagt,legacy designs die noch gebaut werden.
Dann FPGA-Express :-[ & VHDL.

Ich hab den alten Krempel noch auf MO disks ŕ 230 MB.
Sollte ich mal kopieren, solange es noch PCI-Slots für
den Adaptec auf den Motherboards gibt.

DOS-Orcad ging jedenfalls noch auf einem Athlon-4000.
Möglicherweise könnte man die alten Designs über
Altium-DXP in die Jetztzeit retten.

Hat jemand schon mal deren VHDL-bis-board-flow ausprobiert?

Gruß, Gderhard

 

[Heiko Nocon]

Johannes Bauer wrote:

Du
scheinst offenbar eine sehr enge Definition eines Betriebssystems zu
haben.

Nein. Ich habe nur eine sehr enge Definition von RTOS. Das ist genau die
Menge von OS, die aus eigener Kraft, unabhängig von der Güte der darauf
laufenden Anwendungen sicherstellen kann, daß immer alle fehlerfreien
Anwendungen in Echtzeit antworten, egal was der eventuell vorhandene
kaputte Dreck gerade anstellt.

Hast du schonmal mit OSEK oder AutoSAR gearbeitet? Auch dort kann
nicht ausschließlich das Betriebssystem das Echtzeitverhalten
sicherstellen, da der Programmierer trotzdem fehlerfreie Anwendungen
dafür schreiben muss.

Dann sind es zwar OS, die Echtzeitanwendungen unterstützen, aber noch
lange keine Echtzeit-OS.

Auch mit Preemtion kannst du nichts mehr retten, wenn der
Programmierer schlecht ist.

Doch, genau das ist mit wirklichen Echtzeit-OS möglich. Bloß brauchen
die dazu halt, wie schon gesagt, eine entsprechende Hardwaregrundlage.

 

[Johannes Bauer]

Heiko Nocon schrieb:

Johannes Bauer wrote:

Du
scheinst offenbar eine sehr enge Definition eines Betriebssystems zu
haben.

Nein. Ich habe nur eine sehr enge Definition von RTOS. Das ist genau die
Menge von OS, die aus eigener Kraft, unabhängig von der Güte der darauf
laufenden Anwendungen sicherstellen kann, daß immer alle fehlerfreien
Anwendungen in Echtzeit antworten, egal was der eventuell vorhandene
kaputte Dreck gerade anstellt.

Das funktioniert aber nicht.

Beispiel: Ein RTOS, zwei Tasks gleicher Priorität, beide dürfen die
selbe Resource belegen. Mehrfachbelegung ist unzulässig (z.B. ein
Bandlaufwerk o.ä.). Ein Task ist "kaputter Dreck", belegt eine Resource
und hängt sich dann auf. Das Betriebssystem *kann* hier die fehlerfreie
Anwendung niemals schedulen, weil die Resource nicht frei ist und
Resourcen nicht schadfrei entzogen werden können. Das kriegst du mit
noch so viel Hardwareunterstützung eben nicht hin.

Viele Grüße,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electronics <47fa8447$0$11545$9b622d9e@news.freenet.de>

 

[Raimund Nisius]

Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:

Heiko Nocon schrieb:
Johannes Bauer wrote:

Nein. Ich habe nur eine sehr enge Definition von RTOS. Das ist genau die
Menge von OS, die aus eigener Kraft, unabhängig von der Güte der darauf
laufenden Anwendungen sicherstellen kann, daß immer alle fehlerfreien
Anwendungen in Echtzeit antworten, egal was der eventuell vorhandene
kaputte Dreck gerade anstellt.

Das funktioniert aber nicht.

Beispiel: Ein RTOS, zwei Tasks gleicher Priorität, beide dürfen die
selbe Resource belegen. Mehrfachbelegung ist unzulässig (z.B. ein
Bandlaufwerk o.ä.). Ein Task ist "kaputter Dreck", belegt eine Resource
und hängt sich dann auf. Das Betriebssystem *kann* hier die fehlerfreie
Anwendung niemals schedulen, weil die Resource nicht frei ist und
Resourcen nicht schadfrei entzogen werden können. Das kriegst du mit
noch so viel Hardwareunterstützung eben nicht hin.

Warum soll eine Echtzeit Task Resourcen belegen, die nicht zum
Echtzeitbetrieb gehören? Ich meine jetzt nicht den Plattentreiber.
Die kaputte Task bekommt einen oder viele Handles auf Elemente des
Dateisystems und darf die dahinter stehenden Festplattenbereiche
zumüllen wie sie lustig ist. Das gute OS hält Zeit und Platz für die
anderen Tasks frei.

Es ist dann ganz alleine das Problem der kaputten Task, wenn sie nur
noch IO-Error bekommt.

--
Gruß, Raimund
Mein Pfotoalbum <http://www.raimund.in-berlin.de>
Mail ohne Anhang an <Reply-To:> wird gelesen. Im Impressum der Homepage
findet sich immer eine länger gültige Adresse.

 

[MaWin]

"Johannes Bauer" <dfnsonfsduifb@gmx.de> schrieb im Newsbeitrag
newsordm5xkg7.ln2@joelaptop.homelan.net...

Das funktioniert aber nicht.
Beispiel:

Dein Beispiel zeigt nur, dass auch ein RTOS dem Anwendungsentwickler
nicht das Nachdenken abnimmt.
--
Manfred Winterhoff

 

[Johannes Bauer]

MaWin schrieb:

"Johannes Bauer" <dfnsonfsduifb@gmx.de> schrieb im Newsbeitrag
newsordm5xkg7.ln2@joelaptop.homelan.net...
Das funktioniert aber nicht.
Beispiel:

Dein Beispiel zeigt nur, dass auch ein RTOS dem Anwendungsentwickler
nicht das Nachdenken abnimmt.

Und *exakt* das wollte ich damit zeigen. Das beste RTOS kann nicht
verhindern, dass ein schlechter Programmierer das System in den Abgrund
reißt.

Viele Grüße,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electronics <47fa8447$0$11545$9b622d9e@news.freenet.de>

 

[Johannes Bauer]

Raimund Nisius schrieb:

Warum soll eine Echtzeit Task Resourcen belegen, die nicht zum
Echtzeitbetrieb gehören?

Die Resource ist beliebig, ein CD-Laufwerk war ja nur ein (wohl
schlechtes) Beispiel. Denk dir doch einfach ein Funksendemodul, dass in
Echtzeit Daten absetzen muss. Der Task holt sich die Resource (also die
exklusiven Rechte auf das Modul), aber der "Mülltask" hängt sich in
einer Busy-Waiting-Schleife auf, weil er schlecht programmiert ist.

Das beste RTOS kann nichts mehr ausrichten (auch nicht mit
Hardwareunterstützung), wenn der Programmierer pfuscht. Und das war
genau der Punkt.

Viele Grüße,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electronics <47fa8447$0$11545$9b622d9e@news.freenet.de>

 

[Rafael Deliano]

Den Simulator zur Ausbildung der X15-Piloten haben sie noch als
Analogrechner gebaut,
Gute Beschreibung dazu:

http://www.embeddedforth.de/temp/x15sim.pdf
Demnach war schon 1961 klar daß das nicht gut mit Analogrechner
zu bewältigen war. Grund sieht man auf Seite 6 unten:
"nonlinear computing equipment" ist unhandlich.

MfG JRD

 

[Heiko Nocon]

Johannes Bauer wrote:

Beispiel: Ein RTOS, zwei Tasks gleicher Priorität, beide dürfen die
selbe Resource belegen. Mehrfachbelegung ist unzulässig (z.B. ein
Bandlaufwerk o.ä.)

Unteilbare Resourcen können durch _kein_ OS so verwaltet werden, daß
Tasks, die diese benutzen wollen, sich gegenseitig nicht blockieren
können, das ist doch logisch.

Man braucht übrigens nichtmal zwei Tasks zu bemühen. Einer und eine
Resource, die nicht zuverlässig benutzbar ist, reicht bereits. (In
deinem Beispiel: Kopf des Streamers dreckig)

In beiden Fällen gilt: Fehlerfreie Anwendungen müssen mit der Situation
klarkommen, daß die Resource nicht verfügbar ist.

Der springende Punkt ist:

Echte RTOS laufen in beiden Situationen weiter und betreiben alle Tasks,
die nicht auf die nicht verfügbare Resource zugreifen, ohne
Einschränkungen weiter. Und natürlich auch die Tasks, die die Resource
benutzen wollen, aber darauf vorbereitet sind, daß diese nicht verfügbar
ist. Fehlerfreie Anwendungen halt.

 

[Rafael Deliano]

zu der Echtzeithochsprache PEARL, die um einiges handlicher als
die C-Familie ist,
http://www.irt.uni-hannover.de/pearl/

Etwas lieblose Darstellung des historischen Teils.
Soweit ich mich erinnere startete die Entwicklung als Sprache für
Prozeßrechner in den End-60ern. Wurde in den 70ern mit
einigen Millionen BMFT-Fördermitteln aus dem Programm
mittlere Datentechnik vorangetrieben. Das Problem war
aber die Zersplitterung in nationale Programme ( UK: CORAL 66,
RTL/2 ; Frankreich: LTR ). Es hatte das Wohlwollen der
deutschen Hersteller für Prozessrechner ( Siemens, AEG usw. )
das war aber auch der einzig verfügbare Markt dafür.
Als in den USA ab 1975 die Vorentwicklung für Ada anlief wurde
auch PEARL formal untersucht. ( C wurde nicht untersucht weil
Bell Labs auf Anfrage des DoD mitteilte die geforderten
Anforderungen an Lesbarkeit, Sicherheit wären damit nicht
erreichbar ).
Anfang der 80er schwenkte man hierzulande politisch korrekt
auf den großen Bruder ein und Uni Karlsruhe entwickelte bezahlt
vom Verteidungsministerium für Siemens 7000 einen Ada-Compiler.
Letztlich war Pearl als nationales Programm damit auf dem
Abstellgleis.

MfG JRD

 

[Joerg]

Helmut Sennewald wrote:

"Gerhard Hoffmann" <dk4xp@hoffmann-hochfrequenz.de> schrieb im Newsbeitrag
news:e45894tt09qed2e7jiggqmdbn5jrqseubn@4ax.com...
On Fri, 01 Aug 2008 17:08:49 -0700, Joerg
notthisjoergsch@removethispacbell.net> wrote:

Das ist genau das Problem und die Hersteller raffen das seit 20 Jahren
nicht. Selbst fuenf Jahre waere fuer meine Kunden nicht akzeptabel.
Danach kommt was kommen muss: Das gute alte FPGA gibt es eines schoenen
Tages nicht mehr, nach Murphy passiert das natuerlich im Mai, wo alle
... grausige Geschichten vom Krieg, ja damals in den Ardennen ....


Es gibt alte xc3000 und xc4000-Designs von mir, die meine Kunden immer
noch bauen.
Die Chips sind noch zu haben, wenn auch etwas teurer als zu ihren
Mainstream-Zeiten.
Das 3020 war immerhin ein Zeitgenosse des 80286 und in ein Virtex5
passt 1000 * so viel wie in ein 3090.

Die historischen Tools gibt's im Xilinx-Museum noch zum Download.
Das Problem dürfte eher sein, einen Rechner bereitzuhalten mit DOS 5,
memory extendern und ET4000-VGA. XACT machte damals 100 mal/Sekunde
einen Rücksturz in den Real-Mode des Prozessors damit der Maustreiber
lief.

Drucken ist allerdings kein Problem, weil DOS-Orcad schon PostScript
konnte.


Gruß, Gerhard

Hallo,

noch ein kleiner Hinweis. Ich erinnnere mich daran,
dass die Software für dei XC3000,4000 nur bis
Prozessoren mit 450MHz noch einigermaßen stabil lief.
Je schneller dann die Prozessoren wurden, um so
häufiger stürzte die Xilinx Software ab.

Rein aus Neugier, auf welchem Rechner laufen bei
dir die alten Tools? Auch auf einem aktuellen GHz-PC?
Gibt es da einen Trick damit die SW auch auf schnellen
Rechnern läuft. Man weiß ja nie ob man es nicht doch
nochmal braucht.

Falls das der Borland Runtime Error sein sollte, dagegen gibt es ein
Medikament. Auch ohne Neu-Kompilieren.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.