Parallel Counter Block Diagram File Problem

[Bobd]

When creating a 4-bit parallel counter block diagram file with shortened sequence (mod 10 decade) using Quartus Prime Lite 18.0 (see attached), have found what seems to be an inconsistent behavior. University program VWF functional simulation of the counter indicates correct operation (e.g. count from 0000 - 1001). When downloading and programming  DE10Lite FPGA board (MAX10 based) with this code using debounced switch input (KEY[0] or KEY[1]), counter does not count in the same sequence (0000 - 0111 and reset or other mod-8 sequence). If the counter is allowed to count its full sequence (0000 - 1111) by removal of NAND gate on clear lines, or if the inputs to the NAND gate are changed to other MOD-numbers (e.g. MOD-12, etc.) with this same input, no error is seen in simulation or in testing with download to hardware. Use of internal clock on this board with divider (50 MHz and MOD 50000000 LPM_count) with MSB as input to provide 1 Hz clock input to this counter in place of the momentary debounced switch provided same results in both cases (e.g. incorrect count of MOD-10, but correct count for MOD-12).

Has anyone had a similar experience? Is it possible that this is a schematic problem based on connections in BDF creation?

Thanks 

[RichardTanSY_Intel]

I don't think it is a schematic problem since the simulation is fine. 

Have you checked whether the design pass timing? 
Try to debug design by using Signal Tap to check whether the waveform is correct. 

[Bobd]

Hello:

Thanks for your reply. I had tried a timing simulation using the University Program VWF simulator and there didn't appear to be a problem. I believe that may use the simulator you mentioned as its tool as well, but perhaps not.  Similar timing and functional simulations and compilations of other mod-number counters using the same feedback (MOD-12 using the 8 & 4 FF outputs, etc.)  produced correct counts and it doesn't appear to be a debounce problem as the input used for the DE10-Lite is a 3.3V Schmitt Trigger type. I found when slightly re-routing the wiring to bring it more directly to the 2's count FF (see below) that the count seemed to be correct on the DE10-Lite board. After that, I could not duplicate the problem again with either schematic. I am wondering if somehow the programming file was corrupted during my earlier tests. In each case, I used the BDF as the top-level and compiled the project, and then used the programming file generated after compilation. Perhaps when saving the project (or if not saving in the interim), something changed? Still a bit of a mystery.

[RichardTanSY_Intel]

I am amazed that re-routing the wiring somehow solved it. Initially suspect that there could be a propagation delay in the circuit.

Regardless, I'm glad that the problem has been solved.

[Bobd]

Thanks for your reply. I, too. was surprised by this result, and am still not sure that this is entirely resolved even though I can't replicate it now. I've sometimes seen some wiring issues with unintentionally connected nets, but I did try deleting segments and re-routing this before posting the original comment and didn't see any change. I will pursue it on other designs. 

I'd agree that a propagation delay issue is the logical answer, but couldn't see it in the simulation. With the reset to 0000 occurring where it did in the faulted circuit (e.g. counter clears when changing from 0111 to 1000 instead of continuing), that would suggest that the counter MSB changed from 0 to 1 happened before the LSB changed from 1 to 0 (and that both were present and stable enough at the time of the clock pulse to enable the clear through the NAND gate connected to the FF clear lines). The AND gate delay for changing the MSB to toggle mode would seem, if present, to  put that change behind the LSB, which is in toggle mode all of the time, and all 4 FF's are clocked in parallel.  I'd also have expected to see similar problems using other FF outputs to the NAND gate to shorten the count sequence for other MOD-number counters (e.g. MOD-12, etc.), and that didn't occur, so it is still somewhat of a mystery. I am wondering if the programming file somehow didn't get updated properly, but aren't those files generated anew each time that the compilation process takes place?

[RichardTanSY_Intel]

Yes, by default, the compiler's assembler module will generate and renew the primary device programming files at the end of the full compilation.

[RichardTanSY_Intel]

Hi, 

We do not receive any response from you to the previous question/reply/answer that I have provided. Please post a response in the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you with your follow-up questions.

Best Regards,

Shyan Yew