MIL-STD 1553B Project Report

VISVESVARAYA TECHNOLOGICAL UNIVERSITY
Jnanasangama
Belgaum-590018, Karnataka State, INDIA
MINI PROJECT REPORT

ON
DESIGN OF DECODER BASED ON MIL-STD1553B USING

STATE MACHINES
Submitted By
SHRUTI G.GOUDA
2 Sem. M.Tech. (DEC)
nd
In the partial fulfillment of the requirements for the degree of
MASTER OF TECHNOLOGY
IN
DIGITAL ELECTRONICS AND COMMUNICATION
Under the Guidance Of
Mr.PRADEESH KUNHIPPANAN
Asst.Professor
DEPARTMENT OF ELECTRONICS AND COMMUNICATION

ENGINEERING
K.V.G. COLLEGE OF ENGINEERING

SULLIA, D.K. - 574327, KARNATAKA
2013
K.V.G. College of Engineering, Sullia, D.K.-574327

(Affiliated To Visvesvaraya Technological University, Belgaum)
DEPARTMENT OF ELECTRONICS AND COMMUNICATION

ENGINEERING
CERTIFICATE
Certified that the mini-project work entitled DESIGN OF DECODER BASED ON MILSTD1553B USING STATE MACHINES, carried out by SHRUTI G.GOUDA in partial
fulfillment for the award of degree of MASTER OF TECHNOLOGY in DIGITAL
ELECTRONICS AND COMMUNICATION of the Visvesvaraya Technological
University, Belgaum during the year 2013. It is certified that all correction/suggestions
indicated for internal assessments have been incorporated in the report deposited in the
department library. The project report has been approved as it satisfied the academic
requirements in respect of Mini-Project work prescribed for the Master of Technology
degree.
Mr. Pradeesh Kunhippanan

AMIE.,M.Tech
Mini-project Guide
Smt. Bindu M.N.
Dr.Ravikumar
B.E.,M.Tech.,M.I.E.
B.E.,M.Tech,PhD,MISTE
Mini-project coordinator
Professor & H.O.D.
ACKNOWLEDGEMENT
Behind every achievement there is unfathomable sea of gratitude to those who
supported it and without whom it would never have been a reality.
I am thankful to my guide Mr.PRADEESH KUNHIPPANAN Department of
Electronics and Communication Engineering for his inspiration and guidance.
I record esteemed gratitude to Mini Project Coordinator Smt.BINDU M.N., Associate
Professor, Department of Electronics and Communication Engineering for her inspiration and
guidance.
I extend my heartfelt sincere thanks to Dr. RAVIKUMAR M.S., Professor & Head
of Department, Electronics and Communication Engineering, who always built our
confidence and helped me to reach the shore of success.
I gratefully acknowledge for the help rendered by our beloved Principal,
Dr. N.A. JNANESH, for providing constant encouragement and support throughout the
course of our project work.
I
am
deeply
indebted
to
the
Architect
of
modern
Sullia,
Dr. KURUNJI VENKATRAMANA GOWDA, Founder President, Academy of Liberal

Education, and Sullia for having provided an environment with all facilities that helped me in
completing my project. He is the source of inspiration for all of us.
I express my sincere thanks to all teaching and non-teaching staff members of our
college for their valuable support and co-operation. Finally, I would like to thank my parents
for their encouragement with love and affection.
DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES
CONTENTS
ABSTRACT ........................................................................................................................................................................................ 1
CHAPTER 1: INTRODUCTION............................................................................................................................................ 2
1.1
STATE MACHINES .................................................................................................................................................... 2
1.3 VHDL PROGRAMMING ................................................................................................................................................. 2

1.3.1
PROGRAMMING FILE STRUCTURE.................................................................................................... 3
1.4
TEST BENCH................................................................................................................................................................. 4
1.5
OVERVIEW..................................................................................................................................................................... 5
CHAPTER 2: LITERATURE SURVEY............................................................................................................................. 6

CHAPTER 3: MIL-STD 1553B................................................................................................................................................ 7
3.1 BACKGROUND.................................................................................................................................................................... 7
3.1.1 ADVENT OF DIGITAL TECHNOLOGY........................................................................................................ 8
3.1.2 ADVENT OF THE DATA BUS............................................................................................................................ 8
3.1.3 APPLICATIONS .......................................................................................................................................................... 9
3.2 1553B CHARECTERISTICS........................................................................................................................................... 9
3.3 HARDWARE ELEMENTS ............................................................................................................................................10
3.3.1 TRANSMISSION MEDIA.....................................................................................................................................10
3.3.2 REMOTE TERMINAL............................................................................................................................................11
3.3.3 BUS CONTROLLER................................................................................................................................................11
3.3.4 BUS MONITOR..........................................................................................................................................................12
3.3.5 TERMINAL HARDWARE....................................................................................................................................12
3.4 PROTOCOL...........................................................................................................................................................................13
3.4.1 WORD TYPES ............................................................................................................................................................13
CHAPTER4: DESIGN ................................................................................................................................................................16
4.1 ENCODER DESIGN .........................................................................................................................................................16
DEPARTMENT OF ELECTRONICS AND COMMUNICATION, KVGCE
Page I

4.1.1 ENCODER STATE DIAGRAM..........................................................................................................................18
4.2 DECODER DESIGN .........................................................................................................................................................20
4.2.1 BLOCK DIAGRAM OF DECODER.................................................................................................................20
CHAPTER 5: TEST BENCH DESIGN AND SIMULATION ..............................................................................25
CHAPTER 6: SIMULATED RESULTS ...........................................................................................................................27
CHAPTER 7: CONCLUSION................................................................................................................................................28
Page II
TABLE OF FIGURES
FIGURE 1.1:
A VHDL ENTITY CONSISTING OF AN INTERFACE (ENTITY
DECLARATION) AND A BODY (ARCHITECTURAL DESCRIPTION)................................. 3

FIGURE 1.2: BLOCK DIAGRAM OF TEST BENCH ................................................................. 4
FIGURE3.1: HARDWARE ELEMENTS OF 1553B .................................................................. 10
FIGURE 3.2: REPRESENTATION OF MANCHESTER CODING - CHANGE THE LABEL
FOR DATA AS NRZ-L DATA.................................................................................................... 14
FIGURE 3.3: WORD FORMATS................................................................................................ 14
FIGURE 4.1: BLOCK DIAGRAM OF ENCODER .................................................................... 16
FIGURE 4.2: STATE DIAGRAM OF ENCODER ..................................................................... 18
FIGURE 4.3: BLOCK DIAGRAM OF DECODER .................................................................... 20
FIGURE 4.4: BLOCK DIAIGRAM OF THE WORKING OF DECODER................................ 22
FIGURE 4.5: STATE DIAGRAM TO DECODE DATA............................................................ 23
FIGURE 5.1: DESIGNED TEST BENCH................................................................................... 25
FIGURE 6.1: SIMULATED RESULTS OF DECODER (INPUT AAAA)................................. 27

III
Page
ABSTRACT
. This report addresses the design, coding and simulation of a Manchester decoder using State
Machines. The Manchester Decoder are the Front End logics of MIL-STD-1553B protocol,
which is a standard Avionics Bus. The decoder is represented using state machines, which is a
method generally used in the design of Synchronous Systems as against the conventional design
methodology of representing the design using Block Diagrams. The coding of the decoder is
done using VHDL programming language and the functionality is verified using test benches.
The report gives a description of decoders in general, a brief about state machines and why we
choose state machines for our project and a brief about MIL-STD 1553B.
Page 1
CHAPTER 1: INTRODUCTION
This projects aims to study, design and implement the front-end logics of a 1553B protocol
device- MIL-STD-1553B Manchester Encoder-Decoder using a state machine. Synchronous
design using State machines will be used to design the logics involved and the same will be
coded in VHDL, simulated.
1.1 STATE MACHINES

A finite-state machine (FSM) or simply a state machine is a Synchronous design technique used
to design digital logics. It is conceived as an abstract machine that can be in one of a finite
number of states. The machine is in only one state at a time; the state it is in at any given time is
called the current state. It can change from one state to another when initiated by a triggering
event or condition, this is called a transition. A FSM is defined by a list of the possible transition
states from each current state, and the triggering condition for each transition.
State diagram is a pictorial representation of the behaviour of a sequential circuit. The state is
represented by a circle and the transition between the states is indicated by directed lines
connecting the circles. A directed line connecting a circle with itself indicates that next state is
same as present state.
1.3 VHDL PROGRAMMING
VHDL stands for
(Very High Speed Integrated Circuits Hardware Description Language). In
the mid-1980s the U.S. Department of Defense and the IEEE sponsored the development of this
hardware description language with the goal to develop very high-speed integrated circuit. It has
become now one of industrys standard languages used to describe digital systems. The other
Page 2
widely used hardware description language is Verilog. Both are powerful languages that allow to
describe and simulate complex digital systems. A third HDL language is ABEL (Advanced
Boolean Equation Language) which was specifically designed for Programmable Logic Devices
(PLD). ABEL is less powerful than the other two languages and is less popular in industry. This
project uses VHDL, as described by the IEEE standard 1076-1993.
1.3.1 PROGRAMMING FILE STRUCTURE

A digital system in VHDL consists of a design entity that can contain other entities that are then
considered components of the top-level entity. Each entity is modeled by an entity
declaration and an architecture body. One can consider the entity declaration as the interface to
the outside world that defines the input and output signals, while the architecture body contains
the description of the entity and is composed of interconnected entities, processes and
components, all operating concurrently, as schematically shown in Figure 3 below. In a typical
design there will be many such entities connected together to perform the desired function.
FIGURE 1.1: A VHDL ENTITY CONSISTING OF AN INTERFACE (ENTITY DECLARATION)

AND A BODY (ARCHITECTURAL DESCRIPTION).
VHDL uses reserved keywords that cannot be used as signal names or identifiers. Keywords and
user-defined identifiers are case insensitive. Lines with comments start with two adjacent
hyphens (--) and will be ignored by the compiler. VHDL also ignores line breaks and extra
spaces. VHDL is a strongly typed language which implies that one has always to declare
the type of every object that can have a value, such as signals, constants and variables.
Page 3
1.4 TEST BENCH

A test bench is used to verify the functionality of the design at each step in HDL synthesis-based
methodology. The test bench instantiates design under test (DUT). It provides the necessary
input stimulus to the DUT and examines the output from the DUT. For complete automatic
testing, a compare function within the test bench compares the result from the DUT against those
known good results and reports any discrepancies. Alternately, the outputs from the DUT can be
monitored as waveforms, which can be analyzed in detail for all its timing parameters.
A test bench or testing workbench has four components:
a)
Input: The entrance criteria or deliverables needed to perform work,
b)
Procedures to do: The tasks or processes that will transform the input into the output.
c)
Procedures to check: The processes that determine that the output meets the standards.
d)
Output: The exit criteria or deliverables produced from the workbench.
FIGURE 1.2: BLOCK DIAGRAM OF TEST BENCH
Page 4
A test bench is the highest level in the hierarchy of the design. It instantiates the device under
test. The test bench provides the necessary input stimulus to the device under test and examines
the output from the device under test.
1.4.1.1 ADVANTAGES OF USING TEST BENCH

The main advantages of using a test bench area) They are platform independent i.e. the test bench can be used in any simulator to test the
output with respect to the inputs.
b) Outputs of one device can be routed to the inputs of another device
c) The designed device can be checked for multiple inputs at a single time as in the real
world environment.
1.5 OVERVIEW
The scope is to MIL-STD-1553B decoder using state machines, coding using VHDL and
verifying by simulation using a VHDL test bench.
MIL-STD 1553B is a military standard which is widely used in avionics and satellite
communication to interface between different sub systems. To design the encoder and the
decoder, state machines are used instead of the conventional design using Block diagrams and
the coding is done using VHDL. The verification by simulating is done using a test bench.
Page 5
CHAPTER 2: LITERATURE SURVEY

MIL-STD 1553B is a military standard data bus that is used in avionics that is used to exchange
information between various systems. This is a 1Mbps bus which follows the Manchester II
encoding, it is a 20 bit bus and has various message formats for sending command /status and
data between various systems. This data bus has three subsystems the bus monitor, bus controller
and remote controllers.
This project is mainly represented using state machines, which is the sequential logic that can be
implemented using a fixed number of states. Their outputs and states are identical, and there is
no choice of the sequence in which states are visited. More generally, the outputs and next state
of a finite state machine are combinational logic functions of their inputs and present state. The
choice of next state can depend on the value of an input. Finite state machines are critical for
realizing the control and decision-making logic in digital-systems.
State diagram representation has been preferred over other types of representation like the block
diagram or flowcharts as block diagrams give the specific inputs and the outputs but behavior of
the output with respect to the input cannot be decided in the block diagram and the causality of
loops is hard to detect.
Flow charts may seem similar to state diagrams but are not the same. Flowcharts are a good tool
in describing sequential flow which is needed in the project but flowcharts are less qualified to
show continuously running sequential activities. The past in flowcharts has to stored using flags
which is very complex to represent and thus state machines are used which is simpler to
represent loops and the past inputs and outputs.
Thus the main aim of the project is to make a state diagram for the encoder and decoder defining
all the states of these devices and program them using VHDL coding, using case statements for
every state defined in the state diagram.
Page 6
CHAPTER 3: MIL-STD 1553B

MIL-STD-1553 is a standard avionics Command/Response protocol bus at 1Mbps data rate, half
duplex, Manchester Bi-phase encoding that defines the electrical and protocol characteristics for a
data bus. A data bus is used to provide a medium for the exchange of data and information between
various systems. . This chapter provides an introduction, history and applications it also describes
the elements of the data-bus structure and the protocols i.e. the message formats.
3.1 BACKGROUND
In the 1950s and 1960s, aviation electronics, referred to as avionics, were simple stand-alone
systems. The navigation, communications, flight controls, and displays consisted of analog systems.
Often these systems were composed of multiple boxes, or subsystems, connected to form a single
system. Various boxes within a system were connected with point-to-point wiring. The signals
mainly consisted of analog voltages, synchro-resolver signals, and switch contacts. The location of
these boxes within the aircraft was a function of operator need, available space, and the aircraft
weight and balance constraints. As more and more systems were added, the cockpits became more
crowded, the wiring more complex, interfaces became more complex and varied and the overall
weight of the aircraft increased.
By the late 1960s and early 1970s, it became necessary to share information between the various
systems using a standard interface to reduce the number of black boxes and the types of interfaces
required by each subsystem.
A single sensor, for example that provided heading and rate
information, could provide that data to the navigation system, the weapons system, the flight
control system, and pilots display system.
However, the avionics technology was still basically analog, and while sharing sensors did produce
a reduction in the overall number of black boxes, the connecting signals became a rat's nest of
wires and connectors. Moreover, functions or systems that were added later became an integration
nightmare, as additional connections of a particular signal could have potential system impacts.
Page 7
Additionally, as the system used point-to-point wiring, the system that was the source of the signal
typically had to be modified to provide the additional hardware to output to the newly added
subsystem. As such, inter-system connections had to be kept to the bare minimum.
3.1.1 ADVENT OF DIGITAL TECHNOLOGY
By the late 1970s, with the advent of digital technology, digital computers had made their way into
avionics systems and subsystems. They offered increased computational capability and easy
growth, compared to their analog predecessors. However, the data signals, inputs and outputs from
the sending and receiving systems were still mainly analog in nature. This led to the configuration
of a small number of centralized computers (typically only one or two) being interfaced to other
systems and subsystems via complex and expensive analog-to-digital and digital-to-analog
converters. As time and technology progressed, the avionics systems became more digital. And
with the advent of the microprocessor, things really took off. A benefit of this digital application
was the reduction in the number of analog signals, and hence the need for their conversion.
Transferring the data between users in digital form could provide a greater sharing of sensor
information. An additional side benefit was that digital data could be transferred bi-directionally,
wherein analog data was transferred unidirectional. Serial rather than parallel transmission of the
data was used to reduce the number of interconnections within the aircraft and the receiver/driver
circuitry required with the black boxes.
3.1.2 ADVENT OF THE DATA BUS
But this alone was still not enough. A data transmission medium, which would allow all systems
and subsystems to share a single and common set of wires, was needed. By sharing the use of this
interconnect, the various subsystems could send data between themselves and to other systems and
subsystems, one at a time, and in a defined sequence, hence a data bus.MIL-STD-1553B defines the
term Time Division Multiplexing (TDM) as the transmission of information from several signal
sources through one communications system with different signal samples staggered in time to form
Page 8
a composite pulse train. For our example in Figure 1b, this means that data can be transferred
between multiple avionics units over a single transmission media, with the communications
between the different avionics boxes taking place at different moments in time, hence time division.
3.1.3 APPLICATIONS
Since its inception, MIL-STD 1553B has found a lot of applications to interface various
subsystems of a complex system. The applications are:a) The standard has been applied to satellites as well as payloads within the space shuttle (it is
even being used on the International Space Station).
b) The standard has been employed on large transports, aerial re-fuelers, and bombers, tactical
fighters, and helicopters.
c) This data bus is even contained within missiles and serves, in some instances, as the
primary interface between the aircraft and a missile.
d) The Navy has applied the data bus to both surface and subsurface ships.
e) The Army, in addition to its helicopters, has put 1553 into tanks and howitzers.
f) Commercial applications have applied the standard to systems including subways, for
example the Bay Area Rapid Transit (BART), and manufacturing production lines.
3.2 1553B CHARECTERISTICS

The following are the characteristics of MIL-STD 1553B
a) The data rate is 1 MHz
b) Word length is 20 bits which includes a 3 bit sync, 16 bit data with a 1 bit odd parity
c) Data bits/Words is 16 bits
d) Message length is maximum of 32 data words
e) Transmission technique is half-duplex
f) Operation is asynchronous
Page 9
g) It uses the Manchester Bi-phase II encoding technique

h) Terminals present are remote terminal, bus controller, bus monitor
i) Maximum number of remote terminals are 31
j) Transmission media is twisted shielded pair
3.3 HARDWARE ELEMENTS
MIL-STD-1553 defines certain aspects regarding the design of the data bus system and the black
boxes to which the data bus is connected. The standard defines four hardware elements. These
are:
a) The transmission media.
b) Remote terminals.
c) Bus controllers.
d) Bus monitors.
e) Terminal hardware.
FIGURE3.1: HARDWARE ELEMENTS OF 1553B
3.3.1 TRANSMISSION MEDIA
The transmission media, or data bus, is defined as a twisted shielded pair transmission line
consisting of the main bus and a number of stubs. There is one stub for each terminal connected
Page 10
to the bus. The main data bus is terminated at each end with a resistance equal to the cable's
characteristic impedance (plus or minus two percent). This termination makes the data bus
behave electrically like an infinite transmission line.
Optionally, include one typical 1553 bus interface showing all the elements for clarity
3.3.2 REMOTE TERMINAL
Remote terminals are defined within the standard as All terminals not operating as the bus
controller or as a bus monitor. Therefore if it is not a controller, monitor, or the main bus or
stub, it must be a remote terminal. The remote terminal comprises the electronics necessary to
transfer data between the data bus and the subsystem. For 1553 applications, the subsystem is the
sender or user of the data being transferred. In the earlier days of 1553, remote terminals were
used mainly to convert analog and discrete data to and from a data format compatible with the
data bus. The subsystems were still the sensor that provided the data and computer, which used
the data. As more and more digital avionics became available, the trend has been to embed the
remote terminal into the sensor and computer. Today it is common for the subsystem to contain
an embedded remote terminal.
3.3.3 BUS CONTROLLER

MIL-STD-1553 is a Command response protocol. The bus controller is responsible for
commanding/initiating all the transactions on the bus. While several terminals may be capable of
performing as the bus controller, only one bus controller may be active at a time. The bus
controller is the only one allowed to issue commands onto the data bus. The commands may be
for the transfer of data or the control and management of the bus. Typically, the bus controller is
a function that is contained within some other computer, such as a control computer. The
complexity of the electronics associated with the bus controller is a function of the subsystem
interface (the interface to the computer), the amount of error management and processing to be
performed, and the architecture of the bus controller.
Page 11
3.3.4 BUS MONITOR

A bus monitor is a terminal that listens (monitors) to the exchange of information on the data
bus. The standard strictly defines how bus monitors may be used, stating that the information
obtained by a bus monitor be used for off-line applications (e.g., flight test recording,
maintenance recording or mission analysis) or to provide the back-up bus controller sufficient
information to take over as the bus controller. A monitor may collect all the data from the bus
or may collect selected data. The reason for restricting its use is that while a monitor may collect
data, it deviates from the command-response protocol of the standard, in that a monitor is a
passive device that doesnt transmit a status word and therefore cannot report on the status of the
information transferred.
3.3.5 TERMINAL HARDWARE
The electronic hardware between a remote terminal, bus controller, and bus monitor doesnt
differ much. Both the remote terminal and bus controller (and bus monitor if it is also a remote
terminal) must have the transmitters/receivers and encoders/decoders to format and transfer data.
The requirements upon the transceivers and the encoders/decoders dont vary between the
hardware elements. All three elements have some level of subsystem interface and data
buffering. The primary difference lays in the protocol control logic and often this just a different
series of micro coded instructions. For this reason, it is common to find 1553 hardware circuitry
that is also capable of functioning as all three devices. There is an abundance of off-the-shelf
components available today from which to design a terminal. These vary from discrete
transceivers, encoders/decoders, and protocol logic devices to a single dual redundant hybrid
containing everything but the transformers.
Page 12
3.4 PROTOCOL
As we have some knowledge about the hardware requirements, the methodologies with which
the data can be transferred are known as the protocol. The control, data flow, status reporting,
and management of the bus are provided by three word types.
3.4.1 WORD TYPES

There are three distinct types of word formats described in this standard namely
a) Command word
b) Status word
c) Data word
Each word type has a unique format, yet all three maintain a common structure. Each word is
twenty bits in length. The first three bits are used as a synchronization field, thereby allowing the
decode clock to re-sync at the beginning of each new word. The next sixteen bits are the
information field and are different between the three word types. The last bit is the parity bit.
Parity is based on odd parity for the single word.
Bit encoding for all words is based on bi-phase Manchester II format. The Manchester II format
provides a self-clocking waveform in which the bit sequence is independent. The positive and
negative voltage levels of the Manchester waveform is DC-balanced (same amount of positive
signal as there is negative signal) and, as such, is well suited for transformer coupling.
Page 13
FIGURE 3.2: REPRESENTATION OF MANCHESTER CODING - CHANGE THE LABEL FOR

DATA AS NRZ-L DATA
The Manchester waveform is as shown in the figure. A transition of the signal occurs at the
center of the bit time. Logic 0 is a signal that transitions from a negative level to a positive
level. Logic 1 is a signal that transitions from a positive level to a negative level.
BIT TIMES
COMMAND/
STATUS
WORD
SYNC
COMMAND/STATUS
PARITY
DATA WORD
SYNC
DATA
PARITY
FIGURE 3.3: WORD FORMATS
3.4.1.1 SYNC FIELD

The first three bit times of all word types is called the sync field. The sync waveform is in itself
an invalid Manchester waveform as the transition only occurs at the middle of the second bit
time. The use of this distinct pattern allows the decoder to re-sync at the beginning of each word
received and maintains the overall stability of the transmissions. Two distinct sync patterns are
used: the command/status sync, and the data sync. The command/status sync has a positive
Page 14
voltage level for the first one and a half bit times and then transitions to a negative voltage level
for the second one and a half bit times. The data sync is the opposite, a negative voltage level for
the first one and a half bit times, and then a positive voltage level for the second one and a half
bit times.
3.4.1.2 COMMAND WORD

The Command Word (CW) specifies the function that a remote terminal is to perform. Only the
active bus controller transmits this word. The word begins with command sync in the first three
bit times. The following is a 16 bit command and following that is 1 bit parity, only odd parity is
used.
3.4.1.3 STATUS WORD

A remote terminal in response to a valid message transmits only the status word (SW). The status
word is used to convey to the bus controller whether a message was properly received or to
convey the state of the remote terminal (i.e., service request, busy, etc.).
3.4.1.4 DATA WORD

The Data Word (DW) contains the actual information that is being transferred within a message.
The first three-bit time contains data sync. This sync pattern is the opposite of that used for
command and status words and therefore is unique to the word type. Data words can be
transmitted by either a remote terminal (transit command) or a bus controller (receive command).
Transmit and Receive, by convention, references the remote terminal.
Page 15
CHAPTER4: DESIGN
The design of the encoder and the decoder is based on the following characteristics of MIL-STD
1553B
a) The data rate is 1 MHz
b) Word length is 20 bits which includes a 3 bit sync, 16 bit data with a 1 bit odd parity
c) Data bits/Words is 16 bits
d) It uses the Manchester Bi-phase encoding technique
To design the encoder and decoder the following steps are used
a) A state diagram is drawn for the encoder to encode 16 bit binary parallel data to
Manchester coded serial data.
b) Using state diagram, a VHDL code is written for the encoder which is verified and
simulated using a test bench
c) The block diagram is drawn to decode the encoded data and draw the state diagram to
read the encoded data and decode it
d) A VHDL code is written for the decoder and verified and simulated using a test bench
4.1 ENCODER DESIGN
Output
FIGURE 4.1: BLOCK DIAGRAM OF ENCODER
Page 16
Figure shows the I/O diagram of the Manchester Encoder for MIL-STD-1553 standard.
Functions of the various I/O pins are detailed below:
a) RESET: This is a active low input. The entire logic is reset condition when this input is
low. This signal is generated after the FPGA is powered and the design is loaded. This
initializes all the logics, resets all the flip flops in the design and thus provides a known
state for the start of the function after de-asserting the reset pin.
b) START: The encoder starts encoding at the rising edge of the start input.
c) INPUT DATA: this is the 16 bit data serial data that is Manchester encoded and the parity
of the input data is calculated at the output
d) COMMAND/DATA SYNC: these are 3 synchronization bits that are sent to the output
before the input data indicating if the data that is input is a command/ status or a data word
e) CLOCK: All the synchronous elements in the design are clocked by this clock. The MILSTD-1553 Manchester encoder is at 1Mbps rate, hence, there are two transitions for every
data bit. The Sync signal should be 3 bits wide with transitions at 1.5 bit duration. The
encoded/decoded data should be used by the protocol logic, which also has a series of clock
requirements. The standard protocol chips available off the shelf use a 12MHz clock and
this logic, which is meant to replace the use of these standard chips is also designed using
12MHz clock.
f) ENCODER OUTPUT: As the encoder starts reading the data the initial data read is the
cmd/data flag. When this flag is high it indicates that the next 16 bits are a command or a
status or else the next 16 bits are data. After the sync pulses and the command/status or
data are encoded the computed odd parity is displayed at the end as 1 bit of odd parity
which is also Manchester coded
Page 17
4.1.1 ENCODER STATE DIAGRAM

Enable/start
Reset
Idle
Clk>18
Sync1
Start reading data
Datasend
Sync2
Increment clk <18

Sync2 <= NOT Sync1
Clk count>6
Data count<17
Parity
Parity <= dataout1 XOR
dataout2
DataOut1
DataOut2
Data count = 17,
Check if all 16 bits of
data is received and
display parity
Reset clk count.

Dataout2 <= NOT of Dataout1
FIGURE 4.2: STATE DIAGRAM OF ENCODER
The encoder state diagram has six states as shown:

A) IDLE: The encoder when reset enters the idle state. It remains idle in this state until it
receives the sync pulse. On completion of the data transmission it again enters the idle state until
the next transmission.
B) SYNC1: When the start of transmission is signaled the encoder starts transmission with the
sync pulse. Only on the detection of the sync pulse, the encoder will know that the message
being sent is a command/status or data. Sync1 is the first part of the sync pulse. Sync1 is high for
a command or status word and is a low for a data word. The width of sync1 is 1.5 clocks (of the
1MHz clock frequency) thus requiring 18 clocks of the 12 MHz clock frequency given to the
encoder.
Page 18
C) SYNC2: Sync2 is the second part of the sync pulse. It is the inverse of sync1. The width of
sync2 is also 1.5 clocks (of the 1MHz clock frequency) thus requiring 18 clocks of the 12 MHz
clock frequency given to the encoder. On completion of this state the encoder enters the next
state datasend where it accepts the data to be encoded.
D) DATASEND: In this state the encoder starts receiving the 16 bits of data. It accepts the data
and encodes it bit by bit. As it receives each bit, parity is simultaneously calculated. It then enters
the next state dataout1.
E) DATAOUT1: Each bit received in the previous state is encoded in Manchester format to be
transmitted. The width of this state is 0.5 clock times and the output here is same as that of the
bit received in datasend as per the Manchester format. It consists of 6 clocks of the 12 MHz
clock frequency given to the encoder .The next state is dataout2.
F) DATAOUT2: According to Manchester format the second half of the clock is the inverse of
the data encoded in the first half of the clock. This state represents the second half of the
Manchester coding. The width of this state is 0.5 clock times and the output here is the inverse of
dataout1. This pulse also consists of 6 clocks of the 12 MHz clock frequency given to the
encoder. This whole process of reception of data and encoding in Manchester is repeated 16
times for 16 bits of data. After receiving and encoding the 16 bits of data the encoder enters the
parity state from the state dataout2.
G) PARITY: The parity computed while receiving each data bit is encoded in Manchester
coding similar to that of data. Here odd parity is calculated i.e. if the total number of 1s in the
data is odd, then the parity is 0, else if the total number of 1s in the data is even, then the parity
is 1. After the transmission of this parity bit the encoder enters the idle state and remains there
until the next cycle of transmission.
Page 19
4.2 DECODER DESIGN

The decoder design is a bit more complicated as compared to the encoder design as it has to
synchronize its internal clock with the transitions in the data. This is called Bit Synchronization.
To decode one bit, we need to read the incoming data stream at intervals of 0.5 us after Bit
synchronization. The decoder has a separate clock independent of the encoder. The block
diagram describes the process of decoding the encoded data.
4.2.1 BLOCK DIAGRAM OF DECODER
C/D Flag
Par_ok
Encoder output
FIGURE 4.3: BLOCK DIAGRAM OF DECODER
The above diagram is the block diagram of the decoder.

a) START: The decoder starts decoding at the rising edge of the start input.
b) RESET: This is a active low input. The entire logic is reset condition when this input is
low. This signal is generated after the FPGA is powered and the design is loaded. This
initializes all the logics, resets all the flip flops in the design and thus provides a known
state for the start of the function after de-asserting the reset pin.
Page 20
c) CLOCK: All the synchronous elements in the design are clocked by this clock. The MILSTD-1553 Manchester encoder is at 1Mbps rate, hence, there are two transitions for every
data bit. The Sync signal should be 3 bits wide with transitions at 1.5 bit duration. The
encoded/decoded data should be used by the protocol logic, which also has a series of
clock requirements. The standard protocol chips available off the shelf use a 12MHz clock
and this logic, which is meant to replace the use of these standard chips is also designed
using 12MHz clock.
d) ENCODER OUTPUT: This is the 20 bit encoded output of the encoder which is the input
to the decoder. This 20 bit input is decoded by the decoder.
e) OUTPUT: this is the 16 bits of data that is input in the encoder in serial form which is
obtained at the output of the decoder after the decoding operation.
f) C/D FLAG: this is a three bit flag which indicates if the 16 bit data obtained is a data or a
command/status word.
g) PAR_OK: this is a 1 bit output which indicates that the data received is valid by
comparing the parity computed by the encoder and the decoder; if the parity is equal the
par_ok is high.
Page 21
FIGURE 4.4: BLOCK DIAIGRAM OF THE WORKING OF DECODER
The process of decoding follows the following steps
a) The differential output of the encoder is given as input to the decoder. This differential
input is converted to single ended input.
b) As the encoder of the encoder and the decoder are different, both the clocks are
synchronized so that the rate at which the data is sent by the encoder is same as the rate at
which the decoder receives the data.
c) To read the encoded data a sample window is created every 6 clock cycles at which half a
bit is read of the encoded data.
d) The encoded data is read and decoded as described in the state diagram.
e) As the data is being decoded the parity is calculates for every bit of the 16 bit
command/status or data simultaneously.
Page 22
f) This calculated parity of the decoder is compared with the incoming parity from the
encoder, if the parities are same, then the decoded data is valid.
g) The valid data is displayed as 16 bit parallel binary data, which is further used by the
BC/RT/MT protocol logics.
4.2.1.1 STATE DIAGRAM TO DECODE DATA
When got_sync = 1
Reset
Idle
Sync
Convert differential output to a

single ended output, detect clk
edge, and calculate the value of
input by creating sample window
every 6 clks
After parity is calculated
get_data
Calculate the parity

by reading the
Manchester code and
also read each bit of
data and display it as
output
FIGURE 4.5: STATE DIAGRAM TO DECODE DATA
The working of the state diagram is as follows-
IDLE: On reset the decoder enters into this state. Initialization of all signals and variables are
done here. After the one cycle of data is read, the decoder enters the idle state and remains here
until the reception of next data. Once the decoder starts receiving a signal, it enters the sync state.
SYNC: All 1553 messages should start with a Sync and hence, whenever data arrives, we should
detect for Sync first. In this state the sync bits are received. We receive 1 bit for each 6 clocks
thus receiving 6 bits for the entire sync pulse. If the received bits are either 000111 or
111000 the appropriate flag is raised and the decoder enters the next state get_data. When the
received sync is 111000, it is a command/status word and if the received sync is 000111, it
is a data word.
Page 23
GET_DATA: The Manchester encoded data and parity bits are received in this state. For each
Manchester encoded data the bit is decoded and extracted. As each bit is extracted the parity is
simultaneously computed. The computed parity and the received parity are checked. If both are
same the data is valid and can be used else it should be immediately discarded. After the parity is
received, the decoder enters the idle state and remains in that state until the reception of the next
cycle of data.
Page 24
CHAPTER 5: TEST BENCH DESIGN AND

SIMULATION
As described before, a test bench is used to verify the functionality of a design at every step of
the HDL synthesis.
The test bench encapsulates the stimulus driver, the device under test and internal signals to
make a proper connection. The stimulus driver drives inputs into the device under test. The
device under test responds to the input signals and produces output results. The results are then
compared to the known good results and report any discrepancies.
The test bench designed for the encoder and the decoder is as shown below-
FIGURE 5.1: DESIGNED TEST BENCH
Page 25
As a general test bench the test bench or also known as the stimulus driver gives the inputs to the
device under test.
Initially the encoder design is verified and simulated. This is done by giving all the input signals
to the designed encoder i.e. the required clock, start signal, reset signal, cmd/data flag and
data_in. These inputs are given for a specific amount of time and the results are tested.
Once the encoder design is perfect the output of the encoder is given as the data input to the
decoder along with the other common signals which are the start, reset and a clock signal. These
signals are given to the decoder which the present device under test through another test bench.
The test bench drives all the internal signals of the device under test and gives us the output of
the decoder. This output is compared to input of the encoder, if not satisfactory then the
necessary changes are made in the code of the respective programs.
Page 26
CHAPTER 6: SIMULATED RESULTS

Below are the snapshots simulated results of the decoder
FIGURE 6.1: SIMULATED RESULTS OF DECODER (INPUT AAAA)
Page 27
CHAPTER 7: CONCLUSION
MIL-STD-1553 Manchester Encoder-Decoder, which is the front end logics of a 1553 protocol
device, has been successfully designed and realized using State machines. This project has given
us a good insight and understanding on synchronous design techniques, designing using state
machines, programming in VHDL. It has also given us a good understanding on MIL-STD
1553B.
During the design process, we got a good understanding on the behavioral style of programming
in VHDL using state machines. This project has given us an insight on the method of testing the
design using test benches.
Page 28
BIBILOGRAPHY
1. http://www.scribd.com/doc/49284395/MIL-STD-1553Tut
2. http://microsat.sm.bmstu.ru/e-library/military%20standatds/MIL-STD-1553Tut.pdf
3. http://www.ee.iitm.ac.in/~balajis/EE5000/MC_TDM.pdf
4. http://www.atmel.com/images/doc9164.pdf
5. http://en.wikipedia.org/wiki/Manchester_code
6. VHDL primer by douglas perry
Page 29

MIL-STD 1553B Project Report

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

MIL-STD 1553B Project Report

Enviado por

Direitos autorais:

Formatos disponíveis

VISVESVARAYA TECHNOLOGICAL UNIVERSITY

MINI PROJECT REPORT

DESIGN OF DECODER BASED ON MIL-STD1553B USING

In the partial fulfillment of the requirements for the degree of

DEPARTMENT OF ELECTRONICS AND COMMUNICATION

K.V.G. COLLEGE OF ENGINEERING

K.V.G. College of Engineering, Sullia, D.K.-574327

DEPARTMENT OF ELECTRONICS AND COMMUNICATION

Mr. Pradeesh Kunhippanan

Smt. Bindu M.N.

Professor & H.O.D.

Dr. KURUNJI VENKATRAMANA GOWDA, Founder President, Academy of Liberal

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

STATE MACHINES .................................................................................................................................................... 2

1.3 VHDL PROGRAMMING ................................................................................................................................................. 2

PROGRAMMING FILE STRUCTURE.................................................................................................... 3

CHAPTER 2: LITERATURE SURVEY............................................................................................................................. 6

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

DEPARTMENT OF ELECTRONICS AND COMMUNICATION, KVGCE

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

A VHDL ENTITY CONSISTING OF AN INTERFACE (ENTITY

DECLARATION) AND A BODY (ARCHITECTURAL DESCRIPTION)................................. 3

DEPARTMENT OF ELECTRONICS AND COMMUNICATION, KVGCE

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

DEPARTMENT OF ELECTRONICS AND COMMUNICATION, KVGCE

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

1.1 STATE MACHINES

1.3 VHDL PROGRAMMING

VHDL stands for

(Very High Speed Integrated Circuits Hardware Description Language). In

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

1.3.1 PROGRAMMING FILE STRUCTURE

FIGURE 1.1: A VHDL ENTITY CONSISTING OF AN INTERFACE (ENTITY DECLARATION)

DEPARTMENT OF ELECTRONICS AND COMMUNICATION, KVGCE

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

1.4 TEST BENCH

Input: The entrance criteria or deliverables needed to perform work,

Output: The exit criteria or deliverables produced from the workbench.

FIGURE 1.2: BLOCK DIAGRAM OF TEST BENCH

DEPARTMENT OF ELECTRONICS AND COMMUNICATION, KVGCE

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

1.4.1.1 ADVANTAGES OF USING TEST BENCH

DEPARTMENT OF ELECTRONICS AND COMMUNICATION, KVGCE

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

CHAPTER 2: LITERATURE SURVEY

DEPARTMENT OF ELECTRONICS AND COMMUNICATION, KVGCE

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

CHAPTER 3: MIL-STD 1553B

A single sensor, for example that provided heading and rate

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

3.1.1 ADVENT OF DIGITAL TECHNOLOGY

3.1.2 ADVENT OF THE DATA BUS

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

3.2 1553B CHARECTERISTICS

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

g) It uses the Manchester Bi-phase II encoding technique

3.3 HARDWARE ELEMENTS

FIGURE3.1: HARDWARE ELEMENTS OF 1553B

3.3.1 TRANSMISSION MEDIA

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

3.3.2 REMOTE TERMINAL

3.3.3 BUS CONTROLLER

DESIGN OF MIL-STD 1553B DECODER USING STATE MACHINES

3.3.4 BUS MONITOR