The-OpenROAD-Project
[OpenFASoC] write_cdl issue
The temp_sensor in OpenFASoC has LVS issue after the update of write_cdl.
Link to OpenFASoC: (https://github.com/idea-fasoc/OpenFASOC)
The power nets in cdl file are unconnected.
I also checked the 6_final.v file and found that the power nets disappeared when using the latest version of the OpenROAD compared with the older version. I think maybe this could be a reason causing the error in cdl file?
@maliberty Thanks for taking a look. This issue has been dragging for 2 weeks now :/
initially we made a script to fix the write_cdl command errors (I think it was the orders of the pins that was messed up. Then just before running LVS using netgen we would run cdl_parser.py on the .cdl generated by OR as follows:
netgen_lvs: $(RESULTS_DIR)/6_final.gds
python util/cdl_parser.py -i $(RESULTS_DIR)/6_final.cdl -s $(PLATFORM_DIR)/cdl/sky130_fd_sc_hd.spice -l $(OBJECTS_DIR)/merged_spacing.lef -o $(DESIGN_NAME).spice
$(COMMON_VERIF_DIR)/run_lvspex.sh $(RESULTS_DIR)/6_final.gds $(DESIGN_NAME) $(REPORTS_DIR)/6_final_lvs.rpt
link to Makefile.
See attached tempsense.tar.gz. I think based on what I have checked (2weeks ago) I think there is an issue with the power/wells pins on the second voltage domains. You can check in the tar ball:
- Flow scripts based on ORFS:
/tempsense/generators/temp-sense-gen/flow - lvs report from netgen:
/tempsense/generators/temp-sense-gen/flow/reports/sky130hd/tempsense/6_final_lvs.rpt - verilog / cdl /def files:
/tempsense/generators/temp-sense-gen/flow/results/sky130hd/tempsense
Please let me know if you have any questions and thanks again!
I also see many warnings like:
[WARNING ODB-0286] Terminal VNB of CDL master sky130_fd_sc_hd__a2111o_1 not found in LEF.
which suggests cdl/lef mismatches.
What is CDL_FILE set to? I don't see anything setting it in your tgz.
export CDL_FILE = ../blocks/$(PLATFORM)/cdl/sky130_fd_sc_hd_merged.cdl
it is in the config.mk in /tempsense/generators/temp-sense-gen/flow/design/sky130hd/tempsense
[WARNING ODB-0286] Terminal VNB of CDL master sky130_fd_sc_hd__a2111o_1 not found in LEF.
Then it is probably a source file issue. @shuolai please double check the LEF/CDL files versus the one in latest of open_pdk. If it is still there please file an issue.
@maliberty Why do we need the LEF to write the cdl. I think verilog and cdl primitives should be the one to be used?
The database is loaded from LEF/DEF in every step after the first.
On Fri, Oct 1, 2021 at 8:31 PM Mehdi Saligane @.***> wrote:
@maliberty https://github.com/maliberty Why do we need the LEF to write the cdl. I think verilog and cdl primitives should be the one to be used?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/The-OpenROAD-Project/OpenROAD/issues/1146#issuecomment-932673882, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFZ5KVDO7VJ6OJGCOPGDJDUEZ4JJANCNFSM5FDTQZ6Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
The database is loaded from LEF/DEF in every step after the first.
Sure but we could use 6_final.v file which is the one we would eventually use if wanted to the a verilog to lvs cdl conversion. Right?
6_final.v is just generated from the DEF file (there is only read_def in final_report.tcl). You won't get any extra info there.
@maliberty Yes, this is still an issue. I have tried using the same LEF but still seeing weird results during LVS. Have you been able to validate the write_cdl update in any of the other pdks we have?
I have asked @erictaur and @wenbodd to take a look but I did not hear back from them yet.
@msaligane if you have an updated test with a LEF I can take a look. I don't know what "weird results" mean.
@maliberty That would be really helpful. Weird results in LVS means that the VNB and VPB are named as unrecognized net in the 2nd voltage domain of the sensor.
@erictaur do you mind sharing the latest details since you have met with @wenbodd ? Have you modified the LEF as discussed ?
The issue is packaged above. I will try to go over this again on Monday afternoon.
@msaligane in the packaged test case the lef & cdl did not align. Until that is addressed I don't have anything to look at.
@maliberty Actually if you look at the LEF files in the tar I attached. VNB / VPB are there in the CDL and LEF files.
sky130_fd_sc_hd__a2111o_1 this cell is not used in the design at all.
Here is a master you are using (it's the same): [WARNING ODB-0286] Terminal VPB of CDL master sky130_fd_sc_hd__inv_1 not found in LEF.
In the CDL: .SUBCKT sky130_fd_sc_hd__inv_1 A VGND VNB VPB VPWR Y
but in the LEF: MACRO sky130_fd_sc_hd__inv_1 PIN A PIN Y PIN VGND PIN VPWR END sky130_fd_sc_hd__inv_1
So the CDL & LEF mismatch as OR reports. There is no way for OR to know what to write for VNB & VPB since they aren't in the LEF (or DEF). It's a data problem not a tool problem.
In the LEF in openlane I do see the bulk pins. I think ORFS needs a refresh.
There are two types of LEF, magic.lef and .lef The magic.lef is the one which has VPB/VNB defined in it. The original version .lef did not have those pins ( I do not understand why there is a need to define those pins in an inverter - I might be missing something).
@minghungumich Do you think you could update to the LEFs straight out of open_pdks. I think right now, we are using the one ORFS/platforms.
@mithro @RTimothyEdwards can you explain why hd and hs versions of this cell have different handling of bulk pins? hd doesn't have them while hs does. In the .magic.lef they are present in both.
@maliberty : I checked and the differences in the handling of the pins goes back to the original SkyWater files, so I second Tim Ansell's opinion.
It sounds like it might make more sense to use the generated .magic.lef files?
@mithro : No, there is no information about the location of pins other than what's in the original files, so the same issue ends up in all formats of all files no matter what tool generated or modified them. So the pins will be in different places in the different standard cell libraries unless somebody modifies them all specifically to make them mutually compatible.
I thought the issue is that the bulk pins exist in the hd cell's .lef files but not in the hs cell's .lef files?
@maliberty said above;
hddoesn't have them whilehsdoes.
In the
.magic.lefthey are present in both.
I think adding those pins in cells that do not have explicit well connection on them is confusing and creates a bunch of issues. However, if we want to add them for some reason, then we should have consistency since we get a lot lvs issues.
I discussed bulk pins with @louiic who recommends we have them in cdl & lef (it is required at lower nodes so it is best to have a single methodology to support).
@mithro : If pins are not present in all files, then somebody is not using the approved set of files from the open_pdks installation. In the open_pdks libraries, all cell views declare all four power pins. There are still differences between the libraries as to how the pins are positioned, which what what I thought was the issue here.
@msaligane : On the contrary, it is necessary to define the explicit well connections for the LEF to represent the correct connectivity. All of the other file types (CDL, GDS, verilog, etc.) declare 4 power pins for every cell. If the LEF file does not also include four power pins, then various tools start complaining about it.
@msaligane : Also, if you're using netgen for LVS, then why not just compare the extracted layout against the verilog?
I discussed bulk pins with @louiic who recommends we have them in cdl & lef (it is required at lower nodes so it is best to have a single methodology to support).
I think it has to do with the LEF verison (IE 58 here)
@msaligane : On the contrary, it is necessary to define the explicit well connections for the LEF to represent the correct connectivity. All of the other file types (CDL, GDS, verilog, etc.) declare 4 power pins for every cell. If the LEF file does not also include four power pins, then various tools start complaining about it.
Sounds good, so maybe let's go with this plan. I am happy with either. Who can update the files? maybe in the precompiled version of open_pdks?