0

I have the code for LFSR and getting wrong results, the first 8 bits should be 01110010 but i'm getting 0101111001.

I'm talking about Galois LSFR: en.wikipedia.org/wiki/Linear-feedback_shift_register

Can anyone see what the problem is with this code?

def lfsr(seed, taps):
  for i in range(10):
      nxt = sum([ seed[x] for x in taps]) % 2
      yield nxt
      seed = ([nxt] + seed)[:max(taps)+1]



for x in lfsr([0,0,1,1,1,0,0,1],[6,5,1]) :
  print x
neX
  • 35
  • 8
  • 4
    Care to explain what LFSR means? Also, this question is somewhat close to one of the suspension criteria as it is essentially asks "why isn't this code working?" – J0HN Oct 10 '16 at 17:05
  • LFSR: https://en.wikipedia.org/wiki/Linear-feedback_shift_register and what do you mean? You can't ask about bugs? – neX Oct 10 '16 at 17:19
  • 2
    That link should go into the question body (I believe you don't expect anyone to know every possible acronym, right?). As of the second part, I mean that this question essentially means "please debug my code for me", and such kind of questions are discouraged on StackOverflow, as they usualy provide no long-term benefit to community - others unlikely will have the exact same code. – J0HN Oct 10 '16 at 18:12
  • 2
    Asking for help is fine, but it's good form to demonstrate some effort trying to understand the problem. Why are you expecting 01110010, and where do you get 11110111? Your code produces 0101111001, which doesn't look like either. – Yann Vernier Oct 10 '16 at 19:18
  • Yes I meant 0101111001, edited now. I am excepting 01110010 because that should be the correct answer if you follow Galois LSFR rules. – neX Oct 10 '16 at 19:20
  • 1
    @neX See point 1 in http://stackoverflow.com/help/on-topic *"Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself."* If those are met, then asking about a bug is fine. – zvone Oct 10 '16 at 19:22
  • Alright I get it now, my bad guys @YannVernier and zvone . I will edit my post when I come home. – neX Oct 10 '16 at 19:27

1 Answers1

3

My answer to the question posted, "Can anyone see what the problem is with this code?", is no. The code is operational, implementing an LFSR (of the type frequently used to do pseudorandom signals in hardware, and the basis for popular CRC functions). I'm left to guess at why you think it isn't.

An LFSR of this type can be visualised as a shift register with taps:

pos   0 1 2 3 4 5 6 7
reg   0 0 1 1 1 0 0 1
    ^-  +       + +

Each iteration, one value is calculated from the taps and inserted on one end, shifting the other values. In this case, the new bit becomes LSB. So let's run this LFSR a few cycles:

taps    +       + +
pos   0 1 2 3 4 5 6 7
reg   0 0 1 1 1 0 0 1
c1    0 0 0 1 1 1 0 0
c2    1 0 0 0 1 1 1 0
c3    0 1 0 0 0 1 1 1
c4    1 0 1 0 0 0 1 1
c5    1 1 0 1 0 0 0 1
c6    1 1 1 0 1 0 0 0
c7    1 1 1 1 0 1 0 0
c8    0 1 1 1 1 0 1 0

Note that we read the output bits yielded in column 0, from c1 down. Incidentally, position 7 doesn't need to exist, because there are no taps that far back; the slice in the code removes such columns.

I've managed to reproduce the value you say you're getting by reversing the inputs and output of eight cycles. Can you explain how you arrive at the value you say it should be?

One way I can imagine arriving at a similar value is by shifting the other way and observing the shift register's state after one cycle. This requires maintaining its width past active taps (not unusual in CRC use).

taps    +       + +  -v
pos   0 1 2 3 4 5 6 7
reg   0 0 1 1 1 0 0 1
c1    0 1 1 1 0 0 1 0
c2    1 1 1 0 0 1 0 0
c3    1 1 0 0 1 0 0 0
c4    1 0 0 1 0 0 0 1

But even so the output is 0001010111 (this time read in column 7).

Yann Vernier
  • 15,414
  • 2
  • 28
  • 26
  • Checked again and i'm getting 01011110 which is wrong. – neX Oct 11 '16 at 12:38
  • Okay, putting any further thought on this thing on hold until you explain your expectation. The code runs, I've demonstrated what it does, you say it's wrong. Demonstrate what makes your expectation correct. – Yann Vernier Oct 11 '16 at 15:14
  • I stink at stopping. Turns out a Galois LFSR operates differently, putting the XORs inline, thus affecting more than the newly shifted bit (in fact, not necessarily affecting it in the first place). And that should be enough to tell you what you need to change. Of course, you'd have spotted this if you made an attempt to explain your expectation. – Yann Vernier Oct 11 '16 at 15:27
  • Sorry for the stupid question I had, the problem is that I have never programmed in python before, but someone had this code and I tried it. I won't put up questions like this without explaining again. Tbh I don't fully understand this code, but you have to xor every 6th, 5th and first bit. So i'm not sure what you mean. – neX Oct 11 '16 at 15:55
  • It xors them together. That's what `sum([ seed[x] for x in taps]) % 2` does, recognizing that xor is modulo 2 sum. The Galois variant does the operation the other way; take the about to be rotated off bit and xor it into each of the marked places. Notably this means the length past the taps matters, so the slice should be based on `len(seed)`, not `max(taps)`. – Yann Vernier Oct 12 '16 at 10:03
  • seed = ([nxt] + seed)[:len(seed)+1] gives the same answer. – neX Oct 12 '16 at 10:42
  • never mind, I under stood what you meant now and it works. Thanks! – neX Oct 12 '16 at 19:51