Forum: FPGA, VHDL & Co. Machbarkeit SG-Emulator mit FPGA?


von Steffen Hausinger (Gast)


Lesenswert?

Hallo zusammen,

ich habe in jahrelanger Arbeit ein Motorsteuergerät reverse-engineered. 
Jetzt möchte ich gerne dieses Steuergerät applizierbar machen, d.h., ich 
möchte Parameter während der Laufzeit ändern können. Das Steuergerät 
stammt aus den späten 80ern und arbeitet sein Programm aus einem ROM ab.


Meine Idee: Ich tausche diesen ROM durch zwei RAMs, wovon ich eines dem 
Steuergerät zur Verfügung stelle und eines beschreiben kann. Zu 
gegebener Zeit schalte zwischen beiden um. Nach diesem Prinzip arbeiten 
offensichtlich viele EPROM-Emulatoren - also nichts Neues.

Mein Problem: Es wäre für den späteren Anwender sehr einfach, alle meine 
erarbeiteten Erkenntnisse über das Steuergerät auszulesen. Er müsste nur 
einen Parameter ändern, den RAM auslesen und dann schauen, welche 
Adresse sich geändert hat.

Meine Idee: Ich verwende einen FPGA, der die zwei RAMs "emuliert". 
Anstelle der Adresse des zu ändernden Parameters übergebe ich dem FPGA 
eine "ID", aus der er intern die Adresse umrechnet. Damit verhindere 
ich, dass der Datenverkehr zum RAM abgelauscht wird. Desweiteren sorge 
ich dafür, dass gewisse Regeln beim Auslesen eingehalten werden müssen 
(bspw. dass Adressen nicht linear ausgelesen werden dürfen). Damit 
verhindere ich, dass der "emulierte" RAM über ein Lesegerät einfach 
ausgelesen werden kann.

Meine Fragen an Euch: FPGAs sind ursprünglich nicht dazu gedacht, einen 
RAM nachzubilden. Gibt es trotzdem bezahlbare Bausteine, die 2 x 16kByte 
schaffen? Plus ein paar Treiber zum Umschalten zwischen den beiden 
RAM-Einheiten? Der ganze Aufwand bringt natürlich nichts, wenn die 
Konfiguration nach dem Reset extern übergeben werden muss, weil diese 
dann abgehört werden könnte. Soweit ich lesen konnte, gibt es aber 
durchaus FPGAs mit nicht-flüchtigem Speicher.


Meine Fragen zielen darauf ab, ob es sich lohnt, mich in das Thema FPGA 
einzuarbeiten oder ob ich meine Aufgabe damit eh nicht lösen kann. Und, 
da ich weiß, dass das hier auch ein Thema ist: Das Steuergerät soll 
nicht im Straßenverkehr eingesetzt werden.

Grüße
Steffen

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

Hallo,

ich habe mal eine Z80 Emulator in C geschrieben. Da kenne ich auch 
solche Tricks, wie das Umschalten der Speicher-Bank mit einem 
zusätzlichen Offsetpointer.

Ohne dass ich viel von deiner Steuerung weiss, finde den Ansatz 
schlecht.
Entweder eine ganz simple Logik zum Umschalten. Doch du willst noch 
Werte zum Zeitpunkt t an Adresse xy beschreiben. Das wird dann schon 
aufwendiger.
Wer ändert die Werte überhäupt ein zusätzlicher Prozessor oder soll der 
Fpga noch ein paar Sensoren abfragen?

Ich würde sagen, wenn es was aus den 80er Jahren ist. Dann kannst du 
gleich die komplette Steuerung in den FPGA packen!
Dabei kommst du auch preislich noch besser weg, als mit deiner 
angestrebten Lösung.



Ja: Es gibt FPGA mit internen Bootflash. Diese Forderung verringert die 
Auswahl stark.

von Steffen Hausinger (Gast)


Lesenswert?

Hallo dose,

ich denke, wir reden hier aneinander vorbei. Es geht darum, die 
Parameter (Konstanten, Kennlinien und Kennfelder) während des Betriebs 
des Steuergeräts zu verändern. Diese Daten liegen, wie das eigentliche 
Programm auch, in einem EPROM vor. Dazu möchte ich zwischen zwei 
RAM-Bänken umschalten.

Ich habe mich auf die Suche nach einem passenden FPGA begeben. 
Offensichtlich ist die Forderung 32 kByte RAM plus interne Konfiguration 
ein ziemliches Ausschlusskriterium. Ich habe nur einen Spartan-3 AN 
gefunden, der zwar perfekt passt, aber nur als BGA verfügbar ist.

Hat jemand einen anderen Vorschlag?

von horst (Gast)


Lesenswert?

Könnte man die Daten nicht in einem externen RAM haben, während der FPGA 
bloss die Daten und Adressen verschlüsselt?

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

Steffen Hausinger schrieb:
> Hallo dose,
>
> ich denke, wir reden hier aneinander vorbei. Es geht darum, die
> Parameter (Konstanten, Kennlinien und Kennfelder) während des Betriebs
> des Steuergeräts zu verändern. Diese Daten liegen, wie das eigentliche
> Programm auch, in einem EPROM vor. Dazu möchte ich zwischen zwei
> RAM-Bänken umschalten.


Wenn diese Wert Statisch vorliegen, dann kannst du doch sicher die 
Software ändern und die Kennlinien aus einem seriellen EPROM nachladen.

von Steffen Hausinger (Gast)


Lesenswert?

@horst: Deine Möglichkeit klingt ganz gut, aber ich kenne mich mit FPGAs 
nicht aus. Zwar weiß ich, dass man damit ganze Prozessorkerne emulieren 
kann und demnach auch eine Verschlüsselung möglich sein muss. Aber für 
ein erstes Projekt mit FPGAs ist das zu hoch. Ich könnte mir höchstens 
eine Permutation vorstellen. Oder gibt es fertige 
"Verschlüsselungsbibliotheken"?

Viel einfacher wäre es, wenn der RAM halt im FPGA wäre. Dafür würde ich 
finanziell auch mehr ausgeben. (Eine BGA-Station ist aber nicht drin ;-) 
)

@dose: Ich verstehe nicht ganz, wie Du das meinst? Ob ich nun ein 
serielles oder ein paralleles EPROM umschalte, ist doch erstmal egal? 
Abgesehen davon besitzt der Prozessor ein Hardware-Interface zum EPROM, 
von daher würde eine serielle Verbindung leider nicht funktionieren. 
Meintest Du das so?

Grüße
Steffen

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

Ein Pin an deiner Steuerung schaltet über die chip select Leitung den 
Eprom um oder du nimmst einen größeren Eprom wo beide Kennlinien 
hineinpassen.

von GastXIV (Gast)


Lesenswert?

"Meine Idee: Ich verwende einen FPGA, der die zwei RAMs "emuliert".
Anstelle der Adresse des zu ändernden Parameters übergebe ich dem FPGA
eine "ID", aus der er intern die Adresse umrechnet."

Das bringt dir nichts. Das Ram wird dadurch in nichts weniger auslesbar 
da dein FPGA nicht wissen kann ob das Motorsteuergerät ein simpler 
Prozessor der die Daten ausliest oder ein €99,95 Logicanalyzer zum 
mitschreiben dranhängt.

Egal wie tief du es ins FPGA verbuddelst. Du kannst ein Ram nicht 
schützen wenn auf die Adress/Daten/Enable Leitungen zugegriffen werden 
kann.

Eine Chance evtl. Updates. Wenn du nur einen Teil der Funktionen / 
Fehler einbaust bekommst du einen Raubkopierermarkt den du später mit 
"neuen Versionen" melken kannst. Es gibt bekannte Firmen die mit diesem 
Konzept ohne Kopierschutz Marktführer geworden sind.

von Steffen Hausinger (Gast)


Lesenswert?

@dose: Stimmt, das würde die Anzahl der umzuschaltenden Leitungen 
drastisch verringern. Die eigentliche Aufgabe bleibt aber bestehen. 
Wobei dieser Lösungsansatz aber (wie oben geschrieben) in diesem Fall 
leider nicht funktioniert.

@GastXIV: Das ist richtig, habe ich mir auch schon überlegt. Der 
Hintergrund ist aber ein anderer. Ich möchte zwischen zwei RAM-Bänken 
umschalten. Dafür muss ich die ganzen Adress-, Daten- und 
Steuerleitungen umschalten können und es bietet sich ohnehin an, dieses 
Umschalten in einem FPGA (oder CPLD) zu realisieren. Und in diesem Fall 
kann ich das Auslesen auch gleich ein wenig erschweren (nicht 
verhindern!), wenn die beiden Bänke einfach nicht zugänglich sind.

Deine Idee mit den Updates werde ich mir merken :-)



Eine andere, grundsätzliche Frage zu FPGAs: Könnte ich anstelle der zwei 
RAM-Bänke möglicherweise auch nur eine realisieren, diese aber als 
Dual-Port? Dann würde ich nur den halben Speicher benötigen. Wie 
schwierig ist soetwas mit einem FPGA?

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

Die neueren FPGAs habe eine ID die wie eine Seriennummer sind. Diese ID 
könnte man als Schlüssel für eine Verschlüsselung nutzen.

Doch wenn die Datenleitungen und Adressleitungen wieder anzapfbar sind, 
dann kommt man mit dem Logikanalysator dahinter. Es wäre nur zum 
Bootzeitpunkt verschlüsselt. Deine Daten und Adressleitungen müssten 
auch noch im FPGA sein, dann gäbe es keine Adress und Datenleitungen, wo 
man mit den Logikanalysator anzapfen kann.


Es gibt im FPGA dual port ram.

von Steffen Hausinger (Gast)


Lesenswert?

@dose: Du meinst damit die "DNA" oder? Davon habe ich auch gelesen, aber 
wie Du schon schreibst, bringt das leider auch nichts.

Eine einfache Lösung scheint es hier wohl nicht zu geben. Und da ich, 
wie oben ja sehr richtig angemerkt wurde, die Schaltung sowieso niemals 
auslesesicher bekomme, werde ich mich mit einem externen SRAM begnügen. 
Der Aufwand wäre sonst zu hoch und gleichzeitig der Nutzen zu gering. 
Ein FPGA kommt natürlich trotzdem zum Einsatz - für das Interface zum 
Umschalten der RAM-Bänke.


Danke Euch Dreien für Eure Antworten!

Grüße
Steffen

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

Ja die DNA.

Wast hast du für eine CPU im Einsatz?

von Steffen Hausinger (Gast)


Lesenswert?

Einen 8031/8051. Romless, leider. Aber an der Hardware kann ich nichts 
ändern.

Denkst Du an etwas bestimmtes?

von Christian R. (supachris)


Lesenswert?

Mal eine ganz andere Frage dazu: Du hast das reverse engineered und 
willst es jetzt verkaufen? Das halte ich für rechtlich mindestens 
bedenklich....

von Steffen Hausinger (Gast)


Lesenswert?

Nicht ganz. Ich habe es reverse engineered und möchte es jetzt selbst 
anwenden und verleihen.

von D. I. (Gast)


Lesenswert?

Öhm was spricht gegen den internen BRAM? Ich denke 16kb bringt man da 
noch her...

von doofi (Gast)


Lesenswert?

Nimm einen uPSD-3233 von ST. Das ist ein 8032+CPLD+Flash+RAM.

Da kannst Du mit dem eingebauten CPLD einigen Schabernack mit
den Leitungen zu einem externen RAM treiben :-)

von Steffen Hausinger (Gast)


Lesenswert?

@grotesque: Na das ist es ja gerade, ich finde keinen gängigen FPGA mit 
internem Konfigurationsspeicher und großem (B)RAM. Es sollten übrigens 
2x16 kB sein.

@doofi: Deine Idee ist interessant und ich denke, in die Richtung 
(Softcore) zielte auch die Frage von "dose" ab. Aber so tief möchte ich 
nicht in die Motorsteuerung eingreifen. Mit dem EPROM-Emulator kann ich 
eine simple Rückfallebene realisieren, etwa indem ich den FPGA abschalte 
und den /OE des originalen EPROM wieder der Motorsteuerung zurückgebe. 
Da jetzt einen vollkommen anderen Prozessor einzusetzen, ist schon ein 
ganz anderes Kaliber.


Entweder, es gibt hier eine einfache Lösung oder ich werde mich anders 
um den Ausleseschutz kümmern.

Danke
Steffen

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

Die Frage war in Richtung Softcore.

Ich hatte auch daran gedacht, ein paar Algorithmen gleich in VHDL zu 
packen.
Das wäre eine Supersteuerung.

Wie weit bist du vom orginalen ROM entfern?
Da hängen Rechte von dem "Orginalhersteller" dran.
Ich hoffe du hast bei der Reverse  Entwicklung auch einen Schritt nach 
vorne gedacht.

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

Gerade gelesen.
Silicon blue FPGAs habe einen internen Bootrom.

http://www.siliconbluetech.com/ice_technology.aspx

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.