folgendes Problem, in der ersten Inebtriebnahme meines FPGAS werden
mehrere Coreffizienten ermittelt die im laufe des Betriebs verwendet
werden. da sich diese Werte nicht ändern, wär es sinnvoll sie nicht
jedes mal beim starten des FPGAs zu ermitteln sondern irgendwo dauerhaft
zu speichern.
Die einzige möglichkeit die mir einfällt ist das ablegen im ROM und
abrufen bei jedem Programmstart. Dafür benötige ich aber einen EEPRROM
controller und für 4 Werte weiss ich nicht ob sich der Aufwand auch
wirklich lohnt, vor allem weil ich mich da erstmal einarbeiten müsste.
Gibt es andere Möglichkeiten oder komme ich an einem Controller nicht
vorbei?
mfg Dexter?
Dexter schrieb:> meines FPGAS
Welches ist das denn?
Bei passender Kombination lassen sich Daten im Config-PROM speichern.
Oder bei passenden FPGA gleich direkt auf dem FPGA...
P. M. schrieb:> Auch in VHDL kann man Konstanten definieren, also warum nicht?
Aber es wird wohl nicht bei jeder Inbetriebnahme eines jeden Geräts
ein neues Programmierfile erstellt...
P. M. schrieb:> Auch in VHDL kann man Konstanten definieren, also warum nicht?
Darum:
Dexter schrieb:> folgendes Problem, in der ersten Inebtriebnahme meines FPGAS werden> mehrere Coreffizienten ermittelt die im laufe des Betriebs verwendet> werden.
Hallo Dexter,
ich sehe keine andere Möglichkeit, als ein EEPROM mit all dem Aufwand,
so ein Ding zu betreiben: Schnittstelle (IIC oder SPI), Write-Routine
(automatisch einmalig nach Ermittlung der Koeffizienten gestartet),
Read-Routine (automatisch nach jedem FPGA-Anlauf gestartet). Ich habe so
etwas für normale Betriebseinstellungen ("Bedienung") gemacht. In reinem
VHDL ist es schon sehr mühsam. Wenn du einen Controller auf dem FPGA
hättest, würde es natürlich viel einfacher.
Bei Altera gibt's CPLDs mit eingebautem EEPROM, aber die haben auch eine
ganz normale serielle Schnittstelle (SPI, glaube ich), so dass der
Aufwand in VHDL der selbe ist.
Grüße, Uwe
Hi,
Pongo schrieb:> Könnte man nicht ein NOR-Flash FPGA nehmen und parital reconfig?
Dexter schreibt nicht, welchen Hersteller er einsetzt. Bevor ich mich
wegen einer vergleichsweisen Kleinigkeit einem völlig anderen System
zuwende, schlucke ich lieber die (wahrscheinlich) kleinere Kröte des
größeren Aufwands.
Irgendein FPGA-Hersteller mag ja vielleicht etwas Passenderes im
Programm haben, aber ob das ausreichend Motivation zum Wechsel wäre?
Darüber hinaus: Soll ich erst alle Hersteller studieren, ob da
vielleicht irgendwo eine bessere Lösung zu finden ist? Nein, mir müsste
schon jemand (z.B. hier im Forum) präzise sagen, wo ich eine bessere
Lösung finde, und dann müsste die wirklich effizient (= Nutzen/Aufwand)
sein. Andernfalls würde ich den Weg gehen, den ich absehen kann.
Grüße, Uwe
Das bitfile für den FPGA anzupassen muß nicht so aufwendig sein wie es
sich zuerst anhört. Das kann man auch in die übliche prozedure der
Produktionstest einbinden.
Also kalibrieren Werte und ermittel und dann:
Variante 1: in VHDL codieren und Workflow komplett durchlaufen lassen ->
das deuert recht lang (5 - 30 Minuten), mal abgesehen von Problemem das
jedes bitfile sein eigenes timing haben könnte.
Variante2:
Nur für eine Teilkomponente bspw ROM aus LUT den VHDL code anpassen, nur
diesen synthetisieren und damit die Implementierung ab netzliste
durchlaufen lassen (bei Xilinx-ISE ab bgdbuilt). Das dürfte einige
Minoten sparen, hat aber sonst fast alle Nachteile der Variante 1.
Variante 3:
Keine synthese/mapping/P&R, im bitfile werden nur die bits gedreht in
der die Init-werte für den BRAM stehen. Das ist der übliche Weg wie bei
nikroblaze designs das kompilierte Programm in den Speicher kommt.
"Initialize BRAM" siehe
http://dropzone.tamu.edu/~pli/449Fall11/lab/lab2.pdf S.11
Hat man eh einen mikroblaze im FPGA wäre das der empfehlenswerte weg,
ansonste. Ansosnten sollte man sich mal bei xilinx das tool data2mem
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/data2mem.pdf
anschauen
oder auch:
http://users.etech.haw-hamburg.de/users/reichardt/Reprogramming%20of%20block%20RAM%20Memory.pdf
Dergleichen sollte es auch für Altera mit seinen NIOS-Softcore gegebe.
Variante4:
Es muss nicht immer der BRAM sein, bei JTAG kann man 32bit als USERCODE
in den FPGA bringen. Bei einigen Xilinx-FPGA's sind diese 32 bit auch
intern auslesbar. ->
http://www.xilinx.com/support/documentation/application_notes/xapp497_usr_access.pdf.
Wobei ich grad nicht sicher bin ob diese 32bit schon im bitfile gesetzt
werden oder erst beim konfigurien des FPGA's selbst.
Variante 3 und 4 sollte sich bei einem richtigen ATE Stand nahtlos
(labview) in die übliche Erst-Inbetriebnahme von Boards integrieren
lassen.
MfG,
Danke schon mal für die zahlreichen Antworten.
ich habe ein spartan6 auf einem mojo V3 development board. auf dem Board
befindet sich ein SPI Flash.
Wie schon erwähnt sind es nur 4 Werte und mir fehlt die Zeit einen
controller etc dafür zu implementieren bzw überhaupt in mein Projekt
einzubinden, deswegen frage ich hier nach Alternativen.
Da reicht ja dann eine ganz einfache State-Machine, die ein kleines SPI
Modul ansteuert zum Auslesen. Einprogrammieren kannste die Werte ja über
JTAG mit Impact, da kann man auch "non-configuration Files" mit in den
Flash packen, ohne das Bit File zu verändern. Zum Auslesen muss man dem
Flash ja nur 0x03 und dann 24 Bit Adresse schicken und schon fallen bei
jedem nächsten SPI Transfer die Daten raus. Das ist doch in einer Stunde
erledigt.
Christian R. schrieb:> da kann man auch "non-configuration Files" mit in den> Flash packen,
Braucht aber auch wieder jeweils ein Image für jeden FPGA.
Sowas sollte man besser trennen.
Braucht man nicht unbedingt, kann man sich ja temporär erzeugen, am
besten in der Kommandozeile, das bit File bleibt gleich, nur ein mcs
File für den eigentlichen Programmiervorgang braucht man. Eventuell kann
man Impact auch mit einem selbst gebasteltzem Mcs File (ist ja auch nur
hex) dazu bringen, das ganze ohne Bit File zu machen, promgen müsste man
in dem Fall dann übergehen.
Das ist leider eine typische Entwicklersicht. Ein MCS-file, das ein
FPGA-Programmierfile enthält, ist eine Software und Bedarf i.d.R. eines
Freigabeprozesses und dazu gehört immer auch ein Test, eine eigenen
DM%-Summe, ein Beiblatt etc ....
Du möchtest nicht jedes MCS einzeln testen und dokumentieren, oder? :-D
Daher Programm und Parameter sauber trennen. Wenn in der Produktion
irgendo was hingebrutzelt wird, muss man nur einmal testen, dass das
Programm dadurch nicht angefasst werden kann oder beschädigt wird.
Jo, man kann es mit den Prozessen auch übertreiben. Irgendwo müssen die
Daten die extra rein kommen sollen, doch auch gespeichert werden. Von
der Fragestellung her denke ich nicht, dass der in einem Konzern
arbeitet, bei dem statt des Ergebnises der Prozess im Vordergrund steht,
sonst hätte er das Problem sicher anders angegangen. Außerdem hätte er
sicher jetzt noch keine Freigabe für den aus Prozesssicht brandneuen
Spartan 6.
Dann halt wie ich vorgeschlagen habe, nur ein mcs File für die
Konfigwerte...das kannste ja immer noch ausdrucken, mit Nummer versehen,
ddm QM zur Unterschrift vorlegen und abheften.
Wir sind eine GmbH, gehören aber zu einem Konzern! Da bei uns
Geheimhaltung herrscht und die von der Börsenaufsicht nur in der AG
rumschnüffeln dürfen wurde die GmbH als Tochterunternehmen gegründet.
Zum Problem: der FPGA wird für eine Steuerung benötigt, die zwar vom
Algo her gleich ist, jedoch in unterschiedlichen "Geräten" eingesetzt
wird. Wie Frank es schrieb müsse jedes Modul extra geprüft werden bei
Änderungen, deshalb die Werte auslagern. Je nach dem welche Guidance and
Control benötigt wird werden die einzelnen Cores aktiviert und bleiben
es auch bis zur Auslieferung! Danach muss das "Gerät" bei Aktivierung
ca. 45sek zuverlässig funktionieren! Danach ist es egal! Repariert
werden kann eh nichts, da nichts über bleibt ;-)
Auch in der Millitärtechnik gibt es Normen und Funktionsgarantien. Die
Vorstellung, man hätte es da einfacher, ist meistens verfehlt. Geräte
müssen z.T. jahrzehntelang lagern und auf Knopfdruck einsatzbereit sein.
Firmwareprozesse sind nochmal was anderes. Auch da hat sich in den
letzten Jahren viel getan. Es gibt zwar kein Automotive-Spice, aber die
Hersteller von Komponenten müssen irgendwie nachweisen, was eine SW kann
und was nicht. Und es muss ein Zuordnung geben.
Je mehr Versionen es da gibt, um so schlimmer. Jede Kombi aus SW und HW
muss Baumustergeprüft werden. Fertigungsendtest der Exemplare ist wieder
was anderes. Wenn man einmal nachgewiesen hat, dass ein SW ok ist, dann
fast man das besser nicht mehr an.
Ob dann im Einzelfall mal ein falscher Parameter imFlash steht, weil bei
EINEM Justagevorgang irgendwas schief lief, ist das zu verschmerzen. Es
tangiert nicht die anderen.
Aber wenn ich einmal einen Text im Display ändere, und compile drücke,
bekomme ich eine andere firmware die ich neu zulassen muss. Einige Tests
kann man sich sparen, klar, aber es ist dennoch enormer Aufwand.
Ausserdem werden wichtige Sachen 2x gespeichert, schon von da kommt man
um einen externen Flash nicht herum.
Der letzte Dexter-Post ist ein troll. Es handelt sich um um meine
Abschlussarbeit zum auswerten von Sensoren. die Werte sind für Gain und
Offset-Kalibrierung und müssen deswegen nur bei der ersten
inbetriebnahme ermittelt werden. Das Militär würde wohl kaum ein Mojo v3
devBoard verwenden :-D. naja die Sache hat sich denke ich für mich
erledigt. Ein SPI controller für den EEPROM wär wohl das sinnvollste,
deswegen wird es in einer späteren Arbeit umgesetzt. Für mich hat sich
die sache erledigt.
Danke trotzdem für eure Vorschläge und Antworten
