07-04-2019 10:17 PM
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...
07-09-2019 04:18 PM
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.
07-10-2019 05:14 AM
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
07-10-2019 06:31 AM
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?
07-10-2019 09:30 AM
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.
07-10-2019 10:40 PM
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.
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
07-11-2019 02:50 AM
Have you added a ucf file to your Spartan 3 ISE design with at least a clock constraint on your 12Mhz input clock?
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 ;
v_Count := v_Count;
end if ;
if (s_Pulse = '1') then
v_Count := v_Count + 1 ;
end if ;
07-11-2019 04:15 AM
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
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?