Row decoder logic messing up the placement of arrays where row size is a multiple of word size.

[donnie-j]

Thanks for making this tool. The latest change sets (Mar 21) solve most of the issues we were seeing, except this one.

We had previously done reg files with latches and multiplexors (in TSMC 180nm) with standard cells, but let the placer put them in a macro wherever it wanted :) This issue is cosmetic from a functionality POV, especially considering our previous approach...

It looks to me like the size of the row decode and driver logic at the end of a word size row block is not being properly accounted for before the next word size chunk is added to that row of cells. It seems as long as the array is word size width, placement is fine. I ran a bunch of different sizes and reached this conclusion, and there are a subset of sizes that produce completely regular layouts. Here is an example block that is not regular from a 1024x16 array, about 1/2 way down the macro (but that doesn't matter) and with only the tristate buffer poly displayed.

Notice also how the rows at the end of the RAM32 block also perhaps overflow. Again, many thanks and I emphasize there is nothing functionally wrong with the resulting macros, at least related to this issue. J.

[donn]

Ah, I think I know this issue. I'll take a look.

[donnie-j]

Ok, I thought it was the decoder using different 4 input logic gates, but I was wrong about the cause of this. The only one that sticks out, and only a little, is nor4b_2. From the middle of a macro, just the AND[0-7] gates showing:

The cause of the uneven row length turns out to be a variable number of clkbuf_2 packed per row, but only the ones on the right hand side cause the issue. Here with clkbuf_2 cells also displayed:

I haven't gone after which specific clkbuf_2 instances these are yet...