keep-attribute

[P. K. (pek)]

Hallo zusammen

ich versuche, mittels keep-attribute, ein (Debug-)Signal vor dem 
Wegsynthetisieren zu bewahren (Quartus), damit ich's im SignalTap 
darstellen kann. Mein Versuch

  attribute keep               : boolean;
  attribute keep of WdcEventxS : signal is true;

fruchtet aber nicht, das Signal ist nach der Synthese trotzdem weg.

Während der Synthese erhalte ich die (eigentlich erwartete, da noch 
nicht im SignalTap) message/warning:

Warning (10036): Verilog HDL or VHDL warning at procmux.vhd(165): object 
"WdcEventxS" assigned a value but never read

Wie sag' ichs meinem Synthesizer?

[Klaus F. (kfalser)]

Welcher Compiler?

Für Xilinx jedenfalls gilt :
attribute keep               : string;
attribute keep of WdcEventxS : signal is "true";

Docu ist Xilinx "Constraint Guide" (cgd.pdf)

[P. K. (pek)]

Nein, das ist's nicht, bei Altera ist's ein Boolean, das müsste stimmen.
Habe aber folgende Bedingung im Manual überlesen:

> You cannot use this synthesis attribute for signals that have no fan-out.

Wie also mache ich das Signal verfübar, ohne künstlich nicht benötigten 
Fanout einzubauen?

[SuperWilly (Gast)]

"Virtual Pin"

[Cihan K. (lazoboy61)]

Das Problem mit dem Wegsynthesieren hatte ich auch bei Chipscope. Ich 
wollte Signale betrachten, die vorerst keine Verwendung im weiteren 
Programm hattem, die ich aber zur Verständnis gebraucht habe.

Habe es dann folgendermaßen gelöst:
Ich habe einfach einen Output-Pin deklariert, welches ich mit meinem 
Signal kombinierte, um die Wegoptimierung zu blockieren.

Bsp.:

entity Bsp is
Port (
      ...
      Test_Out : std_logic;
      ...
      );
end Bsp;

architecture Behavioural of Bsp is
...
signal bsp_signal: std_logic; -- Signal was normalerweise wegoptimiert wird
...

begin
...

process(clk)
begin
...
if bsp_signal = '1' then      -- Wegoptimierte Signal wird abgefragt,
   Test_Out <= '1';           -- sodass dadurch eine Verwendung da ist
else
   Test_Out <= '0';
end if;
...
end process;
...
end Behavioural;

In diesem Prinzip mache ich es mit allen Signalen, die ich in Chipscope 
betrachten will. So wird auch nichts wegoptimiert. Ist natürlich nicht 
die beste Lösung, aber sie funktioniert. Mit keep-hirarchie hatte ich es 
auch versucht, doch ohne Erfolg.

Benutze selber Xilinx Virtex 5 als FPGA mit ISE Webpack 14.1. Würde auch 
an einer besseren Lösung interressiert sein.

Gruß Cihan

[J. S. (engineer)]

In der Regel sollte ein keep Constraint (hart oder soft = "S") reichen. 
Leider scheinen sich die Xilinx Tools nicht untereinander zu verstehen, 
denn ich habe auch aktuell wieder einen Fall, wo ein halber Bus 
verschwindet, obwohl er ausdrücklich erhalten werden sollte und die 
Xilinx Synthese auf "keep hierarchy = Yes/Soft" steht, was bei anderen 
Signalen funktioniert.

Das seltsame ist, dass das eigentliche Trimming erst im MAP-Prozess 
erfolgen soll, bzw. dort wegklickbar ist, obwohl das ChipScope schon 
nach der Synthese ins Spiel kommt und eigentlich kein getrimmtes Design 
vorfinden sollte.

Ich habe mich dann eine Weile so beholfen, wie Cihan es beschreibt.

Wichtig ist, dass man gleiche Signale mit 2 Namen in unterschiedlichen 
Zeitebenen ins ChipScope führt, weil er auch dort sonst wieder ansetzt 
und Busse verschwinden lässt oder den anderen Namen benutzt.

Eine effektive Methode ist es, erst alle benötigten Signale in die 
ChipScope Domain einzutakten - in kritischen Fällen auch über kurze 
aFiFos - und dann die Signale ins CS zu führen. Das löst auch einige 
Timingprobleme, die der Router immer wieder mal hat (obwohl ja TIGs 
gesetzt werden),

[dasdgw (Gast)]

das Problem kommt mir bekannt vor. :-)

probiers mal mit

signal reg1: std_logic;
attribute noprune: boolean;
attribute noprune of reg1: signal is true;

hat bei mir unter quartus wunderbar funktioniert.

[P. K. (pek)]

dasdgw schrieb:
> attribute noprune: boolean;

Dummerweise ist es in meinem Fall (WdcEventxS) kein Register, geht also 
wieder nicht ganz ohne Zusatzaufwand. Du siehst, bin ein wenig auf der 
Suche nach einer "schönen" Lösung.

Ich lasse mittlerweile meinen WatchDog-Counter bei WdcEventxS = '1' 
saturieren damit das Signal benutzt wird. Dann kann ich mit "keep" 
arbeiten. Meine Hauptanforderung, keine Änderungen für 
Debug-Instrumentierung in den (übergeordneten) Entities zu haben, ist 
somit erfüllt.

[Daniel M. (daniel__m)]

für Xilinx hat bei mir bisher immer das Attribute "S" funktioniert 
(steht wohl für SAVE).

attribute S        : string;
attribute S of xyz : signal is "true";

Dabei ist es egal, ob es ein FF oder ein komb. Signal ist.

[Klaus F. (kfalser)]

Daniel M. schrieb:
> für Xilinx hat bei mir bisher immer das Attribute "S" funktioniert
> (steht wohl für SAVE).
> attribute S        : string;
> attribute S of xyz : signal is "true";
>
> Dabei ist es egal, ob es ein FF oder ein komb. Signal ist.

Wo hast Du denn diese Information her?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

The KEEP attribute does not block trimming - A common misconception is that 
KEEP properties can be used to block signal trimming. The KEEP property can 
be used to prevent a signal from being absorbed into a component, but it has 
no effect on trimming behavior. The correct attribute to block trimming is 
"S" (AKA Save, SAVESIG, NOCLIP).

Aus http://www.xilinx.com/support/answers/23990.htm

[P. K. (pek)]

keep: A VHDL synthesis attribute that directs Analysis & Synthesis to 
not minimize or remove a particular net when optimizing combinational 
logic.

Aus 
http://quartushelp.altera.com/11.1/mergedProjects/hdl/vhdl/vhdl_file_dir.htm

Allerdings funktioniert es nur, wie bereits erwähnt, wenn das Netz nicht 
"dangling" ist, sprich wieder auf ein Register geht.

[T. M. (xgcfx)]

Lothar Miller schrieb:
> The KEEP attribute does not block trimming - A common misconception is that
> KEEP properties can be used to block signal trimming. The KEEP property can
> be used to prevent a signal from being absorbed into a component, but it has
> no effect on trimming behavior. The correct attribute to block trimming is
> "S" (AKA Save, SAVESIG, NOCLIP).
> Aus http://www.xilinx.com/support/answers/23990.htm

Danke, gut zu wissen. Ich bin bis jetzt davon ausgegangen, dass KEEP 
(wie der Name mir zumindestens suggeriert), dafür sorgt, dass Logik 
nicht optimiert wird. Schade ist nur, dass es bei Altera scheinbar 
wieder anders aussieht :-/

[Klaus F. (kfalser)]

Lothar Miller schrieb:
> The KEEP attribute does not block trimming - A common misconception is that
> KEEP properties can be used to block signal trimming. The KEEP property can
> be used to prevent a signal from being absorbed into a component, but it has
> no effect on trimming behavior. The correct attribute to block trimming is
> "S" (AKA Save, SAVESIG, NOCLIP).
> Aus http://www.xilinx.com/support/answers/23990.htm

Toll, wer sucht, der findet.
In der Constraint User Guide steht jedenfalls nix drinnen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Klaus Falser schrieb:
> Toll, wer sucht, der findet.
Da sind sicher noch einige andere solcher Perlen unterwegs...  ;-)

Das mit dem neuen Parser für die "alten" S3 und V5 dürfte sich 
zwischenzeitlich rumgesprochen haben...
http://www.lothar-miller.de/s9y/archives/79-use_new_parser-YES.html

[P. K. (pek)]

Klaus Falser schrieb:
> Für Xilinx jedenfalls gilt :
> attribute keep               : string;
> attribute keep of WdcEventxS : signal is "true";

Diesmal begegnet mir die Sache auf Xilinx, und ich benutze das genau wie 
oben beschrieben:

  attribute keep                : string;
  attribute keep of CurRdFpVxSO : signal is "true";  -- Required in .sdc

Ich brauche das Ganze, um einen Multicyclepfad durch dieses Signal zu 
setzen zu setzten. Das Tool ist Vivado 2013.1, und das Keep funktioniert 
zur Zeit nicht. Muss ich noch irgendwo ein Enable setzen?
Im Synthesis-Log habe ich keine Hinweise gefunden, warum das Statement 
ignoriert wird (kein "ignored" oder so), ich finde aber auch nichts 
relevantes, wenn ich nach "keep" oder "Attribute" suche.
Muss allenfalls eine bestimmte Xilinx-Library in den VHDL-Code?

Mein bestehendes Altera-Pendant funktioniert tipp-topp, die Pfade sind 
also vorhanden...