https://open-source-silicon.dev
Join Slack
Hi <@U01RSNFAM55> <@U017X0NM2E7> <@U016EM8L91B> everyone as we have highlighted issue in meeting. Fo...
# ieee-sscs-dc-23
a
Hi @Boris Murmann @Mitch Bailey @Tim Edwards everyone as we have highlighted issue in meeting. Following DRCs we get when we opened our design in klayout. This is data from one project we have 6 project all six are getting these or more than these DRCs. In magic DRCs were cleared, we had already run post layout simulation, now when we are going for precheck when we opened it on klayout these are DRCs. We have completed layout etc atleast month or 2 ago. What should we do. For further clarification we are using volare and our pdk is updated to 27 oct 2023 version magic is also latest, i have run this on klayout 28.7 and 28.13.
👍 3
There is another issue we have pointed out somewhere above that when we write gds, it seems to show DRCs and in some projects via are broken into parts, @Tim Edwards mentions that it is Gds reading issue and not writing issue.
n
Facing same issues
m
magic uses via areas which are converted into actual vias with correct sizing and enclosure during gds conversion. This is expected. DRC errors are another issue and need to be addressed.
👍 1
Can you share your repo?
a
@Ali Sabir
You can check Pakistan6.rar as detailed readme is attached with it let me know if you have any problem opening it.
a
Thanks @Atif Khan for sharing the repo.
🙌 1
t
@Atif Khan: The layout looks fine to me. Remember that magic is not guaranteed to be symmetric with respect to GDS out / GDS in, although sometimes modifying the GDS read-in rules can fix issues like this. This is a bit of a complicated case that is caused by nwell in cell 
inverter_magic
extending the nwell in cell 
pmos_3p3_VH67F7
. The nwell in the subcell extends under the contact but the nwell in the cell with the contact does not extend under the contact, which is not handled properly on GDS read-in. This could be corrected by extending the nwell to cover the contact and well tap diffusion in the same cell as the contact and diffusion (but to be clear, it is not an error until you read that layout back into magic with 
gds read
). There is another error that is an actual error in the magic tech file that incorrectly merges together the MiM cap contact cuts. It is expanding too far which does not leave enough room to the edge of the capacitor. I just corrected this rule in the tech file and will push it to the open_pdks repository later today. Again, this is not an error in your layout but is caused by reading the GDS back into magic.
a
Ok got it. But for moment if i consider that magic gds reading is issue( no problem) but why in klayout there are tons of DRC. One issue as you mentioned somewhere else that magic doesn’t check connectivity rules. So do we need to clear these rules in klayout or not secondly in k layout getting pres error (resistor with guard ring spacing) while in magic there is no such DRCs. There are many more as i have listed whole list. If get some solution to rectify these in magic it would be helpful.
t
I can't speak to all of these errors without looking up each error type in the documentation. But I know that 
M1.4
, 
M2.4
, 
M3.4
, and 
PL.8
are all density checks and should not be run because GF runs fill pattern generation themselves.
a
Yeh these are density error
t
There are some others like 
M1.3
which is a metal minimum area, and magic checks for that, so that it would be helpful to get the coordinates for one of those errors to see if it's the magic or the klayout deck that is in error.
a
Is there anyway i can open .mag in klayout instead of gds this might solve some problem. I have tried but magic file is not scaled properly in klayout like gate length of say 1u appear in klayout as 25-30u and so does other dimensions
I tried different grid size but couldn’t get 1 to 1 mapping.
t
I know that there is some kind of support in klayout for reading .mag files but they really are fundamentally different databases and I wouldn't trust what klayout shows as being meaningful.
👍 2
a
Is it necessary to clear klayout DRCs for precheck or we can bypass them if magic DRCs are cleared.
t
It's all effectively irrelevant. If SSCS-DC-23 is being submitted directly to GF then what matters is that the design passes DRC on GF's Calibre deck, using whatever options they use to determine whether to accept or reject a customer design. Obviously it works better for everybody if both klayout and magic have a decently good coverage of the rules. Just as a first approximation, you should probably trust the klayout deck more than the magic deck because the klayout deck has been more thoroughly and rigorously tested. However, without at least one coordinate for each class of error, it's hard to tell what the klayout deck is catching, and which tool, DRC deck, or option selection might be at fault.
👍 1
a
It would be very nice of you if you can look at all mentioned error and make sure to correct/mitigate that from magic side as much as they can be resolved.
t
Yes, but I don't have the klayout report. It would be very helpful if you could give me one coordinate set for one example of each of the above error classes (except for the ones related to density, which we know can be ignored). I have a suspicion that some of the other "errors" are for recommended rules (I did not encode recommended rules into magic). There are, however, some like NP.2 and PP.2 that could be real issues and magic might not be handling them properly. There are other rules like the minimum metal area rule that are puzzling because they are simple rules and magic and klayout ought to agree on them.
a
Here is list of coordinates. I have written atleast three coordinates in below attachment. @Tim Edwards
DRC_Klayout_Coordinates.docx
IMG_2420.jpg
Here is updated DRCs, these are 2 new DRCs rest are same, density rules are nomore present after klayout update
j
Hi Atif, I identified that the coordinates of your polygons have 3 decimals. In my case I have only 2 for each one of the layers. When I was constructing the layout I have several off-grid errors since many polygons had 3 decimals. Also, all the DRC corrections that I made in Klayout where based on the "By Cell" directory. Please take a look there if you have some off-grid errors.
a
I checked errors are not due to off grid
Hi @Tim Edwards i hope you have resolved/found some of DRC issue.
t
@Atif Khan: There are definitely errors in the DRC deck for magic, plus an assortment of other issues. Thank you for the detailed report of errors, which I will need to work through carefully and thoroughly.
👍 1
y
We have encountered the same issue before. There seems to be some discrepancies between the layout geometry rules between MAGIC and Klayout. Previously we simply tweaked all the imported geometries in Klayout until they satisfy the Klayout DRC rules, which is time consuming.
t
The best option is to run DRC rules in klayout often and catch errors. I will get the DRC rules corrected in the magic tech file for gf180mcu but it's not going to happen in time for the GF-MPW1 tapeout (which is five days from now). When is the tapeout deadline for IEEE-SSCS?
b
We don't know the deadline for the SSCS tape-out yet, but it won't be in 2023.
a
@Tim Edwards Any update about the DRC rules of magic or issues that we discussed earlier.
t
@Atif Khan: I had somebody working on it before the holiday; I will check how that's going today.
👍 2
b
Dear all, we have been working with CMC on options for our tapeout. The first option would have been a deadline right around now, which is not realistic given the issues that some teams are still facing. The next available option is tapeout in May, with a tentative deadline of May 15. We will be targeting this run in May. Of course, finishing earlier is better, so that there is time for thorough checking!
👀 3
👍 2
a
@Tim Edwards it would be very nice if i can get what is current status of that?
a
@Tim Edwards Agreed with @Atif Khan
🙌 1
This will help us while doing the planning for finishing the design.
👍 1
t
@Atif Khan and @Ali Sabir: I will get back to you on this tomorrow.
👍 1
a
Thanks @Tim Edwards much appreciated.
a
Thanks @Ali Sabir .
t
I owe you an update, so. . . I have a list now of errors correlated to DRC, GDS, and device generation rules in magic, so I will start working through that list today.
👍 2
I pushed an update to open_pdks to correct five errors in the magic rule deck. There are around ten or so other issues remaining that are not simple to fix and will take a few days to implement. Please keep running layouts through the klayout DRC checker, which has a more complete rule implementation, although I found several rules from the error report above that appear to be false positive error flags from the klayout rule deck.
👍 2
a
@Tim Edwards thanks for updating us will be waiting for further info.
a
Thanks @Tim Edwards we will start running the layout by using the KLayout DRC checker and will get back to you.
t
Note that by far the worst of the DRC errors were the resistor poly to diffusion spacing and the MiM cap bottom plate spacing; those will increase the size of your resistor array and MiM cap array. However, looking at your layout, I think you have plenty of room for the expansion. I have a suspicion that you generated your top-level GDS in magic with the "cif *hier write disable" option. If you are writing GDS of an analog layout in magic, do not use that option; it will prevent magic from resolving notch errors of implant layers between subcells, resulting in notch errors, mainly in the NPLUS and PPLUS layers.
👍 1
a
@Tim Edwards we use gui interface write gds to write gds is there any better way Through command window ?
t
You used the menu selection in magic to write GDS? In that case I'm not sure what's going on, and I will double-check what gets produced from your layout.
a
Yes menu selection
I will generate gds again tomorrow after updating, then i will inform you further. Secondly i will check cif *hier option
@Tim Edwards after updating to latest magic, enabled cif *hier write and generated gds. positive result come as few DRc errors are removed. Following is attached list of that DRC error in klayout. Here is one of the question comes to mind Do we have to make sure that unconnected nwell has to be 1.4um apart or 0.6um? Because magic rule doesn’t consider connected and unconnected as different and place them at 0.6u but klayout has rule of 1.4u? I think (not sure)cap issues are resolved but there are still issues with device generator of resistor poly. Also issue like V1.3d which one has corrected magic or klayout? Both have different. On positive note number of drc error are reduced from 3k to 1.5k but still lot to do.
👍 1
t
@Atif Khan: All layout should attempt to satisfy klayout's DRC results except for those that I mentioned I was suspicious about the result klayout was producing. If klayout has been run with connectivity enabled, then it should be able to determine the correct rule distances for the nwells. I see that the 
PP.2
and 
NP.2
errors are still being flagged, which probably indicates that the generation rules for them are internally inconsistent and causing the notch errors. I will need to investigate that. For the V1.3d issue (and the single V1.3c error is related), the problem is that magic's rule implementation of orientation-dependent metal surround rules around contacts is written in such a way that it does not see the error. Please make sure the layout satisfies the klayout DRC report.
👍 1
a
Sure i have ran klayout with connectivity rule checked. I will do further testing on other projects(there are 5 others )and will check what kind of drc error they have.
Hi @Tim Edwards i have opened magic layout after pdk update and resistor layout is showing drc (poly resistor spacing to diffusion < 0.6 um) As discussed yesterday I regenerated resistor but still it is showing drc.
t
@Atif Khan: What do you have for the technology version?
Copy code
% tech version
1.0.465-4-g9e8019b {Global Foundries 180mcu: open PDK rules and DRC}
a
1.0.466
t
@Atif Khan: I just investigated this and discovered a behavior that I wasn't aware of (or maybe I forgot about it), which is that if you update the PDK and hit "Apply" on the generated device, it will not change an existing cell. Possibly I implemented this behavior on purpose to keep it from accidentally changing custom-modified cells. At any rate, it looks like it won't generate a new layout unless you delete the old layout (ppolyf_u_7PLHK3.mag) and create it from scratch. However: There is a "quick & dirty" way to force the change anyway. Since the name of the cell is created from a hash of the extract character strings used for the parameter values, then you can force the cell name to change without changing the parameters by making a simple difference like changing the resistor width from "1.1" to "1.10".
👍 1
a
@Tim Edwards :I tried that but still issue is same
t
Well, this is what I get with (apparently) the same version of magic and the same PDK version:
ppolyf_u_7PLHK3.mag
a
@Tim Edwards at left it is your design i opened. On right the device i have generated.
t
Oh, I had not done a reconfigure to update the open_pdks version number on my desktop. If I look at the git commit log, the open_pdks tech file version with the fix is really 1.0.469.
👍 1
a
Ok i will update when available. One thing more notch error are reduced but there are still notch error of nplus and pplus. are you working on it? PP.2 and NP.2 errors
t
The notch errors will be resolved by the same open_pdks update.
a
@Tim Edwards in volare i have this version available only. I haven’t get update yet.
Also last update is month ago
I have copied and pasted tech file and now i will check
@Tim Edwards : I don’t but i am not getting open_pdks version 1.0.470 even after updating to latest jan update magic tech file has 1.0.466
@Tim Edwards : as you mentioned above about resistor device generator drc and way to resolve them, magic removes drc as you mentioned shortcut way, magic shows no drc but klayout has same drc of pres3,5,6.
For reference i have used your provided resistor layout still there were drc of pres 3,5,6.
Hi @Tim Edwards here-is reminder that resistor generator issue are not resolved yet. Kindly elaborate if there is relevant work is done recently of updating generator.
t
The device generator was fixed some time ago, and I do not understand the nature of the errors you are currently getting. However, there is nothing preventing you from manually editing the cells to resolve the DRC errors.
a
Good point i will try to resolve manually drc error but resistor drc are cleared in magic ( by shortcut way) but when i import that to klayout they are still there. I think i can give a try to resolve all other drcs except resistor generator. It is not in user hand to modify it. ( pres 3,5,6 are still there in klayout)
When i change length from 2.6 to 2.60 then magic shows no drc. But klayout has same drc. I don’t know they are cleared but are actually not cleared when i generate gds and open it on klayout.
t
How are you generating the GDS from magic? It seems like you are picking up the layout for the resistor from elsewhere.
a
I have tried both from menu and command window. For testing i have placed new resistor layout in top level and cleared magic error but when i exported it to klayout error reappears.
This could have been error if cells that i have instantiated in top level (resistor generator) has error but i have generated new layout of resistor in top level that is not possible that it would pick from anywhere? So i think that ruled out this possibility.
t
Is this problem extant in the current repository commit?
a
Yes it is, @Ali Sabir has committed repository. We haven’t updated the repository since 2,3 months but layout is same.
👍 1
a
Thanks @Atif Khan for sharing. We will update the repository and commit again.
a
@Tim Edwards what is current open_pdk version.
t
@Atif Khan: Current version is 1.0.471. The GF180MCU DRC rules were corrected in versions 1.0.468 and 1.0.469, so you need to update from your 1.0.466.
a
Yeah i try to update pdk but i will either get magic tech with revision version or 1.0.466
Can you send me a 1.0.469 or later tech file
t
The tech file just takes its version number from the PDK, so if the tech file says version 1.0.466, then the entire PDK is version 1.0.466. How are you getting/updating the PDK?
👍 1
a
From volare
Currently i am setting system on new pc, i always update it like like that. My magic version is 8.3.464
t
If you pass the git commit number of open_pdks version 1.0.466 to volare, then that's what you're going to get. You need to query volare for the most recent PDK version that it knows about.
a
I am getting this. There is no version came after jan.
IMG_3466.jpg
@Mitch Bailey @Ali Sabir
t
@donn: Is the Jan. 10 version of open_pdks the most recent one known to volare? If so, I just updated all the references (and did the manual mirror copy to github); could you do another build on the current version?
a
When will i get update tomorrow or at 12:00Am
a
@Tim Edwards Can we build open_pdks locally through volare? Something like "volare build <open_pdk_commit>"
t
Yes, I think that works. Donn has mentioned that to me before. I cannot confirm the exact syntax.
a
This after building latest update. Anybody know what is this returned non zero status.
this error while building new version. was working fine on previous pc, currently i am doing this on new system getting this error, below is install.log attached
install.log
t
The relevant part of the log file is:
Copy code
Cloning into '..sourcesgf180mcu_fd_pv'...
fatal the remote end hung up unexpectedly
fatal early EOF
fatal index-pack failed
Failed to execute git cmd after 5 retries
fatal the remote end hung up unexpectedly
fatal early EOF
fatal index-pack failed
Failed to execute git cmd after 5 retries
This is an error with communicating with github. You can (1) just try running again, and see if it will succeed the 2nd time; (2) change values for RETRIES_NO and maybe RETRY_DELAY in 
open_pdks/scripts/download.sh
, as it seems that many repositories encountered a few errors but only one of them failed after 5 tries; or (3) 
cd open_pdks/sources
and manually do 
git clone <https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pv> gf180mcu_fd_pv
until it succeeds.
👍 1
a
@Tim Edwards is use option three and then build again it worked but still my tech version is 1.0.466 although when i go to cd/open_pdks version i get 1.0.471
t
The technology version in magic is derived directly from the open_pdks version number. So you must have two versions of the technology on your system. But if you run magic, you have to pass it a valid path to a startup script file; I always do (through an alias) 
magic -d OGL -rcfile /usr/local/share/pdk/sky130A/libs.tech/magic/sky130A.magicrc
. If you run 
./configure
in open_pdks and don't pass anything for 
--prefix
, then the default install location is 
/usr/local/share/pdk/
. Of course, you have to do 
sudo make install
in open_pdks for it to get installed there.
a
@Tim Edwards is have tried to build this on my couple of friends machine they had 1.0.414, after build it moves to 1.0.466 , it is not moving further i have installed it as you mentioned but still i am not getting update
Hi @Tim Edwards i resolved all the drc error mentioned above and checked it in the klayout my drc was clean
then accidentally I noticed that my whole design was using technology gf180mcuc although i was using magicrc of gf180mcud when i used writeall force command now i am getting np.2 and pp.2 error
t
@Atif Khan: That shouldn't happen. . . the only difference between C and D is the change in thick top metal thickness from 0.9um to 1.1um (on recommendation from GF, because they say that the 0.9um thickness option has an issue with delamination on the pads).
a
Solved i enabled cif hierarchy write enable , thanks for quick response
👍 1
@Tim Edwards @Mitch Bailey was expecting ring_pad.gds provided to be drc free but i read a thread where it is mentioned that there are drc in that. I run on klayout i got following drcs. There are drc in corner pad ,asig5v , in bi_t and in_c. Should we leave them as it is?
👍 1
m
@Atif Khan thanks for the update. I’m not that familiar with the gf180mcu klayout rule status and Tim is busy with chipaloosa the next few days. We can discuss this issue in the meeting in later today/tomorrow. I imagine it will require some clarification from @mehdi , global foundries, or the intermediate company that is handling tapeout.
a
yeah sure i will attend today meeting.
m
can you email me the issues you are seeing at mehdi@umich.edu
👍 2
a
@mehdi sure, i have sent you a mail.
🙌 1
@mehdi DRC issue LPW.2a_5v and NW.2b_3.3 are related to different potential
image.png
@mehdi @Tim Edwards we are encountering some weird issue. When i run ring_pad.gds i got 1064 (diff potential error) but when i open it in magic and placed my design as a instance and write back gds then run drc on klayout we got 400k drc in pad_ring.
m
@Atif Khan In magic, reading and then writing gds can cause problems. Before you read the gds, set
Copy code
gds readonly yes
• Do not modify any gds files that were read in. • Place the gds cells in your magic design and then write the gds. See if that fixes the problem.
a
@Mitch Bailey can i open multiple gds in one magic? I mean ring_pad gds and my design gds?
@Mitch Bailey how i am supposed to do top level connection with ring_pad
m
@Atif Khan You can open multiple gds files, just be sure to set 
gds readonly yes
first, and do not modify the gds cells read in. So if you have a pad ring gds and a design gds, use a top level mag cell and place the pad ring gds cell and your design gds cell in the top level mag cell. Don’t try to place your design in the pad ring gds cell. You can add wiring in the top mag cell to connect the pad ring and your design without editing either the pad ring or your design.
a
When i do this gds readonly true then place my design as a instance and then write back gds and reopen. I only see ring_pad
m
Can you share the exact commands that you use?
a
I use gds readonly true and then from menu i read gds
When i try to read two gds it will keep second gds and close first one.
m
I believe the cells are all there. Use cell manager to see them. Try creating a new top cell to combine them.
a
Okay yes in cell manager there are two cell
m
Copy code
gds readonly true
gds read pad_ring.gds
gds read mydesign.gds
load TOP_CELL
get cell pad_ring 0 0
get cell mydesign 0 0
gds write TOP_CELL.gds
Something like that, but changing the names and positions. You can add routing to the top level before writing.
a
I will get back to you when i will get results od drc after doing this.
What should i write in load “TOP CELL”
m
That’s whatever you want to name your top cell. Place the pad ring cell Place your design Add the wiring
a
Ok thanks when drc run is complete i will let you know
👍 1
Thanks @Mitch Bailey it worked. Though i have to do a lot of wiring again.
👍 1
@Mitch Bailey how can i add comment on chip like we do in AP layer in cadence?
m
Not sure what you mean by AP layer. Something like this?
a
Yes
m
magic data for ascii codes is at https://github.com/efabless/caravel-gf180mcu/tree/main/mag/alpha you might be able to convert those to gds and use them.
✅ 1
a
@Mitch Bailey is don’t know my top level was working fine but i opened it today some of cells of top ring are not expanding ( i have opened closed design many times before today this never happened)
This might be issue
@Tim Edwards
m
Mayby. Can you add 
disable locking
 
locking disable
before reading? I’m not really sure what this does. Use with care (make many backups).
t
Yes, this is the open file descriptor limit issue. 
disable locking
will fix it. It is an OS issue, not a layout issue.
Although that problem was tracked to a bug that was fixed in magic version 8.3.415.
a
How can i do it?
m
Do you have a lot of files in the 
top
directory?
a
Yes lot of files
Because i cannot add wiring of all 88 pads in one go i have to save.
Saving create these
m
Do you have a 
.magicrc
file in the directory? If you do, try putting 
disable locking
 
locking disable
at the beginning of the file. If you don’t, copy 
$PDK_ROOT/$PDK/libs.tech/magic/$PDK.magicrc
to 
.magicrc
and then edit it.
t
FYI, the command is 
locking disable
not 
disable locking
.
👍 2
a
@Mitch Bailey "Calma output error: Can't read cell from vendor GDS. Using magic's internal definition" it is not reading 1/6 gds while i want to write gds
m
Can you tell me exactly what you are trying to do?
a
I was trying to write gds after wiring this issue is resolved. Facing another issue i am using same cell like analog mux in two different projects (different gds) when i try to write gds of top level combining different gds and reread it these cells are missing (showing timestamp mismatches) @Mitch Bailey @Tim Edwards
Also inv and dff of two different project has same name
Secondly we are getting feedback entries parent and child mismatches, for nplus can we use feedback clear?
m
@Atif Khan For duplicate cell names, try
Copy code
gds unique yes
before your 
gds read
. The original cell names should probably be prefixed with unique identifiers. Be very careful when reading gds and the rewriting gds. magic can change the layout unexpectedly. To prevent changes to gds subcells, set
Copy code
gds readonly true
before gds read. For parent and child mismatches, magic needs the hierarchy to be consistent whereas other tools might look at the flattened representation. The feedback entries might be a real problem introduced by using magic to combine the gds.
a
Ok thanks can i use feedback clear because i used in one of layout and i see no difference?
Parent and child disagree?
IMG_4304.jpg
After making unique gds when i try to open gds in klayout got following error
@Amro Tork
@Mitch Bailey
While i made them unique magic renamed same cell and put some _1 _2 etc at the end of transistor now so now we are unable to expand it because this thing doesn’t exit
IMG_4307.jpg
IMG_4308.jpg
@Tim Edwards
Solved running drc check . I change the name of same instances/modules and then placed them again that issue is resolved.
👍 1
@Tim Edwards @Mitch Bailey do we need to add filer on top design before sending (if yes then how we can place in top level gds)
m
I think gf adds their own filler. I don’t think you need to.
👍 1
a
Thanks @Mitch Bailey i have question regarding ascii you provide on which layer that ascii is because in klayout i can see that it is on metal 5? Would it be visible from bare die or it is only visible on chip design only?
m
Not sure. @Tim Edwards?
a
Metal5 would be visible
👍 2
a
Hi @Mitch Bailey i am getting this drc from calibre run IO.1a1_xbutt_xring IO.1a2 IO.3a1 IO.3a2 IO.3b IO.1b I couldn’t comprehend what that mean in this scenario
These two blue metals are vdd and vss and pink one is input from analog pad going to esd circuit
@Amro Tork is get drc from calibre mslot.9d option b i am not getting it why it is flagging this I have generated capacitor from magic generator @Tim Edwards
@Tim Edwards mslot.9d optionb
t
Do not post commercial tool output to a public website.
👍 1
a
Hi @Tim Edwards in capacitor klayout is giving this drc
m
@Atif Khan looks like it might be a capacitor metal spacing rule. If this is in the I/O cell, it may have been waived by the foundry.
a
It is cap issue.I have generated it using magic cap generator
@Mitch Bailey @Tim Edwards
m
The magic cap generator may not have the mim cap bottom plate spacing rule. Is there 1.2um space?
a
I checked it manually it was 1.2
Secondly i am getting mslot9 error in the same area.
t
What tool is generating metal slot layers?
a
I don’t know i have generated capacitor from magic with array of say i.e 10 by 10 and upon dec run we are getting these error along with mimtm.1 error as mentioned above.
t
That is very odd. Magic does not know about or generate slot layers. Seems like some tools disagree about the layer map.
a
Are you referring to this slot created
t
No. The MSLOT.9 rule indicates that a slot layer is drawn over something it shouldn't be, like in this case probably the MiM cap layer. But what tool is drawing slot layers? (Examples: M1 slot = GDS 34:3, M2 slot = GDS 36:3). You should be able to see these layers in klayout.
a
Actually i am getting coordinates of cap and these corner as a location of metal slotting as i am getting this in calibre, i am not seeing this in klayout(error)
I can share the gds if you want to look upto that
t
If it's pushed to a repo, just share the repo link.
a
I have updated gds for m3,4 slotting issue in side rails (haven’t updated gds)but capacitor slotting issue are there in this gds.
t
So this gets even odder. . . If I look at the GDS, there are no slot layers, so I have to assume that the rule is flagging any area of metal that needs to have slotting because it is > 30um wide. That would indicate that the MSLOT.9 error is suggesting that the MiM cap bottom plate is larger than 30um but can't be slotted because MiM caps cannot be slotted under the cap layer. That makes sense, except that there is a rule in the MiM cap section stating that the largest allowable cap is 100um x 100um. The only explanation I can think of is that the MiM cap rule is in error: The largest MiM cap that can be made is 30um x 30um, because of the slotting rules. If that analysis is right, then (1) your layout would be in violation in the area of the 40um x 40um cap which is at (1750um, 978um) in your layout, and could be fixed by breaking up the capacitor into 2 or 4 separate caps totaling the same area; (2) the maximum cap width and length rules need to be changed in the device generators in the PDK.
a
Yeh i can do that and make even cap single unit of 25 by 25 and regenerate layout but then again if this issue is flagged by calibre ( would that be false triggering) we can ignore
t
Is the only error being reported by Calibre in the area of the 40um x 40um cap? If so, then I think you should not continue to get an MSLOT error flagged.
a
No i am getting in all four caps I right now don’t know the exact dimensions of other two caps.
I am getting total of 405 error 264 in big cap and 128 in 1 cap and 12 in 3rd and 1 in smallest
Secondly i have measured now i have used 30 by 30 um dimensions while generating both caps also other two caps are 25 by 25
Only 1 cap is 40 by 40
Rest all are either 30 by 30 or less than 30
Only this is 40 by 40 all other are small
IMG_4375.jpg
Lastly what about mimtm.1?
@Mitch Bailey @Tim Edwards I need your assistance in this matter. MIMtm.1 rule says cap bottom plate distance with bottom plate metal should be 1.2um. But i have checked this distance and it is 0.6um (see attached screen shots). How to solve this issue? as i have no control over internal structure of MIM Cap provided by PDK auto generated by Magic.
002bde69-6e1b-4cb9-9231-c8d056761753.jpg
i have confirmed this by changing drc from 1.2 to 0.6 we get no drc so this i s magic mim cap bottom plate spaing issue ( my opinion) @Tim Edwards can guide further
i think this might be needed to change
@Mitch Bailey @Tim Edwards
m
Sorry, @Atif Khan. I can’t help with pcells.
👍 1
a
@Tim Edwards @Mitch Bailey i have changed end_spacing and cap_surround to 1.2 from 0.67 and 0.6 respectively. Now it generated cap with 1.2 distance
👍 1
i will let you know if drc is passed.
@Mitch Bailey mimtm errors are resolved. But I cannot comprehend what is mimslot9d error is can you elaborate. Because I implemented according to my understanding but drc are not removed.
IMG_4370.png
a
@Atif Khan I don’t get the question. But I have a question for you, why are you using MSLOT layers in the first place? I would imagine they are not required in your design.
a
I am not using it. I have generated magic cap generator that is causing this issue i think.
a
Could you check if the cap generator generates this MSLOT layer?
It shouldn't
a
Actual i am generating say array of 10 by 10 and each mim of 25 by 25 and this issue is raised.
@Amro Tork you can check on this report
a
@Atif Khan Unfortunately, I don't have the time to open the layout. Screenshot from klayout would be better. Please make sure to only open the metal layer that is causing this violation and mslot layer as well. Please close all other layers in the screenshot. If you could also show the highlight, that would help.
a
I have designed on magic but i can share you klayout screenshot today if i could get access or tomorrow.
a
It doesn't matter which design tool you used. You could open the layout in klayout. But I don't understand magic unfortunately.
a
Yeah i understand klayout to some extent, i am checking all error in both tools simultaneously. I will post detailed screenshots tomorrow.
a
Perfect.
m
@Atif Khan did you mean 
mslot9d
instead of 
mimslot9d
? 
mslot9d
looks like the spacing from Pad 
37/0
to any slot layer, but I don’t see slot layers in your gds.
a
Yeah mslot9d
Mitch i think after juan meeting i have identified both issue of latch and mslot ( hope se) i will have to change mim generator again as it is generating extra m5(TM) over mimcap( fusetop) hope so this will be resolved
👍 1
@Mitch Bailey mslot9 issues are resolved. Do i need to open issue in github or no need for that @Tim Edwards
👍 1
t
Go ahead and open an issue on https://github.com/RTimothyEdwards/open_pdks because otherwise I am going to forget about it before I get around to dealing with it.
a
Done
18 Views
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by