Async FIFO to solve tricky issue with a funky input clock?

[Altera_Forum]

I came up with a solution, thanks everyone.

[Altera_Forum]

It sounds to me like you could have a counter clocked by your asynchronous clock along with a combinatorial comparison for the limit. The limit output would then go through a synchronizer to the FSM clock domain. Similarly, your decrement flag would come from the FSM domain and then be synchronized in the async clock domain. That means the decrement would be delayed by two async clock edges, but that should be fine.  

 Create a simulation using Modelsim. That way you can try with two fixed frequency clocks, eg., 1MHz and 5MHz, and then once you have the logic working, you can try a variable clock signal in the asynchronous domain and see that it really works just like a fixed clock. The main thing is that in real hardware, you'll want to make sure your async clock does not have runt high or low times, but it sounds like you've already got that under control.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  It sounds to me like you could have a counter clocked by your asynchronous clock along with a combinatorial comparison for the limit. The limit output would then go through a synchronizer to the FSM clock domain. Similarly, your decrement flag would come from the FSM domain and then be synchronized in the async clock domain. That means the decrement would be delayed by two async clock edges, but that should be fine.   Create a simulation using Modelsim. That way you can try with two fixed frequency clocks, eg., 1MHz and 5MHz, and then once you have the logic working, you can try a variable clock signal in the asynchronous domain and see that it really works just like a fixed clock. The main thing is that in real hardware, you'll want to make sure your async clock does not have runt high or low times, but it sounds like you've already got that under control.  Cheers, Dave  --- Quote End ---    This is ideal but unfortunately the async domain will eventually stop oscillating (0MHz). I can't synchronize the decrement signal to it because it may never get a clock again. When you go above the threshold, you do something in the FSM that has some feedback to the async domain. What that ends up doing is causing the async clock to slow down until it eventually shuts off. That means the decrement may be high but it might never get clocked in. Does that make sense?  Thanks.

[Altera_Forum]

if your your input signal (clock) changes frequency or is off but without glitches then you can just count up on it (count1) 

Once you reach threshold then generate flag for that in this clock domain. The system clock can read this flag directly and there is no need for two stage synchroniser since flag is going to be sampled soon again and again while it stays at same level.  you then count down on system clock(count2).  As such I don't see any problem. If your input clock has glitches it then can't be used as clock.

[Altera_Forum]

count on input clock (a feedback adder) but subtract from outer loop either zero or 1 depending on the value coming from system counter: 

system counter counts 0~4 (500 microsec), at count 4 it outputs a pulse for one clock period, this pulse is passed through fifo to subtractor.

[Altera_Forum]

Could you sample the data on both edges of the 10MHz clock - so effectively a 20MHz sample rate. Then synchronise both bits to one edge of the 10Mhz clock?

[Altera_Forum]

--- Quote Start ---   Each positive edge represents a packet of power that has gone through the analog circuit   --- Quote End ---   This sounds more like a digital signal processing application, than a clock-domain crossing problem.  Does your analog circuit really generate edges, or is it really level transitions (high for some time, and then low again)?  Perhaps you can come up with a digital filtering scheme that is effectively a low-pass filter / averaging circuit that gives you the power-estimate you're interested in.  Could you provide more details on the analog circuit and perhaps a block diagram and example of the digital waveform input to the FPGA?  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  I'm not sure if this is the right section because this is my first time posting here so correct me if I'm wrong.   here is the design problem: I need to count the number of positive edges on the asynchronous clock. If this number goes above a certain threshold (let's say, 25 edges), I need to send a signal to FSM in the system clock domain that I've reached my limit. Now I also need to decrement this count at fixed intervals (let's say, minus 1 every 500us). This issue then becomes I'm decrementing the count with the system clock but incrementing it with the async clock.   Thanks  --- Quote End ---    I would implement the following pieces to process this. 1. Somehow I need to transfer pulse information to synchronous domain right? So a safe way is to count in asyn domain with a counter in the asynchronous clock domain, convert its output to gray counter. In synchronous clock comain all you do is to keep your system counter and apply received pulse counts.   async counter-> bin2gray -> clock domain crossing->gray2bin -> interpret counter changes.  Let's say you implemented a 4 bit counter in async domain.   Let's say asynchronous counter is doing the following. 1 2 3 4 .... 14 15 0 1  Remember in the sync domain all you do is to calculate increments and apply to your FSM counter.  So your sync logic which receives counts, will convert them to +0 to +7 increment values. (I assume async clock is no more than 7 times faster than sync clock)  When you decide to count down, all you need to do is to subtract new counts coming in.  Good luck.

[Altera_Forum]

--- Quote Start ---  Could you sample the data on both edges of the 10MHz clock - so effectively a 20MHz sample rate. Then synchronise both bits to one edge of the 10Mhz clock?  --- Quote End ---   Interesting idea. I'll consider this.   --- Quote Start ---  This sounds more like a digital signal processing application, than a clock-domain crossing problem.  Does your analog circuit really generate edges, or is it really level transitions (high for some time, and then low again)?  Perhaps you can come up with a digital filtering scheme that is effectively a low-pass filter / averaging circuit that gives you the power-estimate you're interested in.  Could you provide more details on the analog circuit and perhaps a block diagram and example of the digital waveform input to the FPGA?  Cheers, Dave  --- Quote End ---   The input clock I'm looking at is the output of a comparator. A voltage is applied across a capacitor then a oneshot is used to discharge it. This creates a current that is compared in the comparator to a known level. I think this is how it works but I'm not an analog guy so I'm a little hazy on the details. I did get a guarantee that they can promise me at least 30ns of high time and 30ns of low time so there shouldn't be any min/max time violations in the gates. Although I can fit anything onto an FPGA, this will end up on an ASIC with severe gate resitrictions so a big digital circuit isn't really an option. I'm trying to limit this to less than 25 flops.     --- Quote Start ---  I would implement the following pieces to process this. 1. Somehow I need to transfer pulse information to synchronous domain right? So a safe way is to count in asyn domain with a counter in the asynchronous clock domain, convert its output to gray counter. In synchronous clock comain all you do is to keep your system counter and apply received pulse counts.   async counter-> bin2gray -> clock domain crossing->gray2bin -> interpret counter changes.  Let's say you implemented a 4 bit counter in async domain.   Let's say asynchronous counter is doing the following. 1 2 3 4 .... 14 15 0 1  Remember in the sync domain all you do is to calculate increments and apply to your FSM counter.  So your sync logic which receives counts, will convert them to +0 to +7 increment values. (I assume async clock is no more than 7 times faster than sync clock)  When you decide to count down, all you need to do is to subtract new counts coming in.  Good luck.  --- Quote End ---   I like this idea a lot actually. This is essentially what I was thinking of doing with an async fifo but I couldn't quite formulate what the hacks to get it to work are. Really I'm just utilizing gray code more so than the async FIFO. I think this may work.