Please Log In for full access to the web site.
Note that this link will take you to an external site (https://shimmer.mit.edu) to authenticate, and then you will be redirected back to this page.
In modern computers, we represent data digitally because doing so provides more resistance to noise than analog representations do. However it doesn't mean errors don't occur, and often times when two devices communicate digitally they will implement some form of error-checking. This lets each device determine if the data it recieved is invalid, if so, either discard it or ask it to be retransmitted. Depending on the method, some forms of error-checking can also serve as error-correction - where the error is not only detected, but can also be fixed.
One of the simplest error-checking techniques is the addition of a parity bit with a message.
Ahead of time, the transmitting and receiving parties will have agreed to use either even or odd parity in thier messages. This means both devices expect each message to have either an even or odd number of 1's, depending on their choice of even or odd parity. To comply with this, each devices adds a 'parity bit' to the end of their message. This parity bit is set to 0 or 1 in order to match the even/odd parity agreement made earlier. Here's some examples:
- If both devices agree to use even parity, and one wants to send the data
1111001, it will set the parity bit to1to have an even number of 1's in the message. The resulting message will be11110011. - If both devices agree to use odd parity, and one wants to send the data
1100001, it will set the parity bit to0to have an odd number of 1's in the message. The resulting message will be11000010.
You'll write logic to check the parity of these messages by completing the parity_checker module below with strictly combinational logic. The module outputs a single bit parity_out, which is 1 if the 8-bit input data_in has even parity, and 0 if it has odd parity.
Note this same function could be used to both generate and check the parity bit of a message.
This is great! However, there's a bunch of protocols that implement parity-checking, and they use messages of a variety of widths. To make our module more portable, let's refactor it to accept an input of an arbitrary width. Refactor parity_checker below so that it has a parameter WIDTH that dictates how large the the input (data_in) port is. Have it default to a width of 8 bits. parity_out should still just be one bit, regardless of the size of the input.
With error-checking out of the way, let's think about how we'd actually transmit our parity-including data. As we'll see in lab02 with the PS/2 keyboard, some interfaces work by sending all the bits in a byte, one at a time, across a single wire. As a result, it'd be super useful to have a module that does this for us, which we'll write below.
When signalled to do so by the input trigger_in going high, this module will write each bit of an input message msg_in out to the output line data_out, starting with the msb and ending with the lsb. It will hold the value of each bit for two clock cycles. While it's transmitting, the module should set the output status_out to be one. When it's not transmitting, the module should set status_out to be zero. The module should be parametrizable with a parameter MESSAGE_WIDTH that should have a default value of 8.
You'll need to write and simulate this module locally - doing so in catsoop will be a nightmare. We can only show you the output of $display statements in simulation, which is a nightmarish way to debug this. You'll want to simulate with iVerilog using the testbench we've provided, and then use a waveform viewer to visualize the output. Getting familiar with this is super handy for making sequential modules, and will pay dividends for future labs and the final project :)
We also have some example output below showing what your module should produce. We used our testbench (with a tweak or two) to produce these simulation outputs, and we've also provided the .vcd files if you'd like to load them into GTKWave for comparision.
msg_in = 16'hBEEF. The corresponding .vcd file is here..