View Single Post
  #4 (permalink)  
Old 10-23-2007, 09:06 AM
Posts: n/a
Default Re: Protecting slices from GLOBAL_LOGIC0/GLOBAL_LOGIC1 usage?

Neil Steiner schrieb:
> Markus wrote:
>> Neil Steiner schrieb:
>>> I would like to prevent GLOBAL_LOGIC0 and GLOBAL_LOGIC1 nets from
>>> stealing unused slices in a particular region. I don't mind if those or
>>> other nets pass through the region, but the logic within the region must
>>> remain untouched.
>>> Does anybody know how this might be accomplished? This is under ISE/EDK
>>> 8.1. I'm not presently using the PR flow, and would rather not use it
>>> if there is any alternate way of protecting the slices.
>>> (I did try defining an AREA_GROUP with attributes PLACE=CLOSED and
>>> MODE=RECONFIG, but that made no difference, either because the tools
>>> think these nets are exempt, or because I'm not using the PR flow.)

>> Can you feed the GLOBAL_LOGIC0 and GLOBAL_LOGIC1 signals via ports
>> (and bus
>> macros) into your module? Probably you have to modify the .edf files,
>> because the synthesis tool introduces some vcc/gnd symbols.

> I think we may be talking about different things. I'm not using the PR
> flow, so there are neither modules nor bus macros involved.
> The GLOBAL_LOGIC0 and GLOBAL_LOGIC1 nets originate with map, if I
> understand correctly. These are compound nets with multiple separate
> drivers and sinks, and par decides that it is free to steal unused
> slices for the drivers. That's the root of my problem: par using slices
> in an area that I want protected. As I mentioned initially, I don't
> mind at all if nets pass through my region; I just don't want any of its
> logic used.

I think there is nothing like a simple area group constraint that solves
your problem. Maybe you can play with you netlists and convert them from
..ncd to .xdl format (and back again) to manipulate them.

You are correct, GLOBAL_LOGIC0 and GLOBAL_LOGIC1 nets originate with map.
Map creates only one net for power and one for ground signals. I think at
this point, the nets have no driving logic. The par tool splits those nets
up into smaller nets, to achieve better routing results and adds driving
logic. In most cases, GLOBAL_LOGIC1_xx nets are driven by local VCC
resources that reside in each CLB. GLOBAL_LOGIC0_xx nets are driven by LUTs
(extra slices) and you want to prevent them to get placed in your region.

It is quite cumbersome, but you might be able to move them away in the

Reply With Quote