This repository was archived by the owner on Jan 10, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 23
Improve Consistent/Deterministic refdeses #4
Labels
Comments
Perhaps https://en.wikipedia.org/wiki/Locality-sensitive_hashing as well? |
amstan
added a commit
that referenced
this issue
Apr 12, 2020
Replaced the old name_part_with_mapping code with a fancier implementation. Now it saves more info about each part in the .refdes_mapping file, each column is called an anchor. Now we also keep track of net names, variable names, values, etc. We're resilient to changes in a variety of anchors now. Fixed Issue #19, the naming loop had to be done in 2 passes. BUG=Issue #4 TEST=git checkout c718fbc~1 examples/servo_micro.py Refdeses should stay the same TEST=Move stuff around in servo_micro.py, change things/connections. Refdeses should stay the same
So this got a lot better. There's still room for:
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
I don't really want people to have to worry about refdeses inside the code. Part initializations should not be littered with refdes="Uwhatever".
Right now Context.autoname, beyond numbering parts automatically, also remembers what things were named (via the
.refdes_mapping
files). But it's hard to track parts via just the code, since there's nothing anchoring part instances across different runs to the place where they're defined.Some traditional EDAs solve this problem by having an UUID for each part (which stays for the life of it, inside the source file), then layout tools don't even care if the refdeses change, as long as the UUID didn't. We don't have that luxury, unless we want things like
R("100k", uuid="d4c1d842-705b-456d-9ee1-585463c11db2")
everywhere.The current implementation of Context.autoname uses the nearby lines contents around every part initialization to track a part. The problem with this is that a simple change to something maybe unrelated, or a simple change to the value of a part, causes the part's refdes to "pop" and get forgotten.
We need to track a few more things beyond just lines of code.
"Design doc"
https://github.com/google/pcbdl/wiki/Consistent-refdeses
The text was updated successfully, but these errors were encountered: