UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Adventurer
Adventurer
357 Views
Registered: ‎01-05-2017

Parallel asyncronous counters - crosstalk problem

Hello Everyone,

I' m working on a parallel asyncronous pulse signal counter design on a Spartan 3AN FPGA board (this one) and having kind of a crosstalk (?) problem.

The issue is, I already have a design for this purpose and used it on a Spartan 3A FPGA board succesfully. Now, I have modified it for 4 counters and would like to use on the board mentioned first. However, when connecting even 2 sources, both counts start oscillating. Since I know the design is working succesfully on another board, I don' t have doubt related to the design. Only difference between two applications are the range of counts. Currently I want to use it for MHz region counts but previously I used it for 100k (at most, usually around 10k) region counts.

So does anyone have an idea if I can solve this issue by modifying the design in some way? 

Is this problem related to the FPGA board I' m usign right now or because of the range of the counts?

Any idea is appreciated.

Thanks in advance...

0 Kudos
7 Replies
Scholar markcurry
Scholar
304 Views
Registered: ‎09-16-2009

Re: Parallel asyncronous counters - crosstalk problem

Can you describe more by what you mean with the term "parallel asynchronous counters".  My mind wanders to many different ways of interpreting what this means.

Do you have multiple counters operating on different asynchronous clocks?  Or does the "asynchronous" adjective apply to what is being measured? 

More details, perhaps a little code would help us help you.

Regards,

Mark

0 Kudos
Adventurer
Adventurer
285 Views
Registered: ‎01-05-2017

Re: Parallel asyncronous counters - crosstalk problem

Hi @markcurry 

Complete design has many submodules but here I attached one of the counter modules which may give some idea. 

I mean by "parallel asynchronous counters", there are 4 asyn. pulse counters and they work independently with the same clock source (100MHz). Under control of a timer unit, they perform counting and then transfer data to another module for temporary storage. Then counters reset theirselves. 

For current case, I want to count MHz region frequency in contrast to the first application (kHz region was enough).

So I' m thinking that maybe current FPGA board is not well suited for counting upto MHz frequencies but it will be ok for lower frequencies? I didn't have chance to check this. I need another signal source which I don't have right now.

Or as I stated in the title, I'm thingk about a possibility that GPIO ports are talking to each other and I don' t know if there is a method to resolve this issue??

Hope it is clearer!

Thanks in advance

0 Kudos
Explorer
Explorer
270 Views
Registered: ‎06-25-2014

Re: Parallel asyncronous counters - crosstalk problem

I'm confused, when you say the count is oscillating are you talking about a signal integrity issue on the FPGA IO or that the counter is not behaving (e.g. incrementing) the way you expect now that you have moved from kHz to Mhz? 

 

If it's integrity then you have PCB layout/termination issues.

If its the later, I assume you have added timing constraints? 

 

 

 

 

0 Kudos
Scholar markcurry
Scholar
255 Views
Registered: ‎09-16-2009

Re: Parallel asyncronous counters - crosstalk problem

It's still not clear to me exactly what is "asynchronous" in your description or example.

With today's FPGA using proper synchronous techniques, you should be able to code logic (and counters) into the multiple hundreds of MHz, without any trouble at all - 100-200 MHz should be easy.

The key is proper synchronous techiques, and I'm thinking this is what is causing some of your troubles.  Have you applied static timining contraints to your design, and does the design pass timing?  Are the inputs to your module "Pulse_Counter_1": PC_Pulse, Pc__period_Over_Flag properly synchrononized to the input clock "clk"?  Where are those inputs sourced from (External to the FPGA, or from other signal within the FPGA?)

I'm a verilog designer, but looking briefly at your VHDL logic, it doesn't appeart to be properly coded to infer FFs for much of your logic - the sensitivity list looks wrong to me:

	Edge_Detector : process (s_clk, s_RESET, s_OPERATION)
and
	Pulse_counting : process(s_clk, s_Pulse, s_Period_Over_Flag, s_RESET, s_OPERATION)

But one of the VHDL folks will need to confirm this.

Regards,

Mark

0 Kudos
Adventurer
Adventurer
234 Views
Registered: ‎01-05-2017

Re: Parallel asyncronous counters - crosstalk problem

@markcurry 

This system was first designed for kind of a random pulse signals counting purposes. So since the input is not a continuous signal with a definite frequency, I understood that this type of a counter is called asyncronous. Also there are several of this counters in my design and they work independently. Maybe "asyncronous" is not the correct word. I' ll search for "syncronous counters" to udnerstand the difference. Thank you for taking my interest tothis point! 

Timing issues ... I didn' t get any warning or error about timing. Hoewever, when I want to increase the number of counters, I got some errors including timing don't remember what they were. Overally it was related to the board resources. 

 

@andrewlan 

By means of "oscillating" I need to count let' s say 5 MHz and I clearly observe a value very close to 5 MHz. However, when I connect even a second input both links shows completely different values say 7 MHz, 2 MHz ... which looks to me kind of oscillation.

Regarding to timing constaraints ... I' m using a clock generator to convert 12 MHz clock source to 100 MHz for main clock to the system. There is no other adjustment. Can you give some more detail?

 

May I ask one more additional question: The previous application was runnig on a breadboardable type FPGA board  Can there be any effect due to the compact, size shorter connections or briefly PCB design of the board? 

 

Thanks in advance 

 

0 Kudos
Explorer
Explorer
220 Views
Registered: ‎06-25-2014

Re: Parallel asyncronous counters - crosstalk problem

Have you added a ucf file to your Spartan 3 ISE design with at least a clock constraint on your 12Mhz input clock?

 

For example:

 

NET "clk_12mhz" TNM_NET = clk_12mhz

TIMESPEC TS_clk_12mhz = PERIOD "clk_12mhz" 83 ns HIGH 50%

 

There is a timing constraints guide covering this large subject where you constrain clocks, external IO requirements WRT setup/hold.. etc etc..

 

From your file I am assuming PC_Pulse and PC_Period_Over_Flag are async to the 100Mhz and therefore should be double registered (along with any other signals that are async) before being used by your edge det/counter logic to mitigate risk of metastability issues. From your info I think you are counting PC_Pulse rising edges over a  PC_Period_Over_Flag period of 1 second?

 

Assuming you have simulated this, I would use chipscope to see what is actually going on. For example is the distance between detected rising edges correct? (if not perhaps the pulse is noisy and you are detecting false edges) Is PC_Period_Over_Flag the correct period? etc etc..

 

Your vhdl code looks ok, the sensitivity list is fine, but you only needed to add the clock to it since your code is all synchronous to the clock. (e.g. if you had coded to use an async reset then you would then add the reset signal to your sens list)

 

I would also change this code:

if (s_Pulse = '1') then

                v_Count := v_Count + 1 ;

else

                v_Count := v_Count;

end if ;

 

To:

 

if (s_Pulse = '1') then

       v_Count := v_Count + 1 ;

end if ;

0 Kudos
Adventurer
Adventurer
208 Views
Registered: ‎01-05-2017

Re: Parallel asyncronous counters - crosstalk problem

Timing constraint is mainly from the manufacturer example designs. You can have a look at it in the attached file. 

"PC_Pulse" is a single square pulse as an input in random nature and  "PC_Period_Over_Flag" is the indicator of a period of time is over.

Pulse counters are designed for rising edges and before that there is an edge detector to identify the real and fake signals which is a suggested practice I read on the web. 

I didn't perform a precise test to identify the precision of 1 sec time period. Maybe a single clock cycle (10ns) difference possible because I'm counting the clock signal which is an internal source not an external one to identify 1 second.

I performed the simulation partly, not the complete design and I didn' t observe any problem. Chipscope... I don' t have much experience on it but I guess I need a JTAG cable which I don't have right now.

Syncronous clock... So it looks I'm wrong by calling my counters as async. counters as you also stated that it is syncronous to the main clock. This looks somehow relative issue but it's ok. 

Suggested modification... This was the design I did first. then I observe people suggest not to leave an empty possibility for such cases instead cover all possibilities. I mean

if this happen do this

and

if it doesn' t happen do this

I prefer your version since it decreases the number of used resources but I guess current version is a better practice. 

Reset signal... I spent relatively long time for this issue and could not solve it. Well reset signal comes from a GUI on the computer and out of start and stop signal a third signal didn't work properly. So I left it for another free tiem to solve. I can just re-upload the design instead reset :)

Eventually, could you please open double registering the PC_pulse and Period_over signals little bit more. Because of edge detector I think I double register the pulse signals. You mean I should do the same for period over signal?

Thank you 

0 Kudos