Prozess-Sensivity-Liste leer lassen

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.

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.

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

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

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.

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.