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?
Wo ist das Problem einen EEPROM an den FPGA anzuschließen und diesen per I²C oder SPI anzubinden? Dazu brauchst Du keinen extra Contoller!
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 ;-)
Das klingt doch sehr nach Militärtechnik. Raketen, Torpedos, oder ähnliches.
Olga schrieb: > Das klingt doch sehr nach Militärtechnik. Raketen, Torpedos, oder > ähnliches. Nach einschlagendem Erfolg
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.