two counters, two clocks - loop problem!

[Altera_Forum]

Hello, 

 I hope someone can provide insight into a problem that has got me scratching my head for the past week!  what i am trying to do is: Two counters from two different clock sources.  When the first (slower clock) counter hits a certain count it must stop (and reset to 0 count) and immediately start the second counter.. ..when the second (faster clock) counter hits a certain count it must stop (and reset to 0 count) and immediately the first counter starts again.  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.  Does that make sense?!  the problem: I see that the inter-relationship between the two counters is of a horrible 'loop-back' nature and this is causing any simulation of my VHDL to get so far and then show 'unknown' signal states.  I have tried many different approaches, but always I can see the problem in my mind but essentially do not know how to basically approach a solution to this problem. i.e. two counter processes inter-dependent on each other. Two processes are needed due to the different clocking sources.  Gaaaaaa! My brain hurts :-P  For the record, I am a relative newbie to VHDL.  Thanks in advance!  Andy

[Altera_Forum]

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.

[Altera_Forum]

--- 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.

[Altera_Forum]

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

[Altera_Forum]

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

 Thank you for your help.  Andy

[Altera_Forum]

That's great! For future reference, if you ever need to communicate between processes that use unsynchronized clocks, you can find information on the net with the keywords "clock domain crossing". There are a lot of pages that describe the different possibilities, including the request/acknowledge handshake scheme. But if you can avoid asynchronous clocks, everything gets a lot easier.

[Altera_Forum]

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

[Altera_Forum]

It's not complicated by itself, once you understood the mechanics behind it. But when you are just learning HDL, I think you can focus on other kinds of problems first ;) Then when you are more confident with digital design concepts and actually need to use two different clocks, you can go back to this. (and of course we'll be there if you need help!)

[Altera_Forum]

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