Irrtümlicher clock

[P. K. (pek)]

Hallo zusammen

ich erhalte im Quartus Timing Analyzer folgende Warnung:

Warning: Node: PROCMUX:PM|DELTAENC:\CDE:CMPD|GENEXP:EXP|exp_cur[0] was 
determined to be a clock but was found without an associated clock 
assignment.

Nun wüsste ich gerne, welchen Pfad der Timing Analyzer im Auge hat. Wie 
kriege ich das am schnellsten heraus?

(Code-Review hat nichts Verdächtiges geliefert und allgemeine Suche, 
sprich fishing Expedition, nach solchen pfaden à la

report_timing -from [get_registers 
{*DELTAENC*CMPD|GENEXP:EXP|exp_cur[0]}] -to [get_pins {*|*|clk *|*|*|clk 
*|*|*|*|clk *|*|*|*|*|clk}] -npaths 100 -panel_name {Report Timing: 
bad_clock}

bringen auch nur Resultate im Stil

Info: Report Timing: No setup paths were found)

Hat da wer eine Idee, wie ich da weiterkomme?

Thanks!

[Matthias (Gast)]

Unter Tools gibts den Punkt "find in design". Auch bei der Auflistung im 
Hauptfenster wenn Quartus fertig ist kann man dort das signal anklicken 
und sich anzeigen lassen. Oder halt händisch suchen im RTL-Viewer.

[P. K. (pek)]

Matthias schrieb:
> Unter Tools gibts den Punkt "find in design". Auch bei der Auflistung im
> Hauptfenster wenn Quartus fertig ist kann man dort das signal anklicken
> und sich anzeigen lassen.
Bei mir nicht. Gab's das in 10.1 noch nicht?

> Oder halt händisch suchen im RTL-Viewer.
Naja, das ist dann die berühmte Nadel im Heuhaufen. Ein erster 
Suchanlauf hat nichts gebracht. :-(

Ich denke, wenn das Tool warnt, hat es ja ein ganz bestimmtes Target im 
Blickfeld, also sollte ich diese Info doch auch irgendwie 
deterministisch aus dem Tool rauskriegen (im Stil von: Der und der RTL 
Input ist ein Clock und wird von dem erwähnten Signal getrieben...)

[Matthias (Gast)]

zB im netlistviewer kann man find verwenden auch in 10.1.

[Pille (Gast)]

Da steht doch explizit, um welches Signal es geht:

Peter K. schrieb:
> PROCMUX:PM|DELTAENC:\CDE:CMPD|GENEXP:EXP|exp_cur[0]

Dann entweder im Code alle kombinatorischen Pfade durchgehen, ob da 
irgendwo ein rising_edge() drauf gemacht wird. Oder im RTL Viewer das 
Signal anzeigen lassen, und dann alle Fanouts davon filtern.

[P. K. (pek)]

Pille schrieb:
> Da steht doch explizit, um welches Signal es geht:

Ja natürlich!

Aber nach dem erfolglosen Durchchecken vom Code und dem noch viel 
aufwändigeren erfolglosen Durchchecken in der RTL-View dachte ich, dass 
ich mal hier im Forum versuche weiter zu kommen.

Im TimingAnalyzer sehe ich, dass alle 1230 Pfade, die von diesem 
Register ausgehen, wieder in einem Dataregister oder RAM-Data-Input 
enden.

Woran ich also interessiert bin, ist herauszufinden, weshalb das Tool 
dieses Signal im Fokus hat. Dazu wäre es nützlich, nicht nur "explizit" 
die Quelle der Warnung zu wissen sondern auch das Ziel (sprich der 
angeblich vermutete Clock-Input, welcher von dem Signal gespiesen wird).

[Karl (Gast)]

Hier könnte es weiterhelfen, den Code zu posten - ansonsten ist das 
Kaffeesatzleserei :-)

[P. K. (pek)]

Karl schrieb:
> Hier könnte es weiterhelfen, den Code zu posten - ansonsten ist das
> Kaffeesatzleserei :-)

Eben nicht.

Eigentlich ist es mir um die Methodik gegangen.

Will heissen: wie kriege ich bei einer Fehlermeldung mehr Info aus dem 
Tool heraus. In diesem Fall bemängelt Quartus einen unspezifizerten 
Clock. Da muss es also irgend einen Clock-Input geben, der von genau 
diesem Signal getrieben wird, und diese Info (welche das Tool 
zweifelsfrei hat), würde ich dem Tool gerne entlocken (denn dass wäre 
wertvolle Debugging-Info, ohne die oben mehrfach angeratenen 
Brute-Force-Methoden nutzen zu müssen).

Wie dem auch sei, funktionell auf dem Prototyp hatte die Warnung nie ein 
Problem verursacht, nach 1 Woche Entwicklung und 8 Synthesen ist die 
Warnung genauso rätselhaft wieder verschwunden, wie sie aufgetaucht ist.

Wäre halt generell spannend gewesen, wie man in so einer Situation mehr 
Info aus dem Tool herausholt, aber vielleicht war das etwas zu 
spezifisch...