-
-
Notifications
You must be signed in to change notification settings - Fork 303
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
Warn / prohibit using SlowArea clock wire #1287
Comments
How were you using it which was making things going bad ? (as code an example) |
I used it go get the clock assigned to a wire, to get it out on a pin. I was expecting the current clock domain, being in the slow area, to return the slow clock. I know this is rather unorthodox, generating a clock like that, but it does work for my purposes. |
Ahh i undertstand I'm realy not sure preventing it is either a good idea. Maybe more documentation would have helped ? or maybe not (i'm personnaly always skiping reading doc by default XD ) |
Conceptually, I see the In that sense, I see it more as an exception that the parent clock domain's clock be used in the area with the derived clock. A warning in the documentation is definitely a good idea anyhow. I made a proposal in PR SpinalHDL/SpinalDoc-RTD#235 |
Closing this since the documentation update was merged, thanks! |
It isn't self-evident that the clock wire of a SlowArea's ClockDomain is actually the original ClockDomain's clock wire.
In order to get a clock running at the desired rate, one must use the ClockEnable signal.
I don't think there's architecturally anything wrong with this construction, but perhaps the derived ClockDomain's clock should be masked somehow to avoid it being assigned to a signal. An explicit override would be possible, and an error could be shown explaining which steps to take to obtain the right signal.
I just went through several hours of debugging to figure this out.
The text was updated successfully, but these errors were encountered: