Hallo, ich habe ein Modul vorliegen (nicht von mir), in dem ein umfangreicher ungetakteter Prozeß ist. Ist nicht schön, aber es tut. Die Sensivity-Liste ist ellenlang. Frage: Soweit ich weiß, wird die Sensivity-Liste von der (Xilinx)-Toolchain bei der Synthese automatisch vervollständigt und nur für die Simulation muß sie korrekt sein. Ist es legithim, die Sensivity-Liste für die Synthese komplett wegzulassen? (Gibt eine Warning, aber das macht in dem Fall nichts)
Bronco schrieb: > Ist es legithim, die Sensivity-Liste für die Synthese komplett > wegzulassen? Willst Du überhaupt nicht simulieren? Der "lästige" Simulationsoverhead zahlt sich in der Regel mehrfach aus... Du brauchst die Sensitivityliste nur für die Simulation (nach der Synthesis ist die HW ja einfach da, nichts muss getriggert werden).
Bronco schrieb: > Ist es legithim, die Sensivity-Liste für die Synthese komplett > wegzulassen? 1. Du kannst sie nicht weglassen (bzw. nur, wenn du ein wait im Prozess hast). 2. Du kannst sie nicht leerlassen. Wenn du hinnimmst, dass deine Simulation dann sicher nicht mehr stimmt, dann schreibst du irgendwas da rein, dann geht das. Aber es wird dich einholen. Garantiert. In VHDL2008 gibt es auch die Möglichkeit die Sensitivliste mit (ALL) zu beschreiben.
Peter K. schrieb: > Willst Du überhaupt nicht simulieren? Der "lästige" Simulationsoverhead > zahlt sich in der Regel mehrfach aus... Simulieren werde ich in diesem konkreten Fall nie. Das Modul ist fertig und seit längerem im Feld erprobt. Ich möchte es nur etwas aufräumen und übersichtlicher machen, ohne die Funktionalität zu ändern. Lothar Miller schrieb: > 1. Du kannst sie nicht weglassen (bzw. nur, wenn du ein wait im > Prozess hast). Doch, das geht. Ich hab einen Vergleich der Bitfiles mit und ohne Sensivity-Liste gemacht, und beide Bitfiles sind (bis auf's Datum) identisch. Alles muß die Toolchain die vollständige Sensitivity-Liste selber erstellt haben. Lothar Miller schrieb: > In VHDL2008 gibt es auch die Möglichkeit die Sensitivliste mit (ALL) zu > beschreiben. Danke, das hört sich gut an.
Bronco schrieb: > Lothar Miller schrieb: >> 1. Du kannst sie nicht weglassen >> (bzw. nur, wenn du ein wait im Prozess hast) > Doch, das geht.
1 | process begin |
2 | -- jetzt kommt alles, aber kein "wait"
|
3 | end process; |
Sowas geht?
Lothar Miller schrieb: > Sowas geht? Sorry, ich seh gerade, ich hab was übersehen: Erst kommt ein riesiger ungetakteter Block, aber ganz am Ende steht doch noch ein if(rising_edge(...)) Block.
Bronco schrieb: > Erst kommt ein riesiger ungetakteter Block, aber ganz am Ende steht doch > noch ein if(rising_edge(...)) Block. Uuuups. Das ist aber schief gegangen! Kombinatorik und getakteter Teil in einem Prozess? Das grenzt ja an "Kündigungsgrund"... :-o Wie auch immmer: In einem if(rising_edge(...)) ist kein wait zu finden. Du kannst dort also nicht die Sensisitvliste leer lassen. Evtl. bekommst du aber nur eine Warnung. Ich probier das gerade mal aus... ... XISE sagt dazu:
1 | No sensitivity list and no wait in the process |
Bronco schrieb: >> Willst Du überhaupt nicht simulieren? > Das Modul ist fertig [...]. Ich möchte es nur etwas aufräumen und > übersichtlicher machen, ohne die Funktionalität zu ändern. Sicher... ;-) Die Simulation zeigt Dir dann den Unterschied zwischen "möchten" und "tun". Lothars Tip bzgl VHDL-2008 ist sicherlich die übersichtlichste Methode, unhandliche Sensitivity Listen in den Griff zu bekommen. -- Marcus
Marcus Harnisch schrieb: > Sicher... ;-) Die Simulation zeigt Dir dann den Unterschied zwischen > "möchten" und "tun". Das wäre ohne Frage der richtige Weg, wenn ich auch nur ansatzweise nachvollziehen könnte, was das Modul genau machen soll. So könnte ich nur etwas simulieren, von dem ich nicht weiß, wie das Ergebnis aussehen soll. Lothar Miller schrieb: > Uuuups. Das ist aber schief gegangen! Kombinatorik und getakteter Teil > in einem Prozess? Das grenzt ja an "Kündigungsgrund"... :-o Ja, mit dem Gedanken trage ich mich regelmäßig, wenn man mir solche Projekte über den Zaun wirft. Vorallem dann diese Diskussionen, das doch alles perfekt funktioniert und ich die >3000 (kein Witz) Timing-Verletzungen doch einfach ignorieren soll...
Bronco schrieb: > Marcus Harnisch schrieb: >> Sicher... ;-) Die Simulation zeigt Dir dann den Unterschied zwischen >> "möchten" und "tun". > Das wäre ohne Frage der richtige Weg, wenn ich auch nur ansatzweise > nachvollziehen könnte, was das Modul genau machen soll. So könnte ich > nur etwas simulieren, von dem ich nicht weiß, wie das Ergebnis aussehen > soll. Warum willst Du das dann "aufräumen"? Das Modul macht doch angeblich was es soll. Never touch a running system. Besonders, wenn es, wie es scheint, weder Doku noch Testbench gibt. Ästhetische Gründe rechtfertigen das nicht. -- Marcus
Bronco schrieb: > Soweit ich weiß, wird die Sensivity-Liste von der (Xilinx)-Toolchain bei > > der Synthese automatisch vervollständigt Da wird nichts vervollständigt, sondern die wird einfach ignoriert, weil die Synthese die nicht braucht. Die Synthes baut alles, was dasteht, egal welcher Zeitabluf sich dahint verbirgt. Nur die SImulation muss das "wissen" weil sie nur das ansprint, was auch zueinander abhängig ist.
Marcus Harnisch schrieb: > Warum willst Du das dann "aufräumen"? Das Modul macht doch angeblich was > es soll. Never touch a running system. Okay, ich war nicht ganz ehrlich: Wir hoffen und beten, daß es tut, was es soll. Nachweisen kann es ja leider keiner mehr. Wenn in der Vergangenheit Probleme aufgetreten sind, wurden halt irgendwelche Workarounds gebastelt. Mein Ansatz ist: erstmal das Modul so verstehen, wie es ist. Quasi Reverse-Engineering. Kommentare einfügen, Signale erklären, den Code strukturieren. Im zweiten Schritt könnte ich dann sogar Bugs finden...
>Okay, ich war nicht ganz ehrlich: Wir hoffen und beten, daß es tut, was >es soll. Nachweisen kann es ja leider keiner mehr. >Wenn in der Vergangenheit Probleme aufgetreten sind, wurden halt >irgendwelche Workarounds gebastelt. >Mein Ansatz ist: erstmal das Modul so verstehen, wie es ist. Quasi >Reverse-Engineering. Kommentare einfügen, Signale erklären, den Code >strukturieren. Damit verstehtst du den Code lokal besser aber nicht die Funktionsweise des Modules. Dein Ansatz sollte besser sein, als erstes eine Simulations ans laufen zu bekommen.: -in TB Instanzieieren -Takt und reset drantütern -In simulator laden -Im wave alle Ausgänge anzeigen lassen - schauen was passiert. Simulation ist Reverse Engineering, dein Ansatz dagegen ist hoffnungsvolle Kaffesatzleserei. Gruß PS.: >Im zweiten Schritt könnte ich dann sogar Bugs finden... Wie willst du bugs erkennen, wenn du keine Spec/referenzpattern/Doku hast? Ein Bugs ist dann das, was im Code nach deiner Ansicht nach einem Bug aussieht?! Das ist reichlich unbedarft.
Drill-Tutor schrieb: > Simulation ist Reverse Engineering, dein Ansatz dagegen ist > hoffnungsvolle Kaffesatzleserei. Seh ich anders. Ich versuche zuerst herauszufinden, was das Modul machen soll, sprich, welche Konzepte dahinterstecken. Denn die Konzepte sind schon durchdacht, nur halt nicht dokumentiert. Was es tatsächlich macht, kann ich heute schon mit ChipScope nachvollziehen, aber ich kann nicht beurteilen, ob dies korrekt ist, solange ich nicht weiß, was es machen soll.
Bronco schrieb: >> Simulation ist Reverse Engineering, dein Ansatz dagegen ist >> hoffnungsvolle Kaffesatzleserei. > > Seh ich anders. Ich versuche zuerst herauszufinden, was das Modul machen > soll, sprich, welche Konzepte dahinterstecken. Denn die Konzepte sind > schon durchdacht, nur halt nicht dokumentiert. > > Was es tatsächlich macht, kann ich heute schon mit ChipScope > nachvollziehen, aber ich kann nicht beurteilen, ob dies korrekt ist, > solange ich nicht weiß, was es machen soll. "was es machen soll" erfährst Du niemals mit Reverse-Engineering. Dafür brauchst Du eine Spezifikation. Mit Reverse-Engineering und Code anschauen findest Du (nicht mehr und nicht weniger) heraus "was es tut", potentielle Bugs hebe sich da nicht ab. Wenn Du also keine Dokumentation/Spezifikation vorliegen hast, ist der Weg über die Simulation sicher der gute Weg. Du kannst damit wenigstens beweisen, dass deine optimierte Version immer noch dasselbe macht wie vorher und Du keine neuen Fehler eingebaut hast (der +/-1 Bock lässt grüssen...). Und wenn Du Dokumentation/Spezifikation vorliegen hast gilt das genau so, nur kannst Du zusätzlich dazu potentielle alte Böcke auch noch angehen.
Peter K. schrieb: > "was es machen soll" erfährst Du niemals mit Reverse-Engineering. Dafür > brauchst Du eine Spezifikation. Mit Reverse-Engineering und Code > anschauen findest Du (nicht mehr und nicht weniger) heraus "was es tut", > potentielle Bugs hebe sich da nicht ab. Gut, dann ist Reverse-Engineering der falsche Begriff. Nennen wir es Spaghetti-Code-Dekyrptographie. Ich kann aus dem Source-Code mit zunehmender Erfahrung auf das zurückschließen, was der ursprüngliche Entwickler machen wollte. Er schreibt an einer Stelle 10 Worte in den FIFO, also gehe ich davon aus, daß er an anderer Stelle auch 10 Worte auslesen will. Wenn er aber 11 Worte ausliest, weiß ich, daß ich diese Stelle intensiv anschauen und testen (bzw. simulieren) muß. Zu diesem Verständnis hilft es mir ungemein, den Code in eine Form zu bringen, die ich besser lesen kann, obwohl das Verhalten noch identisch ist. PS: nach der Denkweise meines Brötchengebers liegt eine Spezifiktion sehr wohl vor, nur eben in Form von Spaghetti-Code :-O
Bronco schrieb: > Ich kann aus dem Source-Code mit zunehmender Erfahrung auf das > zurückschließen, was der ursprüngliche Entwickler machen wollte. Chapeau! > Er schreibt an einer Stelle 10 Worte in den FIFO, also gehe ich davon > aus, daß er an anderer Stelle auch 10 Worte auslesen will. Wenn er > aber 11 Worte ausliest, weiß ich, daß ich diese Stelle intensiv > anschauen und testen (bzw. simulieren) muß. Um bei Deinem Beispiel zu bleiben: Er kann auch 10 Worte reinschreiben und 10 Worte rauslesen und trotzdem was falsch gemacht haben. Oder so. > Zu diesem Verständnis hilft es mir ungemein, den Code in eine Form zu > bringen, die ich besser lesen kann, obwohl das Verhalten noch identisch > ist. Gerade damit nach Deiner Optimierung das Verhalten noch identisch ist, hilft Dir eine Regression-Simulation (vorher-nachher mit "golden" Sets).
Peter K. schrieb: > Gerade damit nach Deiner Optimierung das Verhalten noch identisch ist, > hilft Dir eine Regression-Simulation (vorher-nachher mit "golden" Sets). Die es anscheinend nicht gibt. Man könnte mit einem LEC Werkzeug formal überprüfen, ob die Logik von altem und "aufgeräumten" Design identisch ist. Kostet aber ein bisschen.
Marcus Harnisch schrieb: >> Gerade damit nach Deiner Optimierung das Verhalten noch identisch ist, >> hilft Dir eine Regression-Simulation (vorher-nachher mit "golden" Sets). > > Die es anscheinend nicht gibt. Man könnte mit einem LEC Werkzeug formal > überprüfen, ob die Logik von altem und "aufgeräumten" Design identisch > ist. Kostet aber ein bisschen. Ich mach das viel einfacher: Beim Aufräumen gibt's nur Änderungen, bei denen das Bitfile identisch bleibt. Wenn ich dann ein Grundverständnis hab, wage ich mich auch daran, Signalnamen per Find-Replace umzubennen. Leider verhält sich die Xilinx-Toolchain so, daß das Ändern von Signalnamen i.d.R. zu einem anderen Bitfile führt (schätzungsweise, weil die Signalnamen nach Alphabet sortiert werden).
>Wenn ich dann ein Grundverständnis hab, wage ich mich auch daran, >Signalnamen per Find-Replace umzubennen. Leider verhält sich die >Xilinx-Toolchain so, daß das Ändern von Signalnamen i.d.R. zu einem >anderen Bitfile führt (schätzungsweise, weil die Signalnamen nach >Alphabet sortiert werden). Ne, das hat nix mit sortierung etc zu tun. Eher das die namensbasierenden constraints im ucf file ins leere laufen. Im günstigsten file ist nur das routing etwas anders, im worst case hat sich die Zurordnung Netz - Pin geändert - das ist dann tödlich. Besser als umbenennen wäre IMHO eine Dokumentation der teilblöcke mit ein und asugehenden Signalen, Taktdomain, reset, und kurzer beschreibung was da gemacht wird (FIFO, data processing, synchronisierung) Oft hilft ein Blick in den synthesereport da steht was an Counter, Muxern, Block-Rams, FSM erkannt und synthetisiert wurde. MfG
Bronco schrieb: > Leider verhält sich die > Xilinx-Toolchain so, daß das Ändern von Signalnamen i.d.R. zu einem > anderen Bitfile führt (schätzungsweise, weil die Signalnamen nach > Alphabet sortiert werden). Nicht unbedingt. Die Algorithmen die hinter der Umsetzung der Schaltung (Place & Route) stehen, sind heuristische Algorithmen. Für ihre Arbeit brauchen die Tools einen Startwert. Der wird bei manchen Tools (u.U. auch bei Xilinx) aus der Eingabe generiert.
Mathi schrieb: > Für ihre Arbeit brauchen die Tools einen Startwert. Der wird bei > manchen Tools (u.U. auch bei Xilinx) aus der Eingabe generiert. Andere lassen die Toolchain mit unterschiedlichen Werten mal über Nacht durchlaufen, und nehmen dann die Werte für das beste Design als Startwerte für das weiter vorgehen...
Bronco schrieb: >> Leider verhält sich die >> Xilinx-Toolchain so, daß das Ändern von Signalnamen i.d.R. zu einem >> anderen Bitfile führt (schätzungsweise, weil die Signalnamen nach >> Alphabet sortiert werden). >Nicht unbedingt. Die Algorithmen die hinter der Umsetzung der Schaltung >(Place & Route) stehen, sind heuristische Algorithmen. Für ihre Arbeit >brauchen die Tools einen Startwert. Der wird bei manchen Tools (u.U. >auch bei Xilinx) aus der Eingabe generiert. Dann hat sich das bei Xilinx geändert. Nach Aussage Xilinx- FAE und eigenen Tests wird der Start wert fürs simulated annealing beim plac/routing nicht bei jedem lauf zufällig erzeugt sondern man bedient sich eines seeds das der user den Toolchain explicit übergibt. Wenn aber ein tool eines drittherstellers in die Toolchain spuckt (synthese) haben die xilinx-aussagen auch keinen wert. Gruß
Danke für die Info! Meine Aussage war nur eine Hypothese, warum das Ergebnis ein anderes sein kann. Hatte damit nämlich vor ein paar Jahren mal ein Problem und vom damaligen FAE diese Info bekommen. Dann kann es aber auch nicht der Grund für das unterschiedliche Ergebnis sein.
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.