https://open-source-silicon.dev logo
Join Slack
Powered by
<@U016HSAA3RQ>, <@U0169AQ41L6>, Hi Jeff, I have tw...
# tapeout-job
j
@jeffdi, @mehdi, Hi Jeff, I have two questions, the first one is off-grid problem as shown below, there are nothing I can delete, but it still have off-grid problem, I'm a little confused. the second one is how can I resolve the ZeroArea problem?
below is also the off-grid problem, But actually, there is nothing.
m
@jeffdi Can you please take a look at this
t
@Jianwei Jia, @mehdi: What is the URL of the project git repo?
j
https://github.com/Elon-J/OpenFASOC-NIST-PMU-ReRAM This is other URL but I haven't update it, please give me a little minutes to update it
@Tim Edwards, Hi Tim I have updated my GDS file and also there is a precheck result that has been uploaded for your reference. https://github.com/Elon-J/OpenFASOC-NIST-PMU-ReRAM/tree/main/gds https://github.com/Elon-J/OpenFASOC-NIST-PMU-ReRAM/tree/main/precheck_results/15_JUN_2022___20_49_17
m
@Tim Edwards It is up to date now. Thanks!
t
@jeffdi: I can't find anything in the design where klayout is marking zero area shapes and off-grid points, either. I'm inclined to just give this a pass unless SkyWater flags it. Unless it's the case that klayout will absorb a zero area shape and not display it. But I think we've dealt with those before, and klayout shows them.
I take that back; I can find off-grid points in the GDS data.
This is buried in the GDS data; it's a M2 shape. All values in the GDS should be multiples of 5, so 
3154
is an off-grid vertex.
Copy code
0x002c     # RECORD_LENGTH              Bytes of data in this record
    0x10       # RECORD_TYPE:  XY           An array of XY coordinates
    0x03       # DATA_TYPE:    INTEGER_4    Four byte signed integer
    0x000035fc # DATA: 13820
    0x00000b5e # DATA: 2910
    0x000035fc # DATA: 13820
    0x00000c52 # DATA: 3154
    0x00003d40 # DATA: 15680
    0x00000c52 # DATA: 3154
    0x00003d40 # DATA: 15680
    0x00000b5e # DATA: 2910
    0x000035fc # DATA: 13820
    0x00000b5e # DATA: 2910
j
Thank you, Tim! But how can I locate these errors in Klayout? Or I should see the GDS data to locate them?
t
I'm trying to figure that out.
j
Thanks!
t
@Jianwei Jia: I'm having difficulty matching up coordinates from the klayout DRC report. But I did track down one such shape, which is in the cell DCDC_DAC at position (7.080, 5.845) (coordinates of DCDC_DAC). If I load that subcell, show only metal2 (layer 69/20), and do an area selection, the point position gets selected.
If you do an area select on the whole cell, there are three other such zero-area shapes running up the center of the cell. I was able to select just the points and delete them in klayout.
j
OK, I see. Thanks, Tim! It's very helpful! let me check these parts.
t
Likewise, the off-grid shape is the top edge of the horizontal metal2 rectangle in the same DCDC_DAC cell with the lower left hand corner at (13.820, 2.91). The upper edge of the rectangle is at 3.154um, which is off-grid.
I get the feeling that klayout is reporting coordinates of the subcell DCDC_DAC but then negating both coordinates because the cell instance is upside down. And it may be generating the markers incorrectly as well. Sounds like a bug report needs to be sent to the klayout developers, but I think you should be able to figure out from that where all the errors are pointing to.
Because in the error report in your screenshot, the edge is listed at (-15.4, -3.154), and the marker is placed in that position, but the actual coordinate of the off-grid shape is (+15.4, +3.154) in DCDC_DAC. (@Jianwei Jia).
j
Oh, I have seen them, thank you for your time, Tim! I think this time it will work. I should have realized this problem. Originally I just try to select the error position where it pointed to but found nothing, so I just thought it was a false report. Thank you very much!
Open in Slack
PreviousNext
Powered by