two counters, two clocks - loop problem!

When your two clocks are synchronized in this way, you will find it a lot easier to just use the faster clock and use a clock enable signal.

Basically your have only one process, clocked with the fast clock.

Instead of generating a slow clock, use the counter to generate clock enable pulses. For example if your setup used 10MHz for the fast clock and 1MHz for the slow clock, use a counter on the 10MHz clock to generate a signal that is 0 most of the time, and 1 just one out of 10 periods. This will be your slow clock enable signal.

Implement your fast counter just like before, and change your slow counter to only increment when the clock enable signal is 1.

It makes everything a lot easier because everything is within the same process.

--- Quote Start ---

The two clocks are synchronized:

A clock (used to drive the fast counter above) drives another counter which when that hits a certain count resets back to zero and carries on counting. When it resets this is the clock source that drives the first slower counter above.

--- Quote End ---

Generating a slow clock this way makes it difficult to drive signals from the fast to the slow clock domain.

Instead you'd prefer a single clock domain solution where a slow clock tick is used as a clock enable in the slow counter. Building the design this way allows to operate both counters in one process and sharing all signals between both counters, the straightforward way.

Otherwise a request/acknowldege handshake scheme might be used to couple both counters as intended.

Thank you for the quick responses!

I did think of using a common process (honest guv'). This is why I mentioned that the two clocks are indeed synchronized.

I did write some VHDL to instantiate this, but I got my knickers in a bit of a twist and as a result the second faster clock was always slightly displaced (in terms of clock periods) from the termination of the first slower clock. It performed perfectly apart from that. Even though I had written the VHDL to do this, trying to then get my head around what I had written to understand this offset caused a headache of massive proportions!

It is true what they say about reading and understanding pre-written VHDL (even your own!).

I did not instantiate my common process approach in the manner that both of you are suggesting though, so I will try again with your very helpful insights in mind.

--- Quote Start ---

Otherwise a request/acknowldege handshake scheme might be used to couple both counters as intended.

--- Quote End ---

I believe (but don't quote me) that is also something I have seen on the internet that can be used to solve cross clocking domain problems? As I understood it a kind of inter-process tracking latch. So not one to give up I tried that too: 5 attempts later, quite clearly I still did not quite understand how to do this... and hence this forum post. For the record then, how would one instantiate this kind of process? Personally it would be really interesting to know how this is done. At the end of the day what I am asking is how to train my brain to think in a certain way about such VHDL 'nasties'.

Thank you again,

Andy

Sussed! 10mins of re-writing proved a success. Yes, ONE process was the (easiest & obvious) answer.

Thank you for your help.

Andy

Thank you Daixiwen.

Yep, I did look up "clock domain crossing". Not at all easy to implement I found. Kept getting in a muck & fuddle over it and yes, to be avoided at all costs if possible as I have found.

Cheers chaps!

Andy

Indeed.

Easiest way to learn is by having someone sit next to you and point out the bl00dy obvious - I mentor engineering students here at work and teach them real-time embedded C and this way they learn very quickly if practiced on a day to day basis. Unfortunately, no one else in my company uses FPGAs (deemed too expensive) and hence no experience of VHDL from them to pass on to this old dog. So, the next breast thing is the kind help from chaps like you on the forums.

Thank you (for now and in the future) for your time & effort in responding.

Andy