New Contributor
Super ContributorYour code is missing what should happen if cnt_en is 0, so I'm guessing a latch is getting added in to your design which could be causing issues. Using subtraction is not the cause here. It might just be the way the design gets optimized/implemented when you use subtraction vs. when you don't. It's more important to follow the correct usage of secondary control signals when inferring a register/counter. You probably want to just get rid of the cnt_en signal entirely, add a condition check and action for when cnt_en = 0, or turn cnt_en into a proper clock enable signal, which should be checked first, before checking sclr.
Check the templates available in the Quartus text editor to see if any of the inferred counter templates could help you out.
New ContributorHi sstrell,
Well, if cnt_en is 0 then the only thing that would happen is q would retain its value. I guess I could hold the value in another register and retain the value in an else statement. Although that seems redundant, I could see how that could cause an issue. Also, I'm not seeing any latches inferred in the compilation report.
I'm remaking this lpm counter ip in verilog for a company redesign. The cnt_en is submissive to sload and sclr in the original lpm counter ip, and it's not a clock enable (clock enable is a separate possible pin). This counter must work in the same manner as the intel lpm counter.
I'm unsure of where to find the code for the lpm counter design. The original design our company used involved .bdf ip's, and on further inspection of the design file I'm given a module name called but not a reference to the actual design file for the lpm counter. Do you know where I could find the module that is referenced?
I will try running the TimeQuest Timing Analyzer to see if that may fix any issues.
I also will attach a file called mod_Counter.v, and in this file I tried to create a parameterized counter module that will fulfill the redesign for an up+mod counter and a down counter. If the input parameter "updown" = 0 then it generates the up+mod counter. This part of my code works exactly as it should, and the code is similar to the incorrect down counter.
Thank you,
Nick
