Hierarchische Refernzen in SystemVerilog mit Synplify

[Vancouver (Gast)]

Hallo,

in (System)verilog kann man Signale über Hierarchiegrenzen hinweg 
referenzieren, z.B. A.B.C.s, wenn A, B und C hierarchische 
Moduleinstanzen sind und s ein Signal in Modul C. Wenn s ein Vektor ist, 
kann man mit A.B.C.s[i] auf das i-the Element zugreifen.

Ok soweit, aber angenommen, das Modul C wird innerhalb einer generate 
loop mehrmals instanziiert, und es soll nur die Instanz 0 referenziert 
werden. Ich hätte erwartet, dass die Referenz A.B.C[0].s heißt, aber das 
funktioniert nicht. "Could not resolve hierarchical reference" lautet 
der Fehler bei Synplify. Offenbar wird die Instanz C anders indiziert 
als mit [0]. Weiß jemand, wie die korrekte Referenz heißt?

[Lattice User (Gast)]

Nicht das Module wird indiziert sondern der darüber liegende begin..end 
block.

  for( ... )
    begin
      ModuleName C( .. )
    end

Hier also A.B.xxxxx[0].C.s
Da kein Block Name definiert ist, denkt sich Synplify einen aus und du 
darfst raten.

Also besser:

  for( ... )
    begin:BLK
      ModuleName C( .. )
    end

-> A.B.BLK[0].C.s

[Vancouver (Gast)]

Genau das habe ich mittlerweile auch herausgefunden, aber leider 
funktioniert es trotzdem nicht. Die for-Schleife hat einen Namen wie in 
Deinem Bespiel und ich habe die Referenz nach dem Schema A.B.BLK[0].C.s 
benannt, aber es gibt immernoch den "Could not resolve hierarchical 
reference"-Fehler.

Es gibt wohl eine Synplify-Option, die die Indizierung von den eckigen 
Klammern in etwas anderes ändert. Der Aufruf wäre dann z.B. 
A.B.BLK_0__C.s. In den Scripten kann ich die change_name-Option aber 
irgens finden (die Scripten sind recht lang und nicht von mir), deswegen 
sollten die ecjigen Klammern eigentlich funktionieren.

Ich muss einfach mal weitersuchen. Es ist sowieso ein Wahnsinn, 
hierarchische Referenzen außerhalb der Simulation zu verwenden, aber der 
Code ist nun mal so.

[Lattice User (Gast)]

Vancouver schrieb:

> Es ist sowieso ein Wahnsinn,
> hierarchische Referenzen außerhalb der Simulation zu verwenden, aber der
> Code ist nun mal so.

Hatte ich mir verkniffen anzumerken.
Zu Debugzwecken einzelne Signal auf Pins rauszuschalten ist imo die 
einzige gerade noch sinnvolle Anwendung.


Bei Lattice Diamond muss ich es im Constraintfile d.h ausserhalb von 
Synplify folgendermassen referenzieren:
A/B/BLK[0].C/s

Im Code habe ich bisher nie ausserhalb der Simulation gemacht, wie du 
schreibst das ist fortgeschrittener Wahnsinn.

[Lattice User (Gast)]

Vancouver schrieb:
> A.B.BLK_0__C.s. In den Scripten kann ich die change_name-Option aber

In der Synplify Hilfe finde ich keine change_name option.

Relevante settings könnten sein:

set_hierarchy_separator
bus_naming_style
bus_dimension_separator_style

Das Beispiel in der Hilfe für bus_naming_style ersetzt A[0] durch A_0.
(gehört wenn ich es richtig sehe in den constraint file)

[Lattice User (Gast)]

Probier mal

A.B.BLK_0.C.s

[Vancouver (Gast)]

Danke, das probiere ich mal aus. ich muss auch zugeben, dass ich bei 
Synplify noch etwas "newbie" bin.

Zum Thema Wahnsinn: Die betreffenden Signale sollen auf einen 
Debug-Stecker für den Logicanalyzer gelegt werden. Das kann man mit viel 
gutem Willen noch akzeptieren, wenn es eine temporäre Lösung ist und 
nach erfolgtem Debugging wieder verschwindet. Aber trotzdem verursacht 
das viele Probleme, wenn sich der Code ändert und die herausgezogenen 
Signale plötzlich nicht mehr existieren.  Die Kollegen, die das 
implementiert haben, sind natürlich weg und entziehen sich somit ihrer 
Läuterung.

[Duke Scarring (Gast)]

Vancouver schrieb:
> Die betreffenden Signale sollen auf einen
> Debug-Stecker für den Logicanalyzer gelegt werden.
Ich hab das unter VHDL eine zeitlang mit einem globalen Package gelöst:

library ieee;
use ieee.std_logic_1164.all;

package global_signals is

    signal global_break    : std_ulogic;
    signal global_ready    : std_ulogic;
    signal global_timeout  : std_ulogic;
    ....

end package global_signals;

Das Package wurde an den benötigten Stellen eingebunden. Im top-Modul 
wurden die Signale gelesen und auf den debug-Port ausgegeben und im tief 
vergrabenen Submodul wurde die Signale geschrieben.
Mit Xilinx war das synthetisierbar.

Ich könnte mir vorstellen, das sowas in SystemVerilog auch geht.

Duke