Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Timing unit inconsistencies #1706

Open
gatecat opened this issue Jul 9, 2021 · 0 comments
Open

Timing unit inconsistencies #1706

gatecat opened this issue Jul 9, 2021 · 0 comments

Comments

@gatecat
Copy link
Contributor

gatecat commented Jul 9, 2021 •
edited

The documentation for the units in the https://github.com/SymbiFlow/prjxray/blob/cb5f2a30633bf0d3ac91a9b5802790ac1da86736/docs/dev_database/common/tile_type.rst#pips-section doesn't seem to be correct.

Not only does it mention us (nanoseconds) which must be a typo, it doesn't seem to be consistent with what's actually in the database.

Looking at a random PIP:

        "INT_L.NL1END0->>NE2BEG0": {
            "can_invert": "0",
            "dst_to_src": {
                "delay": [
                    "0.033",
                    "0.041",
                    "0.111",
                    "0.134"
                ],
                "in_cap": "8.473",
                "res": "1185.1186875"
            },
            "dst_wire": "NE2BEG0",
            "is_directional": "1",
            "is_pass_transistor": 0,
            "is_pseudo": "0",
            "src_to_dst": {
                "delay": [
                    "0.033",
                    "0.041",
                    "0.111",
                    "0.134"
                ],
                "in_cap": "8.473",
                "res": "1185.1186875"
            },
            "src_wire": "NL1END0"
        },

firstly the delays are apparently in nanoseconds, so the us is definitely a typo, but in_cap in µF and res in mΩ don't work either.

8.473µF * 1185mΩ = 10.04µS

which is a delay about 5 or 6 orders of magnitude too high.

The absolute values of the capacitance and resistance values don't matter, so long as their product gives a reasonable delay scaling. My awareness of likely ASIC numbers is limited, but something like switching to pF for capacitance and keeping mΩ gives a plausible delay product while staying fairly close to physical reality, I think.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@gatecat