Talk:Shift register

Clarification request

Under 'Destructive readout' we see: "The data string is presented at 'Data In', and is shifted right one stage each time 'Data Advance' is brought high." What does "brought high" mean here? Do we need a link to another article? Thanks -- 69.138.209.185 (talk) 03:37, 3 March 2013 (UTC)

It means that is set to a logically 'one' i.e. 'true'. I added a link. ►Tennis Dynamite◄ 13:35, 6 June 2013 (UTC)

Serial to Parallel Operation

I added a brief paragraph describing how the serial-to-parallel operation works. OldTimeNESter (talk) 18:28, 26 March 2015 (UTC)

Serial-in, parallel-out individual flip-flop frequency

Under 'Serial-in, parallel-out (SIPO)' we see: "The initial flip-flop operates at the given clock frequency. Each subsequent flip-flop halves the frequency of its predecessor, which doubles its duty cycle.". Is it really true? To me it seems that each flip-flop gets the value on input after n clock cycles where n is its position in the chain. If it is really true, could you please elaborate a bit more? — Preceding unsigned comment added by 109.81.211.214 (talk) 06:08, 15 August 2015 (UTC)

Destructive read-out example?

Edit 2017-12-21 The updates by the anon user 142.68.133.108 would seem to indicate that "method 1" (below) is the one being used. If this is so and assuming the unlabeled table at right is the register values, those still need correction after the 5th value.

Original 2017-10-17 I cannot seem to get the same result as indicated, so either the example is "wrong" or I'm not "getting it", which could very well be true but might in turn indicate that the procedure needs to be clarified. I tried 2 methods.

input of 1 0 1 1 0 0 0 0

Method 1

R 0000
I 1000+0 (bit shifted off)
-BitXor-
R 1000
I 0100+0 (shift right of previous I plus next input bit to the left)
-BitXor-
R 1100
I 1010+0
-BitXor-
R 0110
I 1101+0
-BitXor-
R 1011 <-- so far, so good. accident?
I 0110+1
-BitXor-
R 1101 <-- not 0101 as in table
I 0011+0
-BitXor-
R 1110
I 0001+1
-BitXor-
R 1111
I 0000+1
-BitXor-
R 1111

so, output would be 0000 1011. If flush is another 4 cycles of 0000 (as it takes 4 cycles to pop all values off of I):

R 1111
I 0000+0
-BitXor-
R 1111
I 0000+0
-BitXor-
R 1111
I 0000+0
-BitXor-
R 1111
I 0000+0

output 0000 This would correspond with the stated output of 1011 0000, and you'd always get an output corresponding to your ordered input. But you wouldn't get the indicated (0000) register state.

Method 2 If instead the input is a single bit which gets XORd with the left-most register, and each bit is the XOR with the bit to the left...

R 0 000
I 1(000+0) (next input bit with the rest of R shifted right)
-BitXor-
R 1 000
I 0(100+0)
-BitXor-
R 1 100
I 1(110+0)
-BitXor-
R 0 010 <--different from table from this point forward
I 1(001+0)
-BitXor-
R 1 011
I 0(101+1)
-BitXor-
R 1 110
I 0(111+0)
-BitXor-
R 1 001
I 0(100+1)
-BitXor-
R 1 101
I 0(110+1)
-BitXor-
R 1 011 <- coincidentally 1011 value, which is the same as first input bits and the last 4 output bits

the "overflow" shift off bit output was 0000 1011

If flush is supposed to be accomplished with another 0000 4 bits

R 1 011
I 0(101+1)
-BitXor-
R 1 110
I 0(111+0)
-BitXor-
R 1 001
I 0(100+1)
-BitXor-
R 1 101
I 0(110+1)
-BitXor-
R 1 011 <-- I think we've seen this before

overflow output 1011, so total output 1011 1011

So, wrong output (not 1011 0000), wrong final register state (1011 instead of 0000) Pagelm (talk) 18:53, 17 October 2017 (UTC) Pagelm (talk) 21:10, 21 December 2017 (UTC)