|
Xilinx programmable logic is ideal for communicating across time-triggered networks.
For future automotive in-vehicle control
applications, time-triggered networks will
provide the backbone for reliable fault-tolerant
communications among control
network nodes.
Although the automotive industry is
pushing towards an agreement on a single
control network standard, don’t assume that
one single standard will dominate. There will
still be a need to communicate across time-triggered
networks with different specifications
and protocols – a type of gateway.
However, because some of these protocols
are still under review, developing and
testing such a gateway design with fixed
interfaces cannot be future-proof. The
gateway core and its associated test bed
must be configurable and flexible to
accommodate future changes.
This is an ideal situation to exploit the
power and flexibility of programmable
logic. As researchers at PEI Circuits and
Systems Research Centre (CSRC) at the
University of Limerick in Ireland, we have
developed a Xilinx FPGA-based configurable
frame generator/analyzer that can
verify a gateway design for time-triggered
networks, for real-time applications.
Architecture
The Frame Generator and Frame Analyzer
are two distinct designs. Both are synthesized
together and placed in a Xilinx
Spartan™-II XC2S100 FPGA on an
Insight™ Electronics Spartan-II development
board.
Frame Generator
The Frame Generator generates frames
conforming to a proprietary byte-wide
protocol. The generator has the following
sub-modules:
- Transmit interfaces
- Frame generation logic
- Frame Generator state machine
- Frame sets.
Figure 1 shows the building blocks of
the Frame Generator.
The Frame Generator’s four transmit
interfaces emulate the function of sending
frames to the gateway from a time-triggered
communication controller’s
host controller. Each transmit interface
comprises three control signals and an 8-bit
port for byte-wide transmission of the
frame. The three control signals are:
- Frame Start Out
- Port Ready
- Frame End Out.
Frame Start Out signals the transmission
of a new frame.
On each rising edge of Port Ready, the
most significant byte (MSB) of the transmitting
frame is sent to the 8-bit output port.
On the falling edge of Port Ready, the
receiving side reads in the MSB of the
frame. The whole frame is broken down
into bytes like this and transmitted.
When frame transmission is complete,
a Frame End Out pulse is sent to the
receiver to indicate an end-of-frame
transmission so that the receiver then
takes the appropriate action, which is
explained later.
The Frame Generator state machine is a
13-state finite state machine that controls
the frame generation logic based on its
present state.
The frame generation logic block is
responsible for generating the right timing
and picking up the next frame to be transmitted
from the set of frames as defined in
the four frame sets.
The frame sets are the offline-defined
set of frames to be transmitted by the
Frame Generator.
Frame Analyzer
The Frame Analyzer receives frames conforming
to a byte-wide proprietary protocol
and stores them in message RAMs for
analysis.
The Frame Analyzer has the following
sub-modules:
- Receive interfaces
- Xilinx block RAMs
- 4 x 1 dual inline package (DIP)-switch
controlled demultiplexer (DMUX)
- QuickLogic™ RS-232 core.
Figure 2 illustrates the construction of
the Frame Analyzer.
The Frame Analyzer’s four receive interfaces
emulate the function of receiving
frames from the gateway by a time-triggered
communication controller’s host
controller. Each receive interface receives
frames according to a proprietary bytewide
protocol. The receive protocol has
three control signals and one 8-bit reception
port.
The control signals for byte-wide frame
reception are:
- Frame Start In
- Ready to Read
- Frame End In.
A low to high transition on Frame Start
In signals the arrival of a new frame. The
transmitter will make the MSB of the
transmitting frame available on the rising
edge of its Port Ready.
Port Ready is connected to Ready to
Read at the receiver end. On the falling
edge of Ready to Read, the byte is read into
the Frame Analyzer.
Once all of the bytes making up the
frame are received, the Frame Analyzer
waits for a Frame End In pulse. A low to
high transition on the Frame End In signals
the end of a frame reception.
The dual-port block RAMs of the
XC2S100 Spartan-II device are used as
buffers for storing frames. As the frames are
received on each of the four receive interfaces,
they are written into the four block
RAMs associated with each interface. This
is the first phase.
Once the frame reception is complete,
the mode of the Frame Analyzer is changed
from “write” to “read.”
In the second phase, the frames are read
out of the FPGA though an RS-232 connection
to a PC. The block RAMs for the Frame Analyzer are configured as 32 bits
wide and 128 locations deep.
(Although 32-bit wide RAMs
are not possible in a Spartan-II
device, 16-bit dual-port RAMs
can be configured as single 32-bit RAMs, as described in Xilinx
application note XAPP173.)
Two DIP-switches select the
RAM that the PC reads. Four
switch combinations are possible
– 00, 01, 10, and 11. Each combination
corresponds to a particular
block RAM.
The four block RAMs are
read out of the FPGA sequentially
and the frames are displayed
on the screen.
The Frame Analyzer works in
tandem with the Frame
Generator, continuously transmitting
128 frames. Accordingly,
the Frame Analyzer receives and
stores 128 frames. The frame
retrieving and displaying software
then reads those 128 frames out
of the FPGA.
Applications
PEI CSRC is researching the
development of a real-time communication
gateway for timetriggered
control networks such as
time-triggered controller area network
(TTCAN), FlexRay™, time-triggered protocol
(TTP), and byteflight™.
Some of these protocols are still under
development by their respective companies
and standards organizations – which means
that their specifications will change. This is
an ideal situation for using programmable
logic for early prototyping.
The core message router of the real-time
gateway is based on a round-robin packet
routing mechanism. To verify this functionality
in hardware, the gateway core uses programmable
logic solutions from Xilinx.
The gateway’s internal protocol is a proprietary
protocol suitable for round-robin packet
routing. The protocol conversion of TTCAN,
FlexRay, TTP, and byteflight frames to gateway
core format will be the responsibility of
their respective host controllers.
As the Frame Generator/Analyzer emulates
the interface between the gateway core
and the host controllers of TTCAN,
FlexRay, TTP, and byteflight, it makes the
verification of the gateway core independent
of the host controllers that will be
developed in due course.
The Frame Generator/Analyzer can be
configured for different frame rates, frame
sizes, and frame sequences, allowing maximum
flexibility during the testing phase to
enable hard real-time testing of the gateway
core. Network message schedules in time-triggered
networks are defined offline and
have to follow a pre-determined communication
schedule. The frame sets in the
Frame Generator allow for multiple combinations
of frame schedules, making it possible
to test the gateway’s functionality and
performance in a real-world sense.
The Frame Analyzer’s message RAMs
store all incoming frames from the gateway
in the first phase of its operation.
Upon reception of 128 frames, the
first phase of operation is complete.
The frames in individual RAMs can
be now be read out through an RS-232 connection to a PC. The analysis
of the retrieved frames will aid in
checking and verifying the following
operations of the gateway core:
- Proper Internal Frame Routing
- Data Integrity
- Non-Blocking Operation
- Dropped Frames.
Peak performance parameters
of the gateway core will be verified
by configuring the Frame
Generator/Analyzer for different
frame rates and message schedules.
Following such an approach
makes it possible to use the Frame
Generator/Analyzer to test and verify
the routing functionality of the
gateway core early in the design
phase. Figure 3 illustrates the use of
the Frame Generator/Analyzer for
this verification.
Conclusion
Using programmable logic solutions
from Xilinx, we have been able to
develop a test bed for a gateway core for
time-triggered networks at a time when
specifications are under review and qualified
silicon is not available for all of the
emerging TTPs.
The gateway core under development
will be realized using Xilinx programmable
logic solutions as well. As the intended appplication
of the real-time gateway will be in
automotives, the use of the IQ range of
Xilinx Spartan-II devices for development
and deployment will greatly reduce the cost
of induction, which is one of the most critical
factors in the automotive industry.
Using best-in-class, low-cost Xilinx
FPGAs will enable us to deliver a real-time
gateway for time-triggered networks for
hard real-time applications in the automotive
environment, with minimum costs
incurred for design, verification, and
deployment.
Printable PDF version of this article with graphics. (12/11/03) 340 KB |