Hallo liebe VIVADOUser, mich nervt es tierisch, dass die Verzeichnisstruktur eines Projekts deutlich umständlicher ist wie bei ISE. Ok dass man Constraints und Simulation und normale Sourcen trennt verstehe ich noch, aber es geht ja weiter, es gibt also ein constr_1 sources_1 sim_1 im sources_1 landen dann aber nicht direkt alle Sourcen, sondern wenn man eine neue Source anlegt ist diese in sorces_1/new. Was soll das? Da landen alle selbst angelegten Sourcen egal ob neu oder nicht. Aber noch schlimmer ist es wenn man welche importiert, dann landen die in sources_1/imports, aber nein nicht direkt dort sondern der Ordnername aus dem heraus man importiert hat ist dann auch noch im Pfad, also z. B. wenn man Sourcen aus dem sources_1/new Ordner eines anderen Projekts importiert landen sie dann in sources_1/imports/new, importiert man Sourcen aus einem alten ISE Projekt, dann hat man sowas wie sources_1/imports/alter_Projektname. Es führt dazu dass wenn man Sourcen aus unterschiedlichen Orten importiert man viele Unterordner bekommt. Wie geht ihr damit um? Kann man das einfach so umstellen dass alles direkt im sources_1 landet? Vielen Dank!
Hallo Gustl, das hat mich auch schon genervt .. Wenn ich ein Projekt kopieren will, kopiere ich den src Ordner aus dem alten Projekt in das neue Projekt. Dann den Abschnitt <FileSets ..> aus dem alten xpr File in das neue xpr File kopieren (überschreiben). Das klappt auch wenn du IPs dabei hast.
:
Bearbeitet durch User
Danke! Ja hab jetzt händisch die xpr angepasst und das funktioniert, hätte mir aber eine Option gewünscht mit der man irgendwie einstellen kann dass alle Sourcen direkt im sources_1 landen ohne Unterordner.
Kämpfe mich auch gerade damit ab. Meine Frage ist: Wie schiebt man Cores in ein eigenes Verzeichnis? Ich habe eine ISE App konvertiert und alle IP Cores aus dem Verzeichnis werden beim updaten gelöscht und woanders neu angelegt. Wie schiebe ich die Cores und andere Dateien in MEINE Verzeichnisstruktur und gewöhne dem Ding ab, Müll zu produzieren?
Xilinx-Hasser schrieb: > Kämpfe mich auch gerade damit ab. Meine Frage ist: > > Wie schiebt man Cores in ein eigenes Verzeichnis? Ich habe eine ISE App > konvertiert und alle IP Cores aus dem Verzeichnis werden beim updaten > gelöscht und woanders neu angelegt. > > Wie schiebe ich die Cores und andere Dateien in MEINE > Verzeichnisstruktur und gewöhne dem Ding ab, Müll zu produzieren? Die Pfadangaben stehen alle im xpr file. Wenn du in Vivado eine IP neu anlegst landed die in xxx.srcs\sources_1\ip Versuchs mal so ... Verzeichnisstruktur: xxx.srcs\sources_1\ip\IP1_SUBDIR xxx.srcs\sources_1\ip\IP2_SUBDIR XPR File: <FileSet Name="IP1_NAME" Type="BlockSrcs" RelSrcDir="$PSRCDIR/IP1_SUBDIR"> <File Path="$PSRCDIR/sources_1/ip/IP1_SUBDIR/IP1_NAME.xci"> <FileInfo> <Attr Name="UsedIn" Val="synthesis"/> <Attr Name="UsedIn" Val="implementation"/> <Attr Name="UsedIn" Val="simulation"/> </FileInfo> </File> <Config> <Option Name="TopModule" Val="IP1_NAME"/> <Option Name="UseBlackboxStub" Val="1"/> </Config> </FileSet> und für IP2 das gleiche nochmal Und natürlich deine IP in das Verzeichnis kopieren ;)
:
Bearbeitet durch User
Genau diese Verzeichnisstruktur xxx.srcs\sources_1\ip\IP1_SUBDIR gefällt mir eben nicht. Ich will alle Sourcen in xxx.srcs\sources_1 drinnen haben. Gut händisch anpassen funktioniert aber naja, schade dass es keine einfachere Methode gibt.
Das war doch nur ein Beispiel. Du kannst doch Pfade angeben wie du willst. Ich bin halt eher fürs Strukturieren wie alles in einen Topf zu werfen. Aber jeder nach seinem Geschmack ... Vivado kann mehrere Konfiguration verwalten und in verschiedenen Verzeichnissen halten das ist bestimmt bei grösseren Projekten sinnvoll. Das die Burschen mal wieder übder das Ziel hinaus geschossen sind ist ein anderes Thema.
:
Bearbeitet durch User
Hans-Georg L. schrieb: > Das die Burschen mal wieder übder das Ziel hinaus geschossen sind ... wundert mich nicht wirklich. Xilinx war noch niemals eine Leuchte, wenn es um Ordnung im Projekt ging. Da müsste wohl mal jemand ran, der denen Logik erklärt. Nach meinem Dafürhalten sollte sich der Hersteller aus den Themen der Dateistruktur weitgehend heraushalten, weil es projektbedingt Gründe gibt, dies unterschiedlich zu handhaben, z.B. bei Schaltungen mit verschiedenen Interfaces und PCBs. Dabei gibt es sowohl mehrfach genutzte Quellen wie auch Quellenderivate und je nachdem, ob und wo die sonst noch gelinkt werden, macht es Sinn, die in fremden / gemeinsamen Projektordnern zu halten. Quellen sind eben Quellen und haben mit dem eigentlichen Projekt, nämlich der Synthese nichts zu tun. Daher haben sie dort auch nichts zu suchen. Der einzig saubere Weg ist der, wie er in gut sortierten Firmen der SW-Branche gegangen wird, nämlich Code und Scripte sauber zu versionieren und in Datenbanken zu halten.
Ist aber schwierig, das durchzuziehen, weil es jeder Designer anders macht. Außerdem kommen von den CodeGeneratoren wie MATLAB, HDL-Designer und den SOPC-buildern eigene Vorgaben für Dateien, deren Benennung und Ablage. Bei meinen eigenen Projekten handhabe ich es so, dass jede Datei dem Projekt ausdrücklich zugeordnet wird. Ein Derivat, das auf einer anderen aufbaut, wird höchstens mit einem Kürzel versehen, der grob darauf hinweist - die genaue Beschreibung steht in einer Excel-Liste. Jede einzelne Datei bekommt im Dateinamen das Datum und Urzeit der Ersterstellung. Z.B. "Sinus_DDS_20060428_1531". Damit ist gewährleistet, das es immer eine eindeutige Zuordnung zwischen ähnlichen Dateien mit leicht abweichender Funktion in den Projekten gibt. Somit ist es egal, wo die Datei liegt, ob sie gelinkt wird oder ausdrücklich verwendet wird, bzw. ob sie von einem oder mehreren Projekten und Synthesetools zugegriffen wird. Wird eine Datei geändert, kriegt sie einen neuen Namen. Soll sie verwendetet werden, wird sie ausdrücklich gelinkt, oder irgendwohin kopiert. Damit gibt es keine ungewollten Änderungen an alten bestehenden Projekten und auch selbst ein ungeschickter checkout durch Subversion kann nichts kaputtmachen. Die Files können dann irgendwo gesammelt herumliegen oder so eingelagert werden, wie es da Tool vorsieht. Die Ordnung bleibt erhalten. Bei mir kommt alles Synthetisierbare in SRC, Modelle und Testbenches in eigene Ordner. Dient aber nur dem leichteren Auffinden. Eine schlecht durchdachte Datei- und Projektverwaltung der Tools kann man sich dann schenken. Es braucht nur eine Übersicht, welche Version eines Systems unter welchen Bedingungen auf welche Sourcen zugreifen muss, um zu funktionieren. Lässt sich gut in Scripten halten. Derjenige, der dann bei sich lokal für seinen Chip und seine HW einen built macht, ist dann selber dafür verantwortlich, sein Script anzupassen und neue, geänderte Sourcen reinzunehmen. Dies verhindert das typische Chaos beim sustaining alter Hardware mit angepasster SW und erleichtert auch die Wiederverwendbarkeit, weil man sich leichter tut, auf unnötige Modularisierung zu verzichten und eben schnell eine Version machen kann. Um in sicherheitskritischen Bereichen zu verhindern, dass falsche Versionen, die linkbar wären, aber zu Fehlfunktionen führen, ungewollt zusammengelinkt werden, kann man der Quelle auch eine auslesebare Versionsnummer = Dateinummer als Variable verpassen. Das jeweils übergeordnete File prüft dann die Richtigkeit der Source und meldet es passend weiter nach oben. Ein Überwachungsmodul prüft dann zur Lautzeit die SW-Module auf Plausibilität. Auf diese Weise kann in der Entwicklung ein möglicher Fehler des Built-Managers / Configuration-Managers verhindert werden. In VHDL ist das besonders elegant, weil das nicht einmal zusätzliche Struktur produziert, sondern eine so weitergereichte Sourcen-ID bei UND-Verknüpfung mit den Ausgängen dazu führt, dass das Modul leer ist und nichts erzeugt wird. Wenn aber alles stimmt, fliegt der entscheidende Komparator einfach raus.
Man kann z.B. bereits bestehende Dateien (aus Libs oder andere) auch einfach einem Projekt hinzufügen. Diese landen dann nicht unter "sources_1/new", sondern bleiben wo sie sind. Hierz muss man beim Hinzufügen der Dateien den Haken unten bei "copy sources into project" entfernen. Vielleicht hilft das dem Ein oder Anderen :)
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.