• Previous message: R. Timothy Edwards: "technology filenames"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Dear Mikael,

> The routine that parses paths, MakeManhattanPath in CIFrdutils, needs
> to have its integers converted to double or extra long integers when
> using the nanometers keyword in cifinput. If not the integers easily 
> overflow for moderate size designs. 

   I know I shelved that comment for a long time (the implications are
an immediate doubling of memory requirements!), but I was just thinking
about it, and I'm wondering if that first reaction is true.  A standard
32-bit int gives you +/- 2^31 = 2.15e9.  With the "nanometers" keyword,
you get 1 magic unit = 1 nanometer, so you should have an area equal to
2.15 meters on a side.

   What's wrong is the definition of INFINITY (tiles/tile.h, comment at
line 131):

/*
 * The following coordinate, INFINITY, is used to represent a
 * tile location outside of the tile plane.
 *                
 * It must be possible to represent INFINITY+1 as well as
 * INFINITY.
 *  
 * Also, because locations involving INFINITY may be transformed,
 * it is desirable that additions and subtractions of small integers
 * from either INFINITY or MINFINITY not cause overflow.
 *   
 * Consequently, we define INFINITY to be the largest integer
 * representable in wordsize - 5 bits.
 */

#undef INFINITY
#define INFINITY        ((1 << (8*sizeof (int) - 6)) - 4)
#define MINFINITY       (-INFINITY)  


   By subtracting 6 bits, your workable area shrinks by 64 times on a
side, to 3.3 cm.  Big, but not huge by today's standards.

I can't think of any reason why one needs a 6-bit pad to prevent overflow
from "additions and subtractions of small integers".  Please let me know
if I'm missing something.

						Regards,
						Tim

• Next message: Atul Gadgil: "Cif file reading"
• Previous message: R. Timothy Edwards: "technology filenames"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]