Hello 👋, I'm quite enthusiastic about knowing if there's an extension .db for the skywater pdk instead of .lib to be able to use it with design compiler tool

Hello, I am am trying to get a ring oscillator working in openlane/caravel, but the yosys synth script seems to be optimizing out and replacing them with buf_2 primitives. I have tried a couple things such as adding keeps for the following: -for the wires of the inverters -on the the module instantiating the oscillator -on for the generate block instantiating the sky130_fd_sc_hd__inv_2 primitives for the oscillator. I have also turned off synth_buffering just to test does anyone have any advice for how to make yosys leave these inverters alone?

Hello, I'm checking my design with Klayout DRC. Magic was printing

drc.rpt

file for DRC errors. However, I could not find a similar report for Klayout DRC. My design completes the flow successfully, does that mean I don't have any design rule errors? Thank you.

Hello everyone, I am trying to run the openlane flow to a "counter" that I have designed in verilog, but the flow is failing giving me the error shown in the screenshot.

For Openlanes Design Verification (DV) scripting, can these tests verify the operation of internal Macros? What about if the Macro is given the '(* blackbox *)' tag in the RTL?

hey all. I am trying to harden a memory macro generated with openRAM in openlane and am getting this error "[ERROR]: during executing: "sed -i -n {/^<< properties >>/,/^<< end >>/p} /openlane/designs/thesis/runs/core_with_sram/tmp/signoff/gds_ptrs.mag" [ERROR]: Exit code: 1 [ERROR]: Last 10 lines: sed: can't read /openlane/designs/thesis/runs/core_with_sram/tmp/signoff/gds_ptrs.mag: No such file or directory [ERROR]: Flow failed."

I am guessing this is due to the fact that I have not added .mag or .maflef files of the macro in the design only the gds,lef and libs are added

Please let me know if this is indeed the issue or not also tell what commands can be used for adding extra mag and maglef files in a design

Hello everyone, Does anyone know if OpenLane can work with "Nangate45" PDK?

Pretty basic question: I have a hold timing violation and it is mostly due to the fact that the input is a primary input with an ideal clock and the output is a DFF with a clock from the clock tree. What is the recommended way to resolve such an issue?

Has anyone successfully taped out with the

sky130_fd_sc_hs

standard cells? If so, can you share which combination of openlane and skywater-pdk commits you used?

Openlane used to generate an area.rpt at the end. Why did that get removed? And is there a similar report or info somewhere else now?

Is there an example config using OpenLane with a different supply voltage for sky130? (Not with Caravel, just OpenLane + sky130)

I noticed that the FastRoute parameter for

critical_nets_percentage

is not exposed in OpenLane. it is also set as 0% by default. I think this means that FastRoute does not do timing aware routing. Is that correct? Or, at least, it doesn't during congestion optimization.

Has anyone successfully used other sky130 libraries than the hd one in OpenLane (not caravel) with the default Makefiles? It seems the new setup uses volare for the PDK which has only the hd and hvl libraries supplied. There is no longer a "make full-pdk" option.

Hi, Does anyone know How can I simulate the .spice that openlane gives me at the end of the layout, because it imported the file but it doesn't recognize it and I don't know if it's because there are many internal blocks?

Hello, I am getting 70 antennas inserted to protect a node that has only a single fanout. (the node in question is the buffered value of an io_in pin that writes to a register). Is this expected behavior, and are there any ways to reduce it? Increasing "GRT_MAX_DIODE_INS_ITERS" seems to have no effect on "DIODE_INSERTION_STRATEGY" 3. Changing DIODE_INSERTION_STRATEGY results in routing congestion issues (which is weird because its a relatively small design) I ask because I am getting setup violations that increasing "CLOCK_PERIOD" does not fix. Thanks

Hello to all, Does anyone know anything about this warning? I have installed the latest version of OpenLane, the test and any examples show that warning.

I see OpenLane2 is under development, is there any projection on when/If that flow will be used to fabricate a demo chip?

^^^ is there an OpenLANE2 schedule of when OL2 is expected to be generally available (first feature complete release for v2)

Does someone know how to reduce this space and its purpose?

We just found one interesting issue: The AI's have generated code where several different parts are driving the same single-port SRAM block. The problems we faced is that IVerilog does not warn you and seems to find a way to simulate that anyway and the simulation results seem as if everything is ok. And then Yosys also does not warn of that issue and simply optimizes all that stuff away. So we either want to add warnings for such issues to both Iverilog and Yosys, or we want to develop a Verilog linting tool that detects such AI mishaps. Posted in #generative-ai-silicon-challenge

I'm running into an issue where pdngen doesn't seem to follow the FP-PDN-*-HALO options. I also tried disabling FP-PDN-SKIPTRIM but it doesn't seem to change anything.

I made a Python Pandas-based parser of OpenROAD generated files and released it today in case this is useful for others or for others keen on getting involved in more features development!

$ pip install porf

• https://github.com/daquintero/porf • https://daquintero.github.io/porf/ I plan to keep improving it for the foreseeable >year as it's still in development and suspect it will be superseded by OpenLane2.

Can we perform pnr in between SRAM macros? Like in modern designs using openlane?

Hi, could you help me, plz! While hardening my design, Im getting stuck in step number 30 as shown: Is it normal that it might take too long !?

Howdy everyone! I’ve been working on hardening a sky130 design that has some long chains of (only) unclocked combo logic and I’ve noticed with OpenLane that if I specify a CLOCK_PERIOD of 20ns, it fails with setup violations, and comes back to report a “suggested_clock_period” on the order of 28ns. Ok, I’m not surprised. However, if I set CLOCK_PERIOD to something ridiculous like 0.05ns, it does change the layout and reports a “suggested_clock_period” of just under 20ns… as though specifying an impossibly fast timing requirement made it try much harder and came up with a layout that was in fact ~30% faster. But… is this likely to be bogus?

I’ve tried iterating on everything else I could think of: size, density, aspect ratio, pin placement, timing margins, wire length, buffers… and they all seemed to make negligible difference compared to just crushing the CLOCK_PERIOD.

I’m sure I must be missing something that makes this “suggested_clock_period” untrustworthy, but if not — if this CLOCK_PERIOD approach actually does cause OpenLane to use a different strategy (and with still a low number of routing iterations, I might add) — then is there a reason it doesn’t just try this hard from the start when given a value like 20ns?

Hello Everyone! I've been facing difficulty in starting GUI applications from the OpenLane docker container, what can be done to fix this? I've allowed all connections to my X11 server using the

xhost +

command but still no luck