Xcell Journal Home
  Xcell Journal Article
  Partner Yellow Pages
   
  Xcell Archives
  Order Free Xcell Journal
  Comments & Suggestions
  Write Articles for Xcell

    

Home : Documentation : Xcell Journal Online : Article

(NOTE: For faster downloading, all online articles are TEXT ONLY versions with no graphics. To view the complete article with graphics, download the PDF version at the end of this article.)

Verify Gateway Designs for Time-Triggered Networks

by Shehryar Shaheen, Research Engineer, PEI Circuits and Systems Research Centre, University of Limerick
shehryar.shaheen@ul.ie (12/11/03)

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. PDF logo (12/11/03) 340 KB

 
Jobs Events Webcasts News Investors Feedback Legal Sitemap
© 1994-2008 Xilinx, Inc. All Rights Reserved.