Lab #6: Implementation of the Logic of a Simple Modem

Beckie Chan

Michael Chen

Section #3

Group: #14

 

The Sender

Prelab:

The State Diagram

            We began the lab by creating a state diagram for the sender.  We included what inputs are needed to move on to another state and also what outputs each state produced.

The SAS states involved the loading and handshaking for the 4 encrypt bits.  The SBS states took care of loading and handshaking for the lower 4 bits of data.  SCS states loaded the upper 4 bits of data into shift registers and also completed handshaking.  Next, the SDS states encrypted the data.  Data was encrypted by rotating N data bits to the right, where N is the number specified by "encrypt."  In these states a counter was set to zero and was incremented each time a rotation occurred.  We use this counter to compare with the encrypt value.  Once the counter equaled the encrypt, rotation stops.  The system then moves onto the SES states.  The last bit of the lower shift register is shifted into a D flip flop and then the upper and lower registers rotate right by one.  Next, in SES2 and SES3 handshaking is used to send the bit.  This continues for 8 clock cycles in order to send all the bits. 

After all eight bits have been sent, the system goes to SBS0 to accept new lower 4 bits.

 

Control Signals

            We also specified the control signals needed for our devices in each state in our prelab. 

            We used the following table to find the control signals for the shift registers:

S1	S0	register function
0	0	Hold
1	0	shift left
0	1	shift right
1	1	Load

 

The shift register control signals for the encrypt, lower 4 bits, and upper 4 bits were set to load in states SAS1, SBS1, and SCS1.  The lower and upper 4 bit registers are set to rotate right at states SDS2 and SES1.  Theoretically, these control signals at these states should be sufficient to complete the load and rotation.  However, we encountered problems when we actually ran the system.  This is further discussed in the "Observations" section.

            Other signals: Xin_Ack, Send_Req, Cnt1Clr, Cnt1Add, Cnt2Clr, Cnt2Add, Dffclk, CntSel, ShftClk, Erdy are also set based on the state diagram.  Their exact values can be viewed in the sender.tdf file.

Design/Implementation

 

Loading Input

            The design began with the three shift registers for the encrypt, upper, and lower bits.  These three registers all share the same input: X3-X0.  First the user enters the encrypt value.  Once this occurs, the E_Ready bit is turned on.  Next the lower 4 bits are loaded into the register, and finally, during the next handshake, the upper 4 bits are loaded in.

The least significant bit of the upper register is tied to the SRSI of the lower register, and the least significant bit of the lower register is tied to the SRSI of the upper register.  This setup enables the bits to be rotated for encrypting.  The SLSI inputs were also connected but never used because we decided that the encrypt would rotate the bits right.  We used ShftClk, which is produced by the sendcon, to handle the functions of the shift registers.  This signal, like some of the other signals from sendcon, had to be put through a D flip flop so that it would be stable in the next clock cycle.

            To view the contents of the upper and lower registers, the output of these registers are placed in a mux that has outputs: Send3- Send0.  ViewNibble is the select for the mux.

 

Encrypting

            Two counters are used in the sender.  Counter1 is used for encrypting the bits, while Counter2 is used to send the bits. 

            A two input 3-bit comparator was built to compare the counter and the encrypt value.  This comparator was designed using XOR gates and a NOR gate.  The first bit of the first input is XORed with the first bit of the second input.  The second bit of the first input is XORed with the second bit of the second input, and so on.  The results of the XORs run through a NOR gate to produce our Equal signal.  If the inputs are the same, a 1 is outputted. Otherwise, if the two inputs are different, a 0 comes out. 

This comparator is needed to indicate when to stop rotating the data.  When beginning to encrypt the data, we initialize the counter to 0 and compare this value with encrypt.  If they are not equal, the system will rotate the bits by one to the right and increment count.  This cycle of comparing, rotating, and incrementing continues until the counter equals the encrypt value.  Note that both the encrypt and the counter have four bits, but we only inputted the three least significant bits into the comparator.  We designed the system in this manner because a rotation of eight bits returns the data to its original form.  Therefore, rotating by more than eight is equivalent to rotating by a number less than eight.  For example, rotating by 10 (binary 1010) is equivalent to rotating by 2 (binary 0010).  So only the three least significant bits are needed to compare.

The controls for the rotating were done in the sendcon.  Sendcon sets the UNS1, UNS0, LNS1, LNS0 to rotate the bits in the two data registers in state SDS2.  Once again, ShftClk controlled exactly when the registers would rotate.  To control how many times the data shifted during this state, we ANDed the SDS2 state with an input CT.  We only want the rotation to occur once in SDS2.  ANDing with CT allows this to happen.  CT is an unused bit of the CNT1 counter.   We knew that each time the counter changed we would need to rotate the data.  But since CT varies from 1 to 0, the ShftClk would not give the rising edge needed to trigger the shift every time it counts.  To solve this problem, we doubled the value of the counter.  When we ignored the least significant bit, the counter would still count from 0 to 7; and we were able to use the least significant bit as the CT, giving us the needed rising edge.  This allows the data to be rotated the correct number of times.  Doubling the counter value was accomplished by shifting the counter bits to the left once.

After completing the encryption stage, the data is ready to be sent to the receiver.

 

Sending

To send the data serially bit by bit, we attached a D flip flop to the lower 4 bit register.  The input to this flip-flop came from the least significant bit of the lower register. 

First, the second counter CNT2 is initialized to 0.  Then at state SES1, the last bit of the lower 4 bit shift register is placed into the D flip-flop, and the counter is incremented by one.  The output of the D flip-flop is R_Data, which is what is sent to the receiver.  The clock for the D flip-flop is called DffClk.  It rises only when in state SES1.  Also at this state, the two data registers rotate right.  This happens so that  the next bit can be sent into the D flip-flop and eventually to the receiver.  The system then moves to SES2, which sets the Send_Req = 1 to tell the receiver that it has data to send.  It will then go to SES3 when Data_Ack = 1 (the receiver acknowledges taking the data).  At SES3, the Send_Req goes down.  This cycle repeats 7 more times to send all eight bits to the receiver.

Once the counter has reached 7, the system goes back to SBS0 to take another lower 4 bits of data.

 

Observations

Encrypting Problems:

After completing the gdf file, we found that the data was not shifting correctly during the encryption stage.  We analyzed our gdf and found that the input to the comparator was incorrect.  The most significant bits of the counter were had been connected to the comparator instead of the least significant bits.  The most significant bits are not supposed to be connected because an eight bit number can really only have eight different rotations.  Therefore, we can remove the most significant bits of the counter and replace it with the least significant bits. 

Another problem with the encrypting was caused by our design of the counters.  In our original design, we used the same counter to encrypt the bits and to send the bits.  The counter to encrypt the bits needed to be set to zero when it entered a state.  However, to send the bits, the counter had to be set to zero in between states.  When the counter was set to zero in the state SES0, the encrypt process would finish one bit too early.  So, the counter had to be initialized after SES0 but before SES1.  To solve this problem, two counters are used.  The second counter has a D flip-flop before its clear input in order to delay setting it to zero. 

            We also observed that even after modifying the counters, the encryption was still not working correctly.  When designing the encrypt, we had ShftClk = SDS2 and Clk.  This was supposed to make ShftClk rise every time the system went into SDS2 and the Clk rose.  The rise of ShftClk would then cause the registers to rotate.  This, however, did not happen, and we obtained erroneous results after the encrypting stage.  The Clk was not very stable, so we decided to AND SDS2 with the unused bit of the counter, CT.  

 

Register Problems:

            Another major problem we found was that the registers were not loading and shifting in their designated states.  ES1 and ES0, the control signals for the encrypt register, were set to 1, 1 at state SAS1.  However, the encrypt bits were not being loaded.  This problem was solved by extending the 1, 1 of the register from SAS0 to SBS0.  Since the register only loads when the clock rises, we could safely extend the control signals.  A similar process was done to the upper bits and lower bits registers. 

            The same error occurred again when we wanted the registers to rotate.  Just assigning the register control lines to rotate at one state was not effective.  Therefore, we extended the control lines through the other states adjacent to them.  Then, once the clock rose, the control lines were stable and rotation occurred.                      

The Receiver

Prelab:

The State Diagram

            We began the lab by creating a state diagram for the receiver.  In our state diagram, we included what inputs are needed to move on to another state and also what outputs each state produced.

The SAR states controls the receiving of data bits from the sender.  In order to receive each bit, it waits for the send request line to go high.  Then it would shift right the bit on the data line into the shift registers.  Once the data is stored, the Data ACK line would then be set high.  It then waits for the request like to lower, and then it lowers the ACK signal.  It repeats this SAR cycle eight times in order to get all eight bits.  Then the SBR state handles the decrypting process.  To decrypt the data, we rotated left the number of times indicated on the encrypt lines.  In the SCR states, the lower nibble of the data is sent to the user and stays there until the handshaking is complete.  The SDR states sends the upper nibble going through the handshaking process.  Then the receive process starts over again.

            In the states where we had to keep track of how many bits we received or how many times we rotated, we would use the same general counter scheme as we had used earlier in our sender.

 

Control Signals

            We also specified the control signals needed for our devices in each state in our prelab.  We used the same table as the one used in our sender to find the control signals for the shift registers.  The lower and upper 4 bit registers are set to rotate right at states SAR1 and SAR2.  The lower and upper 4 bit registers are set to rotate left for the decrypt at states SBR1 and SAR4.  States SAR1 and SAR4 are included because we realized from the sender part that the control signals are not held long enough before we clocked it.  So we automatically extended the states.

            Other signals: Data_Ack, Y_Req, Cnt1Clr, Cnt1Add, Cnt2Clr, Cnt2Add, CntSel, ShftClk are also set based on the state diagram.  Their exact values can be viewed in the receiver.tdf file or the prelab control line chart.

Design/Implementation

 

Receiving

            The design began with the two shift registers for the upper, and lower bits.  The upper nibble shift register is the only one with a data input line.  This line is tied to the shift right serially in pin.

            Two counters are used in the receiver.  Counter1 is used for decrypting the bits, while Counter2 is used to receive the bits.  A two input 3-bit comparator that was built in the sender, to compare the counter and the encrypt value, was used in the decrypting and receiving.

The Counter2 was cleared in state SAR0.  The counter was incremented whenever it reached state SAR2.  Because this caused the counter to miscount observed in the sender, we used the D flip flop to delay this clear signal for one clock cycle.  The registers are set to shift right, and once the Data request goes high, the clock for the registers will generate a rising edge.  This allows a data bit to be shifted it.  The counter is also incremented in this SAR2 state.  Next the state machine would raise the acknowledge signal, and wait for the request line to drop.  After it drops, the state machine would also lower the acknowledge signal.  The comparator is used to determine if this process was repeated eight times for the eight bits.  After this is done, the state machine waits for the Eready signal from the sender in state SAR4.

The least significant bit of the upper register is tied to the SRSI of the lower register, and the most significant bit of the upper register is tied to the SLSI of the lower register.  The most significant bit of the lower register is tied to the SLSI of the upper register.  This setup enables the bits to be rotated for decrypting.  The SRSI inputs were used for receiving while the SLSI inputs were used for decrypting.  We used ShftClk, which is produced by the recvrcon, to handle the functions of the shift registers.  This signal, like some of the other signals from recvrcon, had to be put through a D flip flop so that it would be stable in the next clock cycle.

 

Decrypting

This comparator is needed to indicate when to stop rotating the data.  When beginning to decrypt the data, we initialize the counter to 0 and compare this value with the encrypt from the sender.  If they are not equal, the system will rotate the bits by one to the left(opposite of the direction we rotated in the sender) and increment count.  This cycle of comparing, rotating, and incrementing continues until the counter equals the encrypt value.  Note that both the decrypt and the counter have four bits, but we only input the three least significant bits into the comparator.  We designed the system in this manner because a rotation of eight bits returns the data to its original form.

The controls for the rotating were done in the recvrcon.  Recvrcon sets the UNS1, UNS0, LNS1, LNS0 to rotate the bits left in the two data registers in state SBR1.  Once again, ShftClk controlled exactly when the registers would rotate.  To control how many times the data shifted during this state, we ANDed the SBR1 state with an input CT.  We only want the rotation to occur once in SBR1.  ANDing with CT generates a rising edge within the SBR1 state.  CT is an unused bit of the CNT1 counter.  This scheme was based on the sender’s encrypting scheme, and since we got the sender to work, we decided that it would be efficient to use the same scheme with the receiver’s decrypt.

 After completing the decryption stage, the data is ready to be output to the user.

 

Outputing

To output the data in parallel four bits at a time, we needed a mux to select whether the upper nibble would be viewed or the lower nibble.  First, the select line for the mux is set to select the lower four bits.  Then at state SCR1, the Y_Req is raised, and we wait for the user to acknowledge the data.  The user raises the Y_Ack line, then we proceed to state SCR2.  We lower the Y_Req in this state and wait for the user to lower their acknowledge.  When the acknowledge is lowered, we go onto state SDR0 where we select the upper four bits to be viewed.  We raise the request in SDR1, and wait for another acknowledge, and we lower the request after we receive an acknowledge signal.  Once the user’s Y_ack is lowered, we go to state SAR0 where another transmission can occur.

 

Observations

Decrypting Problems:

            After testing the receiver quickly we immediately noticed the problems that our decrypter was having was the same as our encrypter so we used the same methods to fix it, namely we extended the length the rotate command was given and extended it into state SAR4 the state right before the rotate state.  So the values would be stable when the clock finally rose.  This promptly solved our decrypt problem.

 

Register Problems:

            Another problem we found was that the registers were not loading and rotating in their designated states.  Just assigning the register control lines to rotate at one state was not effective.  Therefore, we extended the control lines through the other states adjacent to them.  Then, once the clock rose, the control lines were stable and rotation occurred.  This was very similar to the problems occurred in the receiver and we solved it the same way.

 

Control Box Problems:

            One major problem that we kept on encountering was that the control would always jump states with no apparent reason.  We tried many different methods to fix this, we tried inverting the clocks, we modified the method we implemented the reset from being a input that determined the next state, to being tied to the reset line of the state machine.  We found that we liked the simplicity that appeared when we tied the reset line to the state machines directly and we rewrote both controllers to implement this.  But this did not solve our state jumping problem.

            It was frustrating because our sender worked perfectly but our receiver did not.  And both were using the same kind of logic and implemented nearly identically to each other.  Even more frustrating is that separately, both the sender and receiver worked, but together they would not cooperate.  The receiver would always jump from state SAR0 to SDR2.  The idea that did not occur to us was that the sender was getting input from the user which occurred and different times independent of the clock, while the receiver was receiving its inputs from the sender which only generated outputs dependent on the clock.  The inverted clock into the receiver was an attempt to fix this problem, but it did not completely work.  Later the TA suggested that we used D flip flops to make sure the values were steady by the time the state machine had to change, so we added 2 7474 chips which gave us 4 D flip flops, and put the input through the flip flops before it fed into the controller.  This solved our problem effectively and allowed us to get the receiver and sender to work together.