--- Quote Start ---
Why is an LFSR going to save you gates? A counter should use the carry-chain, and probably be the optimal size, i.e if you need 2^20 count, then it should only be 20 logic cells. You really can't store that much information with fewer bits, unless I'm missing something. Is there anything else that has a counter running, because resource sharing might be your best bet.
--- Quote End ---
I'm not disputing that N states will take ceil(log2(N)) bits to store. But I've seen it in many references that LFSRs can be implemented much more cheaply than counters by using one flip-flop per bit and one XOR for each tap.
In any case, according to the fitter report, the design with an LFSR produces 82% cell usage, and 90% usage for the counter; if I recall, without either present, it's at about 60% usage. It's not huge, but it might make the difference between the design fitting or not once I have added some more things and done pin constraints.
Ben - Wikipedia is the first reference I looked at, and it's the source of some of my confusion. It says, "The first and last bits are always connected as an input and tap respectively," and it also says that the number of taps must be even for the LFSR to be maximal. Does the last bit count as a tap? If so, how could an LFSR with taps 3,17 be maximal (as a table I'm looking at claims)?
(Later edit: I added xor bit(20) because it makes sense that I should. Unfortunately this results in a period of about 130, which makes less sense.)
Honored Contributor
