https://open-source-silicon.dev logo
Join Slack
Powered by
I'm getting a 'Cannot find cell' message with netg...
# lvs
m
I'm getting a 'Cannot find cell' message with netgen and I can't work out why.
run 
make lvs
in this directory
message is 
Cannot find cell tt_um_analog_loopback in file
but tt_um_analog_loopback is in both the spice and verilog
image.png
just realised my netgen is sooo out of date on my laptop
t
If the problem persists after an update, please let me know.
m
yes it does
and the same scripts work in some other projects I'm working on
t
I think it has more to do with the way the files are being read in by the script---or is this just a simple single read command? Can you post the script that reads the files?
Okay, you posted the link, I guess I can run with that. : )
I will need to investigate further. The script looks legitimate. Shouldn't take too long to pin it down with a debugger, but it won't happen in the next hour (I have to start looking through Chipalooza proposals).
m
np
thanks Tim!
I can see by eye that there's no LVS issue, but I want to get better at using the tools and understanding the errors
m
@Matt Venn are you trying to run lvs on a subckt that has only pins and no devices?
t
@Matt Venn: My suspicion is that netgen isn't seeing any content in the verilog other than the assignments and is incorrectly deciding that the cell is empty, or something like that.
Yes, that's exactly what it is. Now what to do about it. . .
@Matt Venn: You have run into an obscure issue. There was one superficial issue which was that the "cells list" command does not count empty cells, which caused the immediate "Cannot find cell" error message and early termination. However, having fixed that, it still ends saying "not checked" instead of "matched". That probably could be worked around, except that when I change the assignment statements in the verilog, it continues to say that the pin lists are equivalent, which I guess means that it doesn't really check what nets the pins are connected to if there aren't any internal nets in the cell. So it seems like it needs an extra check.
m
ok, I'll work around it by using a cell
it's an edge case, I was mostly interested in why it was failing
ok, I added a conb tie cell so there'd be one cell in the verilog
now it's failing because it can't match pins
lvs.report
lvs.report
tt_um_analog_loopback.lvs.spice,project.v
tt_um_analog_loopback.lvs.spiceproject.v
maybe it's because the extraction has chosen uo_out[7] as the tie_low pin ?
t
This will likely require some investigation, and I'm going to be pretty tied up with Chipalooza until mid-day Thursday, so please feel free to send me reminders so it doesn't drop off my radar in the next day or two.
m
@Matt Venn this should have been fixed in a recent version of netgen. Is your’s up to date?
t
@Mitch Bailey: No, this is something else. Netgen is not prepared to treat a module with only "assign" statements in it as anything except a black box, and it does not do pin matching on what it perceives as a black box without an set of net and device structures from the comparison, which an empty cell doesn't have. What it needs to do in this case is to do a cursory check on all the pins (after matching them by name, which it is doing) to make sure that any connected/permutable pins are the same on both sides. Because it is currently relying on the net structure to determine this, so without a net structure, it will have to do the check a different way. This error is showing up now purely due to the nature of this "loopback test". But the loopback test is a valid circuit and the condition needs to be handled by netgen.
m
I fixed it like this:
@Tim Edwards you might have missed that I tried with a conb cell to add a single cell to work around the 'only assign' issue
which also fails, unless I assign every port individually
t
@Mitch Bailey @Matt Venn: I didn't miss it, I just forgot about it because I'm juggling with too many balls in the air right now. So I would agree with Mitch's statement about the previous workaround that it "should have been fixed" but I expect it is likely that this is just another failing case somehow. Given your solution that worked, I think it may just be the underlying issue that relying on magic to automatically insert breaks between pins may result in something that is topologically unique and has to be matched with an exactly corresponding set of assignments in the verilog. I can't think of why that would be, but the evidence points to that conclusion.
m
I'm on netgen 1.5.271
I've commited my changes, and happy with them
so no rush
if you want me to test this with a new version of netgen let me know
t
@Matt Venn: You have the latest version (or near enough).
17 Views
Open in Slack
PreviousNext
Powered by