Hello, My precheck got errors only in KLAYOUT BEOL step. I got 2 types of errors: <description>m1.2 : min. m1 spacing : 0.14um</description> <description>m1.7 : min. m1 with holes area : 0.14um²</description> Some of the images from GDS that I checked from the xml report and klayour_beol_check.xml are attached. By the way openlane flow passes without any errors. I just cloned caravel user project repo today, so it is up-to-date. I added efabless_staff as collaborator to the project in efabless server, you can check the repo from: https://repositories.efabless.com/burak_aykenar/SAKAv0.1

@Burak Aykenar those look suspiciously like shorts. Please be aware that openlane does not do full hierarchical device level LVS.

precheck

does though.

Thanks @Mitch Bailey Well as a designer what can we do about it? There are a total of 68030 these DRC errors. This is an eFPGA project and we simulated the wrapper by configuring and running over a dozens of RTL benchmarks over the FPGA fabric netlist instantiated in the wrapper and they seem to be working correctly. The olane flow has no error, only warnings related to the slew, cap and fanout. Are we missing something?

Hmm. Just some guesses here. Do the connections look correct? It looked to me like a signal to power/ground short. You might check the lef file for the macros. Make sure the obstructions are where they should be. If the power rails are being added at a parent level, you might want to check the power rail layer settings.

I did not add obstructions in config file

OBS should probably be set in the macro lef files.

Can something work in the wrapper config such as like this (taken from riscduino_qcore repo wrapper config file): set ::env(GRT_OBS) " \ li1 150 130 833.1 546.54,\ met1 150 130 833.1 546.54,\ met2 150 130 833.1 546.54,\ met3 150 130 833.1 546.54,\ li1 950 130 1633.1 546.54,\ met1 950 130 1633.1 546.54,\ met2 950 130 1633.1 546.54,\ met3 950 130 1633.1 546.54,\ li1 150 750 833.1 1166.54,\ met1 150 750 833.1 1166.54,\ met2 150 750 833.1 1166.54,\ met3 150 750 833.1 1166.54,\ met5 0 0 2920 3520" I don't know how to define obstacles in macro lef files.

That would probably work, but you’d need to change it every time you moved your macro. In magic,

lef write -hide

usually does a pretty good job of creating a lef file. You can check the output in klayout. Make sure the cell boundary covers the cell and work well if the pins are on the cell boundary.

Thanks @Mitch Bailey Are only li, met1, met2 and met3 obstacles are enough or should I need to add met4 also? I saw some GRT_OBS in open source projects add met4 also but some only add met3. Also for JSON file, GRT_OBS syntax should be "GRT_OBS": [ li X1 Y1 X2 Y2,", met1 X1 Y1 X2 Y2,", met2 X1 Y1 X2 Y2,", met3 X1 Y1 X2 Y2" ], right?

Probably need a

"

at the start of each line, but that’s the general idea, I think.

The problems that I got in precheck were related to "FP_PDN_ENABLE_RAILS" is set to '1', where I don't have any std cell in wrapper but only hardened macro instantiations. Openlane pass met1 rails through hardened macros, by the way this can be considered a bug or I miss sth in the configuration. Here are the discussion thread https://open-source-silicon.slack.com/archives/C016H8WJMBR/p1699345649344279

@Burak Aykenar if you don’t have any standard cells in the wrapper, you probably want

FP_PDN_ENABLE_RAILS

set to

0

.