Hallo zusammen!
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.
1. Fehlermeldung
R. R. schrieb:> Besten Dank schon mal, wenn mir jemand helfrn kann.
Wenn dir jemand helfen soll musst du schon den vollständigen
Code zur Verfügung stellen.
R. R. schrieb:> der mal mit ADEL gearbeitet hat.
Ich habe mal mit ABEL gearbeitet, ADEL kenn ich nicht.
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.
"" Error L263/C31 : Warning 1124: 'INVERT' or 'BUFFER' not specified
for 'BETRIEB' - assuming 'BUFFER'."
Ist das wirklich ein Error? Kann man daraus nicht irgendwie nur eine
Warnung machen? Sprich im Tooling etwas umstellen damit es auch so ok
wird?
Andras H. schrieb:> Ist das wirklich ein Error?
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.
R. R. schrieb:> fbs88_21.abl
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
Anzeige = [Off,Off,On,On,On,Off,Off] & UVE.Q;
bezwecken will.
Wastl schrieb:> 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.
Dann convertier das Ganze doch nach VHDL wenn du ABEL nicht korrekt
buchstabieren kannst.
https://support.xilinx.com/s/article/17000?language=en_US
xport.exe findet man bei der ISE bspw.: ISE\14.7\ISE_DS\ISE\bin\nt\
wenn du keine ISE installiert hast, hilft dir vielleicht einer aus dem
Forum bei der Konvertierung.
DSGV-Violator schrieb:> wenn du keine ISE installiert hast, hilft dir vielleicht einer aus dem> Forum bei der Konvertierung.
Du meinst also die aktuellen Syntax Fehler werden in ein
entsprechendes VHDL-Konstukt umgewandelt?
Oder sogar ausgebügelt?
Wastl schrieb:> Du meinst also die aktuellen Syntax Fehler werden in ein> entsprechendes VHDL-Konstukt umgewandelt?> Oder sogar ausgebügelt?
??? zu deppern das TO-Posts zu lesen???
"...mit denen ich als VHDL Entwickler..."
Und den Unterschied zwischen einem Syntax- und einem Synthese-fehler
kennt man auch nicht? Wer hat denn Dich hier reingelassen?!
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.
Andras H. schrieb:> Wastl schrieb:>> 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.
Nur mit ABEL kenne ich mich auch nicht aus.
DSGV-Violator schrieb:> 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.
Wastl schrieb:> Du meinst also die aktuellen Syntax Fehler werden in ein> entsprechendes VHDL-Konstukt umgewandelt?> Oder sogar ausgebügelt?
Nein! Es ist und MUSS ABEL Code bleiben.
Markus F. schrieb:> 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.ä..
R. R. schrieb:> Markus F. schrieb:>> 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 ...
R. R. schrieb:> 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.
DSGV-Violator schrieb:> 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. ;-)
Christoph Z. schrieb:> 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.
R. R. schrieb:> . bei>> (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 ;-)
DSGV-Violator schrieb:> 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.
Bleibt noch Fehler 1.
R. R. schrieb:> Bleibt noch Fehler 1.
Den bekomme ich weg indem ich den .Q Ausgang nicht angebe,
also einfach
Softstart.AR = !BETRIEB;
so wie die anderen verwendeten "BETRIEB" auch vorkommen.
Wastl schrieb:> R. R. schrieb:>> Bleibt noch Fehler 1.>> Den bekomme ich weg indem ich den .Q Ausgang nicht angebe,> also einfach>> Softstart.AR = !BETRIEB;>> so wie die anderen verwendeten "BETRIEB" auch vorkommen.
Das war es!
Danke sehr und ein schönes Wochenende.
supersonic
Thread beobachten
Seitenaufteilung abschalten