Spartan® Family FPGAs

[vishysub]

I'm more familiar with the mcu style of programming so I use the term interrupt here.

I have a module that intends to read a frequency on an external pin of the FPGA. The module has a ref counts 16 external rising edges and counts internal at a ref clock of 50Mhz. At the 16 clock it latches the value into a register.

Now if I instantiate this module in my Top level, I was wondering how do I know when a new count as been latched?

My module looks like this

module capture(
input ref_clk, // 50 MHz ref
input in_clk, // freq to be counted
input reset,
output reg [23:0] f_meas
);

I was wondering if I could give a "ready" out from that module? but then would I need to do something like this in my top level module

always @ (posedge ready) begin

 // process the f_meas value here

end

Are there any elegant ways of doing this. In short i just want to send  "f_meas" as soon as a new value is ready on the uart to the pc.

[eteam00]

Vishysub,

What does "read a frequency on an external pin of the FPGA" mean?

Do you mean "count clock cycles between pulses (or edges)" ?

The module has a ref counts 16 external rising edges and counts internal at a ref clock of 50Mhz. At the 16 clock it latches the value into a register.

I am reluctant to guess at what this means.  Please re-phrase this description.

It sounds like the module is implemented as a state machine.  You should post your module code (along with an updated description of your intended design function).  Maybe Gabor and I can pick this problem apart as thoroughly as your previous thread in this forum!

-- Bob Elkind

[vishysub]

---

eteam00 wrote:

Vishysub,

What does "read a frequency on an external pin of the FPGA" mean?

Do you mean "count clock cycles between pulses (or edges)" ?

The module has a ref counts 16 external rising edges and counts internal at a ref clock of 50Mhz. At the 16 clock it latches the value into a register.

I am reluctant to guess at what this means.  Please re-phrase this description.

It sounds like the module is implemented as a state machine.  You should post your module code (along with an updated description of your intended design function).  Maybe Gabor and I can pick this problem apart as thoroughly as your previous thread in this forum!

-- Bob Elkind

---

Sorry Bob,  I'll try to explain it a bit better,

1. I have generated a reference clock and that is 50Mhz. There is a 24bit free running counter that counts rising edges of this clock.

2. The external clock is the clock to be measure, after receiving 16 rising edges of the external clock I latch the 24bit counter. 

module capture(
		input 	ref_clk,	// 50 MHz ref
		input 	in_clk,		// freq to be 
		input 	reset,
		output reg [23:0] 	f_meas
    );
	 
	 reg [23:0] count;
	 reg [3:0] presc;
	 
	 initial begin
	    f_meas = 0;
	    presc = 0;		// clear prescaler
	 end
	 
	 // on ref clock rising edge
	 always @ (posedge ref_clk) begin
		if(reset) begin			// synchronous reset
			count <= 0;		// clear counter
		end else begin
			count <= count + 1;	//
		end
	 end
	 
	 // on ext clock rising edge
	always @ (posedge in_clk) begin
		presc <= presc + 1;
		if(presc == 0) begin
			f_meas <= count;	// assign output
		end
	end

endmodule

[eteam00]

Here we go again!

Do you want register f_meas aligned to ref_clk clock domain or to in_clk clock domain?  If you want f_meas aligned to ref_clk clock domain, I'll give you three tries to guess whether the f_meas register assignment belongs in the ref_clk process or the in_clk process -- and your first two guesses will be ignored!  in other words, you already know the answer to this question, yes?

If you are not sure, then let's drop this design coding question for the moment and address the fundamental concept which must be understood by logic designers:

how to recognise and properly handle asynchronous inputs to a synchronous logic system.

If f_meas belongs in the ref_clk domain, you simply need an enable signal (or "sample" signal) from the in_clk domain which will cross to the ref_clk clock domain.  This requires a single-bit register clocked by ref_clk.  If you wish to perform edge detection on this enable signal, then you will need a two-bit register.

If you mentioned the frequency of in_clk, I missed it.  If in_clk is higher frequency than ref_clk, then the enable signal must be stretched in width to at least one full ref_clk cycle.

-- Bob Elkind

[eteam00]

If in_clk is less than half the frequency of ref_clk, an alternative design approach would be to synchronise the in_clk input to ref_clk straight away, and your entire design then dwells within a single clock domain.

If you maintain two clock domains, you will need two BUFG clock buffers.  Synchronising in_clk to ref_clk eliminates both the in_clk clock domain and the power consumed by its BUFG buffer.

-- Bob Elkind

[vishysub]

---

eteam00 wrote:

Here we go again!

Do you want register f_meas aligned to ref_clk clock domain or to in_clk clock domain?  If you want f_meas aligned to ref_clk clock domain, I'll give you three tries to guess whether the f_meas register assignment belongs in the ref_clk process or the in_clk process -- and your first two guesses will be ignored!  in other words, you already know the answer to this question, yes?

Sorry I don't know the answer.

If you are not sure, then let's drop this design coding question for the moment and address the fundamental concept which must be understood by logic designers:

how to recognise and properly handle asynchronous inputs to a synchronous logic system.

Yes I don't quite comprehend what are the implications of asynchronous frequency, what are the potential pitfalls. And how to synchronize this async input to the sync logic.

If f_meas belongs in the ref_clk domain, you simply need an enable signal (or "sample" signal) from the in_clk domain which will cross to the ref_clk clock domain.  This requires a single-bit register clocked by ref_clk.  If you wish to perform edge detection on this enable signal, then you will need a two-bit register.

Sorry I don't understand this, What does it mean to belong to a domain?

If you mentioned the frequency of in_clk, I missed it.  If in_clk is higher frequency than ref_clk, then the enable signal must be stretched in width to at least one full ref_clk cycle.

In_clk much lower (< than 1/60th) than ref_clk

---

[eteam00]

Two definitions:  clock domain and asynchronous input.

Clock domain:

• All the registers clocked with a single, specific clock belong to a single clock domain.

• All these registers have a uniform timing reference for their inputs and outputs.

• The timing reference is the clock.

• The timing reference is applied to the register inputs to evaluate setup and hold time.

• The timing reference is applied to the register outputs to evaluate minimum and maximum delay.

• The logic signals directly or indirectly sourced from the register outputs also belong to the same clock domain.

Asynchronous input:

• A register input, either direct or indirect, from a different or unknown clock domain is considered an asynchronous input.

• The setup and hold time of an asynchronous input cannot be determined.  This is the definition of asynchronous input, the important characteristic which identifies and distinguishes an asynchronous input.

These definitions gloss over some details, and are (therefore) less than 100% complete,  but the important parts of these two definitions are described above.

Before any further discussion of design implementation details, these two definitions must be understood.  It is unfortunate that these concepts must be presented to you in a forum post.  This material should be presented (for the first time) in a face-to-face conversation where drawings and illustrations can be used and questions can be asked.

-- Bob Elkind

[vishysub]

Hello Bob,

I read your articles 

this thread, post #18

this thread, post #6

and now its starting to make some sense.

If I understand correctly then async inputs may cause unpredictable propagation delays that the synthesizer doesn't know about since it doesn't have these parameters with it so the circuit may behave unpredictably under certain conditions.

My questions are

1. Would it be possible to reliably model an async system for eq a frequency counter when we can count an external frequency.

2. If the above is not possible then how should I convert the external frequency which is async in nature to the domain of a sync clock which is running inside the FPGA?

With Regards

[eteam00]

I read your articles 

this thread, post #18

this thread, post #6

and now its starting to make some sense.

Give it some time.  Understanding clock domains and clock domain crossing will become better and more fully understood as you spend more time working with the issue.

If I understand correctly then async inputs may cause unpredictable propagation delays that the synthesizer doesn't know about since it doesn't have these parameters with it so the circuit may behave unpredictably under certain conditions.

Async inputs do not "cause" or even affect propagation delays.  They cause setup and hold time timing violations at inputs to clocked registers.  Do you fully understand the meaning of data input setup time and data input hold time with respect to a register clock?

If the data input to a register is changing state at the same time the register clock (active) edge is occurring, the state of the register is uncertain.  In order to guarantee the reliable operation of a clocked register

• The input must be valid and stable before the register's clock edge -- this is called (minimum) setup time
• The input must remain valid and stable after the register's clock edge -- this is called (minimum) hold time

 My questions are

1. Would it be possible to reliably model an async system for eq a frequency counter when we can count an external frequency.

Please consider what you would be modeling.  Would you be modeling logic function (if yes, then use a logic simulator) or would you be modeling failure rate (if yes, then use an analogue circuit simulator)?

2. If the above is not possible then how should I convert the external frequency which is async in nature to the domain of a sync clock which is running inside the FPGA?

What are the frequencies of the external input and the internal (FPGA) measurement system clock?  If the external input frequency is less than 1/2 the measurement clock frequency (with pulse widths which are wider than the measurement clock period), the two threads you linked in your last post describe with considerable detail how to reliably perform edge detection with asynchronous inputs.  If you can detect edges, you can

• count input edges over a number of measurement clock cycles
• count measurement clock cycles between input edges

-- Bob Elkind

[vishysub]

 Async inputs do not "cause" or even affect propagation delays.  They cause setup and hold time timing violations at inputs to clocked registers.  Do you fully understand the meaning of data input setup time and data input hold time with respect to a register clock?

In the first forum post (Excerpt below)

"Let's say the propagation delay (mostly interconnect) between the inc package pin and the registers for tiempo and vIncAnterior is as short as 1nS for the shortest connection and as long as 2nS for the longest connection.

If the signal inc changes from '0' to '1' only 3nS before the clock rising edge, then all the registers will see a '1' when they are clocked.  If the signal inc changes from '0' to '1' only 1.5nS before the clock rising edge, then some of the registers will see a '1' when they are clocked, because the propagation delay from inc package pin to register input is nice and short.  Some of the registers will see a '0' when they are clocked, because the propagation delay from inc package pin to register input is longer."

you were talking about how an async input can erratic functioning of the circuit. I read about propagation delay here possibly I misuderstood it.

If the data input to a register is changing state at the same time the register clock (active) edge is occurring, the state of the register is uncertain.  In order to guarantee the reliable operation of a clocked register

• The input must be valid and stable before the register's clock edge -- this is called (minimum) setup time
• The input must remain valid and stable after the register's clock edge -- this is called (minimum) hold time

Excellent explanation here Bob regarding the setup and hold time I wasn't aware of the importance of considering these during design with async inputs.

Please consider what you would be modeling.  Would you be modeling logic function (if yes, then use a logic simulator) or would you be modeling failure rate (if yes, then use an analogue circuit simulator)?

By analogue circuit simulator are you talking about SPICE?

What are the frequencies of the external input and the internal (FPGA) measurement system clock?  If the external input frequency is less than 1/2 the measurement clock frequency (with pulse widths which are wider than the measurement clock period), the two threads you linked in your last post describe with considerable detail how to reliably perform edge detection with asynchronous inputs.  If you can detect edges, you can

• count input edges over a number of measurement clock cycles
• count measurement clock cycles between input edges

Yes my asyc input is less than half the measurement system clock.

So I would need to synchonize the async input to the high frequency system clock.

1. Is this done by testing the input at every rising edge of the system clock and incase I find that the value of the input has changed I would consider if either as a positive or negative edge?

2. Apart from synchronizing the external clock to the system clock is there any other approach to design a async input system?

3. Regarding setup and hold time, If I design a system with no async inputs, won't the setup and hold times still be violated by propogation delays between long routed traces or multiple gate units.

Sorry I still don't understand how a system void of async inputs still would be free of these?

Regards

---