From: Antti on
Tim Verstraete schrieb:

> Hey,
>
> I have 2 LVDS clock signals and both are terminated with the DIFF_TERM
> attribute on the LVDS25 input buffer IBUFGDS but i only use 1 of them
> ... now i want both buffers to stay in my design and not optimized
> away. Is there a constraint that i can place on that buffer? i guess
> that it should be a UCF constraint since when i look into the RTL
> viewer of planahead and ISE i still see the buffer.
>
> I know that there is an option in NGBuild -u which keeps the unused
> logic, but i do not want to use it just for that 1 buffer ...
>
> thanks in advance,
>
> kind regards,
>
> tim
>
> p.s. i'm using ISE8.2SP2 and a V4SX55-FF1148C

the best thing possible is to use it without using it :)
1) like route the unused input to non-bonded IO,
2) or use in some net in way that the signal isnt really used but XST
fails to optimize it out
3) or if you dont use BSCAN you can also route it to TDO pin

all those tricks would keep the net alive. sure it would use
some interconnect resources.

Antti

From: yttrium on

Indeed, that was what i was doing until now ... i just hoped that
somewhere there was a constraint that you could use to keep it
unoptimized ....

thanks anyway ...

kind regards,

Tim

Antti wrote:
> Tim Verstraete schrieb:
>
>> Hey,
>>
>> I have 2 LVDS clock signals and both are terminated with the DIFF_TERM
>> attribute on the LVDS25 input buffer IBUFGDS but i only use 1 of them
>> ... now i want both buffers to stay in my design and not optimized
>> away. Is there a constraint that i can place on that buffer? i guess
>> that it should be a UCF constraint since when i look into the RTL
>> viewer of planahead and ISE i still see the buffer.
>>
>> I know that there is an option in NGBuild -u which keeps the unused
>> logic, but i do not want to use it just for that 1 buffer ...
>>
>> thanks in advance,
>>
>> kind regards,
>>
>> tim
>>
>> p.s. i'm using ISE8.2SP2 and a V4SX55-FF1148C
>
> the best thing possible is to use it without using it :)
> 1) like route the unused input to non-bonded IO,
> 2) or use in some net in way that the signal isnt really used but XST
> fails to optimize it out
> 3) or if you dont use BSCAN you can also route it to TDO pin
>
> all those tricks would keep the net alive. sure it would use
> some interconnect resources.
>
> Antti
>
From: Matthew Hicks on
You could try turning off the "Trim unconnected signals" option.


---Matthew Hicks


"Antti" <Antti.Lukats(a)xilant.com> wrote in message
news:1160731469.227624.198590(a)f16g2000cwb.googlegroups.com...
> Tim Verstraete schrieb:
>
>> Hey,
>>
>> I have 2 LVDS clock signals and both are terminated with the DIFF_TERM
>> attribute on the LVDS25 input buffer IBUFGDS but i only use 1 of them
>> ... now i want both buffers to stay in my design and not optimized
>> away. Is there a constraint that i can place on that buffer? i guess
>> that it should be a UCF constraint since when i look into the RTL
>> viewer of planahead and ISE i still see the buffer.
>>
>> I know that there is an option in NGBuild -u which keeps the unused
>> logic, but i do not want to use it just for that 1 buffer ...
>>
>> thanks in advance,
>>
>> kind regards,
>>
>> tim
>>
>> p.s. i'm using ISE8.2SP2 and a V4SX55-FF1148C
>
> the best thing possible is to use it without using it :)
> 1) like route the unused input to non-bonded IO,
> 2) or use in some net in way that the signal isnt really used but XST
> fails to optimize it out
> 3) or if you dont use BSCAN you can also route it to TDO pin
>
> all those tricks would keep the net alive. sure it would use
> some interconnect resources.
>
> Antti
>


From: Brian Drummond on
On 13 Oct 2006 02:13:55 -0700, "Tim Verstraete"
<tim.verstraete(a)barco.com> wrote:

>Hey,
>
>I have 2 LVDS clock signals and both are terminated with the DIFF_TERM
>attribute on the LVDS25 input buffer IBUFGDS but i only use 1 of them
>... now i want both buffers to stay in my design and not optimized
>away. Is there a constraint that i can place on that buffer? i guess
>that it should be a UCF constraint since when i look into the RTL
>viewer of planahead and ISE i still see the buffer.

Look into "keep" attributes. See the Constraints Guide for details.

(Sometimes "keep" attributes don't work though. On registers, they are
overridden by "equivalent_register_removal" and result in an obscure
error message instead. I haven't tried them on clock buffers)

- Brian
From: yttrium on
i also thought that but then i read the description:

<http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/cgd/cgd0109_70.html>

KEEP Description

KEEP is an advanced mapping constraint and synthesis constraint. When a
design is mapped, some nets may be absorbed into logic blocks. When a
net is absorbed into a block, it can no longer be seen in the physical
design database. This may happen, for example, if the components
connected to each side of a net are mapped into the same logic block.
The net may then be absorbed into the block containing the components.
KEEP prevents this from happening.

KEEP is translated into an internal constraint known as NOMERGE when
targeting an FPGA. Messaging from the implementation tools will
therefore refer to the system property NOMERGE?not KEEP.

and tried it out but no change ...

i think i will go for antti's idea and just make some small logic to an
unbound pin so it does not get removed ...

too bad there is no constraint for this ...

kind regards,

Tim

Brian Drummond wrote:
> On 13 Oct 2006 02:13:55 -0700, "Tim Verstraete"
> <tim.verstraete(a)barco.com> wrote:
>
>> Hey,
>>
>> I have 2 LVDS clock signals and both are terminated with the DIFF_TERM
>> attribute on the LVDS25 input buffer IBUFGDS but i only use 1 of them
>> ... now i want both buffers to stay in my design and not optimized
>> away. Is there a constraint that i can place on that buffer? i guess
>> that it should be a UCF constraint since when i look into the RTL
>> viewer of planahead and ISE i still see the buffer.
>
> Look into "keep" attributes. See the Constraints Guide for details.
>
> (Sometimes "keep" attributes don't work though. On registers, they are
> overridden by "equivalent_register_removal" and result in an obscure
> error message instead. I haven't tried them on clock buffers)
>
> - Brian