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: 
1,602 Views
Registered: ‎12-28-2018

Unable to properly read an 8-bit counter output

Jump to solution

Hi, I am using Xilinx ISE 14.7 on a XC3S500E Spartan FPGA and I am facing a problem with a 8-bit counter.

I have synthesized a simple VHDL 8 bit counter fed every 1us, and I am reading the counter output just to test my code and my hardware:

  • the FPGA running clock frequency is 100MHz
  • a register counts the clock edges; when it reaches the 1us count, it sets a flag that drives the up counter
    • please see the attached periodic_pulse_generator.vhd file
  • the up counter is latched by the main VHDL module that then computes a word in the form [cnt_1us_vector_act; CRC_of_cnt_1us_vector_act] and gives the resulting value to a DSP for reading
  • from the DSP I can read continuously the counter output (and its CRC), so I would expect to read a counting up sequence 0, 1, 2, ...
  • I see that the CRC is always correct for every reading, so the communication between the FPGA and the DSP is OK
  • but randomly the cnt_1us_vector_act value gives an incorrect value
    • if I set the main VHDL module to latch the counter vaues at the very beginning of the read, I have sometimes an incorrect value of 0x00 or 0xFF
    • if I set the main module to just output the counter values with no latch at the beginning of the read, I see the typical counter glitch errors when many bits switch from 1 to 0 e.g. when the counts rolls from 0111 to 1000, I read 1111
  • I tried swapping the position of the CRC and the count value, but the error is the same, so it is not a problem in the reading or in the hardware, it seems that the incorrect value comes for the FPGA
  • I already tried reducing the FPGA main clock frequency to 50MHz but the problem is the same
  • I tried widening the read timing from the DSP (anyway the CRC is always correct so the reading is fine); if I set a fixed pattern on the output I always read the correct value, so it seems the read interface is definitely OK
  • I have set a simple constraint for the main clock
    • TIMESPEC TS_CLK = PERIOD "CLK" 50 MHz HIGH 50%;
  • I derive the FPGA clock from a DCM which doubles the clock, and I have set the constraint for it
    • NET "clk_100" TNM_NET = clk_100;
  • the compilation gives no timing errors
  • the design seems to me fully synchronous but despite all my efforts, the glitch still appears
  • what am I missing?

Many thanks for your help!

Best regards,

Michele Sponchiado

0 Kudos
1 Solution

Accepted Solutions
1,466 Views
Registered: ‎12-28-2018

Re: Unable to properly read an 8-bit counter output

Jump to solution

Hi, I found the issue and obviously it wasn't on the FPGA nor in its programming...

The fault was in the test code on the DSP:

  • the test was (my fault!) put after the DSP interrupts were enabled
  • the test was using a static structure variable
  • and the test was (may fault again!) called from the interrupt too
  • so when called from the interrupt it was using the same variable used in the main loop and this was generating the random errors

This explains why the fault was periodic too: the counter I was testing generates the DSP interrupt, so periodically the readings were corrupted by the interrupt call :(

So now I have to check the original problem I was investigating (erroneous random 32-bit counter read) but I have no more a reproducible test case.

Many thanks for your help!

Michele

View solution in original post

8 Replies
Teacher drjohnsmith
Teacher
1,587 Views
Registered: ‎07-09-2009

Re: Unable to properly read an 8-bit counter output

Jump to solution
You seem to have very very very complicated code for such a problem outlined

Is this on purpose , or are you up for a simpler answer.
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
1,580 Views
Registered: ‎12-28-2018

Re: Unable to properly read an 8-bit counter output

Jump to solution

Hi, Mr. drjohnsmith!

The attached code is a module part of a larger project, and is derived from examples from the book "FPGA prototyping by VHDL examples" by Pong P. Chu :

The whole project is already "up and running" but after some tests, I noticed some random glitches on the reading from FPGA internal counters the like of the one that's the object of the post.

So, after some digging, I got to the point where the glitch comes just from the sampling of the counter itself.

It seems that the time needed for the up counter to stabilize its outputs takes longer than the main clock, so when I transfer the counter output on the main clock edges, the counter is still in an unstable state.

 

0 Kudos
Teacher hgleamon1
Teacher
1,530 Views
Registered: ‎11-14-2011

Re: Unable to properly read an 8-bit counter output

Jump to solution

Have you simulated this design? Can you see or recreate the behaviour in simulation?

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
1,521 Views
Registered: ‎12-28-2018

Re: Unable to properly read an 8-bit counter output

Jump to solution

Hi, Mr. hgleamon1!

Thanks for your reply!

Yes, I have already simulated both the whole system and the counter in details, but I see no problems from the simulator output, the counter readings are always OK.

I have done further tests and I noticed a weird thing:

  • when the problem arises:
    • the previous good reading for the counter has always a value of 0x46 or 0xB6 (!)
    • the bad reading has always a value of 0x00 or 0xFF
    • the CRC is always OK
    • the next good reading is three counts further, e.g. from 0xB6 to 0xB9, while normally I can sample the counts with a maximum delay of 1 count between the samples...

Many thanks for your help

Michele

 

0 Kudos
Teacher drjohnsmith
Teacher
1,512 Views
Registered: ‎07-09-2009

Re: Unable to properly read an 8-bit counter output

Jump to solution

Ok, so if your happy with the style,  

Your problem is cross clock domain clocking.

 

The counter is on one clock, your sampling on another.

This wont show up in simulation of the HDL as simulation assumes zero / one delta delays,

The two ways to go about this are, 

    CDC techniques, ( clock domain crossing ) 

    timing constraints,  ( what do you have for the design )

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
1,511 Views
Registered: ‎12-28-2018

Re: Unable to properly read an 8-bit counter output

Jump to solution

I tried removing all the modules from the project except the bus interface and the test counter, and the test now works  fine, no errors...

Now I plan to restore the modules, one by one.

Michele

0 Kudos
1,499 Views
Registered: ‎12-28-2018

Re: Unable to properly read an 8-bit counter output

Jump to solution

Hi, Mr. drjohnsmith!

Many thanks for your help!

I am using the same clock in the whole project, all the synchronous updates are done on the same clock for all the modules, so I think this should be not a cross domain clocking problem, but I will surely give it a double check.

I tried to remove all the modules except the bus interface, the DCM and the test counter and it works fine, so now I am restoring the various modules.

Best regards

Michele

1,467 Views
Registered: ‎12-28-2018

Re: Unable to properly read an 8-bit counter output

Jump to solution

Hi, I found the issue and obviously it wasn't on the FPGA nor in its programming...

The fault was in the test code on the DSP:

  • the test was (my fault!) put after the DSP interrupts were enabled
  • the test was using a static structure variable
  • and the test was (may fault again!) called from the interrupt too
  • so when called from the interrupt it was using the same variable used in the main loop and this was generating the random errors

This explains why the fault was periodic too: the counter I was testing generates the DSP interrupt, so periodically the readings were corrupted by the interrupt call :(

So now I have to check the original problem I was investigating (erroneous random 32-bit counter read) but I have no more a reproducible test case.

Many thanks for your help!

Michele

View solution in original post