Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proxy pins for implicit verilog pins no longer working #61

Open
RTimothyEdwards opened this issue Sep 20, 2022 · 8 comments
Open

Proxy pins for implicit verilog pins no longer working #61

RTimothyEdwards opened this issue Sep 20, 2022 · 8 comments

Comments

@RTimothyEdwards
Copy link
Owner

Since merging code related to pull request #59, netgen no longer correctly handles implicit pins in verilog. This issue is caused by the fact that verilog syntax allows pins to be missing from a module instance call if those pins do not connect to anything. This case was previously handled by the "proxy pins" method.

@d-m-bailey
Copy link
Contributor

@RTimothyEdwards Is this related to LEF based LVS where there are no underlying cell defintions? On full device level LVS, when I read the spice libraries, this isn't a problem.

Maybe adding proxy pins only on black boxes would be a solution.

@RTimothyEdwards
Copy link
Owner Author

Yes, that's what I had in mind. Allowing proxy pins on black box cells---if and only if they come from verilog (which is the only format that allows implicit pins). My original solution was too broad and led to the over-use of proxy pins, which is what your code corrected. But I would still like the proxy pin solution to work in the narrowest case.

@RTimothyEdwards
Copy link
Owner Author

The big problem here is that your last pull request that redid the MatchPins() function completely removed the proxy pin code, so there is no longer any way to get proxy pins back. I may have to take the undesirable step of adding back the original code and having two different versions of MatchPins()---although what I really want is to have the best parts of both.

@d-m-bailey
Copy link
Contributor

Do the implicit pins show up on gate level verilog that is automatically generated from openlane?
What use case generates gate level verilog with implicit pins?

@RTimothyEdwards
Copy link
Owner Author

@d-m-bailey : Yes, it does show up in output from openlane. A good example is from the vezzal repository at https://github.com/lankasaicharan/vezzal , under testcases/netgen/case6. This is the most typical case, caused by the use of the sky130_fd_sc_hd__conb_1. In this case it comes from the DLL in caravel. The source is digital_pll.v, and the netlist being compared can also be found in the caravel repository under verilog/gl/digital_pll.v. The synthesis has produced the following for a constant-valued wire:

 sky130_fd_sc_hd__conb_1 \ringosc.iss.const1  (.HI(\ringosc.iss.one ),
    .VGND(VGND),
    .VNB(VGND),
    .VPB(VPWR),
    .VPWR(VPWR));

The conb cell has both HI and LO outputs, but since the synthesis tool only needs one, the other goes undeclared.

@RTimothyEdwards
Copy link
Owner Author

Requiring prototypes of all modules is always an option, but I rather liked the simplicity of netgen just handling the implicit pins.

@d-m-bailey
Copy link
Contributor

I believe one of the intermediary commits had the proxy code just commented out rather than removed.
On my branch pin_match, I can see the proxy code at HEAD~2.
Does that help?

@proppy
Copy link

proppy commented Sep 30, 2022

Possibly related to The-OpenROAD-Project/OpenLane#1380 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants