Sei sulla pagina 1di 13

1.

Introduction
The sake of this assignment is to achieve the transmission of a series of data by utilizing
Data Packet. Owing to the analysis of the basic system model given in the assignment
sheet, the system can be divided into 4 components (generator, error block, detector and
display) with 2 digital clock modules which serve for data-processing architectures and
driving display block respectively. The structure is illustrated below (Figure 1),

Figure 1 Hierarchy of the whole system

As shown in the above figure, the 4Hz clock in the system is utilized to send serial data
and 100Hz is used to drive display component. In our system, we utilize the rising edge
of the 4Hz clock to generate data packet in generator architecture, and choose falling
edge of 4Hz clock to receive data in detector part. The link between generator and error
block is attained by a counter arisen through counting the bit number that a data packet
has obtained in generator. We use this link to achieve the synchronization of sending
serial data and adding errors. More details about the design of the system will be given in
sub-system illustration part.

2. Sub-system Illustration
The system contains 6 components, two sub-systems are digital clocks, and the other four
are generator, error block, detector, display block, respectively. The architecture of each
sub-system will be elaborated separately in this part.

2.1 Digital Clock Modules


The digital clock modules in this application are constituted by one 4Hz clock and one
100Hz clock. The design for both clocks is based on the structure shown in Figure 2.
Figure 2 Rationale of Digital Clocks

The first part of the graph is counter block which is utilized to divide system clock
(50MHz) to 4Hz and 100Hz. The flowchart for the counter block is demonstrated in
Figure 3 and coding of the procedure is Division process in Clock_4H.vhd file.

Figure 3 Logical structure of counter block

As shown in Figure 3, the function of the counter block which is to divide system clock
is obvious and the range of Count_50M_int is attained by the calculation as follows,
 Range of Count_50M_int for 4Hz = 50MHz / 4Hz = 50*106 / 4 = 12500000
 Range of Count_50M_int for 100Hz = 50MHz / 100Hz = 50*106 / 100=500000
Obviously, the division for 4Hz is 12500000 and for 100Hz is 500000. Thus the range
for the 2 digital clocks is 0 to (12500000-1) and 0 to (500000-1), respectively.
The signal of FastSim is aiming at a faster simulation which is served for obtaining 4Hz
and 100Hz clocks in a short time through adding a large number to Count_50M_int per
time substitutes only plus one once.

Following the division process (counter block in Figure 2) is the comparator process
(comparator block in Figure 2) whose sake is to avoid getting skew clock edge and
outputting perfect 4Hz and 100Hz signals. The logical structure of this part is given
below,

Figure 4 Flowchart of Comparator block

From Figure 4, it is straightforward that the output of the Digital Clock Module is
C4Hz_Enable or C100_Enable which is 4Hz pulse or 100Hz pulse. The C4Hz_Enable
will be sent to generator block and detector block to achieve data transmission, whereas
the C100Hz_Enable will be utilized in display module to drive LED and four digit seven-
segment display.

2.2 Generator Block Design


In the original design of generator block we made a serious mistake that we
misunderstood the meaning of sending bits in serial due to our poor English. We sent data
all in one 4Hz-rising-edge, and we realized the mistake when we proceeded to the
Detector block. Thus we changed the coding to send one bit per time by coding as
follows. Date
Figure 5 Coding for sending bit by bit

In Transmitter, it is necessary to use Finite State Machine to control its operation and
simplify the coding. The states of the Generator are separated into 5 sending-bits states
based on the structure of a data packet given in Figure 5 (Victor, 2010, p. 2), together
with a waiting state created by Reset signal.

Figure 6 Structure of Data Packet

The procedure of generating and sending a data packet is illustrated in the following
graph,

Figure 7: 6 state machine for Generator


As shown in Figure 7, the five sending-bits states mentioned above are state_startbits,
state_header, state_DataSeg, state_Parity, state_CheckSum, respectively. In the
generator.vhd file, there are two process statements utilized to achieve the success of
sending data. One is named Mode coded to judge the generator mode to determine the
data in Data Segment. And the other one is named Start arisen to achieve sending data bit
by bit on 4Hz rising edge.

In Start process statement, the current state of the system will stay in waiting state
when Reset signal equals to ‘1’, whereas when the value of Reset signal is ‘0’ the current
state will be substituted by next state value at every 4Hz rising edge. However, the value
of Next_State can be changed only when the value of Send signal which is determined by
a push button(T14) on target board is ‘1’ or the value of count(a defined variable to count
bits after starting to send data) overflows the expected number, and the condition which
will be efficient depends on the Current_State value as illustrated in Figure 7. More
specifically, at a 4Hz rising edge the next state will be the state of sending Start Bits when
current state is state_wait. And if Current_State is not state_wait, the value of Next_State
is determined by the count value at every 4Hz rising edge. In this system, the Generator
block state will back to state_wait after sending one Data Packet, as shown in Figure 7.

In this system, the data in Start Bits(1010), and Header Code ( T34: AD 10101101) is
given, and Data Segment is determined by generator mode controlled by two slide switch
(K13 and K14) in Spartan 3 FPGA target board. However, the data in Parity Bits and
Check Sum need to be calculated by specific formula. As the requirement in the
coursework sheet, the 2nd and 4th bit in Parity are values satisfying the requested “even
parity” based on Header Code and Data Segment respectively. After analysis, we found
the values are the results calculated through XOR every bit in the specified data segment.
And the confirmation of this algorithm is mentioned in page of my logbook.

As regards the bits in Check Sum, they are attained through a given Linear Feedback
Shift Register, whose structure is shown below in Figure 8 (Victor, 2010, p. 4),

Figure 8 The LFSR utilized to obtain Check Sum

However, the coding for this LFSR we used is a little difference from other groups,
because we defined Tx_Din (the Din shown in the above graph) and the logic vector
which stores the calculated Check Sum as variables to achieve the utilization the first bit
in Data Segment, thanks to the immediately change in values of Tx_Din and
Check_Sum(0) , which cannot be realized by using signals. The code for checksum
algorithm is given in Figure 9,

Figure 9 Algorithm for Check Sum

According to the coding in Figure 9, it is straightforward to obtain the reason for why
the Check Sum we demonstrated during the assessment was not the desired one when
data in Data Segment is “AAAAAA”.

2.3 Error Block Design


In the Error.vhd file, there is only one process statement whose sensitivities are
Data_Packet, Counter and Error_Mode. And as mentioned in the Introduction part, no
clock edge is used in this part, because if the system utilizes 4Hz rising edge to drive
Error Block, an asynchronous phenomenon will be arisen between Generator block and
Error block, which will also brings difficulties in inducing errors to the pointed bits. To
avoid this case, in our system, we use an integer signal which is one output in transmitter
to store the bit number of data already sent from Generator block, which is also one input
of Error Block. Actually, the signal Counter is utilized to achieve the same function given
by 4Hz rising edge without delay and to accomplish the introduction of error to the
specified bits correctly. Choosing this approach can simplify the code in Error block and
realize the real time for transmitting data. The method of using Counter is shown in
Figure 10.
Figure 10 Coding for introducing errors
As the coding shown in Figure 10, it is obvious that the rationale of this approach is to
locate the bits may have errors and then detect if the error mode which is determined by
three slide switches( J12, J14 and H13) on the target board matches with the bits’
position. More specifically, the errors induced by Error block may occur in the last bit of
Header Code, Data Segment, and Check Sum, which are the 11th, 35th and 47th bits of the
Data Packet, respectively. Thus the values that need to be tested of Counter are 11, 35,
and 47, when the bits’ position in a Data Packet matched the error mode, reverse the
current values of corresponding bits through if statement as illustrated in Figure 10.

2.4 Detector Block Design


The differences between Generator block and Detector block is inducing flag signals, and
the clock edge utilized to drive the receiver is changed to falling edge. The reason to
choose falling edge in Detector block is to avoiding one pulse delay caused by using the
same clock edge as transmitter. As mentioned above, the clock edge utilized in Generator
block is rising edge, thus we altered to falling edge in receiver to shorten the delay which
causes difficulties when checking the waveforms in ISIM. Therefore, the delay shown in
waveform is shortened to the smallest-scale, as shown below.
Figure 11 The delay between Generator, Error block and Detector

As shown in Figure 11, the data transmission between Generator block and Error block
is synchronous as illustrated in 2.3 Error Block Design. The delay between Error block
and Detector block is controlled in a fairly small gap.

Due to the similarity of mechanism between Generator block and Detector block, the
coding for receiver is almost the same as transmitter, expecting the introduction of
processing flags and error flags which control the working state of the 8 LEDs in the
Spartan 3 target board. Therefore, only the coding for the flags will be elaborated in this
part.
The coding for processing flags is based on the requirement in the assignment sheet.
Here explain the rationale by utilizing the coding of Header Flag.

Figure 12 coding for Header Flag

As shown in the above graphs, the lit period for Header Flag is started from the first bit of
Header Code (count=4) and stopped at the first bit of Data Segment (count=12), satisfying
the requirement given in Figure 13 (Victor, 2010, p. 4).

Figure 13 Definition for processing flags


Based on the above interpretation and coding in Figure 13, it is straightforward to get the
method of programming the code for the 4 processing flags. The key is to locate the
position of the start points and the ending points which are the first bit of present data
segment and the first bit of next segment, respectively.

Similarly to the coding for processing flags, the coding for error flags is also to locate the
position firstly, whereas the position is the bits where the errors may be induced in. Then
compare the data in the specified bits sent through Error block with the data sent from
Generator block directly. However, one special point is that the Parity Bits and Check Sum
in Detector block are calculated from the received Header Code and Data Segment as the
algorithm mentioned in 2.2 Generator Block Design instead of receiving the
corresponding bits from Error block straightway. That is the reason for the detected Data
Parity and Check Sum are the same as the ones in Generator block, when no error
introduced in Data Segment in Error block. In other words, the corresponding LEDs off
Data Parity and Check Sum will be in the off states when detected Data Segment is the
same as the original one, although there are errors introduced into Data Parity and Check
Sum in Error block.

Following the above explanation, we can realize the detection for errors existing in serial-
data. However, there is one problem when detecting the error in Checksum through
comparing every bits of Checksum. Due to the algorithm of Checksum, the data in some
bits of Checksum might be the same as the transmitter ones, although error is induced into
the original Data Segment already. This will cause the flicker of Checksum Error flag. To
solve this problem, we introduced one signal named Detected to record the state of
Checksum error, if there is error having been detected, then give the value of ‘1’ to
Detected. The comparison of Checksum bits will be carried on only when Detected equals
to ‘0’, as the coding illustrated in Figure 14.

Figure 14 Detection of Checksum Error


2.5 Display Block Design
Different from the above blocks, this component is driven by the rising edge of 100Hz and
the sake of display module is to demonstrate the specified data received from transmitter
and receiver in 4 digit seven segment display and the states of LEDs which are controlled
by 8 flags values. And the links of display module with transmitter and display module
with receiver are achieved by the data needed in display block.

There are 3 process statement in Display.vhd file, and the first process named LED is
utilized to serve the control of the 8 LEDs on target board, whereas the 8 flags values are
obtained from Receiver, and the approaches to attain the values are interpreted in the 2.4
Detector Block Design. The coding is as follows,
Figure 15 Coding for LEDs controlling

The other two process statement named Show_Datas and Decoder which are both to aid
the working of 4 digit seven segment display. The working principle is given in page in my
logbook.
The Show_Datas process is mainly to transmit specified data limited by display mode to
the seven segment display and choose one seven segment display at one effective rising
edge of 100Hz. Thanks to the high frequency of 100Hz, human will not perceive the blank
in other 3 seven segment display caused by the limitation that only one seven segment
display can be chosen per time.
As listed in coursework sheet, there are 4 display modes and the first three can be easily
accomplished by sending specified bits to limited seven segment display, whereas the
fourth display mode is to scroll Rx Data Segment, which cannot be achieved only by
sending bits to seven segment display. To attain the scrolling Rx Data Segment, we utilize
one signal named flag, and the rationale of this approach is to send the next four data
obtained through satisfying the requirement of scroll periodically. The period for altering to
the next four data is 1Hz, which is achieved by count the rising edge of 100Hz for 100
times. The reason to use counter substitutes utilizing 1Hz digital clock directly is the seven
segment display cannot be driven by two digital clocks. The realization of utilizing counter
to get 1Hz is shown in Figure 16.
Figure 16 Coding for 1Hz attained by counter

The signal of wait_1Hz is plus one at every effective rising edge (Reset equals to ‘0’) of
100Hz, and the signal count is used to select seven segment display. As shown in Figure 16,
the flag signal plus one (when its value less than 5) when wait_1Hz is greater than 100,
which equals to flag (when its value less than 5) adds one in every 1 second. And the range
of flag signal is derived from the bit number of Data Segment. Because there are 6 Hex
data in Data Segment, thus the range is 0 to 5 to accomplish the full scroll of Rx Data
Segment. The coding for the approach to use flag signal is shown in Figure 17.

Figure 17 Coding for scrolling Rx Data Segment to the left

3. Interaction amongst sub-systems


The connection of sub-systems is achieved by utilizing signals, which are outputs of one
sub-system and inputs of other sub-systems.
4. Demonstration
After achieving the desired waveform in ISM, we downloaded the programming to target
board, however, the demonstration on the target board was not correct. In the beginning, we
downloaded to the board successfully after adding the sentence NET "Reset"
CLOCK_DEDICATED_ROUTE = FALSE; in UCF file, however, there was no reaction
when we pressed Send button (L14). The reason is somewhere in the process statement did
not fit the synthesis template. The principle for a process statement is illustrated in Figure
18(Victor, 2010).

Figure 18 Principle for coding in process

Through changing the coding as Figure 18, we downloaded to target board successfully.
And the change procedure can be found in page in my logbook.

In the team demonstration on 17th December, although our team got the mark 40/40, there
was a little problem that the Checksum data when Data Segment is “AAAAAA” is not the
desired values. The reason for this problem is illustrated in 2.2 Generator Block Design.

5. Conclusion
From the design for the Prototype of Bit-Serial Data Packet Generator – Detector, I gained
a great deal of experience. At the beginning of this semester, I have little knowledge about
VHDL that I even did not know what VHDL is. However, through hard-working learning
of this subject during this semester, I believe I have a better understanding for this
programming language and ISE software.

In my view, this assignment design is a complicated project, because it is constituted by 6


modules (generator, error block, detector and display and 2 digital clock modules). Thus
the evaluation of the methods and approaches based on this project is representative in my
opinion.

The approach to that I conclude from this project to accomplishing a complicated system
which we may encounter in the future is listed as follows,
(1) Analyze the structure of the system and derive the sub-systems might be in the project.
(2) If there are digital clocks required in the system, try to complete digital clock modules
first. Because in this way, the clock pulse can be attained easily, when we need to
utilize them.
(3) Find out the sub-system needs to be done first, and draw its block diagram and to
analyze the structure and signals may exist in the modules.
(4) Draw the block diagram of the second sub-system, and then combine the first finished
sub-system and this sub-system together and draw a block diagram for the combination.
(5) Analyze the following sub-system and draw its block diagram, and then do like 4 th step
to draw a block diagram by utilizing this sub-system and the combined block diagram
in former step.
(6) Repeat the 5th step until accomplish all the sub-system, and then we will get the block
diagram for the whole system. Compare the inputs and output (without internal signals)
in the finial block diagram with the ones we desired in the system. If not match with the
requirement, modify the previous block diagrams and analysis to achieve the correct
ones.

As regards the coding in every sub-system, I think drawing flowcharts is an excellent


method to assist us to program the complex logic existing in the system.

Reference
[1] Victor, Dunn. (2010, September). B325 2010/2011- Design assignment. Unpublished
internal document, University of Portsmouth.
[2] Victor, Dunn. (2010, Dec 14). General Queries about the Coursework [Msg 50.].
Message posted to https://intranet.ee.port.ac.uk/Forums/index.php?showtopic=7668&st=40
Bibliography
[1] Victor, Dunn. VHDL Review Part 1. Unpublished internal document, University of
Portsmouth.
[2] Victor, Dunn. VHDL Review Part 2. Unpublished internal document, University of
Portsmouth.
[3] Victor, Dunn. VHDL Review Part 2. Unpublished internal document, University of
Portsmouth.
[4] Xinlinx. (2005). Spartan-3 Starter Kit Board User Guide [Electronic version].
[5] Linear feedback shift register. from http://en.wikipedia.org/wiki/LFSR
[6] PONG P, H. (2008). FPGA Prototyping by VHDL Examples, Wiley

Appendix

Potrebbero piacerti anche