Looking for ways to keep diagnostic signal from being optimi

[Bill Austin]

To aid debug with Xilinx chipscope, I've added some temporary signals
to the design that are only for diagnostic purposes. However, these
signals get optimized away in the XST -> map -> PAR tool chain.

Looking for ways to preserve the diagnostic signals so they can be
hooked up with the Chipscope Inserter tool.

 

[Nathan Hunsperger]

Bill Austin <biau@altavista.com> wrote:

To aid debug with Xilinx chipscope, I've added some temporary signals
to the design that are only for diagnostic purposes. However, these
signals get optimized away in the XST -> map -> PAR tool chain.

Looking for ways to preserve the diagnostic signals so they can be
hooked up with the Chipscope Inserter tool.

A few years ago, I had problems with the Xilinx tools optimizing
out my state counter. Our final solution (although not pretty) was
to bring one of the wires from the counter out as an output from
the Verilog module. This output was never hooked up to anything,
but it prevented the buggy tools from breaking our state machine.
(It would appear the optimizations were not done accross modules.)

Just an (ugly) suggestion,
Nathan

 

[Bill Austin]

Nathan Hunsperger <njh@soda.csua.berkeley.edu> wrote in message news:<cdpp8q$bbe$1@agate.berkeley.edu>...

Bill Austin <biau@altavista.com> wrote:
To aid debug with Xilinx chipscope, I've added some temporary signals
to the design that are only for diagnostic purposes. However, these
signals get optimized away in the XST -> map -> PAR tool chain.

Looking for ways to preserve the diagnostic signals so they can be
hooked up with the Chipscope Inserter tool.

A few years ago, I had problems with the Xilinx tools optimizing
out my state counter. Our final solution (although not pretty) was
to bring one of the wires from the counter out as an output from
the Verilog module. This output was never hooked up to anything,
but it prevented the buggy tools from breaking our state machine.
(It would appear the optimizations were not done accross modules.)

Just an (ugly) suggestion,
Nathan

Thanks, Nathan. That approach was considered. Eventually, however, it
was found that a "keep" constraint could be attached to the signal.
The constraint can be associated with the signal in a few ways. The
one that I used sucessfully was to declare "keep" as a VHDL attribute
and then specify it for the signal in question:

signal diagnostic_sig : std_logic;
attribute keep : string;
attribute keep of diagnostic_sig : signal is "true";

That kept the signal around through XST synthesis. Then, when the
chipscope was inserted, the signal was available.

The description in the Constraints Guide said that the purpose of
"keep" applied to a signal is to inhibit the tools from pulling it
into, for example, a LUT. However, "keep" also seems to work for
keeping an unconnected signal from being optimized awaye. (The
description of "keep" in the XST document left me unsure as to the
usage and syntax, so I was glad that the constraints guide at least
made the syntax clear.)

A technique that didn't seem to work was to drive the diagnostic
signal into one input of a two-input AND gate, then feed the AND
output back to the other input -- i.e. a tight combinatorial feedback
loop leaving a piece of worthless logic but no floating signal.
However, I may have made mistakes when doing this. Does anyone know if
this should work?