Warn / prohibit using SlowArea clock wire

[louiecaulfield]

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.

[Dolu1990]

I just went through several hours of debugging to figure this out.

How were you using it which was making things going bad ? (as code an example)

[louiecaulfield]

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.

[Dolu1990]

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 )

[louiecaulfield]

Conceptually, I see the Area as part of the design tied to a single clock domain, especially so when considering SlowArea.

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

[andreasWallner]

Closing this since the documentation update was merged, thanks!