ct-Basic 2.3 ISE Übersetzungsprobleme

Das Forum für die Software der FPGA-Basisplatine
VGOE
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 45
Registriert: 26.10.2009, 10:56

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von VGOE » 15.12.2009, 18:25

So,
ich habe jetzt mal das von mir generierte main.bit geladen. Alle Dateien sind ansonsten identisch mit der Version ct-Basic 2.3.

Resultat:

Der Kern scheint zu funktionieren (BREAK für Neustart, Initialisierung usw.),
ebenso die Kommunikation zum AtMega (DIR, LOAD ...)
leider ist die Bildschirmdarstellung völlig unbrauchbar.
Nach dem Start wird ein teilweise zerstörter Startbildschirm ausgegeben (inkl. kleinem Farbbalken),
die Kommandos und Ergebnisse (DIR) werden in eine einzige Zeile geschrieben,
der LOAD und RUN (IOTEST0.BAS) funktioniert anscheinend, nur die Ausgabe ist teilweise durch völlig falsche Werte und Positionen zerstört. Es kann zwar eine Tabellenstruktur erkannt werden, jedoch ist die Positionierung der Werte eher unstrukturiert.
Ich denke, es gibt Probleme mit der Verlagerung des Video-Rams in den FPGA und damit zu unkoordinierten Zugriffen.
Ich denke, die Version ist noch nicht der Stand, mit dem die fertige main.bit erzeugt wurde, bzw. es fehlen noch wichtige Einstellungen im Projekt.
Aufgefallen ist mir, dass in der Projektstruktur 2 Einträge weiterhin mit einem gelben Fragezeichen gekennzeichnet sind: beides sind Konstantendefinitionen, im Schaltbild die beiden linken kleinen Kästchen neben dem ISP Interface.

Soviel für den Moment....

CU
Volker

PS: Die ISE Version ist 10.1.
Zuletzt geändert von VGOE am 16.12.2009, 18:59, insgesamt 1-mal geändert.

Klaus_Phi
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 23
Registriert: 26.01.2008, 13:20
Wohnort: Achim

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von Klaus_Phi » 15.12.2009, 23:01

Hallo Volker, hallo Paul,

zunächst muß ich gestehen, ich habe einen Fehler gemacht. Ich hätte schreiben müssen, daß ich die Untersuchung des ct-BASIC-2.3 Designs mit der ISE Version 10.3 durchgeführt hatte. Das war meine Schuld und ich werde diesen Fehler in Zukunft nicht wiederholen.
Ach wenn es jetzt merkwürdig erscheint, ich arbeite seit 10 Jahren mit dem ISE-Software-Paket. XILINX hat immer wieder Verbesserungen vorgenommen und neue „Features“ eingebaut.
Die Software ist eben sehr komplex und es ist nahezu unmöglich alle Fehler zu beseitigen.

Es gibt jedoch einige „does and don’ts, die man berücksichtigen sollte.

Ich verwende in den Dateinamen niemals – . oder Blank. Bevor ich ein Projekt bearbeite, entferne ich den Schreibschutz auf dem Projektordner. Wenn irgendeine Datei nicht schreibbar sein sollte, kann es zu sehr merkwürdigen Fehlermeldungen kommen. Die fallen dann unter die Rubrik „Stunden später“.

Eine weiter Punkt sind die ISE Optionen. Dazu könnt ihr einfach unter dem Projektpunkt „Implement Design“ mit einem rechts Klick ein neues Fenster öffen und sehen, was man sich von ISE alles wünschen kann. Betreiber eines „Rotlicht Etablissements“ würden in Erfurcht erstarren. Aber das gehört nicht hier her. (Dazu hätte ich auch keine Zeit, die Überlegung war rein hypotethisch.)

Da in der Elektronik Geschwindigkeit alles ist, setze ich zuerst alle Parameter auf „Speed“. Leider führte dies nicht zu besseren Ergebnissen.

cm hat alle Parameter geeignet gesetzt und ein fehlerfrei lauffähiges main.bit erzeugt. Wenn wir nun versuchen die Probleme mit der neu Übersetzung zu beseitigen, würden wir nur versuchen Probleme lösen, die cm bereits erfolgreich gelöst hat. Das ergibt nur den Sinn, sich in ISE einzuarbeiten.

Wenn man jedoch mit Erfolg neue Projekte durchführen will, kommt man an der "ISE-Lernkurve" nicht vorbei.

ISE 10.3 verwende ich nur deshalb, weil ich noch mit dem "Embedded Developer Kit 10.3" arbeite. Wenn ich ein update auf webpack 11 durchführen würde, könnte ich mit dem EDK nicht mehr arbeiten. Aber das ist ein anderes Problem.

Ich weiß aus eigener Erfahrung wie schwer es ist, mit Projektmanagern zu verhandeln. Wir müssen cm den Rücken stärken.
75 Seiten ct-Lab sind ein hervorragendes Ergebnis. (Rekord). Wenn der Heise Verlag denken sollte, das ct-Lab könnten sie zu den Akten legen, dann täuschen sie sich. Wir fangen gerade erst an. In der Community gibt es sehr viele kampferprobte Mitstreiter und junge Menschen die sehr viel lernen möchten.

Was wir daraus machen liegt an uns, ich bin auf jeden Fall dabei etwas besseres daraus zu machen.

Mit freundlichen Grüßen

Klaus Philipp

Roddot
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 146
Registriert: 19.06.2008, 13:53

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von Roddot » 16.12.2009, 14:52

Klaus_Phi hat geschrieben:..... junge Menschen die sehr viel lernen möchten.
Klaus Philipp
Es gibt auch eine größere Menge "spätere" Menschen, die auch noch was von der Technik erlernen möchten, was in ihrer Jugend wie ein Geheimnis behandelt wurde. :-)
Na ja, war eigentlich nicht wirklich witzig.
Gut, dass es nun das W3 und solche Projekte gibt.

Was das mit dem Kämpfen auf sich hat, weiß ich nicht wirklich. Insider-Infos?
Will die C'T das Projekt nun gar nicht mehr?
Let's fets with Static-DC. :-)

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 879
Registriert: 25.01.2008, 23:34

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von psclab38 » 16.12.2009, 17:08

Klaus_Phi hat geschrieben:Hallo Volker, hallo Paul,
zunächst muß ich gestehen, ich habe einen Fehler gemacht. Ich hätte schreiben müssen, daß ich die Untersuchung des ct-BASIC-2.3 Designs mit der ISE Version 10.3 durchgeführt hatte. Das war meine Schuld und ich werde diesen Fehler in Zukunft nicht wiederholen.
Hallo Klaus, mir war schon klar, daß Du eine andere ISE-Version verwendest, drum hab ich meine Version immer dazugeschrieben. Bitte keine Gewissensbisse!
Die Irreführung liegt hier ganz eindeutig an der Eigenmächtigkeit des Werkzeugs.
Klaus_Phi hat geschrieben: Ach wenn es jetzt merkwürdig erscheint, ich arbeite seit 10 Jahren mit dem ISE-Software-Paket. XILINX hat immer wieder Verbesserungen vorgenommen und neue „Features“ eingebaut.
Die Software ist eben sehr komplex und es ist nahezu unmöglich alle Fehler zu beseitigen.
Sehr wahr! 8)
Klaus_Phi hat geschrieben:Eine weiter Punkt sind die ISE Optionen. ... Da in der Elektronik Geschwindigkeit alles ist, setze ich zuerst alle Parameter auf „Speed“. Leider führte dies nicht zu besseren Ergebnissen.
cm hat alle Parameter geeignet gesetzt und ein fehlerfrei lauffähiges main.bit erzeugt. Wenn wir nun versuchen die Probleme mit der neu Übersetzung zu beseitigen, würden wir nur versuchen Probleme lösen, die cm bereits erfolgreich gelöst hat. Das ergibt nur den Sinn, sich in ISE einzuarbeiten.
Meiner (etwas angestaubten) Erfahrung nach ist es durchaus sinnvoll, sich die Warnings und Infos näher anzuschauen, um vielleicht den Ursachen auf den Grund zu kommen. Ich hab' da im Vorbeiscrollen u. a. ein paar mal "bad design practice" gesehen, was nichts bedeuten muß, aber vielleicht kann. Ich krieg allerdings 416 Warnings und 44 Infos. Das wird mühsam.

Aber u. U. ist ja das Archiv wirklich nicht auf dem letzten Stand und wir jagen ein Phantom.
Klaus_Phi hat geschrieben:Wenn man jedoch mit Erfolg neue Projekte durchführen will, kommt man an der "ISE-Lernkurve" nicht vorbei.

Was wir daraus machen liegt an uns, ich bin auf jeden Fall dabei etwas besseres daraus zu machen.
Das ist doch mal die richtige Einstellung. :P

Viele Grüße
Paul

VGOE
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 45
Registriert: 26.10.2009, 10:56

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von VGOE » 16.12.2009, 19:26

Neue Fakten:

Die ISE in der Version 10.1.03(nt) in 2 identischen virtuellen Maschinen unter XP-SP3 installiert.
In beiden VMs die selbe Projektversion (ct-Basic 2.3 mit der hier geposteten main.ise) installiert.

Die erste VM erzeugt ein lauffähiges main.bit welches ohne Probleme funktioniert,
bei der zweiten VM wird ein main.bit erzeugt, welches beim DIR Befehl zwischen der # und der Subchannel Nummer sporadisch ein Leerzeichen einfügt. Ansonsten funktionieren beide main.bit gleich.
Nächste Compilation (ohne Änderungen) auf der 2ten VM bringt wieder die 118 Fehler im Translate Prozess.

Zumindest kann ich jetzt weiter arbeiten, aber so richtig einsichtig ist mir dieses Verhalten nicht.
Wie will man sich denn darauf verlassen, dass die Projekte zuverlässig reproduzierbar weiter entwickelt werden können?
Bei meinen Projekten kann ich jedenfalls nicht mir ruhigem Gewissen die WEB Software von Xilinx empfehlen.

Ach ja, das Manual zur IDE habe ich inzwischen ebenfalls durch gearbeitet ......
CU
Volker

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 879
Registriert: 25.01.2008, 23:34

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von psclab38 » 16.12.2009, 20:52

Hi Volker!
VGOE hat geschrieben: Wie will man sich denn darauf verlassen, dass die Projekte zuverlässig reproduzierbar weiter entwickelt werden können?
Soweit ich mich erinnere (korrigiert mich bitte), dann ist beim Place&Route immer eine gewisse Menge Zufall drin. Das heißt, bei zwei Läufen werden keine identischen Ergebnisse rauskommen. Das sollte eigentlich auf die Funktion keinen Einfluß haben, aber wenn die Ressourcen knapp werden, dann kann es passieren, daß nicht jeder Lauf erfolgreich ist.
Ich persönlich tippe aber erstmal auf die vielen Warnings, da könnte das Tool bei einigen Dingen vielleicht mal Recht haben?! :roll: Nicht umsonst sollte man beim "normalen" Programmieren auch versuchen, die Warnings des Compilers zu verstehen. Nur die wenigsten sind unbegründet..

Viele Grüße
Paul

VGOE
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 45
Registriert: 26.10.2009, 10:56

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von VGOE » 17.12.2009, 15:58

Hiho,
wenn jeder Lauf mit einem Grad an Zufall gepaart ist, bedeutete dies, das man ein fast bel. komplexes Projekt für verschiedenste Einsatzzwecke nutzen kann. Man muss nur lange genug die Router beschäftigen und schon hat man alle aktuellen und zukünftigen Probleme erschlagen. Ich hoffe nicht, dass auch nur das geringste bischen Zufall implementiert ist.
Das Problem ist ja, dass eine korrekt definierte Signalzuordnung plötzlich nicht mehr zugeordnet werden kann. Das deutet auf den Verlsut von Informationen hin, oder, schlimmer, auf gecachte Infos, die die aktuellen Infos einfach ersetzen.
CU
Volker

cm
Konstrukteur
Konstrukteur
Beiträge: 124
Registriert: 06.12.2007, 10:36
Wohnort: Hannover
Kontaktdaten:

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von cm » 17.12.2009, 19:23

ISE ist äußerst eigenwillig mit der Projektdatei. Manchmal reicht es schon, main.sch ein wenig zu verändern, und nichts geht mehr. Offensichtlich taucht das Problem aber nur auf, wenn das Top Level ein Schaltbild ist. Mit einem .VHD hatte ich noch nie (!) Probleme. Workaround wäre, main.sch einen VHD-Wrapper zu verpassen (nur 1:1-Routing) und das main.vhd dann als Top Level zu deklarieren.

Dieser ISE-Bug zieht sich jetzt schon über einige Versionen. Zum Übelwerden :twisted:

Beim Übersetzen mit anderen ISEs als der 10.1.03 rate ich zur Vorsicht: Die Midpoint-Geschichten (Grafik) sind eher nachlässig kodiert, was Typecasts angeht. Version 11 castet die Signale irgendwie anders. Vielleicht weiß Klaus Philip mehr dazu.

Ich nehme immer noch die 10er, weil die noch den grafischen Simulations-Editor hat. ISE 11 hat m.E. eine völlig andere Projektdatei-Struktur.
Carsten Meyer

Redaktion c't

cm
Konstrukteur
Konstrukteur
Beiträge: 124
Registriert: 06.12.2007, 10:36
Wohnort: Hannover
Kontaktdaten:

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von cm » 17.12.2009, 19:28

PS: Version 2.3g ist jetzt da, mit vielen Tastatur- und Detailverbesserungen. Ist online (jetzt immer in sdcard.zip, auch neues main.bit darin verwenden!). Es sollten jetzt wg. expliziter Initialisierung auch USB-Kombi-Tastaturen mit PS/2-Adapter funktionieren, meine taten es jedenfalls alle.
Carsten Meyer

Redaktion c't

umatthe
träumt vom eigenen c't-Lab
träumt vom eigenen c't-Lab
Beiträge: 5
Registriert: 08.10.2008, 23:20

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von umatthe » 17.12.2009, 20:26

Hi,

bisher konnte ich immer die FPGA-Configuration mit ISE funktionsfähig
nachbauen (Momentan mit ISE11.4).
Irgendwie muss man aber immer in den von cm gelieferten Projekten
etwas von Hand nachziehen.

So gehe ich normalerweise vor:
- main/main.xise als Project öffnen.
- In der Hierarchy nach "?" suchen und diese Files dann mit add Source hinzufügen.
Die "?" sollten dann verschwinden.

Bei beim aktuellen Projekt musste ich aus dem
Verzeichnis "source"
COM_mux.vhd
GTEXT.sch
bresenham.vhd
framer.vhd
parser.vhd
und aus dem Verzeichnis "main"
graph_mem.vhd
hinzufügen.
Dann lies sich mit ISE11.3 und ISE11.4 unter Linux und WinXP ein funktionsfähiges Config-File erzeugen.

Wieso diese Files betroffen sind, weiss ich leider nicht.

ciao
Udo

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 879
Registriert: 25.01.2008, 23:34

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von psclab38 » 17.12.2009, 22:05

VGOE hat geschrieben:wenn jeder Lauf mit einem Grad an Zufall gepaart ist, bedeutete dies, das man ein fast bel. komplexes Projekt für verschiedenste Einsatzzwecke nutzen kann. Man muss nur lange genug die Router beschäftigen und schon hat man alle aktuellen und zukünftigen Probleme erschlagen. Ich hoffe nicht, dass auch nur das geringste bischen Zufall implementiert ist.
Das Problem ist ja, dass eine korrekt definierte Signalzuordnung plötzlich nicht mehr zugeordnet werden kann. Das deutet auf den Verlsut von Informationen hin, oder, schlimmer, auf gecachte Infos, die die aktuellen Infos einfach ersetzen.
Hi Volker,
ich stimme Dir zu, wenn es sich um die Synthese handelt, also die logische Schaltung aus dem Konglomerat von Schematics, VHDL und sonstigen Logikblöcken zusammengebaut wird. Das sollte natürlich streng deterministisch sein, da hat der Zufall nichts verloren.
Aber ich bezog mich auf das Place&Route: wenn das Place&Route durchgeführt wird, dann gibt es (fast) unendlich viele Lösungen, die resultierende Schaltung aus der Synthese auf die Ressourcen des FPGA (Logikblöcke, Verbindungen, etc) abzubilden. Auch wenn der Prozeß da mittlerweile vermutlich mit sehr viel "Vorwissen" ausgestattet sein dürfte und entsprechende Strategien fährt, können aus dem Place&Route trotz Optimierungsalgorithmen x verschiedene Lösungen rauskommen. Die sollten natürlich alle funktionieren, wenn man die Constraints richtig und vollständig formuliert hat, denn nur dann kann der Place&Route Prozess das erforderliche Timing rauskitzeln.

cm hat geschrieben:PS: Version 2.3g ist jetzt da, mit vielen Tastatur- und Detailverbesserungen. Ist online (jetzt immer in sdcard.zip, auch neues main.bit darin verwenden!). Es sollten jetzt wg. expliziter Initialisierung auch USB-Kombi-Tastaturen mit PS/2-Adapter funktionieren, meine taten es jedenfalls alle.
Prima, vielen Dank. Wir werden's testen!

umatthe hat geschrieben:Dann lies sich mit ISE11.3 und ISE11.4 unter Linux und WinXP ein funktionsfähiges Config-File erzeugen.

Wieso diese Files betroffen sind, weiss ich leider nicht.
Hi Udo, mit dem von Dir beschriebenen Verfahren bin ich auch soweit gekommen und die Generierung lief durch. Nur leider funktioniert das Ergebnis nicht so hundertprozentig, die Bildschirmdarstellung ist nicht ganz deterministisch. Funktioniert das bei Dir denn reibungslos?

Viele Grüße
Paul

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 879
Registriert: 25.01.2008, 23:34

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von psclab38 » 17.12.2009, 22:41

cm hat geschrieben:PS: Version 2.3g ist jetzt da, mit vielen Tastatur- und Detailverbesserungen. Ist online (jetzt immer in sdcard.zip, auch neues main.bit darin verwenden!). Es sollten jetzt wg. expliziter Initialisierung auch USB-Kombi-Tastaturen mit PS/2-Adapter funktionieren, meine taten es jedenfalls alle.
Prima, ein erster Test mit der c't-Silikontastatur (USB+PS/2) war erfolgreich.
Allerdings gibt es ein reproduzierbares Problemchen: Die automatisch geladene LABINP.BAS wird mit dem Kommando "load" anstelle von "LOAD" geladen und das produziert dann einen "Syntax Error". Und das obwohl im Autoload.mac alles in Großbuchstaben steht.

Viele Grüße
Paul

umatthe
träumt vom eigenen c't-Lab
träumt vom eigenen c't-Lab
Beiträge: 5
Registriert: 08.10.2008, 23:20

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von umatthe » 17.12.2009, 22:45

Hi Paul,
Hi Udo, mit dem von Dir beschriebenen Verfahren bin ich auch soweit gekommen und die Generierung lief durch. Nur leider funktioniert das Ergebnis nicht so hundertprozentig, die Bildschirmdarstellung ist nicht ganz deterministisch. Funktioniert das bei Dir denn reibungslos?
soweit ist mir nichts besonderes aufgefallen. Das GTEST.BAS Demo
läuft wie gewohnt. Nur das Verschieben des Sinus-Displays wird
wohl nicht mehr mit den Strahlrücklauf syncronisiert, man sieht
es manchmal etwas blitzen (aber das macht die "original" cm 2.3
Konfiguration auch). Im Textmodus ist mir auch nichts aufgefallen.

ciao
Udo

VGOE
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 45
Registriert: 26.10.2009, 10:56

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von VGOE » 18.12.2009, 08:28

Hiho,
die Version 2.3g konnte ich mit der ISE 10.1.03(nt) AppVersion K.39 auf Anhieb ohne Fehler übersetzen.
Vielen Dank CM!!
CU
Volker

Ergänzung: Ich habe jetzt aus dem Schaltbild eine VHD Datei gemacht (VHF erzeugen und umbenennen :) , anschliessen die VHD Datei auf root-level einbinden und das Sheet vollständig entfernen. Bisher konnte ich ohne Probleme weiter compilieren. Wenn es wirklich daran liegt, dass kein Schaltbild als root Objekt angelegt sein darf, konnte der Fehler ja einfach behoben werden.

Ich teste weiter ....
CU
Volker

cm
Konstrukteur
Konstrukteur
Beiträge: 124
Registriert: 06.12.2007, 10:36
Wohnort: Hannover
Kontaktdaten:

Re: ct-Basic 2.3 ISE Übersetzungsprobleme

Beitrag von cm » 18.12.2009, 11:24

psclab38 hat geschrieben:Allerdings gibt es ein reproduzierbares Problemchen: Die automatisch geladene LABINP.BAS wird mit dem Kommando "load" anstelle von "LOAD" geladen und das produziert dann einen "Syntax Error". Und das obwohl im Autoload.mac alles in Großbuchstaben steht.

Viele Grüße
Paul
Uups. Da passiert wohl eine Buchstaben-Wandlung zuviel. Vielleicht funktioniert als vorläufiger Workaround, in der aufgerufenen MAC-Datei Kleinbuchstaben als Befehl zu verwenden, die dann wiederum in Literale gewandelt werden.

Grund ist der gemeinsame Interrupt-Buffer für die Pseudo-Eingaben vom Atmega und der "richtigen" von der Tastatur (läuft jetzt aus Platzgründen alles über eine Routine). Wahrscheinlich ist das Verhalten auch noch davon abhängig, ob CAPS-Lock an ist.

Hatte ich eigentlich schon über die schwachmatische Tastenkodierung bei PS/2-Tastaturen gejammert? Dann tu' ich das jetzt. Das Umsetzen der Codes erfordert gut 1 KByte kostbares 6502-ROM. Das reichte früher, um ein einfaches Schachprogramm unterzubringen! OK, das war beim ZX81, aber trotzdem.
Carsten Meyer

Redaktion c't

Antworten