-
Notifications
You must be signed in to change notification settings - Fork 610
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
Add debug clock tap port to all default designs #1697
Conversation
generators/chipyard/src/main/scala/config/fragments/ClockingFragments.scala
Show resolved
Hide resolved
(Also reminder to change the default ClockDivider for debug clock) |
Sorry, I don't follow? |
I haven't looked into the issue, but I think we have two type of clock dividers: The first type will disable the clock when DIV is set to By default the clock debug pad is using the first one, and should be changed to use the second one. |
The clock debug tap is currently set up to use a fixed divider with a configurable >1 ratio. I couldn't think of a use case for dynamically setting the division ratio for this debug tap. |
I would recommend to instead make the divider an MMIO device within the PRCI controller region. Most IOs only support <200MHz output speed, and having an MMIO clock divider would be handy for debugging fast clock signals like PLL, which can reach GHz level. I believe most of the chips we have taped out are implemented this way, so it would be nice if this is the default configuration. |
The default config uses a static division of 16, although it can be changed at hardware elaboration time. Is there a use case for dynamically setting the ratio of the debug clock tap at runtime? I figured making it a fixed static divisor would make it easier to interpret, reduce complexity in the system, and avoid polluting the memory map |
For example, during the initial stage of chip bringup, we want to set the divider to be pass-through, feed in 100 Hz clock, and be able to get 100 Hz clock at the debug clock pad to verify basic signs of life. |
I find this is a pretty good reference design. It comes very handy and straight-forward when using this feature. |
Wouldn't it be safer to just set a fixed division ratio? So in slow bring up, you'd expect 100MHz/16, then once you switch to the fast clock, you expect ~1GHz/16. This requires no software manipulation of the debug clock, and the clock is always slower than the max supported frequency of the IOs |
If 16 is not sufficient as a static division ratio, we can change it to a much higher ratio, like 64 or 128. The reason why I'm pushing for a simpler debug clock is to avoid situations like Argo, where the debug clock is broken for whatever reason. In Argo I made tbe debug clock programmable, but it doesn't seem to work. |
We can verify the design with FPGA prototyping. I still insist that software-configurable clock divider is a must-have feature and helps the bringup process enormously. |
What information could be extracted from a software programmable debug divider, that could not be extracted from a statically divided debug clock? If there's a scenario, I'm happy to make the change. But otherwise, I'd prefer to implement to simplest system that provides all the desired debug information. |
Note that this only affects the division FROM the sbus clock to the debug out.You can still dynamically set a division ratio for the sbus clock from the pll clock. I'm just trying to argue against having two programmable dividers in series, that seems too complex with little inherent gain |
Ok, I concede. I can change this such that the debug clock is its own independent "domain" with its own programmable divider and mux. The tradeoff is that this may not precisely match the sbus clock. But it sounds like that isn't that useful anyways? Is this acceptable? |
Thanks! Is there anything I can help? |
Once I fix this (tomorrow T the earliest), can you check that the divider works as intended in RTL simulation? |
@T-K-233 I've updated this PR.
I believe the initial state for the clock tap should be the slow clock. |
This is to work-around Verilator's modeling of reset, which does not model a posedge reset as t=0
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.
tyty
Related PRs / Issues:
Resolves #1687
Type of change:
Impact:
Contributor Checklist:
main
as the base branch?changelog:<topic>
label?changelog:
label?.conda-lock.yml
file if you updated the conda requirements file?Please Backport
?