Home > Community > Forums > Digital Implementation > About GCELLGRID and TRACK Statement in DEF

## Email

Recipients email * (separate multiple addresses with commas)

Message *

 Send yourself a copy

## Subscribe

Intro copy of the newsletter section here, some intro copy of the newsletter. Instruction of how to subscribe to this newsletter.

First Name *

Last Name *

Email *

Company / Institution *

 Send Yourself A Copy

# About GCELLGRID and TRACK Statement in DEF

Last post Thu, Jun 26 2008 9:00 PM by archive. 5 replies.
 Started by archive 26 Jun 2008 09:00 PM. Topic has 5 replies and 3443 views
• #### Thu, Jun 26 2008 9:00 PM

• archive
• Joined on Fri, Jul 4 2008
• Posts 88
• Points 4,950
About GCELLGRID and TRACK Statement in DEF
 ``` How are the parameters for following statements used in DEF file calculated GCELLGRID TRACK For example, in a DEF file, statements appear as: TRACKS Y 500 DO 146 STEP 1000 LAYER metal1 ; GCELLGRID Y -50 DO 2 STEP 9950 ; GCELLGRID X 173250 DO 1 STEP 7450 ; How are the parameters for these statements calculated. GCELLGRID and TRACK are two of the statements which are used to define the floorplan for a particular design. But, how are the values for these statements calculated? Thanks. <\code>``````Originally posted in cdnusers.org by johariph `````` `````` ```
• Post Points: 0
• #### Fri, Jun 27 2008 10:38 AM

• archive
• Joined on Fri, Jul 4 2008
• Posts 88
• Points 4,950
RE: About GCELLGRID and TRACK Statement in DEF
 I believe they are calculated based on the floorplan size and the routing metal definitions in the LEF. For example, TRACKS Y 500 DO 146 STEP 1000 LAYER metal1:This means put metal1 tracks horizontally (stepping along the Y axis) starting at 500. Put down 146 of them, 1000 apart. FE knows how many to put down (146) based on the size of your floorplan. It knows the spacing (1000) from the width and spacing of metal1 in the LEF. It knows the starting coordinate (500) based on where your floorplan starts and whether or not you start with half-track offset (looks like you do here). GCELLGRID numbers are also automatic, and meant to create a "box" encompassing a certain number of horizontal and vertical tracks. The tool tunes this automatically and we never really mess with it.Not sure that answers your question, but hope it helps somewhat.- KariOriginally posted in cdnusers.org by Kari
• Post Points: 0
• #### Fri, Jun 27 2008 12:28 PM

• archive
• Joined on Fri, Jul 4 2008
• Posts 88
• Points 4,950
RE: 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. ```Originally posted in cdnusers.org by johariph
• Post Points: 0
• #### Fri, Jun 27 2008 12:34 PM

• archive
• Joined on Fri, Jul 4 2008
• Posts 88
• Points 4,950
RE: About GCELLGRID and TRACK Statement in DEF
 ``` ****************************************** Apologize for previous far-stretched reply Here is the properly formatted one. ****************************************** 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. ```Originally posted in cdnusers.org by johariph
• Post Points: 0
• #### Fri, Jun 27 2008 2:20 PM

• archive
• Joined on Fri, Jul 4 2008
• Posts 88
• Points 4,950
RE: About GCELLGRID and TRACK Statement in DEF
 I think half-track offset is the default. No setting required. Did you get the DEF TRACKS section from somewhere, or did you let FE create this?Also, I'm not aware of the GCELLGRID having any impact on placement, at least not directly. It affects routing, but if trialRoute uses it, and placement looks at trialroute results, then I suppose it could indirectly affect placement. I'm not sure about this though.I think the real question is, what are you trying to achieve in your placement? :-)- KariOriginally posted in cdnusers.org by Kari
• Post Points: 0
• #### Fri, Jun 27 2008 3:42 PM

• archive
• Joined on Fri, Jul 4 2008
• Posts 88
• Points 4,950
RE: About GCELLGRID and TRACK Statement in DEF
 ``` Yes your are right, I checked DEF reference, and the half-track offset is the default. But, I got this question since, FE is using 1600 offset by default for metal6. The metal6 pitch in LEF is 1200 (Real 1.2u). And there is no Offset definition defined in my LEF file for metal6. So logically, FE should have taken 600 as an offset by default for metal6, then why 1600? No, I am not using DEF TRACKS and GCELLGRID from somewhere else, FE is creating it for me. Moment I load the netlist and libraries (conf), it creates the floorplan. But the offset used for metal6 is troubling me. Infact, I tried various designs with same libraries, and it always uses same offset and pitch combination. So, if FE expects to get these values from LEF, and does not found, it should have taken default values. Well, FE displays following message about offset for metal1 and metal2 Horizontal Layer M1 offset = 500 (guessed) Vertical Layer M2 offset = 400 (derived) Suggestion: specify LAYER OFFSET in LEF file How does it guess for other layers (metal6 for ex:) ----------------- I feel, GCELLGRID affects the placement and routing both, but I don't know exactly how. The reason I need this information because, I have to modify my placement little bit manually. So if core area increases in this process, there would be change in floorplanning also. I want to know this information so that I can decide, if there is a big impact on floorplan or if I can keep it as original (since core area may increase only marginally) ```Originally posted in cdnusers.org by johariph
• Post Points: 0