2 - Mini-Project FAQ

2.1 - Do we have to follow the organization shown in the handout?
2.2 - What is the testbench?
2.3 - How long is the CS (Chip Select) pulse asserted "1"?
2.4 - What is RS232 or serial communication?
2.5 - What is the Hyper Terminal?
2.6 - What is the "enable" signal?
2.7 - What is resynchronization?
2.8 - Why do we need to do "resynchronization"?
2.9 - Which bit is sent first?
2.10 - If there is no data to Tx, what is the value of TxD?
2.11 - Which part of the SPART should be tested first?
2.12 - What else can go wrong?
2.13 - How big are the received and transmit buffers?
2.14 - Should we worry about buffer overflowing?
2.15 - How wide are the start, stop bits?
2.16 - How can the logic "0" and "1" be converted to RS232 signals?
2.17 - How wide are the start, stop bits?
2.18 - I was curious what you were indicating when you mentioned that the pulse periods should occur more than once per bit time. Do you recommend that the students implement some oversampling?
2.19 - What setting (#data bits, #stop bits, #parity bits) is required for the miniproject?
2.20 - In the receiver module, we have one big always @ (posedge clk) loop and the RxD changes within that. Isn't that the same as putting a DFF on the RxD...If not how do you do put a DFF on the RxD?
2.21 - I worked on the ltring for our group, and I noticed that design manager doesn't like it when reset is assigned to the sw1 pushbutton pin. When I remove that assignment from the ring ucf file, DM runs the implementation with no errors. It seems to want to assign the reset signal to another specific pin (forgot which one exactly). It's strange because I just modified the given ring .v and .ucf files, and they worked ok for the tutorial design.
2.22 - What to be included in the report?
2.23 - Why do we need to grade their report with the Verilog source code?
2.24 - "modularity" -- is that just that they didn't do the whole SPART in one big verilog source file?
2.25 - "module interface" -- I'm not sure what you're looking for with this one...
2.26 - "resynch" -- that's for synchronizing the incoming Rx line, right?
2.27 - "sampling scheme" -- is that for using enable signals at 16x the baud rate to sample Rx in the middle of each bit?
2.28 - Is it a bad thing to have a block: always @ (posedge SHIFT), where SHIFT is a user-defined signal generated in a different always block?...just wondering if that is a bad use of the language constructs or not.

2.1 - Do we have to follow the organization shown in the handout?
It is not necessary as long as the new organization is modular and easy to divide into many tasks.

2.2 - What is the testbench?
It is a simple finite state machine acting like a processor receiving a character from RxD one at a time and sending it back to the terminal via TxD.

2.3 - How long is the CS (Chip Select) pulse asserted "1"?
Its pulse width is 1-2 "fast" clock cycle.

2.4 - What is RS232 or serial communication?
RS232 is a standard for serial communication over a short distance. The signal is converted to +/- 12 volts for logic "1" and "0" respectively.

2.5 - What is the Hyper Terminal?
It is a program in MS Windows allowing us to connect to a serial port. You can use other terminal emulator programs such as SecureCRT as well.

2.6 - What is the "enable" signal?
It is the divided clock from the clock the divider. It stays high for one master clock cycle and low all the way.

2.7 - What is resynchronization?
It is a simple technique to convert asynchronous input signal to a synchronous one. The input signal (asynchronous) is fed to a D flip-flop and read of from the Q output.

2.8 - Why do we need to do "resynchronization"?
The RxD is an asynchronous signal to the receiver's clock. Therefore, we must resynchronize it for stability of the receiver.

2.9 - Which bit is sent first?
The LSB first.

2.10 - If there is no data to Tx, what is the value of TxD?
TxD always sends "stop bit" when there is no data to transmit.

2.11 - Which part of the SPART should be tested first?
The transmitter should be able to transmit something to the terminal.

2.12 - What else can go wrong?
The phenomenon called "metastability" that may cause the unknown stage of any flip-flop in the circuit.

2.13 - How big are the received and transmit buffers?
An 8-bit buffer is sufficient. Several teams in the past modified this buffer to hold 4 8-bit characters to support burst mode

2.14 - Should we worry about buffer overflowing?
No, because typing is much slower compared to the transmitting/receiving operation.

2.15 - How wide are the start, stop bits?
The start bit is always one baud wide and the stop bit is programmable to be either 1.5 or 2 bauds wide.

2.16 - How can the logic "0" and "1" be converted to RS232 signals?
It is converted by the MAX232 chip on the XSV800 board.

2.17 - How wide are the start, stop bits?
The start bit is always one baud wide and the stop bit is programmable to be either 1.5 or 2 bauds wide.

2.18 - I was curious what you were indicating when you mentioned that the pulse periods should occur more than once per bit time. Do you recommend that the students implement some oversampling?
What I meant is oversampling the RxD so that you can guarantee to receive the correct one.

2.19 - What setting (#data bits, #stop bits, #parity bits) is required for the miniproject?
Check the settings in the HyperTerminal program.

2.20 - In the receiver module, we have one big always @ (posedge clk) loop and the RxD changes within that. Isn't that the same as putting a DFF on the RxD...If not how do you do put a DFF on the RxD?
They are different because you don't know how the synthesis tool (FPGA Express) implements the circuit from that always block. To be safe, a D FF should be explicitly used to resynchronize the RxD signal.

2.21 - I worked on the ltring for our group, and I noticed that design manager doesn't like it when reset is assigned to the sw1 pushbutton pin. When I remove that assignment from the ring ucf file, DM runs the implementation with no errors. It seems to want to assign the reset signal to another specific pin (forgot which one exactly). It's strange because I just modified the given ring .v and .ucf files, and they worked ok for the tutorial design.
That error is from how you write the Verilog code. The synthesis perceives and treats the "reset" signal as a clock. Therefore, DM expects the clock pin to e assigned to "reset" signal as well.

2.22 - What to be included in the report?
Your report should consist of the following:
1. Verilog code for your entire design with clear, useful commenting.
2. An accompanying narrative describing the function of the overall SPART and each of the blocks including the testbench. (maybe mention what Verilog code modules go with each functional block)
3. A record of the experiments conducted including the characters transmitted for a basic test. (include annotated simulation waveforms demonstrating your working top-level system for the required clock frequencies and baud rates)
4. A discussion of problems encountered in the design and solutions employed.

2.23 - Why do we need to grade their report with the Verilog source code?
We're trying to criticize and feedback how they did the miniproject so that they can improve their project.

2.24 - "modularity" -- is that just that they didn't do the whole SPART in one big verilog source file?
You can see whether thier functional blocks makes sense or not. I believe they just followed the diagram.

2.25 - "module interface" -- I'm not sure what you're looking for with this one...
This one deals with the declaration of each module. They should have some kind of convention to start with input or output fisrt but not mixed. The second issue is about moule instantiation. They should use the dot notation. Another one is about naming of the input/output ports whether they are meaningful or not.

2.26 - "resynch" -- that's for synchronizing the incoming Rx line, right?
Yep. They must have an explicit DFF to resynch the RxD.

2.27 - "sampling scheme" -- is that for using enable signals at 16x the baud rate to sample Rx in the middle of each bit?
Right.

2.28 - Is it a bad thing to have a block: always @ (posedge SHIFT), where SHIFT is a user-defined signal generated in a different always block?...just wondering if that is a bad use of the language constructs or not.
That means they used something else as a clock signal. This is bad!