Ref: z2717152m
In the world of motor racing, speed is everything and not just on the track. In many classes, the electronic control unit (ECU) that controls the engine has become as critical a component as the engine, the aerodynamics of the car and its driver. The ability to eke out as much performance as possible from the engine under the extreme conditions that are found on the racetrack is critical to a team's ability to stay ahead of the competition. As a result, teams need to be able to tune how the ECU behaves, and do so quickly.
At specialist ECU design company, Life Racing, systems designer Mark Colby understands just how quickly racing teams need the software in an ECU to be updated. He does not think in terms of having months or even weeks to write a new piece of software for an ECU, but days. "In motor sport you are writing software all the time. We average one software release to the car every week. Whenever the racing team thinks up a new control possibility, they will be on the phone to us," he said. "We have had just two hours to turn around a new control strategy."
The need to be able to produce software to such tight deadlines has driven not only how Colby and his small team write software but to how the hardware it runs on is put together. The hardware architecture that Life Racing developed is tuned for rapid software development. At its heart is a high-performance microprocessor and a field-programmable gate array (FPGA) that offloads tasks from the host processor that would be more complex to implement in software or slow down the core algorithms too much.
In a space of just under two years, Life Racing has gone from being a new venture for a sports-car engine manufacturer, to having design-ins in several high-profile racing engines. Life Racing was formed in April 2002 as an offshoot of the specialist engine builder, Advanced Engine Research (AER). Mike Lancaster, the managing director of AER decided it would be useful to be able to supply ECUs as well as the engine themselves. That combination came to fruition with a clean-sheet engine design for MG's Le Mans car. Life Racing's ECU has also been designed into the engines used in the cars that race in the Superfund World Series Lights championship.
For the ECU board, Life Racing opted to use Actel's ProASIC APA450 non-volatile FPGA to sit alongside the host processor, a PowerPC 565 made by Motorola. Colby was no stranger to working with Actel devices based on antifuse technology in previous projects. He chose them over volatile SRAM-based parts because the ECU designs needed an FPGA that would work as soon as power is applied to the system. The ECU cannot wait for a configuration file to be downloaded from a serial EPROM into an SRAM-based part. "The antifuse parts were also very simple in terms of board designs," said Colby.
For the new generation of ECUs, Colby needed a design where the FPGA could be reprogrammed. But he still wanted the FPGA to be live at power-on. So, the ProASIC was selected. "With flash, we still do not have to worry about boot time," he explained.
The move to the ProASIC FPGA has proved important for a number of reasons. It makes the design more flexible and it greatly reduces the number of spare boards the company has to carry for each team. Crashes and other calamities on the track can mean a team calling up for a replacement for a race the next day. "With the flash-based FPGA, the board can be made blank and programmed as necessary," said Colby. "We have the ability to ship product that is working but, in a sense, not complete. We manufacture in low volumes and so we need to pay attention to lead times."
Another reason for using a reprogrammable FPGA is that it allows more flexibility over which parts of the control run in software and which can be implemented as hardware. In the early days of motor racing with ECUs, the boards were based on designs used in road vehicles. Over time the paths taken by the racing community and the road-car builders have diverged.
Colby said the ECU in a modern car will make extensive use of engine models and use advanced processing techniques to determine how the engine is performing and avoid conditions such as knocking. In the race environment, knock detection can be as important but is handled in a different way. With a road car, it can take years to optimise the theoretical models and control algorithms for the ECU. There is no time to do that for a racing car so the engineers rely on empirical models of engine behaviour based on direct experience of how it performs on the track.
Without the use of an advanced theoretical model, latency is a much bigger issue for the racing ECU than for its road-car cousin. That means performing a lot of measurements, such as crankshaft position, in a short space of time and reacting to changes quickly. The more frequently a reading can be updated, the better the ECU can gauge how conditions are changing. For example, when pulling out of a corner, engine conditions will change rapidly. Reacting to this can mean the difference between staying in front or dropping behind a competitor with better acceleration.
Says Colby: "With a processor you may only have time to look at a signal once in a given period. The FPGA can look at the signals more frequently and make a more accurate prediction. That way, you can better handle acceleration."
The FPGA can perform pre-processing on the incoming signals, such as determining crankshaft position by letting the FPGA deal with the pattern of signals produced by the encoder. As the FPGA handles a lot of the sensor pre-processing, "there is very little to change in the software for each different engine", said Colby, which helps greatly in getting an ECU ready for each new engine.
The need to keep software simple has extended to the way that the company deals with the highly integrated host processor that is on the ECU board. That paid off in terms of getting the design up and running quickly. "With this ECU, we had it running an engine within three to four weeks of getting the board from the manufacturer," said Colby.
He said that decisions on interrupt structures and how peripherals are controlled were all informed by their effects on software complexity. For example, Colby said that peripherals will align to different clock edges used by the queued serial peripheral interface (QSPI) that features on the PowerPC embedded processor. "We would try to organise those transfers to be on different buses," said Colby, as that would simplify the programming model.
The focus on rapid software development is paying off for Life Racing, and its customers, in the highly competitive world of motor racing. It shows how critical choices, such as which FPGA to use, can pay dividends in implementing a complete system.
| Tel: | +27 11 315 8316 |
| Email: | [email protected] |
| www: | www.asic.co.za |
| Articles: | More information and articles about ASIC Design Services |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version