https://open-source-silicon.dev logo
Join Slack
Powered by
After writing my GDS out and trying the precheck, ...
# magic
n
After writing my GDS out and trying the precheck, I got an error saying some of cells were used by not defined. So I tried to read the GDS into magic itself and got the same thing. It seems like the cells are related to the SRAM units I'm using, but I'm not sure why because I didn't have any related errors on the GDS write step. I've posted a screenshot of an example in the comments.
image.png
m
I also had problems related to the streaming of the memories. In my case, different size memories result in conflicts in the flat GDS name space
n
Yeah and I don't know how to fix this; my design isn't passing the precheck as a result. How did you go about debugging? I'm only using one size SRAM instantiated multiple times.
In fact it seems like it says that none of the SRAM cells exist, e.g. column_mux, precharge_array all give the same error.
h
Did you build your pdk with sram macros? By default, the pdk is not build with SRAM macros
n
I did.
h
the precheck will load the SRAM maglef from the PDK
I can see that the pdk generate these cells from the GDS in pdks/sky130A/libs.ref/sky130_sram_macros/mag. Maybe you need to add it to the search path?
n
just using the addpath command in Magic you mean?
No, did not work, thanks for the suggestion though.
t
I notice that it is reading, e.g., "pinv_0_5" and then later complaining that "pinv_0" does not exist---it seems that there are "_5" suffixes added to cell definitions but that the instances are calling the cell without the suffix. What GDS file was this that you were reading?
n
This was the one that I wrote out using "gds write"
t
But this looks like an OpenRAM block that has the suffixes. . . what SRAM is in the layout?
n
It's the latest 4KB SRAM
generated by OpenRAM
t
No other SRAM blocks? There is something in Magic's code for reading GDS that deals with cells already defined by adding a suffix with an underscore and a number. . . The number starts at 1 and increments, meaning that it saw a definition for all these cells six times, or at least that's what it's suggesting.
n
The SRAM is instantiated 8 times, but it's the same 4KB SRAM.
t
If you do 
strings <filename>.gds | grep pinv_0
, what does it return?
n
image.png
t
In magic, did you have a complete view of the SRAM, or an abstract view, of the layout?
n
It was a complete view. When I expand and zoom in, I can see all the transistors.
t
It seems to have written the definitions with a suffix but all the instances reference the cell name without a suffix. . . I don't even know how Magic can do that. . .
What version of magic are you using? (magic --version)
n
8.3.169
t
And how did you get the SRAM cell into the layout? "getcell" (loaded from the open_pdks installation mag/ directory)?
n
I generated the digital design .def file using Innovus. Then I did a def read from that.
Didn't actually instantiate the SRAMs individually.
t
I'm trying to figure out where the "5" is getting added. . . Just to make sure, does 
strings /path/to/sky130_sram_macros/gds/sky130_sram_4kbyte_1rw1r_32x1024_8.gds | grep pinv_0_5
return anything? (I assume that's the macro you're using?)
n
Yeah doesn't return anything.
Do you want me to DM you any files?
t
Just looking at the code changes, I feel like this must be related to the change made in version 8.3.160, although I just don't see how. You can try compiling version 8.3.159 and see if that makes the problem go away. I also made changes recently that affect the behavior writing GDS, athough again I don't see how it would be related, but the other choice would be to pull the most recent version, which is 8.3.180, and try that.
n
Ok I'll pull the most recent version. Would I need to write the gds again (takes several hours)?
It would probably take the rest of the time until 11:59 just to write the gds out...
t
I'd suggest this: Use "cif *hier write disable ; cif *array write disable" before writing GDS. That should make the GDS write go quickly, although treat that GDS as just a test case, not a real layout. Then you can run the "strings" command like above to see if it has a "pinv_0_5" defined once and "pinv_0" defined many times.
Don't worry about the submission deadline.
I think you have already made a project submission? If not, go ahead and do so with the existing GDS file. We'll get it sorted out tomorrow, or early next week.
n
Ok. Yes, I've already submitted a GDS on there (the one that fails the precheck).
t
I probably need to try to reproduce the error by pulling your repository and running the "def read" and "gds write" myself and see if I can make it do the same thing. I won't be able to get around to that until tomorrow, though.
n
Same issue with the most recent version of magic.
Ok I will try to put all the necessary files together onto the repo linked with my project on Efabless.
Thanks so much by the way!
I regenerated the GDS a different way: I used just the LEF file for the digital unit and wrote the GDS file for the top level design. I already had the GDS from Innovus for the digital unit, then I merged the two. I no longer get those errors when I read the merged GDS into Magic. I just uploaded that to my repo and am running the precheck right now. Last time the precheck errored out in around 2 minutes, but now it's been going on with the XOR for around 45 minutes now, which I guess is promising (it probably means it's recognized the SRAMs). I went ahead and kept this new GDS on my repo for submission.
m
Nice. The commercial tools merged the right way and renamed things.
t
@Matthew Guthaus: There is a "gds unique true" option. However, it will end up renaming all cells with the same name, even the ones that have the exact same content. Definitely the right way to do it is with checksums, and determine definitively if two cells with the same name have the same content or not (I do this with xcircuit, but it's a lot easier to compare two schematics than it is to compare two layouts).
n
The XOR checks have been going now for 12 hours...
t
The XOR is run by klayout and we have not benchmarked it on more than the designs from the 1st tapeout. I don't have enough experience with it to know if it's slow or if it's stuck.
3 Views
Open in Slack
PreviousNext
Powered by