lpm_counter bug?

Question

Hi,I'm using Quartus 4.1 Web Edition to program a MAX7000S CPLD.I'm using an lpm_counter as a programmable divider with data[] and sloadinputs, and cout output.  I'm not using the q[] outputs.  Originally, Iconnected cout directly back to sload, but I had intermittent problems.  Irouted cout to an I/O so I could look at it on the 'scope, and it wasoscillating at very high frequency.  To fix this, I had to put a DFF betweenthe cout and the sload.  This works, but now I need two dividers, and Ican't spare another DFF.  Is there another way to do it?

John_H · Accepted Answer

I don't see the behavior of the cout and the sload documented.

I would expect your tools would report a race condition if the cout IS dependent on the sload. But, assume for the moment the sload affects the cout such that an sload with a data[] value of all ones would force a cout even if the original count was less.

To get around the problem, tie sload to "the q[] value of all ones" to eliminate the cout dependence on sload.

between

Peter Sommerfeld · Answer

Hi Andrew,There was a problem with Q II 4.1 which didn't synthesize lpm_countercorrectly, but not when targetting this device. Still, you might wantto check it out:-- PeteAndrew Holme wrote:

Andrew Holme · Answer

Hi Peter,Thanks, I came across that article myself.  I didn't think it appliedbecause the MAX7000S isn't listed - as you point out, and also I'm not usingsynchronous clear or asynchronous set.  It does sound spookily similarthough.  Perhaps I should try it anyway...

Andrew Holme · Answer

[snip]I should've mentioned -1. I'm using the lpm_counter as a down counter.2. I think (fairly sure, but not 100%) the problem goes away if you add aclock enable input - this forces it to use a different template orsomething.

lpm_counter bug?

Join the Discussion

Didn't find your answer?