-
Notifications
You must be signed in to change notification settings - Fork 104
KLayout DRC Enhancements and QA #529
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
Conversation
Signed-off-by: FaragElsayed2 <[email protected]>
Signed-off-by: FaragElsayed2 <[email protected]>
Signed-off-by: FaragElsayed2 <[email protected]>
Signed-off-by: FaragElsayed2 <[email protected]>
…h latest klayout version Signed-off-by: FaragElsayed2 <[email protected]>
Signed-off-by: FaragElsayed2 <[email protected]>
Signed-off-by: FaragElsayed2 <[email protected]>
b9f6544
to
d776c13
Compare
Signed-off-by: FaragElsayed2 <[email protected]>
8e2aef0
to
67ad578
Compare
Signed-off-by: FaragElsayed2 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh nice! I will run them on my designs and give you more feedback.
@atorkmabrains @FaragElsayed2
|
Run IHP SG13G2 OpenSource DRC. | ||
|
||
Usage: | ||
run_drc.py (--help| -h) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use Python argparse
: https://docs.python.org/3/library/argparse.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should also use pylint
and/or flake8
and try to fix those reported issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dnltz Thanks for your review.
We will take care of linting issues. But may I understand why do we need to use argparse package?
docopt is POSIX standard documentation based parsing library that has been there for a while.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dnltz @atorkmabrains We support flake8
for code style checks, and our GitHub Actions includes a linting step that validates all our python scripts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dnltz @atorkmabrains We support
flake8
for code style checks, and our GitHub Actions includes a linting step that validates all our python scripts.
Yes, sorry. Missed that change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dnltz Thanks for your review.
We will take care of linting issues. But may I understand why do we need to use argparse package?
docopt is POSIX standard documentation based parsing library that has been there for a while.
argparse is a Python built-in library and doesn't require any additional packages. Additional it has some nice features:
- Default values. For example
parser.add_argument('--mp', default=os.cpu_count())
- Limit possible arguments with choices. For example `parser.add_argument('--run_mode', choices=['flat', 'deep'])''
- Define argument types which can simplify arguments like
density
. For example `parser.add_argument(''--density', action='store_true)' and this argument is False when not defined and True and defined. - Validate arguments when parsing them. For example you can validate a file actually exists: https://stackoverflow.com/questions/11540854/file-as-command-line-argument-for-argparse-error-message-if-argument-is-not-va
there is more but you can basically off-load quite a load of work to argparser and simplify your code by also expecting correct values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm familiar with argparse library and what it can do. docopt is capable of doing everything you have mentioned without writing a line of code with the exception of number 4. For docopt, all you need to do is to format your script docstring to the standard POSIX tool usage documentation schema which has been around for decades now. And docopt package automatically do the rest. Not a single line code is required.
The only drawback is that you have to install the docopt package while argparse is standard package. I kind of don't think installation is a problem anyway.
Posix standard: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02
Happy to use argparse but I just wanted to clarify the reason we used docopt as I believe there was a good reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@atorkmabrains @dnltz @FaragElsayed2
In general would be preferable to use python built-in libraries, what releases us of installing and dealing with the dependencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
All docopt
usage has been migrated to argparse
.
@FaragElsayed2 tried it on a small design with |
…rt, updating docs and workflow Signed-off-by: FaragElsayed2 <[email protected]>
Signed-off-by: FaragElsayed2 <[email protected]>
Did the crash occur while setting the options, or during the actual run? I've made some updates that might help prevent this issue, could you please try again and let me know if it still happens? |
Signed-off-by: FaragElsayed2 <[email protected]>
Signed-off-by: FaragElsayed2 <[email protected]>
Signed-off-by: FaragElsayed2 <[email protected]>
Signed-off-by: FaragElsayed2 <[email protected]>
Signed-off-by: FaragElsayed2 <[email protected]>
Signed-off-by: FaragElsayed2 <[email protected]>
Hi @FaragElsayed2, is it possible to put LVS regression update into a separate PR?.. |
Signed-off-by: FaragElsayed2 <[email protected]>
Done in #567 |
Signed-off-by: FaragElsayed2 <[email protected]>
Hi @FaragElsayed2, should we expect more updates in this PR or we can merge it if there are no outstanding issues that you know of?.. |
Hi @sergeiandreyev, yes, I believe we can go ahead and merge this PR. I'm planning to open a separate PR soon with the missing rules and some additional enhancements. |
Signed-off-by: FaragElsayed2 <[email protected]>
Hi @EngGhaith The current DRC implementation does not perform density checks outside the chip boundary, as you pointed out. For the window-based density check, we use a window size of 800 µm × 800 µm, with a step size of 400 µm. This step size was recommended by the commercial PDK team. In practice, this means your layout is divided into overlapping windows of 800 µm × 800 µm, each shifted by 400 µm relative to the adjacent window. Known that our formula is:
For example: If the layout size is not an exact multiple of the step size, additional partial windows will be created at the edges to cover the remaining areas. These edge windows are treated as individual windows for density calculation. For such edge cases, the density is computed using only the portion of the window that lies within the chip boundary. In other words, the formula becomes:
The area outside the chip extent is ignored when calculating density, the density is based solely on the valid portion of the window inside the chip. Regarding V1.a, I’m not sure what you mean by “is not corrected here”. Could you please provide a screenshot or share the specific testcase where you’re encountering an issue with? |
I think @EngGhaith is referring to this issue w/ |
@sergeiandreyev I got it now. It seems that some DRC violations for certain PCells are being ignored. We have applied this exclusion for the ones explicitly mentioned in the DRM as “The following rules do not apply”. However, I noticed in the older implementation for V1.a was excluding transG2L from this check, and I also see a cntb.h1 violation in npn13G2, but those exclusions not mentioned in DRM. I believe we could exclude all PCell violations from DRC, but that would be risky for actual designs. The safer approach would be to use waivers for these cells, but as far as I know, KLayout doesn’t provide built‑in waiver support (not sure). @atorkmabrains, what would be the best approach here? |
Hi @stefansimon42, shall we review the DRM for any missing device-specific waivers? also that one #628 |
Hi @FaragElsayed2, could you please resolve the conflicts, then we will merge this PR |
@KrzysztofHerman @FaragElsayed2 is off today, will get it done soon. |
KLayout DRC Enhancements and QA
This PR includes major improvements and validations for the KLayout G2 DRC:
✅ DRC Improvements