About GCELLGRID and TRACK Statement in DEF

Thanks Kari. It does answer to my question to some extent. Meantime, I tried figuring it out, how these parameters are calculated. As you have indicated, the TRACK statement defines vertical(x) and horizontal(y) routing tracks. In above statement, first x/y track is located at 500 offset from the placement grid defined in LEF. And Rest is numofsuchTracks each separated by pitch. What I am not able to understand is that how does the tool arrive at the value of 500 offset. This 500 offset (here for metal1 layer) is not defined anywhere in my LEF file (I verified, it does not have any offset keyword under metal1 definition). Likewise, for metal6, I have following definition in all of my design DEF files- TRACK x 1600 DO 54 STEP 1200 LAYER metal6; TRACK y 500 DO 56 STEP 1000 LAYER metal6; Again, why 1600 and 500 offset for metal6 (I have 400 and 500 offset for all other layers (1-5) for TRACK x and y resp. in this example design). There is no such values defined in LEF for metal6 macros definitions. However, there is a definition for manufacturing grid (500) in LEF. Also the metal6 is vertical routing layer. And its pitch defined in LEF is 1200 (1.2u). So 1200 for TRACK x definition makes sense. But why 1000 in TRACK y definition (y is horizontal ???, and metal6 is supposed to go vertically??) --------------------------- About GCELLGRID, it defines the some virtual placement grid, which is used for global cell placement. The statements in DEF (always in pair of GCELLGRID x and y) creates such grids. In all of my DEF, it is creating number of grids in core region (depending on the core size), each of size 9750 x 9750 (Real 9.75u x 9.75 u). And it always starts at -50 and ends at +50 after die area boundary. I want to know, how does it come to conclusion that the placement grid size must be 9750 by 9750 (and not something else). What I feel is, probably, this grid size is to calculated based on partitioning algorithm requirements. And its a trade-off value between quality of placement, performance and time. Reducing the grid size will improve the placement quality, but will take more number of partitioning iterations. Whereas, increasing the grid size will make the partitioning fast, but the global placement will be more coarse....this is just what I think...Not sure. If my understanding is correct, then I want to know, is it ok to alter the grid size (usually GCELLGRID is decided automatically, but I want to change this manually), would the tool be able to perform a valid legal placement, if I change these values and define a new coarser or finer grid. Thanks.

Thanks Kari. It does answer to my question to some extent. Meantime, I tried figuring it out, how these parameters are calculated. As you have indicated, the TRACK statement defines vertical(x) and horizontal(y) routing tracks. In above statement, first x/y track is located at 500 offset from the placement grid defined in LEF. And Rest is numofsuchTracks each separated by pitch. What I am not able to understand is that how does the tool arrive at the value of 500 offset. This 500 offset (here for metal1 layer) is not defined anywhere in my LEF file (I verified, it does not have any offset keyword under metal1 definition). Likewise, for metal6, I have following definition in all of my design DEF files- TRACK x 1600 DO 54 STEP 1200 LAYER metal6; TRACK y 500 DO 56 STEP 1000 LAYER metal6; Again, why 1600 and 500 offset for metal6 (I have 400 and 500 offset for all other layers (1-5) for TRACK x and y resp. in this example design). There is no such values defined in LEF for metal6 macros definitions. However, there is a definition for manufacturing grid (500) in LEF. Also the metal6 is vertical routing layer. And its pitch defined in LEF is 1200 (1.2u). So 1200 for TRACK x definition makes sense. But why 1000 in TRACK y definition (y is horizontal ???, and metal6 is supposed to go vertically??) --------------------------- About GCELLGRID, it defines the some virtual placement grid, which is used for global cell placement. The statements in DEF (always in pair of GCELLGRID x and y) creates such grids. In all of my DEF, it is creating number of grids in core region (depending on the core size), each of size 9750 x 9750 (Real 9.75u x 9.75 u). And it always starts at -50 and ends at +50 after die area boundary. I want to know, how does it come to conclusion that the placement grid size must be 9750 by 9750 (and not something else). What I feel is, probably, this grid size is to calculated based on partitioning algorithm requirements. And its a trade-off value between quality of placement, performance and time. Reducing the grid size will improve the placement quality, but will take more number of partitioning iterations. Whereas, increasing the grid size will make the partitioning fast, but the global placement will be more coarse....this is just what I think...Not sure. If my understanding is correct, then I want to know, is it ok to alter the grid size (usually GCELLGRID is decided automatically, but I want to change this manually), would the tool be able to perform a valid legal placement, if I change these values and define a new coarser or finer grid. Thanks.