Ich habe die Ehre erhalten, in einem ca. 15 Jahre alten CPLD Projekt "nur" einen Wert ändern zu müssen. Natürlich ist der ehemalige Entwickler schon lange aus der Firma ausgeschieden und nicht mehr greifbar.
Beim Versuch, ob es überhaupt noch möglich ist, das alte CPLD Projekt zu übersetzen, bekomme ich vom Synthezier gleich zwei Fehlermeldungen, mit denen ich als VHDL Entwickler nicht viel anfangen kann. Vielleicht gibt es ja hier Jemanden, der mal mit ADEL gearbeitet hat.
Als Entwicklungsumgebung steht mir Xilinx Foundation 3.1i zur Verfügung.
Du hast mit ABEL natürlich recht. Ich sollte mich beim Schreiben eines Beitrages nicht immer ablenken lassen. ;-)
Ich war der Meinung, alle wesentlichen Zeilen des Codes angegeben zu haben, da die anderen Signale davon unabhängig sind (sein sollten). Was eventuell fehlt sind die Sektionsangaben. Ich hoffe, dass es diesmal nun verständlicher ist. Ansonsten habe ich die komplette ABEL Datei als Anhang beigefügt.
Nein, ein Warning. Das wird nur von der IDE so gehandhabt dass
es gemeldet werden kann. Sollte man aber beheben so wie in C
Warnings oft ernst zu nehmen sind.
Ich bekomme beim Compilieren die gleichen Meldungen. Es wäre
hilfreich auch den Zielbaustein zu kennen. Ferner gibt es
vielleicht noch eim Constraints File?
Offensichtlich ist das nicht das Original das sich mal fehlerfrei
synthetisieren liess. Aktuell verstehe ich nicht was der Autor
mit der Zeile
Offensichtlich ist das nicht das Original das sich mal fehlerfrei
synthetisieren liess. Aktuell verstehe ich nicht was der Autor
mit der Zeile
Scheint mir auch so. Versuche die Original Files zu finden. Wenn die es noch zu finden gibt. Sonst hast du das Problem, dass wenn es sich synthetisieren lässt dass es eventuell doch noch alte Bug beinhaltet.
Anzeige = [Off,Off,On,On,On,Off,Off] & UVE.Q;
Ich kenne mich zwar mit ABEL nicht aus, aber so wie ich das sehe, ist das links eine Array, und rechts nur 1 bit. Wie soll dass denn gehen? Jede element mit UVE.Q verodern? Das würde vermutlich gehen. vielleicht braucht der tool dann das in eine andere Form?
Anzeige = [Off,Off,On,On,On,Off,Off] & [UVE.Q,UVE.Q,UVE.Q,UVE.Q,UVE.Q,UVE.Q,UVE.Q];
Es konnte auch sein dass du mit einer anderer Toolversion das versuchen sollt. Vielleicht hat man die Sprache über die Jahre geändert.
Ich kann kein ABEL, aber das ist doch offensichtlich die Ansteuerung einer 7-Segment-Anzeige mit den einzelnen Segmenten a-f in den eckigen Klammern? Entsprechend des Zustands der Bits UVE.Q, OVE.Q, OT2.Q und UVO.Q wird "u", "o", "t", "U", "0" oder eben nichts angezeigt.
Offensichtlich ist das nicht das Original das sich mal fehlerfrei
synthetisieren liess. Aktuell verstehe ich nicht was der Autor
mit der Zeile
Scheint mir auch so. Versuche die Original Files zu finden. Wenn die es
noch zu finden gibt. Sonst hast du das Problem, dass wenn es sich
synthetisieren lässt dass es eventuell doch noch alte Bug beinhaltet.
Alle mir vorliegenden Dateien sind die Originaldateien
Es konnte auch sein dass du mit einer anderer Toolversion das versuchen
sollt. Vielleicht hat man die Sprache über die Jahre geändert.
Das kann sein, denn der Originalentwicklungsrechner ist (natürlich) nicht mehr vorhanden. Ich habe dieses Projekt erhalten, weil ich noch eine alte Xilinx Foundation 3.1i für ein altes FPGA Projekt, mit VHDL Code, zur Verfügung habe.
Ich kann kein ABEL, aber das ist doch offensichtlich die Ansteuerung
einer 7-Segment-Anzeige mit den einzelnen Segmenten a-f in den eckigen
Klammern? Entsprechend des Zustands der Bits UVE.Q, OVE.Q, OT2.Q und
UVO.Q wird "u", "o", "t", "U", "0" oder eben nichts angezeigt.
Richtige Annahme.
Ist offensichtlich ein Arry von Bits, das dann auf die entsprechenden Ausgangspins gelegt wird. Und der Inhalt des Bitarrays soll der Ausgabewert sein.
So viel zur Theorie. Jetzt fehlt mir nur die Lösung der beiden Fehler. ;-)
Alle mir vorliegenden Dateien sind die Originaldateien
Wahrscheinlich ist der Satz der dir vorliegt, respektive den du hier präsentierst, unvollständig. Wie oben bereits geschrieben, fehlt wohl das constraint file und oft wird so ne CPLD über ein script gesteuert, die mglw. die command line options so setzt, sodas der vorgebliche Fehler nicht auftaucht. bei modernen tools wäre so ein compileschalter beps. der für die verscghiedenen VHDL-Standards. Projektdatei wäre auch noch so ein fehlender Kanditat.
Es konnte auch sein dass du mit einer anderer Toolversion das versuchen
sollt. Vielleicht hat man die Sprache über die Jahre geändert.
Das kann sein, denn der Originalentwicklungsrechner ist (natürlich)
nicht mehr vorhanden.
Dann wirste wohl alles aus der Hardwarespec entnehmen müssen statt die verschollenen Sourcen zu reverse enginerren. Also schnapp dir ne Hardware, schreib den IC-Code ab und poste den hier, grobe schaltungsbeschreibung wäre auch nicht schlecht. Und mit diesen Erkenntnissen sollte man eine komplette ISE toolchain für den CPLD auf VHDL aufsetzen.
Dann convertier das Ganze doch nach VHDL wenn du ABEL nicht korrekt
buchstabieren kannst.
Konvertieren ist absolut verboten!
Jede grundlegende(!) Änderung würde einen riesigen Zulassungsprozess
anstoßen. Eine Parameteränderung darf gerade noch so gemacht werden.
Dann konvertier es trotzdem, aber verwende den VHDL-Code nicht für die Entwicklung sondern nur damit du verstehst/simulierst was der ABEL-Code machen könnte.
Und wenn tatsächliche Änderung verboten ist, dann musste halt ne Änderung drumherum bauen, bspw mit nem 74* gatter.
Und dann wäre noch der Äquivalenzcheck als Möglichkeit. Überleg dir ein testsetting, wo die geänderte Variante parallel zu unveränderten alten läuft und teste automatisiert auf Verhaltensunterschiede. So kann man auch eine komplette Neu-zertifizierung umgehen.
Aber ich glaube immer mehr, das du als VHDL-Programmierer nicht der richtige Mann dafür bist. Ein Hardware-entwickler old school scheint mir da geeigneter, schau mal nach Freiberufler/Ingenieurbüro o.ä..
Ich kann kein ABEL, aber das ist doch offensichtlich die Ansteuerung
einer 7-Segment-Anzeige mit den einzelnen Segmenten a-f in den eckigen
Klammern? Entsprechend des Zustands der Bits UVE.Q, OVE.Q, OT2.Q und
UVO.Q wird "u", "o", "t", "U", "0" oder eben nichts angezeigt.
Richtige Annahme.
Ist offensichtlich ein Arry von Bits, das dann auf die entsprechenden
Ausgangspins gelegt wird. Und der Inhalt des Bitarrays soll der
Ausgabewert sein.
So viel zur Theorie. Jetzt fehlt mir nur die Lösung der beiden Fehler.
;-)
Dann ist IMHO die Vorgehensweise, die Syntaxfehler fixen zu wollen, wahrscheinlich die falsche. Nachdem wir sehen, dass der Code einigermassen sinnvoll erscheint, ist es unwahrscheinlich, dass die auf irgendwelche Änderungen im Quellcode zurückzuführen sind. Also hast Du wahrscheinlich das falsche ABEL-Tool.
Selbst wenn Du so umschreibst, dass deine Version die Logik frisst, weisst Du nicht, ob die nicht auch noch woanders Dinge anders macht als die richtige - dann könntest Du auch gleich neu schreiben.
M.E. musst Du, statt zu versuchen den Code zu ändern, erst nach einem ABEL-Tool suchen, das das Original frisst.
Anbei der design/file-flow für ABVEL unter Xilinx. Schau, das du an alle Original-files bekommst, interessant sind auch report-files von damals.
Wenn du nicht ABEL ändern willst, geht es mit den richtigen tools u.U. auch an einem generierten file.
Hat man bspw für FPGA's schon per fpga-editor direct man geroutetetn *ncd-file gemacht (Lookup-table auf negiert geändert). bei (dokumentierten) PLD's gehts u.U auch per Hexeditor.
"nur" einen Wert ändern zu müssen
Was für eine Änderung konkret? Inverter einbauen? Eingang fest auf irgendwas klemmen? ...
PS: den src-Ersteller D.B. kann man lt. xing in berlin finden ...
Das kann sein, denn der Originalentwicklungsrechner ist (natürlich)
nicht mehr vorhanden. Ich habe dieses Projekt erhalten, weil ich noch
eine alte Xilinx Foundation 3.1i für ein altes FPGA Projekt, mit VHDL
Code, zur Verfügung habe.
Hast du schon in den Zulassungsunterlagen nachgesehen ob dort steht welches Tool und Version eingesetzt wurde? In unseren Entwicklungsplänen für den Kunden müssen wir auch Tools und deren Versionen angeben.
Da es damals versäumt wurde, sicher zu stellen, dass die Entwicklungsumgebung auch archiviert werden kann, bzw. mindestens Dokumentiert ist wäre es jetzt eine Gelegenheit, die Tools in einer Virtuellen Maschine (VM) zu installieren. 1. Bessere chancen das es läuft, da du auch ein passend altes Betriessystem z. B. Windows 2000 nutzen kannst, 2. kannst du dann die VM abglegen und archivieren.
Hat man bspw für FPGA's schon per fpga-editor direct man geroutetetn
*ncd-file gemacht (Lookup-table auf negiert geändert). bei
(dokumentierten) PLD's gehts u.U auch per Hexeditor.
Wäre eine Idee!
Was für eine Änderung konkret? Inverter einbauen? Eingang fest auf
irgendwas klemmen? ...
Den fixen Vergleichswert für einen Digitalwert anpassen.
PS: den src-Ersteller D.B. kann man lt. xing in berlin finden ...
Dann werde ich mal den Projektleiter darauf ansetzen. Der darf auch was für sein Geld machen. ;-)
Hast du schon in den Zulassungsunterlagen nachgesehen ob dort steht
welches Tool und Version eingesetzt wurde? In unseren Entwicklungsplänen
für den Kunden müssen wir auch Tools und deren Versionen angeben.
Alles, was noch vorhanden ist, habe ich (angeblich) bekommen. Das war damals noch eine andere Firma, die dann mit unserer fusioniert wurde. Die hatten anscheinend, entweder andere Ansprüche bzgl. Dokumentation, als wir oder bei der Fusionierung ging einiges verloren. Nicht nur Personal.
Da es damals versäumt wurde, sicher zu stellen, dass die
Entwicklungsumgebung auch archiviert werden kann, bzw. mindestens
Dokumentiert ist wäre es jetzt eine Gelegenheit, die Tools in einer
Virtuellen Maschine (VM) zu installieren. 1. Bessere chancen das es
läuft, da du auch ein passend altes Betriessystem z. B. Windows 2000
nutzen kannst, 2. kannst du dann die VM abglegen und archivieren.
Das ist bereits meine Entwicklungsumgebung, da ich das ja auch für das, weniger, alte FPGA Projekt aus unserem (alten) Hause verwende.
(dokumentierten) PLD's gehts u.U auch per Hexeditor.
Wäre eine Idee!
Was ist es den für ein PLD? Ich tippe auf XC95-Familie. Das könnte übrigens ein Grund für die messages sein, falschen typ angegeben beim Tool-aufruf. Im Abel steht der typ jedenfalls nicht, man könnte aber anhand der Pin-Anzahl raten (XC95216 im HQFP mit 208 Pins vielleicht?). Dann bleibt aber auch die Frage ob *XL, *XV oder nur XC9500.
Was für eine Änderung konkret? Inverter einbauen? Eingang fest auf
irgendwas klemmen? ...
Den fixen Vergleichswert für einen Digitalwert anpassen.
Das ist schon etwas Anspruchsvoller, da muss man wohl mehrere Zellen "drehen". An die Möglichkeit, statt dem vergleichswert den eingehenden Wert vor dem PLD anzupassen habt ihr sicher schon gedacht?! Wenns über einem ADU vom Sensor kommt könnte man auch daran denken den Sensorwert an die alte vergleichsschwelle anzupassen (Verstärkung/spannungsteiler zwischen Sensor und ADU.
PS: den src-Ersteller D.B. kann man lt. xing in berlin finden ...
Dann werde ich mal den Projektleiter darauf ansetzen. Der darf auch was
für sein Geld machen. ;-)
Wenns eine Leiterin ist, wird wohl billiger, man weiß ja Berlin ist arm aber sexy ;-)
Was ist es den für ein PLD? Ich tippe auf XC95-Familie. Das könnte
übrigens ein Grund für die messages sein, falschen typ angegeben beim
Tool-aufruf. Im Abel steht der typ jedenfalls nicht, man könnte aber
anhand der Pin-Anzahl raten (XC95216 im HQFP mit 208 Pins vielleicht?).
Dann bleibt aber auch die Frage ob *XL, *XV oder nur XC9500.
Gut getippt! Laut Schaltplan "nur XC9500".
Den fixen Vergleichswert für einen Digitalwert anpassen.
Das ist schon etwas Anspruchsvoller, da muss man wohl mehrere Zellen
"drehen". An die Möglichkeit, statt dem vergleichswert den eingehenden
Wert vor dem PLD anzupassen habt ihr sicher schon gedacht?! Wenns über
einem ADU vom Sensor kommt könnte man auch daran denken den Sensorwert
an die alte vergleichsschwelle anzupassen (Verstärkung/spannungsteiler
zwischen Sensor und ADU.
Da müssten komplett neue Platinen erstellt werden. Viel zu teuer, zu aufwändig und würde wieder einen kompletten Zulassungsprozess in Gang setzen.
Umprogrammierung des CPLD ist der einzig zulässige Weg.
Allerdings habe ich zumindest für den 2. Fehler eine Lösung gefunden. Inklusive einer qualitativen Verbesserung des ABEL Codes, ohne gleichzeitig an der Funktionalität zu drehen.
Damit sind diese Syntaxfehler schon mal entfernt.
Die Logikoperationen sind die Bedingungen, bei denen dieser Anzeigewert aktiv wird, wenn das logische Ergebnis '1' ist.
Redundanzen entfernt heißt, dass diese Art der Zuweisung für die 7 Segmentanzeige mehrfach im Sourcecode vorkommt und einige Bitmuster (= Anzeigewerte) öfters verwendet werden. Müsste man einen Anzeigewert verändern, so erfolgt das jetzt einmal, an der Stelle der Definition, und nicht mehrfach, verteilt im Code.
