Hallo, ich bin absoluter Neuling im Bereich der FPGA Programmierung / Beschreibung. Eine Sache hat mich jedoch gerade neugierig gemacht. Ein Arbeitskollege hat erzählt, dass die Generierung eines Datenstroms von zwei identischen VHDL Beschreibungen immer unterschiedlich aussieht. D.h. es gibt keinen Determinismus für den Datenstrom?! Kann mir das jemand erklären? Warum wird der Datenstrom nicht deterministisch erzeugt? Welche Faktoren sind ausschlaggebend für die Erstellung des Datenstroms? Vielen Dank :)
VHDL schrieb im Beitrag #6079731: > Ein Arbeitskollege hat erzählt, dass die Generierung eines Datenstroms > von zwei identischen VHDL Beschreibungen immer unterschiedlich aussieht. Definiere "Datenstrom". BTW: mit "immer" und "nie" bin ich aus Erfahrung arg vorsichtig. Wenn das auch nur ein einziges Mal nicht stimmt, dann stehe ich nämlich schön blöd da.. ;-)
Einige Schritte bei der Erstellung des Bitfiles (z.B. das Place&Route) sind Heuristiken. Das bedeutet z.B. sie beginnen mit einer zufälligen Anfangsplatzierung und versuchen diese dann iterativ zu verbessern, bis bestimmte Constraints erfüllt sind. Dabei können abhängig vom zufalligen Anfangsplacement bei verschiedenen Druchläufen unterschiedliche (aber gleich gute) Ergebnisse herauskommen. Das ist bei jeder Art von komplexen Optimierungsproblemen so, z.B. liefern auch PCB-Autorouter gerne mal bei jedem Durchlauf ein anderes Ergebnis.
VHDL schrieb im Beitrag #6079731: > Warum > wird der Datenstrom nicht deterministisch erzeugt? Schlag nach: "Traveling sales man" "Simulated anealing" "Place & Route" sonst stirbst Du dumm.
Durch Vorgabe eines Seeds kann man durchaus dafür sorgen, daß zweimal hintereinander dasselbe rauskommt.
Manche lernens nie schrieb: > sonst stirbst Du dumm. Du solltest nicht von dir auf andere schließen.
VHDL schrieb im Beitrag #6079762: > Du solltest nicht von dir auf andere schließen. Mach ich nicht, weil dann müsste ich alle für schlau halten; schlau durch eigene Recherche und Denkvermögen.
Markus F. schrieb: > Durch Vorgabe eines Seeds kann man durchaus dafür sorgen, daß zweimal > hintereinander dasselbe rauskommt. Kann ich bestätigen für Lattice. Zwei P&R Durchläufe ohne Änderung des Codes/Constraints/Seeds/Tool Version liefern ein identisches Bitfile. Entsprechend kann/soll man auch am Seed rumdrehen, wenn das Timing nur knapp verfehlt wird. Da ich nicht mehr mit Lattice arbeite sollte ich diesen Versuch bei Gelegenheit mal wiederholen.
VHDL schrieb im Beitrag #6079731: > Eine Sache hat mich jedoch gerade neugierig gemacht. Ein Arbeitskollege > hat erzählt, dass die Generierung eines Datenstroms von zwei identischen > VHDL Beschreibungen immer unterschiedlich aussieht. D.h. es gibt keinen > Determinismus für den Datenstrom?! Kann mir das jemand erklären? Warum > wird der Datenstrom nicht deterministisch erzeugt? Welche Faktoren sind > ausschlaggebend für die Erstellung des Datenstroms? Das Gegenteil ist der Fall, die Erzeugung des Bitfiles (Datenstroms) ist sogar hochgradig deterministisch! Das ist sogar aeusserst wichtig, da komplexe Designs auch komplexe CI Prozesse durchlaufen. Wenn dieser Vorgang nicht deterministisch waere, dann wuerde man nie ans Ziel kommen. Was jedoch passieren kann, ist dass schon kleine Aenderungen der HDL Files, grosse Auswirkungen am Bitfile verursachen koennen (da gibt es dann so komisch Faelle wie: ich hab doch nur das Signal umbenannt und nun passen die Timings nicht mehr). Z.B. bei Xilinx ist das mit ISE noch der Fall, da die einzelnen Slices erstmal pseudo-zufaellig (zumindest lokal) verteilt und geroutet werden und anschliessend ueberprueft wird ob die Timing Contraints eingehalten wurden. Ist das nicht der Fall, erhaelt man entsprechende Fehlermeldung und hat die Chance eine neue zufaellige Platzierung der Elemente vorzunehmen in der Hoffnung dass die Timings beim naechsten Durchgang hinhauen. Der Seed mit dem der Pseudozufall erzeugt wird nennt sich im Falle von Xilinx ISE "Placer Cost Table". Kleiner Hinweis: Vivado verfolgt diesen Ansatz nicht mehr, da mit groesseren FPGAs dieser Ansatz immer unperformanter (bzgl. P&R Zeiten) wird. Dein Bitstream haengt demnach von drei Dingen ab: 1.) Der HDL an sich. 2.) Dem Seed (Placer Cost Table). 3.) Den entsprechenden Workflow Settings. Sind diese drei Dinge mit jedem Durchlauf identisch, kommt auch immer ein identische sBitfile heraus. Eine Ausnahme gibt es jedoch - waere auch zu schoen wenn nicht. ;-) Du hast z.B. bei Xilinx die Chance nach der Erzeugung des Bitfiles nachtraeglich Daten zu manipuleiren, z.B. den Inhalt von Block-RAM Elementen oder dem User Access Speicherbereich. Mit beidem hast du natuerlich via Post-Processing die Moeglichkeit die Bitstreams zu manipulieren.
:
Bearbeitet durch User
Tobias B. schrieb: > Dein Bitstream haengt demnach von drei Dingen ab: nein, nicht nur > > 1.) Der HDL an sich. > 2.) Dem Seed (Placer Cost Table). > 3.) Den entsprechenden Workflow Settings. es fehlen: ) timing constraints ) ziel-Typ (Fpga-familie, Speedgrad, pining) ) gespeicherte Ergebnisse vorheriger Läufe (incremental compile) Wobei unterschiedlicher Bitsream nicht unbedingt geändertes Designverhalten bedeudet. Wenn bspw. eine Periode von 10ns constrained ist, ist es wurscht, ob die realisierte Route zwischen 2 FF, 2,3,4 oder 9 ns benötigt.Gelegentlich werden auch Pfade auf "dont core constrained", da ist die Signallaufzeit völlig uninteressant. Und das ist auch bei normalen Programmiersprachen so, das gleicher Code unterschiedlich umgesetzt wird, insbesonders wenn die Befehlsreihenfolge wurscht ist. Manche CPU's machen sich das zu nutze, in dem sie gleichen Code zur Laufzeit unterschiedlich abarbeiten ("Out-of-order-Execution" dt. "Ohne-Befehl-Erschiessung") ;-)
Tobias B. schrieb: > Du hast z.B. bei Xilinx die Chance nach der Erzeugung des Bitfiles > nachtraeglich Daten zu manipuleiren, Zu welchem Zweck?
Weltbester FPGA-Pongo schrieb im Beitrag #6098393: > Zu welchem Zweck? Um z.B. eine Revision Nummer oder das Datum ins Bitfile zu packen.
Tobias B. schrieb: > Weltbester FPGA-Pongo schrieb im Beitrag #6098393: >> Zu welchem Zweck? > > Um z.B. eine Revision Nummer oder das Datum ins Bitfile zu packen. Diese Idee habe ich hier doch schon gelesen: Beitrag "Vivado Version im BIT file checken und ändern - Checksumproblem?" ... doch erschließt sich mir nicht der Sinn. Das geht doch auch vor dem Auslösen des Bit-File-Erstellens? Besonders im hiesigen Fall.
Tobias N. schrieb: > ... doch erschließt sich mir nicht der Sinn. Das geht doch auch vor dem > Auslösen des Bit-File-Erstellens? Nicht unbedingt, z.B. wenn du die SVN Revision Nummer oder den Git Hash ins Bitfile schreiben moechtest um Code und Bitfile eindeutig zuzuordnen. Da hast du ein klassisches Henne - Ei Problem. Ebenso das Datum und Uhrzeit, gerade wenn die mal ein groesseres Design hast, das auch mal ueber Nacht durchlaeuft, ist das ganz praktisch.
Vielleicht beinhaltet der Datenstrom einen Kopierschutz, der auch eine Zufallskomponente enthält.
Tobias B. schrieb: > Nicht unbedingt, z.B. wenn du die SVN Revision Nummer oder den Git Hash > ins Bitfile schreiben moechtest um Code und Bitfile eindeutig > zuzuordnen. Da hast du ein klassisches Henne - Ei Problem. Wozu muss eine SVN-Nummer in das Bit-File? Die SVN Nummer wird vergeben, wenn man eincheckt und landet im Source Code an den vordefinierten Plätzen. Genauso kann man ein BIT in SVN hosten. Niemend muss die SNV Nummer durch die Design-Files managen. Das Aufsuchen der richtigen RePo Version geschiet ja im Recherchefall nicht dadurch, dass man alle BitFiles durchgeht und dort die Nummer findet, sondern man sucht einmal im ReRo mit einem Schritt alle zugehörigen Files. Tobias B. schrieb: > Ebenso das Datum und Uhrzeit, gerade wenn die mal ein groesseres Design > hast, das auch mal ueber Nacht durchlaeuft, ist das ganz praktisch. Das Bitfile wird zuletzt, meistens binnen <Min erzeugt und geschrieben. D.h. Erzeugung und Schreiben liegen nicht weit auseinander. Es ist also nicht nötigt, das in der anderen Richtung auch noch zu verzeigern. Das ist sogar ein Problem: Die einfachverzeigerung verträgt sich bestens mit den 2stufigen Vorgehensweise: 1) Sourcen abschließen, Einchecken und im SVN eine Version für die Sourven erhalten. 2) Implementierung A mit Bedingungen 1 anwerfen und einen FPGA für Plattform 1 bekommen. Bitfile erzeugen und einchecken 3) Implementierung B mit Bedingungen 2 anwerfen und einen anderen FPGA für andere Plattform erzeugen und einchecken. Damit ist in jedem branch / trunk immer exakt definiert, welches Bitfile in SVN exisitert und es ist klar, welche Version die Quelle für diese Implementierung ist. Es gibt also nicht etwas allemöglichen Bitfiles auf der Platte von denen man nicht weiß, welchen Status sie haben. Irgendwo auf der Platte exisitente, die nicht im SVN eingecheckt sind, gelten auch nicht als Release sondern sind experimental. Die Vorgehensweise, dass aus den Designfiles zu machen ist eine schlechte und schlampige Technik, die von Hackern und unaufgeröumten Programmierern gepfelgt wird. Der saubere Weg ist, ein klares Anforderungsprofil für ein Spektrum der Gerätefunktionen zu haben, diesem eine Releaseversion zuzuordnen und diese sowohl aktiv (manuell oder per script) in allen Sourcen für C und VHDL und dem USER Code des FPGA einzutragen. Die automatisch vergebenen Versionsnummern, die dann aus dem RePo kommen, werden entsprechend nachgetragen, sind aber selber für sich nicht relevant. Fortlaufende Nummern taugen da eh nicht richtig für.
Weltbester FPGA-Pongo schrieb im Beitrag #6104740: > Wozu muss eine SVN-Nummer in das Bit-File? Die SVN Nummer wird vergeben, > wenn man eincheckt und landet im Source Code an den vordefinierten > Plätzen. Genauso kann man ein BIT in SVN hosten. > > Niemend muss die SNV Nummer durch die Design-Files managen. Das > Aufsuchen der richtigen RePo Version geschiet ja im Recherchefall nicht > dadurch, dass man alle BitFiles durchgeht und dort die Nummer findet, > sondern man sucht einmal im ReRo mit einem Schritt alle zugehörigen > Files. Solche Aussagen sind sau gefaherlich und werden meist von Leuten getroffen, die nicht wirklich Expertise haben. Es gibt nunmal Workflows in denen dieses Feature Gold wert ist und es gibt Workflows in denen ich darauf verzichten kann. Ich als User habe die Entscheidung ob ich es brauche und benutze oder ob ich es links liegen lasse. Pauschale Aussage der Form "braucht kein Mensch" sind einfach nur schwach und inkompetent.
Tobias B. schrieb: > Es gibt nunmal Workflows Das sind aber schlechte und undurchdachte workflows. In umfängliche Beschreibung einer Lieferkomponenten (und das ist ein FPGA-Bit-file) wird von oben in der Versionsverwaltung und Projektverwaltung her verwaltet und induziert. D.h. - es gibt erst ein (change-)request, d.h. erst die Definition dessen, was die neue Funktion sein soll - dann gibt es einen (aktualisierten) Komponentenentwicklungsplan - danach erst gibt es ein Datum, und eine Versionsnummer für die neue SW - dann wird es gebaut, übersetzt und verifiziert - spätestens jetzt gibt es einen Testplan und eine Referenz auf das FPGA-files (An dieser Stelle liegt also eine SW-Versionsnummer vor!) - dann wird ein bit-file gemacht - dann wird es getestet - dann wird der Testplan abgehandelt und bestätigt - dann gibt es eine Freigabe und gfs eine Releaseversion - dann wird das im RePo und SAP oder sonstwo abgelegt und der Produktion übergeben So steht es sinngemäß in praktisch allen formellen Anforderungen für Softwareentwicklung in den einschlägigen Brachen, die nicht gerade Consumer-Gebastel sind. Wahrscheinlich arbeiten aber nach wie vor viele FPGA-Entwickler in Bastelbuden oder sie sehen FPGA-HW nicht als SW-Entwickler.
Das Leben ist nunmal nicht perfekt und ebenso sind Entwicklungsprozesse. Wenn ich einen CI Prozess habe der mit jedem Commit den Git Hash oder die SVN Revision Nummer ins Bitfile einbrennt, dann kann ich zu JEDER Zeit sicherstellen, dass ich JEDEM Bitfile eindeutig den Source Code Stand zuordnen kann. Wenn sich Geraete im Feld befinden und der Servicetechniker oder Kunde einen Fehler berichtet, dann bin ich froh er kann mir die entsprichende Revision Nummer mitteilen. Dann weiss ich zumindest schonmal ob der Fehler bereits bekannt ist und das Gerate nur ein Update braucht oder ob der Fehler neu ist. Auch ich finde dass Entwicklungsprozesse eine gewisse strenge brauchen, moechte aber nicht wissen wieviele Firmware Staende in Geraete sind, welche am definierten Prozess vorbeigeschleust wurden. Das passiert nunmal, manchmal durch unachtsame Entwickler, manchmal durch Druck von oben. Die Gruende sind auch egal, die Welt ist nunmal nicht perfekt, jedoch habe ich mit diesem Werkzeug die Chance jederzeit das Bitfile EINDEUTIG dem Source Code zuordnen zu koennen. Auserdem schliesst das den Flow von dir in keinster Weise aus, ist halt ein Werkzeug und in vielen Faellen soetwas wie ein Sicherheitsfallschirm. Und ob ich oder sonst wer dieses Feature nutzen moechte oder nicht, soll doch bitte das Entwicklungsteam entscheiden und nicht der "Weltbester FPGA-Pongo" vom uC.net Forum. ;-)
:
Bearbeitet durch User
Weltbester FPGA-Pongo schrieb im Beitrag #6104789: > - dann gibt es eine Freigabe und gfs eine Releaseversion Wenn du die Releaseversion erzeugst durch Ändern der Sourcen und neu übersetzt ist das ein komplett anderer Bitstream als der den du getestet hast. Wenn man für den Versionsstring nachträglich nur den Inhalt von Speicherblöcken ändert kann man immerhin argumentieren dass sich das Zeit- und Temperaturverhalten nicht ändert.
Weitere Anwendungsfälle für das Ändern von Speicherinhalt nach Synthese/PAR zum Erzeugen verschiedener Bitstreams: - uC-Softcore Programm (mit eigenem svn/git repo) - geräteindividuelles kryptographisches Material
Blechbieger schrieb: > Wenn du die Releaseversion erzeugst durch Ändern der Sourcen und neu > übersetzt ist das ein komplett anderer Bitstream als der den du getestet > hast. Richtig, und wenn man das tut, gab es einen Grund dafür. Also haben wir ein req change, eine neue Version, neue Beschreibung, aktualisierten Testplan und eine Projektfreigabe für die Änderung, BEVOR das Ganze angegangen wird. Man kann also genau so verfahren, wie oben beschrieben. VHDL hotline schrieb im Beitrag #6105151: > Weitere Anwendungsfälle für das Ändern von Speicherinhalt nach > Synthese/PAR zum Erzeugen verschiedener Bitstreams: > - uC-Softcore Programm (mit eigenem svn/git repo) Das steckt aber nicht im BIt-File (?) > - geräteindividuelles kryptographisches Material Das gehört nicht ins BIT-File, sondern in eine gerätespezifischen Bereich eines EPROMs inklusive Sicherung gegen Auslesen und Verwenden.
Weltbester FPGA-Pongo schrieb im Beitrag #6106000: >> - uC-Softcore Programm (mit eigenem svn/git repo) > Das steckt aber nicht im BIt-File (?) Bei mir schon. Duke
Weltbester FPGA-Pongo schrieb im Beitrag #6106000: > Blechbieger schrieb: >> Wenn du die Releaseversion erzeugst durch Ändern der Sourcen und neu >> übersetzt ist das ein komplett anderer Bitstream als der den du getestet >> hast. > > Richtig, und wenn man das tut, gab es einen Grund dafür. Also haben wir > ein req change, eine neue Version, neue Beschreibung, aktualisierten > Testplan und eine Projektfreigabe für die Änderung, BEVOR das Ganze > angegangen wird. Du hast ihn glaube ich falsch verstanden. Es geht darum, den quasi-finalen Stand zu testen, und wenn der fehlerfrei ist schreibt man so etwas wie "final" in die Version. Das ist also die einzige Änderung, und diese führt zu einer Änderung des Bitstroms, da die Syn/PAR-Tools auch bei kleinen Änderungen manchmal viel anders machen (je nachdem ob die Version in FF oder RAM gespeichert ist, mal mehr mal weniger). Man hat also nicht den finalen Bitstrom getestet. Weltbester FPGA-Pongo schrieb im Beitrag #6106000: > VHDL hotline schrieb im Beitrag #6105151: >> Weitere Anwendungsfälle für das Ändern von Speicherinhalt nach >> Synthese/PAR zum Erzeugen verschiedener Bitstreams: >> - uC-Softcore Programm (mit eigenem svn/git repo) > Das steckt aber nicht im BIt-File (?) Wo sonst? Weltbester FPGA-Pongo schrieb im Beitrag #6106000: >> - geräteindividuelles kryptographisches Material > Das gehört nicht ins BIT-File, sondern in eine gerätespezifischen > Bereich eines EPROMs inklusive Sicherung gegen Auslesen und Verwenden. Das ist zu pauschal. Erstens eine Frage des benötigten Sicherheitsniveaus, zweitens eine Frage des Anwendungsszenarios.
VHDL hotline schrieb im Beitrag #6106381: > ... Es geht darum, den > quasi-finalen Stand zu testen, und wenn der fehlerfrei ist schreibt man > so etwas wie "final" in die Version. Das ist also die einzige Änderung, > und diese führt zu einer Änderung des Bitstroms, da die Syn/PAR-Tools > auch bei kleinen Änderungen manchmal viel anders machen (je nachdem ob > die Version in FF oder RAM gespeichert ist, mal mehr mal weniger). Man > hat also nicht den finalen Bitstrom getestet. Keine Ahnung, wie Xilinx das macht, aber bei Altera kann man (zumindest nach meinem Wissen) "offiziell" an einer einmal erzeugten Config nichts mehr ändern. Was man kann (und da spricht aus meiner Sicht wenig dagegen) ist, die .mif- (memory initialization file, also irgendwelche ROM-Daten) Dateien ändern und mit dem (ansonsten nicht veränderten) Ergebnis der Synthese neu assemblieren (das setzt natürlich voraus, dass man auch wirklich mit den - ansonsten eher unhandlichen - .mif Dateien umgeht). Damit sind lediglich die ROM-Inhalte modifiziert (ein Datum oder eine SCM-Kennung läßt sich so einfach "unterschieben"), das Design aber ansonsten unverändert.
Markus F. schrieb: > Damit sind lediglich die ROM-Inhalte modifiziert (ein Datum oder eine > SCM-Kennung läßt sich so einfach "unterschieben"), das Design aber > ansonsten unverändert. Bei Xilinx das gleiche Prinzip. Zusaetzlich gibt es noch das User Access Feld. Das ist ein dedizierter (kleiner) ROM in dem man noch ein paar Daten ablegen kann, bzw. der IDE sagen kann dass es nach jedem Bitfile Build da automatisch etwas reinschreibt, wie z.B. das Build Datum.
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.