DRC and database hierarchy

jcdoll

Hi Matthias -
First off, thank you for the amazing tool. The amount of care and attention you have put into it is astounding.

I have a question about a surprising DRC result. I have a database with a top cell and ~100 cells within it, each containing a single die. When I run DRC on the individual design cells, I catch some rule violations that are not found when I instead run it on the overall top cell. I'm outputting the violations to a report and viewing them in the marker database browser.

As a simple workaround, I can step over each design and run DRC individually on it. This has the benefit of collecting the rule violations by design cell, vs. right now all of the violations are lumped under [TOP].

But I'm curious about the potential cause of this behavior. I've reproduced it on 0.23.4 and 0.23.5 on Windows x64. I found this issue for a spacing rule check, which catches about 23k violations when run on the overall top cell.

Thanks!
Joey

jcdoll

Nevermind, I just tested it again without tiling enabled and the problem vanished. So it was related to catching violations at tiling boundaries.

- joey

Matthias

Hi Joey,

thanks for the praise :-)

Basically, with tiling the results should be equivalent to the non-tiling case. Maybe some violations are reported twice, but error markers must not vanish if you enable tiling for example.

Are you saying the results are not the same with tiling enabled and some violations are not found with tiling?

Thanks,

Matthias

jcdoll

Hi Matthias -
Correct - some violations were not found with tiling.

In my initial runs, the tile size was not an integer multiple of the die pitch, and so some tile boundaries were falling directly on top of the devices. The places where some violations were missed were relatively large looping structures that apparently got got across tile boundaries in the worst-possible location. This might have been compounded by the fact that I did not initialize tile_borders and so I'm assuming there was no overlap. The simple fix for running in tiling mode for multi-design databases was to pick the tile size to avoid splitting designs.

I've found that when running DRC on "set files" that contain many die, it is helpful to run it die-by-die anyway. This is so that the output cell in the marker database is set to the particular design where the violation occurred, rather than just pointing to the top level cell. For example, here's a snippet of what I run now for cases where I want to start a run, go grab a coffee, and come back to look at violations with the design clearly indicated...

active_layout = RBA::CellView::active.layout
active_layout.top_cell.each_child_cell do |current_cell_index|
current_cell = active_layout.cell(current_cell_index)
source(current_cell)
output_cell(current_cell.name)
drc_check()
end

Given that DRC is run on a flattened structure I'm not sure if there's a nice way to do this without an iterator. But I basically have fast and slow options now that I can pick from depending on the task at hand.

- joey

Matthias

Hi Joey,

thanks for the explanation.

Basically the tiling option should automatically select the tile_borders to catch all relevant cases for functions where the interaction distance is known. The width/spacing checks are among them, so I'd consider the described behaviour a bug. If you happen to have a simplified test case I can have a look at it.

Regarding the loop .. that is a valid approach unless you're interested in intra-die and die/topcell interactions. By just looking at a child cell you won't catch these. There are hierarchical DRC engines which automatically determine the level on which to do DRC for optimum performance and take into account interactions with the cell environment. But that is the domain of big commercial tools.

Thanks,

Matthias