Download Design Creation Tutorial for a Prototyping System

Printed Documentation
we have a byte of data. Whether this data is valid or not is decided by the flags
module below.
5.
flags: When the last bit of the data frame is received, count72 port is
triggered indicate this. Then this module attempts to identify if a valid stop-bit (1)
has been detected. If it does not detect a valid stop-bit, it flags an error by sending
the dError signal with a BIT payload to 1. Otherwise, dReady is triggered.
A gl_reset signal is included so that the components can be brought into a known state
at the start of operations.
Clocking requirements of UAR
As decided earlier at the UAR specification, we will need to make the Receiver clock
connected to UAR to be eight times the bit rate. Since the bit rate is 1 bit/ 80 clock
cycles, so the Receiver clock period needs to be set to 10 clock cycles.
We could re-use an instance of the clkgen module (Figure 9) to drive the UAR. But since
we want the user of the UAR design to control the Receiver clock frequency/period, we
create another module called varclkgen. It is very similar to the clkgen module except
that its clock period is defined as a VS_INT and can be controlled from the test bench.
The default value of the clock period is set to 10 clock cycles.
MakeFrame to Handle Transmission Error
We modify MakeFrame module to handle any frame error indicated by the UAR. It is also
nice to be able to reset the module.
For this reason, three new pins are added: Enable, GetData, and ErrorData. When
ErrorData is triggered by the UAR, MakeFrame aborts processing of the current video
frame and waits until the beginning of the next frame. GetData indicates that a valid byte
is available in SerialData bus.
Controlling the Receiver
To enable the user to control the operations of the Receiver, we modify the Receiver.tb
Test Bench to add the following Test Bench controls:
Figure 20: New Test Bench Controls For Receiver
104