I just ran the precheck and the XOR check found a difference. How can I find out what the actual difference is? I've checked  

checks/

 and to be honest, couldn't get much from them except there's exactly 1 discrepancy. I couldn't see anything on the

.png

either. Since the

full_log.log

is quite long, here's a snippet of the relevant section:

Step 4 done without fatal errors.
 Executing Step 5 of 6: Executing XOR Consistency Checks.
 Running XOR Checks...
Total XOR differences = 1
 XOR Checks on GDS Failed, Reason: XOR Differences count is 1. Please view /tmp/kustinj/ee272bclone/caravel_user_project_analog/checks/*.xor.* for more details.
TEST FAILED AT STEP 5

I've opened up the .xor.gds, selected the top cell (XOR), and tried to select any paint and could select none. Specifically, what does

XOR differences: 1
"_output" in: xor.drc:41
Elapsed: 0.010s

mean?

I assume that the xor.gds file is small? If so, can you post it? There could be layers like HVI that are not represented in the sky130A.tech magic techfile; you can also try reading the file in magic using the sky130A-GDS.tech file, which displays all layers.

It is small. I'll post it right now

This is not a cause for failure to open/read a file; it's just mentioning a GDS layer:purpose pair that it does not handle, which is okay. Generally, it's better to read an xor.gds file into klayout, or else use the magic "sky130A-GDS.tech" tech file, which represents many more layers. The 81:14 layer is "low tap density" which is supposed to be placed over the whole central area of the chip, 50um inside the padframe edge. This layer represents the area in which tap spacing can be set to 15um. The layer should be generated automatically for the chip top level and should not be the responsibility of the user (the user area is all 50um within the padframe edge, due to power routing). Is that the only layer inside the xor.gds file?

I tried opening the file like so

magic -T ../open_pdks/sky130A/libs.tech/magic/sky130A-GDS.tech ../caravel_user_project_analog/checks/user_analog_project_wrapper.xor.gds &

and I get an

(UNNAMED)

cell view.

The errors do suggest that the design went out-of-bounds and extended into the management area, which it is not supposed to do. BTW, not getting a cell when you read GDS just means that the GDS was written as a library and does not indicate a top-level cell. So you need to do "cellname top" to list all top-level cells and load the one that is appropriate (probably there is only one).

You know the comment layer on the magic template? Should the pins be crossing that line?

Then that indicates that whatever it is being checked against does not have a pin there. That might simply be because there isn't yet a valid top-level layout for the caravan chip. You can ask Jeff DiCorpo if you should expect to see XOR errors from the caravan user project.

Ok. What's the best way to contact him?

Through Slack.

@John Kustin The

235/4

layer is the pr.Boundary, I think it is missing from your design because you don't have the FIXED_BBOX property in the mag file https://github.com/efabless/caravel_user_project_analog/blob/main/mag/user_analog_project_wrapper.mag#L2304. I think the other differences could be caused if you don't have an origin of (0,0). You can check on the origin by running

set bbox [box values]

in magic. If the lower x and lower y values aren't 0 0, you can move the origin by running the following:

set bbox [box values]
set offset_x [lindex $bbox 0]
set offset_y [lindex $bbox 1]
move origin [expr {$offset_x/2}] [expr {$offset_y/2}]
property FIXED_BBOX [box values]

@Manar Abdelatty I checked my mag file

user_analog_project_wrapper.mag

and found it does have the FIXED_BBOX property:

<< properties >>
string FIXED_BBOX 0 0 584000 704000
<< end >>

The bbox initially had its lower left corner at -800i, -800i. I followed your steps and now the FIXED_BBOX property shows

{FIXED_BBOX 0 0 585600 705600}

I tried the precheck once more and I still get mismatches. I will add that it seems odd for me to change something like the origin when I start from the provided

user_analog_project_wrapper_empty.mag

. Thanks for your suggestions though!

I'm looking at the

caravel_user_project_analog

repository, and the FIXED_BBOX values for the

user_analog_project_wrapper_empty.mag

layout are

0 0 292000 352000

(this is scaled by 1/2 from what Manar posted for

user_analog_project_wrapper.mag

due to a scalefactor of 2 at the top of the file, so they are equivalent). There is no offset at the corner.

I reached out to Jeff DiCorpo about whether or not I should expect any XOR errors from the caravan user project. Until I hear back is there anything you'd recommend trying?

Since it appears something got shifted, you can grab the original

user_analog_project_wrapper_empty

cell from the

caravel

repository and overlay it on your design and see if the pins align. It's possible that somehow part of your layout got shifted, in which case moving the origin back to zero won't make things any better. You could also just drop a fresh copy of the empty wrapper into your design and then splice your design into it (carefully). This assumes that the problem originated in your layout. The evidence points to that but it is by no means certain, so you might not want to do something quite so radical until we're certain of that.

I think you're right... something was shifted. I don't remember what but now the XOR check passes. I'm pretty sure the issue was on my side.