Failed routing, due to different pitches on each metal layer?

[SarahAnto]

Hi! I'm new to using qflow/qrouter and I'm hoping someone can help me learn what went wrong with my routing attempt.

I am testing out qrouter to use with an 180nm technology from a foundry, and unfortunately it failed. The routing in the DEF doesn't look like it's landing correctly on the pins, and I got the following warnings in the log file.

Horizontal route layer at non-minimum pitch 0.61. Using smaller pitch 0.56, will route on 1-of-2 tracks for layer MET3. Vertical route layer at non-minimum pitch 0.95. Using smaller pitch 0.56, will route on 1-of-2 tracks for layer MET4. Horizontal route layer at non-minimum pitch 0.61. Using smaller pitch 0.56, will route on 1-of-2 tracks for layer MET4.

Looking at the techlef provided by the foundry, it appears that each metal layer has a different pitch (MET1=0.56, MET2=0.56, MET3=0.61, MET4=0.95). Does qrouter support varying pitches for each metal layer?

Thanks for the help! Sarah

[RTimothyEdwards]

Qrouter supports a different vertical and horizontal pitch, but all vertical pitches must be the same (or a multiple of the minimum vertical pitch) and all horizontal pitches must be the same (or a multiple of the minimum horizontal pitch). The messages. By forcing metal 3 to the next largest multiple of 0.56um, the metal 3 will be 1.12um, which is not very efficient, but otherwise is not a problem.

If it's not landing correctly on the pins, it's more likely an issue with the positioning of the standard cells with respect to the grid. Have you checked whether the layout has pins nominally under track crossings?

[SarahAnto]

Thanks so much for your response! Your explanation about the pitches makes sense.

It looks like qrouter is placing MET1 halfway between where I would expect the MET1 tracks to go, and in some cases is causing shorts. Here's a screenshot of the post-routing DEF. (This is a 6-track cell library. The hashed blue shapes are MET1 in the cells, solid blue shapes are MET1 placed by qrouter, and the red dashed lines are where I would expect MET1 tracks to align.)

I tried adding an "OFFSET 0.28 ;" (half a pitch) to my techlef file for MET1 and that doesn't seem to have made a difference.

[RTimothyEdwards]

@SarahAnto : I believe that 1/2 pitch is the default value for offset (which is why that has no effect), so if it is already a half pitch off, try OFFSET 0.0 in the technology LEF file.

[SarahAnto]

@RTimothyEdwards Thanks for the suggestion, I really appreciate your feedback! Unfortunately, that doesn't seem to have changed anything either. I tried offsets of 0.7, 1.12, and 2.0 too without any effect. For a sanity check I changed the MET1 pitch to 0.4 and that did cause a change, so qflow and qrouter are definitely looking at the same tech LEF file as I am.

[RTimothyEdwards]

One question i have is: Are you using qflow (graywolf) to do the placement, or are you starting with a DEF file generated by another tool? if it's another tool, can you get it to shift the vertical placement by 1/2 track?

In the screenshot you posted earlier, it looks to me like the alignment in X is correct, which is interesting because usually the tracks are defined as offset by 1/2 pitch in both X and Y, which would mean that it got one of the two right.

And one thing to point out is that if you do "qrouter -i", or run qrouter interactively and give the "layer_info" command, you get a dump of what qrouter thinks the pitches and offsets are, which is good for a sanity check. The file dumped by "qrouter -i" has lines containing .

[RTimothyEdwards]

Another thing that occurs to me is that qrouter uses only a single grid, so that if metal 1 has an offset but metal 3 (metal 5, etc.) don't, then it's going to do something to make them all match, and it may be that a default offset on all the other odd-numbered metals will override any offset that you put on metal 1, so make sure that the offset is the same on all the odd metal layers.

[RTimothyEdwards]

If all else fails, try the OpenROAD router (https://www.theopenroadproject.org).

[SarahAnto]

Thanks for all of the input! I am using qflow, and it looks like graywolf placed my cells half a track too high. I'll need to dig around with that to see how I can fix it. However, that doesn't explain why changing OFFSET wouldn't make any difference in the resulting DEF, right? I tried setting OFFSET to the same value for all metal layers and that didn't seem to have any effect either.

I'll look into OpenROAD too, thanks!

[RTimothyEdwards]

Sorry for the late reply (nothing in the last comment seemed urgent. . .). But yes, I would expect that OFFSET should do what you would expect it to do. Possible issues are (1) there may be problems unless every routing layer, or every routing layer in the same direction has the same offset, and (2) possibly the tool may want to see both X and Y values after OFFSET (i.e., OFFSET 0.0 0.0) although it ought to be correctly parsing both forms of syntax.

[SarahAnto]

Thanks for the input! I ended up trying the 7-track library to give the router more room, and that worked like a charm. I appreciate your help with trying to get the 6-track library working though!