Article: 2736 of comp.lsi.cad
Newsgroups: comp.lsi.cad
Subject: Xilinx FPGA APR NetWeights
From: philip@xilinx.com (Philip Freidin)
Date: Fri, 26 Mar 1993 22:56:25 GMT
Organization: Xilinx Inc.
Lines: 219

In the following included article, Chris Taylor asks some interesting questions.

I did some research, and here are some answers, but be aware that this is an
area in which we are actively improving our software, and so the following
applies only to the current release of our software, that was shipped to
customers around November 1992. For APR the version number is V3.30, and
for PPR the version number is V1.30. Also, as always, this is my opinion,
not the company's. This is also IMHO, but I have been wrong in the past
(although I don't remember when). No guarantees expressed or implied.
Xilinx may (will) change things and not tell me, so I might not know what
the current reality is. Etc...Etc...Etc... All other disclaimers expressed
and implied included although not referenced....

Now: on with the info.

>Concerning the APR (automatic placement and router) for Xilinx XC3000 FPGA's.
>=============================================================================
>
>Does anyone have any experience with adjusting the net weights so as to
>drive the design towards a desired specification.
>
>>From what little documentation I have on this subject...
>
>Nets can be assigned a weight value between 1 and 99.
>By default nets are given the weight 1.
>Nets can be specified as CRITICAL which is equivelent to a weight of 100
>or as NONCRITICAL which is equivelent to a weight of 0.
>

The 3 symbolic levels are CRITICAL (== netweight 10)
			  NORMAL   (== netweight 3)
			  UNCRITICAL (== netweight 1)  (not NONCRITICAL)

The default value is NORMAL.

This is from 'XACT reference guide, Vol 1, Oct-1992, page 3-131'

In APR, any net weight value specified 10 and above, is translated
into a CRITICAL value.  So, even though we specify values of 1 to 99,
there are no real gradations in value.  A net is considered CRITICAL
if it is given a weight of 10 or greater, UNCRITICAL if the weight
is 1 (or less), and NORMAL otherwise.

SO: NetWeight 0..1        == UNCRITICAL
    NetWeight 2..9        == NORMAL       (the default)
    NetWeight 10..99      == CRITICAL

    The Router only uses these 3 levels

The CRITICAL and UNCRITICAL net weight tends only to be useful if only
a few are used.


>Exactly how this weighting influences the subsequent placement and routing
>is not clear. I suppose it is either factored into the "scoring" or is
>used to arrange the order in which placement/routing is done (or both).

Netweight affects placement in that it is used as one of the coefficients
in the primary placement cost function.  As the netweight is increased, the
algorithm encourages closer placement of the loads relative to the source.

Netweight effects the ordering of nets that the router then routes. There
are other issues such as nets that feed TBUF 'I' pins that are effectively
ranked even higher than CRITICAL.

Netweight IS changing (even as we speak), and all the above is changing
in the next version. (so forget this when you get your next release).

>
>Of course it is hard to quantify the degree to which a weight will effect
>a nets final route, but one would hope that in general (or on average) the
>weighting produces a roughly intuitive result (i.e sort of "linear").
>
>By this I mean that in general (on average) the differance between giving a net 
>weights of 1, 25, 50, 75, 99 will produce an observable effect with some 
>rough correspondance to the weighting.

As described above, this is not the case.

>
>On the other hand, it could be that (for example) nets with weights of 100
>get very good priority, weights of 0 get very little priority and
>weights 1-99 are somewhere in between but are indistinguishable from each 
>other.  

See above.

>
>I have already observed that CRITICAL (weight 100) and NON-CRITICAL (weight 0)
>seem to produce observable differance from default nets (weight 1).
>Thus the differance between weights 0 and 1 seems observable.
>I would have thought that the logical default net weight would be 50
>so I'm concerned about how "linear" the effect of the weights is.
>

See above.

>
>I'm not sure whether the placement alogarithm takes into account the
>limited routing paths of the FPGA, or just uses a simple point
>to point "rubber-band" model. If it uses a "rubber-band" model the 
>quantative effects of weights would tend to be very unpredicatable
>since the length of possible routing paths (through the limited FPGA pathways)
>could be disproportionate with the point to point length.
>  
>I would be interested if anyone already knows that experimenting with
>weights in the range 1 to 99 is basically a waste of time.
>
>Also is there some way of setting the default net weight used by APR to
>a particular value.

No. but as you can see from above, it wouldn't do you any good any way.

>
>BTW - I am aware that the placement/router for XC4000 (called PPR)
>is better suited to driving a design towards a specification because
>it can be used with the new "Performance" stuff from Xilinx which allows
>the user to specify actual target delays. However, this wont be available for
>XC3000 until the end of this year (I'm told).
>

See what follows the next section

In frustration of not getting a timely response to his NET query, Chris sent
the following to the Sandia sponsored mail list. 

>From: chris@labtam.labtam.oz.au (Chris Taylor)
>To: xilinx-users@sandia.gov
>Subject: Using APR weights
>Content-Length: 1040
>
>Has anybody had any success with applying a range of net weights 
>to a design.
>
>For example, (rather than just applying CRITICAL and NONCRITICAL attributes)
>defining 11 classes of nets (with weights 0,10,20,30,40,50,60,70,80,90,100) 
>in order to apply finer contraints on the placement and routing.

as described above, this has little effect in the current release
>
>I am using APR on an XC3000 design but I'm interested in anyones' 
>experience with using weights in such a way.

Net weights have an effect, but not much. In particular, customers who
have gone through and assigned a net weight to each and every net, with
careful use of all values between 1 and 99, have been dissapointed.

>
>Apparently in APR the net weight is used in calculating scores during placement
>and so influences positioning. For routing it is used to determine the order in
>which nets are routed (weight 100 first), providing a "first in first serve"
>favouritism.

basically right, as discussed above.

>
>I expect that the effect of these weights is too unpredictable to
>provide a reliable fine level of control over the relative path lengths
>of nets.

Not unpredictable, but not of strong influence. The initial net order
is effected, but once the rip-up router gets started, the order does
not matter much.

>
>BTW - I know that a timing driven placement/router is really what I need
>      but for the moment I'm stuck with APR and so am investigating
>      how effectively I can emulate this using APR's net weights.
>
>chris@labtam.oz.au


PPR is a very different animal from APR.

The latest version of PPR supports DEADLINE TIMING (Marketing calls this
XACT Performance). The default is to have this turned on, and when enabled
it ignores net weights completely.

If DEADLINE TIMING is disabled (or you are running an older pre V1.30 version)
then here is what happens:

	For placement, the net weights range from UNCRITICAL,1..99,CRITICAL
	and are used in the scoring function. They DO NOT play a major role
	in this function though.

	For routing, The net weight's 'tens digit' is used to effect the 
	ordering of the nets prior to the router getting started. The router
	may re-arrange the order once it gets started, depending on where
	it gets into trouble. I.E. weights 1..9 become 0, 10..19 become 1,
	90..99 becomes 9.

The quality of the routing and the performance of the design is always better
with DEADLINE TIMING turned on, so the above is of minimal and historic
interest only.

Unfortunately, there is no support for 'flag net skew_critical' at this time.
Maybe in a future release.

>
>Replies by Email are prefered (since I don't check the news that often)
>
>chris@labtam.oz.au
>


Thankyou for the opportunity to go do the research... Even our developers
found some interesting stuff.

(with help from Chris, Anonymouse_1, Rick, Mon-Ren, Anonymous_2)

Philip Freidin.  3/26/93

-- 
Philip Freidin: Product Planning Manager, Xilinx, INC
(rest of clever .sig still under construction....
		coming to a terminal near you, Real Soon Now (tm))