https://open-source-silicon.dev logo
Join Slack
Powered by
I have updated my repo at <https://github.com/thes...
# magic
p
I have updated my repo at https://github.com/thesourcerer8/caravel_stdcelllib_stdcells_project/ with updated files (which solved several other problems), so I think it should be possible to reproduce it with that. (Unless it is an issue with my environment)
t
Your issue is in the queue, but the queue is longer than I will have time to finish today, I expect. One possibility---This issue is most likely related to the LEF origin. If you can move the origin of your circuits so that the lower left corner of the standard cell abutment box is at position (0, 0), then the LEF origin will be (0, 0) and I think the alignment issue will go away (this is a workaround, not a solution, but is likely the fastest way to get the design done and passing precheck). If you do that, please post the current commit hash of the failing example so that I can retrieve it later to work on the actual solution to the problem.
p
My cells are positioned that the lower left corner of the standard cell abutment box is at position (0, 0).
grafik.png
t
I'm not sure where I got the idea that the LEF origin was off. Looking at the screenshots, it does appear that one of the cell views has all coordinates snapped to the lambda grid, such that positions can be off by 5nm in any direction depending on how the value is rounded. If the error is not in the GDS (which it presumably isn't, if the error isn't showing in klayout), then the error occurred when reading GDS in magic, probably by starting magic without the sky130A.magicrc startup file, which sets the internal grid to 5nm.
In fact, the screenshot directly above is such an instance; you started magic without the sky130.magicrc startup file, so the internal grid is set to 10nm.
p
I never played around with the .magicrc's lately, so it should be the .magicrc files shipped with caravel/open_pdks/openlane (which project does them?) somewhere
Ok, I'll investigate where it comes from.
t
open_pdks has the .magicrc file. In your original screenshots for this thread, you are using the .magicrc file, but not in the screenshot above.
p
Yes, this one was done from the StdCellLib where I do not have a .magicrc, the other screenshots above were done from the caravel directory
I think the runs directory are dynamically generated by openlane: This is the .magicrc that causes the problem: openlane/user_proj_example/runs/user_proj_example/results/magic/.magicrc
The caravel/Makefile copies it around: cp -r $(CARAVEL_ROOT)/mag/.magicrc mag/tmp/
But there is no .magicrc in the mag directory
t
That sounds like an openlane caravel bug. The file in the source is sky130A.magicrc.
Actually, yes, I recall it being mentioned yesterday that there is no .magicrc file in the caravel-lite repository mag/ directory.
p
Caravel is referencing a number of different .magicrc files:
t
But the only recipies that copy the .magicrc are fill generation and final compositing, both of which require the full caravel repository, not caravel-lite.
p
There are several different flavors of the .magicrc, the problematic one seems to come from the PDK: /usr/share/pdk/sky130A/libs.ref/sky130_fd_sc_lp/mag/.magicrc
So either caravel or openlane seems to copy it from the PDK to the results/magic directory
t
Where in the Makefile is it pulling a .magicrc file from inside a library directory? Is that in OpenLane?
p
Ok, I can turn off the grid with "snap internal" but that doesnt have much effect on the mispositioning, so I guess this is mispositioning is already in the user_proj_example.mag file
I currently think that "snap lambda" seems to be wrong in the .magicrc files. I'll change it in all the relevant files and rerun the openlane flow to build the caravel
t
Yes; once you have read in a GDS file and converted it to a .mag file, if it snapped to a grid then the only thing to do is to re-create the .mag file again with the correct grid scale.
"snap lambda" is not _wrong_; it's just setting the default definition of units as interpreted by commands like "box".
p
Ok, the magicrc definitely comes from open_pdks, my changes in the PDK propagated to the file in results/magic/.magicrc
But the problem is still there, so "snap lambda" is not the root cause.
Could it be scalefac or scalegrid?
set scalefac [tech lambda] if {[lindex $scalefac 1] < 2} { scalegrid 1 2 }
t
There should be a "scalegrid 1 2" applied at the beginning of the startup (.magicrc) file.
Yes, the above code is correct.
p
Should I try to change that to scalegrid 1 1 ?
t
No, that would cause your issue, not cure it.
p
Any ideas what I could try to cure it?
Or is there anything wrong with my cells that I could fix?
t
I don't know what your flow is and how each view is created. You said that there was no issue in klayout, so I assume everything up to generating GDS is okay. After that, something is generating a .mag view that is getting snapped to the lambda grid. So what files are created for each standard cell, in sequence?
p
My flow is generating .mag, .gds, .lef and providing them to caravel/openlane which builds the user_proj_example
t
Generating them in what order, with what dependencies? Because that's the critical question.
Post an example .mag, .lef, and .gds of a single standard cell, and I can probably tell you where the error gets inserted.
p
These are the cells that I am providing to the caravel/openlane flow: https://github.com/thesourcerer8/caravel_stdcelllib_stdcells_project/tree/main/cells/
t
The first and most obvious thing to point out is that your GDS and magic layouts are completely different.
p
Thanks for pointing that out. Good idea to compare them side by side! I have fixed it now, but that wasn't the root cause for the misalignment.
Ah, now I found it. The basic standard grid of sky130A is 10nm, which is too coarse for the standard cells of Skywater, so they were using magscale. I didnt' knew about magscale and thought that magic can only handle integer coordinates, so I just generated my .mag files with 10nm resolution.
Ok, so I have to enhance my flow to provide 5nm scaled "magscale 1 2" files
Then it should work properly.
@Tim Edwards Please update the mag(5) fileformat documentation sometime, it's hard to demand proper mag file support from other vendors if it isn't documented properly.
Well, and magic has the magic capability that it scales up its internal grid from 10nm to 5nm as soon as you load magic files with 5nm resolution.
Well, another question is why the sky130A.tech file specifies a 10nm base grid if most of the standard cells need 5nm, I guess the rescaling slows things down a bit.
Open in Slack
PreviousNext
Powered by