https://open-source-silicon.dev logo
Join Slack
Powered by
<@U016EM8L91B>, Can the VPWR of decap_4 be connect...
# magic
j
@Tim Edwards, Can the VPWR of decap_4 be connected to the output of a logic gate (specifically a NOR gate) in OpenLane? I aim to prevent the VPWR from connecting to VDD and instead link it to the logic gate's output. If feasible, what modifications are necessary to achieve this? Thank you.
t
No, the VPWR is continuous across the standard cell row, and cannot be reconnected to something else; the decap cells are specifically designed to add capacitance between the power rails. What are you trying to achieve by loading the NOR gate output?
j
Thank you for your prompt response. In my project, I employ decaps to mitigate transient signals during signal propagation in NOR gates (or any logic gate). I have successfully achieved this in SPICE simulations by connecting the VPWR of the decap to the output of the NOR gate, effectively mitigating the transients as expected. Now, I am attempting to replicate this process in the EDA flow to generate a GDSII layout. I have designed a custom cell and modified all the required .lef, .lib, .v, .mag, and .maglef files. The new cell integrates into my design successfully, and it routes successfully, passing until detailed routing, generating the expected .def file with the integrated cell and wire connections. However, an issue arises during the "*run_magic*" phase when reading the DEF file. It errors out with "DEF read, Line 203 (Error): Cell sky130_fd_sc_hd__decap_1 is not defined. Maybe you have not read the corresponding LEF file?" Despite both the LEF and DEF files (read by the tool) containing this cell, the error persists. I would greatly appreciate your assistance with this matter. Thank you very much.
t
There is no decap_1 cell. The suffix on decap is related to the size of the cell; the minimum size decap cell is decap_3.
Other ways to load a digital output with additional capacitance: (1) Connect it to a large inverter input (or any cell input, or multiple cell inputs); (2) Connect it to antenna diodes. The problem is finding any cell with an input with as much capacitance as a decap, particularly as standard cells tend to be designed to minimize input capacitance.
j
Yes, you are right. I'm looking for a cell with more capacitance and thought decap can achieve that so that the transients can be mitigated by increasing the critical charge of the logic gate. I'm defining a custom cell named decap_1 with features of deacp_4 with the following modifications to the decap_4 in the sky130_fd_sc_hd.v, sky130_fd_sc_hd.lef and *tt_025.lib:
Will loading the NOR gate to standard cells or antenna diodes create any impact on the final output signal?
I tried the SPICE simulations, and there is no observed alteration in the signal when the NOR gate is loaded with the diode, indicating no transient mitigation. Moreover, loading the NOR gate with inverters results in an increase in the strength of the transients, rather than a decrease. However, when the NOR gates are loaded with the decap cells, the transients are mitigated to a larger extent.
t
Your idea of a custom cell which moves the gate connection from the power supply to a pin is probably the best way to go. We have been able to implement our own custom cells and drop them into the flow. It's pretty easy to do. For reading into magic from a DEF file, you will need a layout of the cell; for that, you can use the LEF file, but you will need to do a 
lef read
of the cell before you do a 
def read
of the layout containing it.
j
Great! Could you please guide me in the steps to do an LEF read before the DEF in an Openlane's interactive flow? I highly appreciate it.
t
First, I would not suggest modifying the existing library verilog/lef/lib files. You just need those files for your own custom cell, and within openlane there are various "EXTRA_LIB" (or something like that) variables for specifying how to add your custom cell files into the flow. So, something like this: Read the standard cell technology LEF, the standard cell LEF macros, your own LEF macro, and then the DEF file:
Copy code
lef read $PDK_ROOT/sky130A/libs.ref/sky130_fd_sc_hd/techlef/sky130_fd_sc_hd__nom.tlef
lef read $PDK_ROOT/sky130A/libs.ref/sky130_fd_sc_hd/lef/sky130_fd_sc_hd.lef
lef read your_cell.lef
def read your_top_level.def
j
It works now. Thank you very much! However, I do not see the GDSII layout (it is empty) generated as *.gds in the results/signoff directory, which may be due to an error in the 19-gdsii.log: Cell "sky130_fd_sc_hd__decap_12" is an abstract view; cannot write GDS. I see this only for decap_12. Do you have an idea what this could be?
t
You cannot write GDS from abstract views ("decap_12" is just the first cell found, and then it stopped so it didn't flag the rest of the cells). Once you have read a DEF file, you can save it as a .mag file. Then re-run magic on the .mag file using 
load -dereference
. That will strip the location information from the abstract views; it will then find the proper layout views in the PDK and replace the abstract views with real layout views. Make sure that you have a real layout view for your custom cell.
j
Thank you very much. It works fine and I see the GDS layout with my custom cell loaded to the logic gate. Sorry to bother you again, but I do see the following LVS error. What could be the reason for this mismatch? Thanks.
t
Can't really tell without looking at the full report. But there are multiple counts of decap and fill cells in the first netlist, and those should be merged together in parallel, so the count should only be one for each of them. The reason could be something like disconnected power rails.
j
Yes, you are right. Attached is the log generated by LVS. How to fix this?
25-or1.lef.lvs.log
t
So there is parallel merging in both netlists, but the merging comes down to two devices on the first netlist and one device on the second netlist. That indicates that somewhere in the first list, the power supply didn't connect to some part of the layout, leaving maybe a single row unconnected from the rest of the power supply, so you have two isolated power supply nets. That's a fairly common problem and probably easily fixed with some configuration change in the PnR. To figure out where the power supply is split, you would need to view the layout and check the connectivity of the power and ground nets.
Actually, you can tell where the split is by looking at this part of the output:
Copy code
Net: PHY_9/VPB                             |(no matching net)                          
  sky130_fd_sc_hd__decap_12/VPB = 1        |                                           
  sky130_fd_sc_hd__decap_12/VPWR = 1       |                                           
  sky130_fd_sc_hd__fill_1/VPB = 1          |                                           
  sky130_fd_sc_hd__fill_1/VPWR = 1         |                                           
  sky130_fd_sc_hd__fill_4/VPB = 1          |                                           
  sky130_fd_sc_hd__fill_4/VPWR = 1         |                                           
  sky130_fd_sc_hd__decap_3/VPB = 1         |                                           
  sky130_fd_sc_hd__decap_3/VPWR = 1        |                                          
  sky130_fd_sc_hd__fill_2/VPB = 1          |                                           
  sky130_fd_sc_hd__fill_2/VPWR = 1         |                                           
  sky130_fd_sc_hd__tapvpwrvgnd_1/VPWR = 1  |
So it's the power supply net that is cut, since the ground nets are shown as matching in the output. All of the cells should show up in both the power and ground nets. But the 
nor2_2
and the 
decap_1
do not appear in the list of devices connecting to the power supply, so those two cells have become isolated from the rest of the power supply. Since 
decap_1
is your cell, chances are that your cell is breaking the power net, and the 
nor2_2
cell is on the same side as the broken net, cut off from the rest of the network.
j
Impressive explanation, much appreciated! Should this task be handled manually in the layout or incorporated into the Place and Route (PnR) process? Furthermore, is there any action required for addressing device mismatches, or will they automatically resolve after NET mismatches are addressed?
Here is my global config.tcl file from the runs directory.
config.tcl
t
@Janani Aravind: Device and net mismatches are complementary, and just different ways of looking at the problem. The matching algorithm uses the list of nets to sort devices, then uses the list of devices to sort nets, and keeps doing that iteratively. Usually it's more helpful to look at the mismatched nets report, but occasionally the mismatched devices report better pinpoints the problem.
@Janani Aravind: To figure out what's going on in this case and what needs to be done about it, you really need to look at the final layout around those two isolated standard cells and see what happened to them.
j
Sounds good. I will take a look. Thank you very much for your valuable insights.
@Tim Edwards, Is there something I can do with the configurations of PDN, VPWR, or VGND in the config.tcl?
t
If you are designing your standard cell to match the existing HD library, then no, there is nothing you need to do in the openlane configuration. Any issues are likely arising from the standard cell itself.
j
Ah, I see, thank you for clarifying that. I've observed a discrepancy in the spice file (.spice) generated by magic. Instead of the expected VPWR and VPB power signals, they are replaced by PHY_9/VPB, which matches the non-matching net identified in the "*-lef.lvs.log". I've attached both the spice file and the lef.lvs.log file for your reference. Additionally, I've included the *.ext file extracted by magic (located in tmp/signoff/magic_spice_ext/), where the merging process occurs. I've noticed some nets being merged to "none" and vice versa. Is this behavior normal? Also, could you advise on how to ensure that the power nets remain as VPB and VPWR in the *.spice after extraction? Thank you for your time.
25-or1.lef.lvs.logor1.extor1.spice
t
What do you have in your layout for your cell? "VPB" is the nwell, which suggests that your nwell does not extend to the cell boundaries. Have you checked the resulting layout for DRC violations?
j
Here, are the different views of or.gds with NOR2_2 and decap_1 (custom cell), also I'm attaching the or.gds file for reference. I'm not sure what is missing in the layout.
or1.gds
t
That's not a valid GDS file, since it contains abstract views, which are not physical. I can save this as a .mag file and read it back with physical views, but I still don't have a physical view of the new 
decap_1
cell. With the physical view missing, the extraction is not valid, as the missing cell makes a gap in the nwell which is what is isolating the cells to its left, which include the 
nor2_2
cell and a 
decap_3
and a handfull of fill cells.
j
Thank you for clarifying. My design passes DRC but fails during LVS. It seems the issue might arise from the absence of VPWR in my customized decap cell. Instead, I've replaced VPWR with a signal pin, A. My understanding is that this pin is connected to the output of a logic gate, which should power up the decap cell as the signal propagates. Upon inspecting the magic spice extraction, I've noticed instances of "none" in the /tmp/signoff/magic_spice_ext/*.ext file, which could be attributed to the missing power signal (VPWR) in my customized decap. I have some questions: 1) Is VPWR necessary for a physical cell like a decap when customized for a different purpose? 2) What is the process for generating a GDSII from LEF? Thanks
t
(1) All four signals VPWR, VGND, VNB, and VPB must be present in any cell that is to be placed and routed with the standard cell set. VPWR and VGND must be on metal rails that stretch the entire width of the cell. Otherwise you will break the power supply across the standard cell row. (2) You don't generate GDS from LEF. LEF is an abstract view of a layout. You have to have a full layout, unabstracted, in order to generate GDS.
j
Great explanation! Thanks. I modified the LEF (it had a different pin name and that was the issue) and now it's working fine. LVS passed. Thank you very much for your valuable suggestions. Highly appreciated!
5 Views
Open in Slack
PreviousNext
Powered by