The automotive industry is constantly striving to reduce costs but at the same time introduce new and innovative comfort and convenience features to meet customer demand. Almost all automotive companies have adopted various busing systems to reduce wiring complexity and weight, and hence overall costs. This also results in increased fuel efficiency.

Although flexible topologies are ideal, the need exists for global standards to offer better business cases to suppliers, which would ultimately lead to greater competition and lower prices. J1850 (in the U.S.) and the ubiquitous Bosch™-defined Controller Area Network (CAN) (in Europe) are the most popular standards to date, but in some applications can be considered overkill.

In such applications you could consider using LIN as an alternative. The Local Interconnect Network (LIN) is a singlewire UART-based networking architecture originally developed for automotive sensor and actuator networking applications. The LIN master node connects the LIN network to higher-level networks like CAN, extending the benefits of networking all the way to the individual sensors and actuators.

In addition to CAN, LIN also complements Media Oriented Systems Transport (MOST) for high-speed data rates and FlexRay for safety-critical applications such as steer- and brake-by-wire. Figure 1 shows the relative cost per node and speed of various automotive networks.

Conceived in 1998, the LIN consortium comprises car manufacturers Audi™, BMW™, DaimlerChrysler™, Volvo™, and Volkswagen™. LIN is an inexpensive serial bus used for distributed body control electronic systems in vehicles. It enables effective communication for smart sensors and actuators where the bandwidth and versatility of CAN is not required. Typical applications are door control (window lift, lock, and mirror control), seats, climate regulation, lighting, and rain sensors. In these units the cost-sensitive nature of LIN enables the introduction of mechatronic elements such as smart sensors, actuators, or illumination. They can be easily connected to the car network and become accessible to all types of diagnostics and services. Outside the automotive sector, LIN is used for machine control as a sub-bus for CAN.

A LIN network comprises one master node and one or more slave nodes. All nodes include a slave communication task that is split into a transmit and a receive task, while the master node includes an additional master transmit task. The communication in an active LIN network is always initiated by the master task: the master sends out a message header that comprises the synchronization break, synchronization byte, and message identifier.

Exactly one slave task is activated upon reception and filtering of the identifier, which starts the transmission of the message response. The response comprises two, four, or eight data bytes and one checksum byte. The header and the response part form one message frame.

The identifier of a message denotes the content of a message but not the destination. This communication concept enables the exchange of data in various ways: from the master node (using its slave task) to one or more slave nodes, and from one slave node to the master node and/or other slave nodes. It is possible to communicate signals directly from slave to slave without the need for routing through the master node, or broadcasting messages from the master to all nodes in a network. The sequence of message frames is controlled by the master and may form cycles including branches.

Flexible LIN Solution
Programmable logic has long been accepted as an effective way to bring designs to market quickly and also allow design flexibility right up to production and beyond. Historically, this time-to-market advantage and flexibility had to be balanced with higher component costs.

But times have changed. PLDs cost much less and can now be used in high-volume, cost-sensitive applications such as mobile phones, PDAs, and automotive infotainment systems. To enable designs to be brought to market quickly, some Xilinx AllianceCORE™ third-party IP providers have developed robust and fully verified IP cores aimed at FPGA and CPLD architectures. One example is their LIN core, which occupies a fraction of a low-cost FPGA (for example, 13% of a 200,000 system-gate device), thus leaving space for additional LIN nodes, CAN nodes, UARTs, soft core processors, or simply glue logic.

The LIN interface – whether implemented in programmable logic, ASIC, or ASSP – is approximately half the cost of a CAN node.

LIN Bus Benefits
The reliability of LIN is high, but it does not have to meet the same levels as CAN. A LIN bus is designed to be a logical extension to CAN. It is scalable and lowers the cost of satellite nodes. No crystal oscillator or resonator is required. It is easy to implement, has a low reaction time (100 ms max), and predictable worst-case timing.

The LIN bus can be implemented using just a single wire, while CAN needs two wires. This means that a LIN network can also be lower in cost through simpler connectors and wiring – thus also reducing the weight of wiring, increasing fuel efficiency, and reducing handling time and manufacturing costs. CAN also needs a 5V supply for the bus, whereas LIN only requires 2V.

Table 1 shows the relative merits of LIN versus CAN.

Table 1 – CAN versus LIN

Automotive Network	Speed	Cost Per Node	Requirements	Size in Programmable Logic
CAN	Up to 1 Mbps	$2	Crystal oscillator, two wires, 5V bus supply	348 slices (FPGA)
LIN	20 Kbps	$1	Single wire 40M line length	256 slices (FPGA) or 216 macrocells (CPLD)

In summary, LIN offers these benefits:

• Complementary to CAN as an ultralow- cost sub-network
• Self-synchronization mechanism means no quartz oscillator required
• Low-cost silicon implementation using on-chip UART or SCI
• Single wire + low baud rate = reduced harness cost
• No protocol license fee

• Software: bit bashing
• Software: UART implementation
• Hardware: MCU with dedicated LIN port
• Hardware: PLD

Software: Bit Bashing
A LIN node can be implemented in many microcontrollers (MCUs) with no additional hardware except for a physical layer driver device. It can be implemented using existing on-chip MCU resources such as timers, GPIO, and interrupts – effectively “bit bashing.”

This type of implementation does have restrictions – designers must adhere to strict real-time programming constraints to meet the full LIN specification. This is expensive with respect to MCU timing and on-chip resources and leaves very little bandwidth for other application code.

LIN nodes based purely on “bit bashing” may also be complicated to test, particularly when integrated with existing RTOSs. With this type of implementation, it would be very difficult to achieve accurate bit timing measurement and control and may not be power efficient or practical.

Software: UART Implementation
LIN was originally conceived to make use of existing UARTs within standard MCUs, along with on-chip timers, GPIO, interrupts, and serial ports. This is a better way of implementing than simply “bit bashing” but may have certain limitations in designs that already use the on-chip serial port for other tasks.

This implementation may also burden the application code with LIN protocol requirements and will complicate the design and testability of the code. This method also needs to be complemented with GPIO functionality for error checking and synchronization purposes and requires CPU activity throughout LIN message exchange. Therefore, it is not the most power-efficient solution.

Hardware: MCU with Dedicated LIN Port
An MCU with dedicated LIN port may appeal to more designers, as it uses off-the-shelf verified silicon. Thus, it will not burden the software application with LIN protocol processing, as shown in the previous examples. This type of micro is well suited for CAN-to-LIN bus bridging applications where a need exists to pass data between the two networks. This implementation also tends to be less power hungry than the equivalent software solution.

As with most emerging networks, however, the availability of silicon and relatively high cost may be an issue and create long lead times – so forward planning is a must with respect to ordering devices. One of the potential downfalls of using these devices is when more than one LIN is needed. For example, in an ECU gateway, you may need to use more than one MCU – which will impact part costs, manufacturing costs, stocking costs, and PCB complexity.

If your design requires something outside of the specification provided by the silicon vendor, this may also cause issues, as these fixed function parts allow little or no flexibility for customization. The devices still require an external bus transceiver chip and a degree of real-time processing in the MCU.

Distributed MCU solutions can also result in complex design and test issues associated with software-based designs; designers may need to explore all potential fault and interrupt loop states so that no strange indeterminate states occur. Exhaustive testing is costly, however, and the test vectors can take longer to write than the design code itself.

Hardware: Programmable Logic Device (PLD)
LIN implemented in PLDs offers similar benefits to LIN implemented in an MCU-dedicated hardware peripheral. They do benefit from being implemented in generic devices that are off-the-shelf, low cost, and low power. This means that time to market is extremely quick and easy.

The LIN implemented in PLD hardware does not suffer from complicated test issues, as testing is much simpler and determinant than software-based designs. PLD LIN does not burden the software application with LIN protocol processing. It allows for accurate LIN timing control and does not require a crystal oscillator in slave mode, thus saving costs, board space, and power consumption.

PLDs are generic devices. They do not incur non-recurring engineering charges and can be used across many projects. One of the key advantages is the ability of the devices to be programmed in-system, so changing the hardware from master to slave is a breeze. As with MCU designs, the PLD needs an external transceiver device to drive the line.

The main downside to using PLDs? You may not be conversant with the design flow, so this may not be your most natural design route – but it is certainly worth trying. In more integrated higher end designs you will still need some sort of processor support, but this can be achieved by using an embedded soft-core processor such as MicroBlaze™, a lowcost 32-bit RISC processor.

LIN System Development
Automotive designers have a dilemma when adopting a new bus standard: Should they wait for standard silicon devices or try to develop an ASIC with a semiconductor supplier in advance of a final agreed and verified protocol specification? Some specifications take years to be agreed upon, verified, and ratified, so many semiconductor suppliers are loath to start designing devices before the specification is frozen.

To take advantage of new busing networks in advance of fixed specifications, designers are turning to soft IP cores embedded within programmable logic devices. This allows designers to try out new ideas risk-free and add in customized solutions within the bounds of the protocol. This approach also allows cut-down versions of the full interface if not all of the features are required – thus saving even more silicon area.

Now that programmable logic prices have dramatically dropped, they can even be considered a viable way of designing production solutions as well as prototype builds. A key benefit of having a LIN interface embedded within a PLD in the form of an IP core is that it can be reconfigured remotely to be either a master or a slave node, thus aiding greatly the test and design phases. Even in field fault diagnosis and vehicle maintenance, the ability to make nodes either master or slave may be beneficial. In the case of a non-volatile CPLD, reconfiguring the node is simply a matter of erasing the device and reprogramming it with a new personality.

The ability to switch between master and slave in the same device means that inventory and stocking costs are reduced – plus there is only the need to qualify one device rather than two, thus saving the lengthy device qualification time and costs associated with it.

PLDs from Xilinx are offered in the extended temperature range of -40°C to +125°C for automotive applications. PLDs come in two main types: the larger FPGAs and simpler, low-power CPLDs.

Conclusion
The LIN bus can be used as a cost-effective alternative to CAN in low-speed automotive and industrial networks. To add even more flexibility to the network, the LIN interface can be implemented in reconfigurable logic, which is not only low power but can be reconfigured remotely to be either a master or slave in the device.

The ability to reconfigure the device to either node can help with fault diagnosis in the field, test in development, and also cut down on inventory by only stocking one device. This also reduces device qualification time and costs.

For more information, visit these websites: CAN – www.can.bosch.com; LIN – www.lin-subbus.org; LIN IP core – www.intelliga.co.uk; Xilinx automotive devices – www.xilinx.com/automotive/.

LIN IP Cores and LIN Application Note

LIN IP Cores and LIN Application Note Xilinx currently has two AllianceCore partners that offer fully verified LIN IP cores: Intelliga Integrated Design Ltd. and CAST™ Inc. Further details of these IP cores can be found at www.xilinx.com/ipcenter/. You can download Xilinx application note XAPP432, “Implementing a LIN Controller on a CoolRunner-II CPLD,” to use in an existing CoolRunner-II design, or simply to understand how to design your own LIN network. The application note is available at www.xilinx.com. For more information, please e-mail the automotive team at automotiveteam@xilinx.com. Note: The LIN IP Core from Intelliga Integrated Design Ltd. and CAST Inc. are fully supported for use in automotive designs. The LIN implementation in XAPP432 is a reference design and should be used for evaluation purposes only.

Printable PDF version of this article with graphics.  (9/15/04) 260 KB