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.
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.
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:> 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.
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. ;-)
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.
