Thesis presented to the Faculty of the Department of Graduate Studies

of the Aeronautics Institute of Technology, in partial fulfillment of the

requirements for the Degree of Master in Science in the Course of
Aeronautical Engineering, Field Electronic Engineering

Matheus Silva Iglesias

MODELING, IMPLEMENTATION AND

ANALYSIS OF ARINC 429 TRANSCEIVER
EMBEDDED IN PROGRAMMABLE HARDWARE
INSIDE A REAL TIME SIMULATION
ENVIRONMENT

Thesis approved in its final version by signatories below:

Ph. D. Osamu Saotome

Advisor

MSc. Raphael das Neves Calvo

Co-advisor

Prof. Dr. B
Head of the Faculty of the Department of Graduate Studies

Campo Montenegro
São José dos Campos, SP - Brazil
2099
Cataloging-in Publication Data
Documentation and Information Division
Silva Iglesias, Matheus
Modeling, implementation and analysis of ARINC 429 transceiver embedded in programmable
hardware inside a real time simulation environment / Matheus Silva Iglesias.
São José dos Campos, 2099.
50f.

Thesis of Master in Science – Course of Aeronautical Engineering. Area of Electronic

Engineering – Aeronautical Institute of Technology, 2099. Advisor: Ph. D. Osamu Saotome.
Co-advisor: MSc. Raphael das Neves Calvo.

1. Keyword 1. 2. Keyword 2. 3. Keyword 3. I. Aeronautics Institute of Technology. Division of

Electronic Engineering Division. II. Title.

BIBLIOGRAPHIC REFERENCE

SILVA IGLESIAS, Matheus. Modeling, implementation and analysis of ARINC

429 transceiver embedded in programmable hardware inside a real time
simulation environment. 2099. 50f. Thesis of Master in Science – Aeronautics
Institute of Technology, São José dos Campos.

CESSION OF RIGHTS

AUTHOR NAME: Matheus Silva Iglesias

PUBLICATION TITLE: Modeling, implementation and analysis of ARINC 429 transceiver
embedded in programmable hardware inside a real time simulation environment.
PUBLICATION KIND/YEAR: Thesis / 2099

It is granted to Aeronautics Institute of Technology permission to reproduce copies of

this thesis to only loan or sell copies for academic and scientific purposes. The author
reserves other publication rights and no part of this thesis can be reproduced without
the authorization of the author.

Matheus Silva Iglesias

Rua Francisca Maria de Jesus, 148, 4 404
CEP 12230-083 – São José dos Campos–SP
 iii

MODELING, IMPLEMENTATION AND

ANALYSIS OF ARINC 429 TRANSCEIVER
EMBEDDED IN PROGRAMMABLE HARDWARE
INSIDE A REAL TIME SIMULATION
ENVIRONMENT

Matheus Silva Iglesias

Thesis Committee Composition:

Prof. Dr. ToDO Presidente - ITA

Ph. D. Osamu Saotome Advisor - ITA

MSc. Raphael das Neves Calvo Co-advisor - EMBRAER

Prof. Dr. ToDO Membro Externo - UXXX

Prof. Dr. ToDo Membro Externo - UYYY

Prof. Dr. ToDo Membro - ToDo

Prof. Dr. ToDo Membro - ToDo

ITA
 iv

Dedicado ToDO
Acknowledgments
 “XXX,
XXX.”
— XXX
 Resumo

Palavras–Chave: keywords, keywords, keywords, keywords

 Abstract

Keywords: keywords, keywords, keywords, keywords

 Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Bibliographic Review . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1 ARINC 429 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Development Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3 Simulink HDL Coder tool . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Transmitter Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 Main Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.2 Simulink
R
Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.3 Hand-written Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1.4 Comparison between hand-written code and HDL Coder

R
model code . . . 42

4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Appendix A – Specific topics . . . . . . . . . . . . . . . . . . . . . 49

Annex A – Annex Title . . . . . . . . . . . . . . . . . . . . . . . . . 50

CONTENTS x

A.1 some annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
 List of Figures

FIGURE 2.1 – Arinc 429 frame format. . . . . . . . . . . . . . . . . . . . . . . . . 20

FIGURE 2.2 – Arinc 429 bit encoding. . . . . . . . . . . . . . . . . . . . . . . . . . 21

FIGURE 2.3 – Mojo V3 development board. . . . . . . . . . . . . . . . . . . . . . . 23

FIGURE 3.1 – Transmitter device block. . . . . . . . . . . . . . . . . . . . . . . . . 25

FIGURE 3.2 – Voltage level equivalency. . . . . . . . . . . . . . . . . . . . . . . . . 27

FIGURE 3.3 – Model top level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

FIGURE 3.4 – ClockController block. . . . . . . . . . . . . . . . . . . . . . . . . . 31

FIGURE 3.5 – IntervalController block. . . . . . . . . . . . . . . . . . . . . . . . . 32

FIGURE 3.6 – FiniteStateMachine block. . . . . . . . . . . . . . . . . . . . . . . . 34

FIGURE 3.7 – OutputStage top layer. . . . . . . . . . . . . . . . . . . . . . . . . . 36

FIGURE 3.8 – Hand-written code top level schematic. . . . . . . . . . . . . . . . . 38

FIGURE 3.9 – The interior view of the transmitter_top module. . . . . . . . . . 39

FIGURE 3.10 –Finite state machine. . . . . . . . . . . . . . . . . . . . . . . . . . . 40

FIGURE 3.11 –A429 frame obtained through test bench code simulation. . . . . . . 41

FIGURE 3.12 –Comparison of Model Based Design workflow and manual workflow
timelines for Datalink layer. (??) . . . . . . . . . . . . . . . . . . . 43
 List of Tables

TABLE 2.1 – SSM Codes for BCD and BNR data . . . . . . . . . . . . . . . . . . 20

TABLE 3.1 – Device utilization comparison. . . . . . . . . . . . . . . . . . . . . . 45

List of Abbreviations and Acronyms
List of Symbols
1 Introduction

1.1 Motivation

Industries worldwide experienced, in the last decades, the necessity for changes in

product development paradigm. The accelerated development of transportation and in-

formation technology brought to the industry new quality, price and time standards from a

market that desires higher quality products at a lower price and new technologies available

as soon as possible.

This new product development paradigm shorts the development cycle and increases

product maturity before offering it to a so competitive market, avoiding the risks of

losing time to market or staining company reputation. Hence, verification of the product

performance and its safety has grown in last years (??).

Aerospace industry is also pushed to offer more mature solutions in a shorter develop-

ment period. Besides market behavior and requirements, two other elements inherently

linked with aerospace industry stands as additional challenges: Firstly, manufacturers of

highly integrated complex products as an aircraft usually integrate several third party

specialized systems, each one with its own development cycle. Secondly, there is a strong

commitment to safety due to the nature of aerospace industry.

CHAPTER 1. INTRODUCTION 16

Since third party systems have their own product development cycle, it is usual not

to have the system fully developed or adapted at the first stages of aircraft development

cycle. Therefore, aircraft manufacturers resort to models and simulation in order to

validate and mature their products, regarding system integration, mainly. Testing and

simulating became indissoluble from product development cycle, even more in aerospace

industry. In order to provide suitable representative level on those tasks, two techniques

are remarkable: System modeling and real time simulation.

Two approaches are very usual in the testing phase of the development cycle. In the

first, system’s functionalities are modeled and simulated using software tools. The level of

confidence of the results obtained depends on the availability and accuracy of the system

models, test cases coverage, and other aspects. In the second approach, the model is

deployed on a target device as a programmable hardware to verify system behavior under

more realistic conditions.

High-fidelity models support engineers to simulate accurately static and dynamic be-

havior of systems that consists, considering the context presented above, in a relevant

advantage in integration tasks. Since model-based design is a well-established method

of designing through mathematical and visual models, many tools emerged supporting

R
engineers in this task. Through tools such as Simulink , it is relatively easy to build

a model in different levels of detail, from functional to physical layer, testing it quickly

through simulation inside the same development environment.

The second technique addressed in this thesis is the Hardware in the loop (HIL) which

consists in a real time simulation used in the development and testing of complex real-time

embedded systems (??). In order to enhance the reliability of the model in comparison

with the real system, it is common to implement a real-time simulation of a high-fidelity

CHAPTER 1. INTRODUCTION 17

model in dedicated hardware as Field-programmable gate array (FPGA).

The last paragraphs help to elucidate the main technologies that are addressed in this

work. Besides that, it is also desirable to choose a case study where it is possible to

exercise those technologies.

The growth in the number of functions embedded in aircraft systems, mainly in elec-

tronics, leads to more integrated systems where communication protocols play important

roles. Hence, it was chosen as a study case the implementation of a transceiver of a widely

used serial communication protocol in aeronautic industries: the ARINC 429.

As it is exposed in details in the section 1.2, the objective of this study is to implement

an ARINC 429 device in FPGA, emerged in a real time simulation environment in order

to exercise the methodologies above mentioned. Lastly, using the environment developed,

this work aims to research new applications and enhancements for the protocol itself.

1.2 Objectives

The objective of the present study is to exercise part of a product development cycle,

addressing system modeling and deployment in programmable hardware in addition to

build a real time simulation environment as a test bench for investigation of enhancements

and new applications for the product itself.

The concrete objectives of this thesis may be detailed as exposed below.

1. Implementation of an ARINC 429 transceiver FPGA-based device.

(a) Comparison between hand-written code and automatically generated code from

a model through Simulink HDL Coder

R
tool.
CHAPTER 1. INTRODUCTION 18

(b) Physical layer frontend development in order to allow verification through test-

ing, using commercial of the shelf devices.

2. Implementation of a real time simulation capable test bench using Hardware in the

loop technique.

3. Protocol enhancement and new applications research.

1.3 Organization

In Chapter 1, the introduction for this work is presented. A brief bibliographic review,

presented in 2, provides the previous knowledge requirements necessary to understanding

the study development exposed in 3. Finally, in Chapter 4, the conclusions and future

works are exposed.

2 Bibliographic Review

2.1 ARINC 429

The ARINC 429, henceford referred as A429, is a communication protocol specified

in (??). This standard is the most widely used data bus on higher-end commercial and

transport aircraft’s avionics (??). This protocol is a self-clocking, self-synchronizing, serial

protocol above a physical layer connection composed by twisted pairs carrying differential

signaling.

The A429 frame consists in a 32-bits word followed by a variable interval period. The

minimum interval allowed between each word is a 4-bit periods whose duration depends

on the baud rate chosen and the maximum depends on the application but reaches the

scale of few seconds. The A429 standard defines two baud rates: 100 Kbps and 12.5 Kbps.

Each transmitted message is a fixed length word with 32 bits and the typical format is

depicted in Figure 2.1 that consists in an 8-bits label, a parity bit at the end of the word,

two fields that will be detailed in next paragraphs (SSM and SDI) and the transmitted

data with 19 bits.

The parity bit is a checksum, usually implemented by A429 COTS drivers and defined

by its standard as an odd parity encoding that works as error-detecting tool. The parity
CHAPTER 2. BIBLIOGRAPHIC REVIEW 20

FIGURE 2.1 – Arinc 429 frame format.

of the word is the number of either ”1” bits inside it in odd parity (typical) or the number

of ”0” bits in even parity.

The SSM is a 2-bits field that contains hardware equipment condition, operational

mode or validity of data, coded according that depicted in table 2.1 according how it is

coded.

TABLE 2.1 – SSM Codes for BCD and BNR data

Bit 31 Bit 30 Meaning for BCD data Meaning for BNR data
0 0 Plus, North, East, Right, To, Above Failure Warning
0 1 Plus, No Computed Data Plus, No Computed Data
1 0 Functional Test Functional Test
1 1 Minus, South, West, Left, From, Below Normal Operation

Data field consists typically of bits 11 to 29 although various manufacturers have

implemented many non-standard formats. The detailing of each possible word format

and the related data field format is not scope of this thesis but it is demonstrated in

details in the standard (??).

The Source Destination Identifier (SDI) is used for multiple receivers to know for whom

the message is addressed. Finally, the bits 1 to 8 are the label that identifies data type

and parameters associated with it. It is transmitted ahead of the rest of the word and,

unlike the other fields, the most significant bit of this field is transmitted first.

There are many possible data formats depending on the application, the following

quote, enumerating them, was gathered from Condor Arinc 429 manual (??).

”All ARINC data is transmitted in 32 bit words. The data type may be Binary Coded
CHAPTER 2. BIBLIOGRAPHIC REVIEW 21

Decimal (BCD), two’s complement binary notation (BNR), Discrete Data, Maintenance

Data and Acknowledgment, and ISO Alphabet number 5 character data. In the newest

versions, bit oriented packets of messages can be used to transmit files”.

The nominal transmission voltage is 10 ± 1 between the pair of wires, with either

positive or negative polarity representing ”1” and ”0” respectively. Once this differential

signal is modulated as a BPRZ (bipolar return to zero), three voltage levels are allowed.

1. HI, from 7.25 to 11 volts;

2. NULL, from -0.5 to 0.5 volts.

3. LO, from -11 to -7.25 volts.

A bit encoding example is shown in Figure 2.2.

FIGURE 2.2 – Arinc 429 bit encoding.

The receiver voltage depends on wires length and how many devices are connected to

the bus since the standard requires the capability of connecting 20 receivers in a single

bus. Other physical characteristics as slew rate and coupling impedance are addressed in

chapters regarding physical front-end.

CHAPTER 2. BIBLIOGRAPHIC REVIEW 22

2.2 Development Kit

A field-programmable gate array (FPGA) is a programmable hardware generally con-

figurable through a Hardware Description Language (HDL). FPGAs contain an array of

programmable logic blocks with configurable interconnections to perform several functions

from basic combinational functions to an entire processor: flip-flops, arithmetical unities,

memory and even analog features as analog-to-digital and digital-to-analog converters.

The Mojo V3 is a FPGA development board chosen for implementing the transceiver

of this study. This board consists in a Spartan 6 XC6SLX9 FPGA kernel with a microcon-

troller ATMega 32U4 used as a bootloader, USB communicator and reading analog pins,

LEDs connectable with FPGA ports, voltage regulators, reset button and flash memory.

The board, shown in Figure 2.3, provides to the FPGA an external clock of 50 MHz

and a DC voltage source of 3.3 V. The hardware description program is load through

USB port supported by the software manufecterer. The program is kept in the memory

and the microcontroller used for loading purposes can be used as a serial communicator

controller latter.
CHAPTER 2. BIBLIOGRAPHIC REVIEW 23

FIGURE 2.3 – Mojo V3 development board.

2.3 Simulink HDL Coder tool

Although the tool description and usage is not within the scope of this work, due to the

contextual importance, complexity and its large number of possible boundary conditions,

next paragraphs address this theme briefly.

When talking about programmable hardware, computational resources optimization

and timing restrictions are the main concerns for the design. It is well known that the

signal type chosen affects greatly the resources usage, hence, the first step in this coding

approach is to minimize the data size avoiding, when it is possible, using float point

representation for real numbers.

Since the nature of this design does not require any real-number manipulation, it is not

required to extend this discussion here. Even so, it is strongly recommended convert all

data types for fixed point representation before start coding from the model. Simulink
R

possess a tool called Fixed-point toolbox to assist the engineer in this process.
CHAPTER 2. BIBLIOGRAPHIC REVIEW 24

Once data type is no more an issue, the next step is to configure Simulink
R
to deal

with fixed-step without continuous states. The following configuration shall be applied in

every block of the system.

In the menu Simulation → Model Configuration Parameters → Solver → Solver Op-

tions, configure Type as Fixed-step, Solver as discrete (no continuous states) and Fixed-

step size (fundamental sample time) as the external clock period.

Still in Simulation → Model Configuration Parameters, the Optimization → Signals

and Parameters, the Inline parameters option is very useful when designing. This option

makes coder to use the numerical values of model parameters, instead their symbolic

names in generated code.

To be continued...
3 Development

3.1 Transmitter Module

The transmitter module, whose Simulink

R
block representation is shown in figure 3.1,

was the first module implemented in this work. It consists in a device that picks up the

data (31-bits parallel input) and sends it according to the protocol standard and the user

user options (i.e baud rate and interval code) through two ports: Hi (High) and Lo (Low).

FIGURE 3.1 – Transmitter device block.

CHAPTER 3. DEVELOPMENT 26

3.1.1 Main Features

The intern functionalities and other general features were inspired in commercial off

the shelf transmitter devices as HOLT HI-8470-C and served as requirements for the device

development.

Firstly, aiming to test enhancements for the protocol, it is necessary to allow trans-

mission in different baud rates. Since the protocol had been defined with two standards

(i.e. high speed at 100 Kbps and low speed at 12.5 Kbps), only one bit could be used to

choose transmission rate. Nevertheless, considering research purposes, 8 baud rates are

required to be selected by a 3-bits input.

Another aspect of this protocol is that the stop period may vary depending on the

application. Considering the research purposes and in order to provide application flexi-

bility, it was established as a requirement that the interval should be selectable from 4 bit

periods (i.e. the minimum stop period defined in the standard) and 2.55 s that is simply

a 8-bit selection multiplied by 10 ms. This upper limit was based on commercial devices

values and attain the maximum value foreseen in the standard (??).

Besides the inputs listed above, there are three implicit inputs (i.e. clock, enable and

reset) and the data input port. The reset provides an asynchronous way to restore a

known state to the system while enable port allows the module to works when set. The

clock input is used to calculate each sub-clock, supporting all the transmission timing.

The last input is the digital parallel data input. The data port consist in a 31-bit port

that receives useful data and process it according the sending options set.

The transmission can be briefly explained by the following steps:

CHAPTER 3. DEVELOPMENT 27

1. The device that wants to communicate must supply the clock, enable and reset

signals to the transmitter device besides baud rate and stop period options;

2. The data shall be available in the transmitter data input port during all the word

transmission. The buffer that controls it is external to the transmitter device itself;

3. The last bit of the frame (i.e. parity bit) is internally calculated and it is sent by

the transmitter at the end of the frame;

4. Since digital output voltage level does not allow generating differential signals with

10 volts peak-to-peak, it was defined that the transmitter implemented in FPGA

should generate the output with the same format and timing but with the 3.3 volts

peak-to-peak board limitation. Then, a frontend should be designed to adequate

the FPGA output to the A429 physical layer standard. The Figure 3.2 provides the

A429 standard defined signal and the equivalent output of FPGA board.

FIGURE 3.2 – Voltage level equivalency.

CHAPTER 3. DEVELOPMENT 28

3.1.2 Simulink
R
Model

The architecture of the transmitter was developed in a top-down approach, fitting the

design of the device with the required inputs, outputs and other functional requirements.

The model was designed in Simulink

R
that was also used as simulation and validation

tool. Figure 3.3 shows the top level schematic of the model.
 CHAPTER 3. DEVELOPMENT
FIGURE 3.3 – Model top level.

29
CHAPTER 3. DEVELOPMENT 30

The main function of the top level module is to integrate the hierarchically inferior

modules that perform specialized functions. Since the FPGA clock can not be directly

used for frame timing because of it is too fast, it was defined that an internal counter

should be implemented for timing the frame according the selected baud rate. The second

function is to count the bit position of the frame. These two functions are performed by

the module BitCounter.

Other relevant function is to calculate the stop period or the interval between each

word since it is variable. The user must select either the minimum stop period (4 bit

periods) or a multiple of 10 ms period up to 2,55 s. This interval shall be provided in

terms of bit periods since it is the basis of the frame timing. This function is executed by

the IntervalCalculator module.

Since the frame may be divided in three distinct parts (i.e. 31 first bits or data, parity

bit and stop period), a subsystem was required to delimit each part of the frame. This is

the function of the FiniteStateMachine.

Finally, leaded by the FSM, there shall be a module that conform each bit to the

correct format to be sent besides calculating the parity bit. This function is performed

by OutputStage subsystem.

3.1.2.1 BitCounter

The BitCounter block function is to provide the timing for the whole device through

two counters. As seen in Figure ??, this subsystem consists in two counters in a cascade

configuration and externally reset.

 CHAPTER 3. DEVELOPMENT
FIGURE 3.4 – ClockController block.

31
CHAPTER 3. DEVELOPMENT 32

The first counter is a free-runner counter without enable port. It increments the output

count in 1 unity each time there is a positive edge from the FPGA’s clock (i.e. implicit

in the model but configured in simulation options). The reset signal is set every time the

count reaches its limit for the selected baud rate.

This limit is the output of the switch that in selected by the 3-bits port. It keeps how

many FPGA’s clock cycles it lasts to complete a bit period in that baud rate.

Explicitly, since the FPGA clock frequency is 50 MHz, its period is 20 ns. If the baud

rate chosen to transmit is 500 Kbps, the period of each bit transmitted is 2 µs. Hence,

a bit period lasts 2e − 6/2e − 8 = 100 FPGA clock cycles. The baud rate options were

arbitrarily changed according to research needs.

The second counter is called Bit Counter and increments in 1 unity every time the

count reaches the limit. It is reset by any state change in the FSM and serves to determine

how many bit periods elapsed since the current state (i.e. data, parity or interval) started.

3.1.2.2 IntervalCalculator

The Figure 3.5 shows the subsystem IntervalController.

FIGURE 3.5 – IntervalController block.

This subsystem function is to translate the user selected interval into its equivalent
CHAPTER 3. DEVELOPMENT 33

multiple of bit periods. The switch address either the minimum interval or the product of

how many 10 ms has been selected times the number bit periods lasts a 10 ms period in

each possible baud rate. This last value had been previously calculated and is consulted

through a lookup table (LUT). The data type conversion block is required due to the

native LUT block limitations.

3.1.2.3 FiniteStateMachine

The FSM, observed in Figure 3.6, is the logical core of the transmitter design. Its

function is to determine the transition of each state which delimits the part of the frame

the system is, based on the counter provided by BitCounter block.

This block also address two state-dependent outputs. Firstly, it serializes the Data,

addressing in the DataBit port each bit during a bit period. And secondly it issues a

flag called NextState that is an external way to identify the current FSM state. This

nomenclature requires some explanation.

The state is kept outside the FSM in a memory block, already depicted in the Figure

3.3. This memory block updates its output with the input’s value each FPGA’s clock.

Since the current and stable data is the one that already passed through block memory,

it is called current state while the FSM output is called NextState.

The FSM has four states. The transmitter wakes up in the DATA state that can be

achieved in cold power up, every time enable value is false or at frame completion. At this

state, twoall flags are initialized and the state remains until enable is set and the counter

reach the value 1.

The DATA state delimits the period while transmitter is sending the 31 first bits.
CHAPTER 3. DEVELOPMENT 34

FIGURE 3.6 – FiniteStateMachine block.

During this state, the DataBit signal receives the serialized data input. The FSM transits

from the DATA state to the PARITY state after transmitting the 31 first bits. Since

all data transmission is delayed by one bit period as it is explained ahead, the first bit

period starts when counter equals to 2 and ends when BitCounter signal reaches 33.

The following state is PARITY and delimits the parity bit sending. It issues a false

in the DataBit port because the bit to be sent is not originated from the data port, instead

of it, it is calculated ahead in the OutputStage module. Since it is a don’t care, it was

chosen a logical false for this signal. This state lasts one single bit period (BitCounter

reaches value 1) and then, the system enters the next state: INTERVAL.

The INTERVAL state informs the system that no useful data is transmitted in this

frame anymore. Since the interval between words is selectable, the number of bit periods

that interval lasts may vary.

After the stop period, the state changes to DATAENTRY in which system remains

during one clock cycle only. This intermediate period assures that the DataBit is addressed

only after the BitCounter reset since it lasts one clock cycle to it to restart the counter.
CHAPTER 3. DEVELOPMENT 35

3.1.2.4 OutputStage

The OutputStage block, as seen in Figure 3.7, aims to format the digital data in the

Binary Return To Zero (BRTZ) differential signal with the previously presented timing

and calculate the parity bit.

 CHAPTER 3. DEVELOPMENT
FIGURE 3.7 – OutputStage top layer.

36
CHAPTER 3. DEVELOPMENT 37

The parity bit is calculated through the XOR operation between the current DataBit

with the last parity of the previous bits sent. The circuitry assure that the parity bit is

update only one time per bit period by comparing by detecting the change in BitCounter

(i.e. comparing BitCounter and BitCounterNext). It also guarantees the reset of the

parity calculation at interval phase. The last two blocks pick up the DataBit and the

ParityBit and determine using the NextState signal when to send each of them. Due to

the need of some timing corrections in the transitioning of frame phases, and in order to

toggle the output signal between the bit itself and the NULL that completes the BRTZ

bit format, a combinational circuit was implemented in a S-function block.

3.1.3 Hand-written Code

The hand-written design aims to provide a reference for evaluating the coding from

model approach. For a fair comparison, it was pursued the same architecture in both

designs differing each other only in the description level of abstraction since MBD describes

the behavior mostly in the functional layer while the hand-written code was describes it

in RTL.

The top level schematic of the design is shown in Figure 3.8 below.
CHAPTER 3. DEVELOPMENT 38

FIGURE 3.8 – Hand-written code top level schematic.

In this design, the top level main function is also to integrate more specialized sub-

functions implemented in other blocks but, besides it, there are two additional RTL de-

scriptions in this level: The FSM and the data serializing implementations. The general

internal structure of this block may be appreciated in Figure 3.9.

 CHAPTER 3. DEVELOPMENT
FIGURE 3.9 – The interior view of the transmitter_top module.

39
CHAPTER 3. DEVELOPMENT 40

Besides the three main modules, the Figure 3.9 shows the block state_q1 that is the

RTL originated from the synthesis that regards FSM machine implementation. It has

three hidden comparators (i.e. for keeping the readability of the diagram) that guides

the FSM in determining which part of the frame the transmission is, as it is observed in

details in Figure 3.10.

There is also the Mmux_databit1 that is a product of the synthesis that implements

the serialization of datain. It outputs the datain indexed by the bit_counter position

when the state is DATA and false otherwise. Some intermediate signals were hidden for

keeping the diagram understandable.

FIGURE 3.10 – Finite state machine.

Since the architecture of the modules are exactly the same as the MBD analogue

blocks, presented in Sections 3.1.2.1, 3.1.2.2 and 3.1.2.4, no additional description of them

is required in this Section. The entire hand-written code used in the comparison ahead is

available in Annex A.1.

The Figure 3.11 below shows the frame built by the transmitter module in a simula-

tion transmitting at 100 Kbps, with minimum interval selected. The 31 bist sent were

1111111111-00000-111111111-000-111.
 CHAPTER 3. DEVELOPMENT
FIGURE 3.11 – A429 frame obtained through test bench code simulation.

41
CHAPTER 3. DEVELOPMENT 42

3.1.4 Comparison between hand-written code and HDL Coder

R

model code

In this section, it is presented a brief comparison between the two coding approaches

explained in sections 3.1.3 and 3.1.2. Before starting the comparison itself, it is valid

to present the context where this discussion is situated and why it is worth the time to

discuss it.

The model based design, as a design paradigm, has expanded its application fields in

the last years. In electronics, the High-level synthesis tools intend to allow designers to

describe a desired behavior and create digital hardware that implements that behavior

in order to substitute the The Register-Transfer level (RTL) hardware description, that

should be done automatically by the HLS tool as an intermediate step before the code

generation. Part of the alleged benefits increasing the reuse and shortening the product

development cycle.

The first allegation is that HLS may shorten the product development cycle by accel-

erating the coding process itself. Several case studies, such as (??), (??), (??) and (??)

confirm it as it is shown in Figure 3.12 that represents one of those study cases analysis.

(??)

Due to the overhead in Detailed design specification phase, it is reasonable to suppose

that this methodology fits better in large design developments.

The second above-mentioned advantage of MBD approach is the increase of reuse since

the model is not directly linked with the deployment target, Since the model is focused

on the functional description that is independent of the device where it will be deployed.

It is clear that part of the MBD approach advantages depends on the project scale
CHAPTER 3. DEVELOPMENT 43

FIGURE 3.12 – Comparison of Model Based Design workflow and manual workflow time-
lines for Datalink layer. (??)

and the development environment chosen. In this work, it was used the Simulink HDL

Coder
R
whose features exceeds the mere model-to-code functionality. It allows the user

to simulate the model, to deploy the code generated directly in the target device, simulate

the code through automatically generated test benches, to analyze test coverage, to co-

simulate a hand-written code together with the automatically generated code, to build

a HIL environment easily and it also has a built-in tool that support the analysis and

conversion of all number types to fixed point.

Of course that several advantages may be reached with this tools if they deliver what

it promises, but it is important to mention that some features cited above are within

separate toolboxes and may be brought separately. Once this work aims to compare the

MBD-based versus hand-written codes, the unique tool used in this work is the HDL

coder already mentioned. Hence, it is not expected to analyze all the development cycle
CHAPTER 3. DEVELOPMENT 44

and, due to this design scale, it is not expected to observe all the alleged advantages of

MBD here.

Nevertheless, it is expected to compare how is to develop HDL code through both

approaches, the main differences between them, if it is feasible to use MBD in this niche

and, objectively, which is the performance of both generated codes. The first comparison

is presented in the section 3.1.4.1, where the resources consumption of each code are com-

pared. The second comparison, in section 3.1.4.2 is arising from the designer’s perceptions

about both development process that emerged with the designing exercise.

3.1.4.1 Resource Utilization

The resource utilization comparison is based on the Device Utilization Summary

exported from ISE Xilinx

R
tool. The FPGA’s resources utilized in both codes were

compared and the results, depicted in 3.1, show that the code from MBD architecture

consumes more resources than the hand-written code, except for the carry multiplexers

that is more consumed by the hand-written code mapping. It is observed a relevant

difference between the average fan-out of each code, which indicates that the hand-written

code tends to be more energetic efficient. In short, it is noted a small difference in

resources consumption of each code that is not relevant in small-scale designs such as that

comparison’s object. The average fan-out is considerable higher in the MBD code which

suggests that hand-written code is leaner in this term.

CHAPTER 3. DEVELOPMENT 45

TABLE 3.1 – Device utilization comparison.

Slice Logic Utilization Available Manual coding Model-based

Number of Slice Registers 11,440 19 61
Number of Slice LUTs 5,720 75 85
Number of occupied Slices 1,430 25 29
Number of MUXCYs used 2,860 84 48
Number of LUT Flip Flop pairs used N/A 75 98
Number of RAMB16BWERs 32 0 0
Number of RAMB8BWERs 64 0 0
Number of BUFIO2,BUFIO2-2CLKs 32 0 0
Number of BUFIO2FB,BUFIO2FB-2CLKs 32 0 0
Number of BUFG,BUFGMUXs 16 1 1
Number of DCM,DCM-CLKGENs 4 0 0
Number of ILOGIC2,ISERDES2s 200 0 0
Number of IODELAY2,IODRP2,IODRP2-MCBs 200 0 0
Number of OLOGIC2,OSERDES2s 200 0 0
Number of BSCANs 4 0 0
Number of BUFHs 128 0 0
Number of BUFPLLs 8 0 0
Number of BUFPLL-MCBs 4 0 0
Number of DSP48A1s 16 0 0
Number of ICAPs 1 0 0
Number of MCBs 2 0 0
Number of PCILOGICSEs 2 0 0
Number of PLL-ADVs 2 0 0
Number of PMVs 1 0 0
Number of STARTUPs 1 0 0
Number of SUSPEND-SYNCs 1 0 0
Average Fanout of Non-Clock Nets N/A 2.84 4.46

3.1.4.2 General perceptions

Analyzing the coding process, either through building a model or manually, it is ob-

served that some aspects, even the intangible ones, make some tasks easier to execute in

one or other approach.

Firstly, both designs started with the same requirements and architecture. The MBD

aimed in describing the desired behavior in high-level functions supported by the HDL

Coder
R
while the hand-written approach focused on the RTL description.
CHAPTER 3. DEVELOPMENT 46

The HDL Coder

R
, as a HLS tool, has some functions already implemented in sup-

ported libraries such as free-runner counters, limited counters, memory blocks, CRC, FSM

and others. Despite most part of the work would be done through the integration of those

blocks in the design, this task requires relevant workload sometimes due the lack of flexi-

bility in changing block aspects as timing and reset. Hence, some subsystems as the CRC

calculator were manually implemented, forcing a RTL description in a environment where

it is clearly less productive.

A pleasant surprise in this exercise was to describe FSM with Simulink Stateflow
R
. It

is easy to handle, it shows a clear and intuitive diagram and several features as describ-

ing internal logics, state transitions and external signal by both graphic and code-based

instructions (i.g. M-code and C statements).

In terms of describing RTL in a Simulink

R
, it was also noted that implementing a

large logic expressions may result in a confusing and demanding task besides it is less

productive than doing the same in code lines. For this reason, the last part of the design

was implemented in a S-function block.

Designing through models allows developers to check the logical consistency of each

subsystem in each development step resorting that the early the logical consistency is

checked, the early level of confidence and maturity grow.

Nevertheless, designing a model that intends to be transcribed in HDL code requires

substantial work in order to keep all the boundary condition (e.g. simulation configuration,

signals and variables, subsystem architectures, used blocks, etc.) adequate, it means

capable of being codified.

Finally, considering this design scale, it is substantial more productive to code man-
CHAPTER 3. DEVELOPMENT 47

ually than through a model. This analysis is based on development period observed in

this project that consisted in a double faster development when coding manually. It is

important to note that the situation observed is strongly dependent on the designer back-

ground, the level of intuitiveness of the approach to the designer, used tools and several

other aspects that make the analysis alone not conclusive or, at least, without statistical

representativeness by itself.
4 Conclusion
Appendix A - Specific topics
Annex A - Annex Title

A.1 some annex

subtitle subtitle subtitle

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam pellentesque justo vitae mauris ultricies

feugiat. Suspendisse ut est vel eros rutrum pellentesque eu eget nisi. Vivamus eget arcu sem. Nullam

venenatis massa vitae pellentesque vestibulum. Sed nec lacus placerat, malesuada leo sit amet, cursus nibh.

Phasellus accumsan dolor eleifend rutrum porttitor. Phasellus sapien neque, luctus at dictum sagittis,

fermentum vitae est. Cras consectetur tristique urna. Mauris aliquam mauris sit amet ultrices ultrices.

Vivamus vitae augue odio. Praesent eleifend enim a metus placerat, eget auctor leo imperdiet.
 FOLHA DE REGISTRO DO DOCUMENTO

1. 2. 3. 4.
CLASSIFICAÇÃO/TIPO DATA REGISTRO No No DE PÁGINAS
TM 99 de dezembro de 2099 DCTA/ITA - XXXXXXXXXX 50
5.
TÍTULO E SUBTÍTULO:
Modeling, implementation and analysis of ARINC 429 transceiver embedded in programmable hardware inside
a real time simulation environment
6.
AUTOR(ES):
Matheus Silva Iglesias
7.
INSTITUIÇÃO(ÕES)/ÓRGÃO(S) INTERNO(S)/DIVISÃO(ÕES):
Instituto Tecnológico de Aeronáutica. Divisão de Engenharia XXXXXXXX – ITA/EAM
8.
PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:
keywords, keywords, keywords
9.
PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
keywords, keywords, keywords
10.
APRESENTAÇÃO: (X) Nacional ( ) Internacional
ITA, São José dos Campos. XXXXXXXXXXXX. Programa de Pós-Graduação em Engenharia Aeronáu-
tica e Mecânica. Área de Sistemas Aeroespaciais e Mecatrânica. Orientador: XXXXXXXXXX. Defesa em
XXXXXXXX. Publicada em 2099
11.
RESUMO:

12.
GRAU DE SIGILO:
(X) OSTENSIVO ( ) RESERVADO ( ) CONFIDENCIAL ( ) SECRETO