Quartus Prime Standard Edition 17.1 - Subtraction Operator Problem

[NicholasNuti]

Hello,

I'm trying to remake the lpm down counter in verilog and I'm having an issue with the subtraction operator. Every time I include the subtraction operator (I've tried using it in many different ways...) it causes "sclr" to make "q" go to 8'd0 in a combinational manner rather than a sequential manner ("q" should go to zero a clock cycle after "sclr" goes high, but "q" goes to 8'd0 immediately when "sclr" is pulled high).

I've included two photos, from a VWF file, of how "sclr" causes "q" to act when there is no subtraction and when subtraction is included. I've also included the basic verilog file for viewing.

• Files:
  • "downcounter without subtraction operator.PNG" exemplifies correct behavior of "q" with respect to "sclr"
  • "downcounter with subtraction operator.PNG" exemplifies incorrect behavior of "q" with respect to "sclr"

I have run into this issue in the past when making an i2c master in verilog.... but I thought the problem was with my code. Now, I've come to the realization that it is truly a problem with Quartus 17.1 unless someone can tell me my basic code is wrong.

Please help!!

Thank you,

Nick

[sstrell]

Your 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.

[NicholasNuti]

Hi 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

[SyafieqS]

In text editor in Quartus, you can get the coding style how to inferred LPM, right click and go to template.

[SyafieqS]

Nicholas,

May I know if there is any update?