Why aren't FPGA's used more often for ECU's?
08-13-2006, 03:44 AM
#1
On The Tree
Thread Starter
iTrader: (1)
Join Date: Jul 2002
Location: Austin, TEXAS > *
Posts: 192
Likes: 0
Received 0 Likes
on
0 Posts
Why aren't FPGA's used more often for ECU's? They're relatively cheap and offer incredibly more accurate hardware event timings than processor based systems. It seems like they'd be very attractive for engine control systems. Anyone know why they aren't used more often?
I'm going to be adding an FPGA to my hardware setup to offload the precision timing tasks from my main computer. It should greatly improve accuracy (25ns event timing resolution) and reliability (keeps running even if the host computer crashes). I'll also be able to focus the current system processors on the AI systems without losing clock cycles to the mundane tasks.
I'm looking at the NI PCI-7833R to complement my current NI PCIe-6259. These are much more expensive than some other systems, but they allow me to focus on software tasks (AI systems, etc) during the development stages with very little time overhead required to have working hardware. Once my development is successful, I'll probably end up moving to a custom board based on the Xilinx Spartan-3L or similar to save money (combining the required features from my 2 NI boards into a single module optimized for the application).
I really like certain features, like the fact that any of the 96 digital lines can be used for any sort of independent or synchronized precise timing output, including PWM on a 40MHz output clock. 25ns resolution means you can control individual injectors or ignition coils down to 1/500th of a degree of crank rotation at 12,000rpm.
At this point I find I'm asking myself, "Am I dedicated, or am I just stupid?" :o I suppose only time whatever comes from my efforts will tell....
I'm going to be adding an FPGA to my hardware setup to offload the precision timing tasks from my main computer. It should greatly improve accuracy (25ns event timing resolution) and reliability (keeps running even if the host computer crashes). I'll also be able to focus the current system processors on the AI systems without losing clock cycles to the mundane tasks.
I'm looking at the NI PCI-7833R to complement my current NI PCIe-6259. These are much more expensive than some other systems, but they allow me to focus on software tasks (AI systems, etc) during the development stages with very little time overhead required to have working hardware. Once my development is successful, I'll probably end up moving to a custom board based on the Xilinx Spartan-3L or similar to save money (combining the required features from my 2 NI boards into a single module optimized for the application).
I really like certain features, like the fact that any of the 96 digital lines can be used for any sort of independent or synchronized precise timing output, including PWM on a 40MHz output clock. 25ns resolution means you can control individual injectors or ignition coils down to 1/500th of a degree of crank rotation at 12,000rpm.
At this point I find I'm asking myself, "Am I dedicated, or am I just stupid?" :o I suppose only time whatever comes from my efforts will tell....
Last edited by 280Z28; 08-13-2006 at 03:56 AM.
08-13-2006, 04:16 AM
#2
TECH Regular
Join Date: Mar 2002
Posts: 433
Likes: 0
Received 0 Likes
on
0 Posts
I guess it's the old story..SW. Manufacturers trying to support as many cars as possible with the same basic SW modules with minimal modification work etc. Going to FPGA could cause more trouble with tailoring car specific solutions. Processor based systems do have better abstracted development tools making this easier, at least for the moment. But yes, FPGAs do have huge potential for combining complex control( using Altera NIOS, Xilinx MicroBlaze..), massive calculation power and accurate IO. You're not alone 
08-13-2006, 12:54 PM
#5
Simple, cost.
Do you have much realtime embedded experience? While your goals for precision are noble, they are a bit overzelous.
Take a long hard look at the precision and rate of change in your control target before you make the controller over complicated. Also, consider the speed of your inputs to the system. If your controller can respond in nanoseconds, that won't do you much good if your actuators are working in the milisecond range.
Personally, i would focus on getting the most execution rate you can for code and aim for hardware speeds about 4x your fastest I/O. That should keep you in good shape on nyquist for your fastest signals.
Engines are pretty "slow" when it comes control systems.
my .02
Do you have much realtime embedded experience? While your goals for precision are noble, they are a bit overzelous.
Take a long hard look at the precision and rate of change in your control target before you make the controller over complicated. Also, consider the speed of your inputs to the system. If your controller can respond in nanoseconds, that won't do you much good if your actuators are working in the milisecond range.
Personally, i would focus on getting the most execution rate you can for code and aim for hardware speeds about 4x your fastest I/O. That should keep you in good shape on nyquist for your fastest signals.
Engines are pretty "slow" when it comes control systems.
my .02
08-13-2006, 01:36 PM
#6
TECH Regular
Join Date: Mar 2002
Posts: 433
Likes: 0
Received 0 Likes
on
0 Posts
I'd guesstimate suitable FPGAs are in the $20-30 range, less if used only to accelerate some of the functions, say, fueling and ignition.
FPGA could open new approaches, like calculating individual cylinder fueling from WB feedback per engine revolution without fearing that something else would interrupt the calculation..
FPGA could open new approaches, like calculating individual cylinder fueling from WB feedback per engine revolution without fearing that something else would interrupt the calculation..
08-13-2006, 02:20 PM
#7
On The Tree
Thread Starter
iTrader: (1)
Join Date: Jul 2002
Location: Austin, TEXAS > *
Posts: 192
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by pekkaz
I'd guesstimate suitable FPGAs are in the $20-30 range, less if used only to accelerate some of the functions, say, fueling and ignition.
FPGA could open new approaches, like calculating individual cylinder fueling from WB feedback per engine revolution without fearing that something else would interrupt the calculation..
FPGA could open new approaches, like calculating individual cylinder fueling from WB feedback per engine revolution without fearing that something else would interrupt the calculation..
The Xilinx chips give you 3M gates and 102 I/O for under $20, and it's clocked faster than my dev system.
Trending Topics
08-13-2006, 03:15 PM
#8
On The Tree
Thread Starter
iTrader: (1)
Join Date: Jul 2002
Location: Austin, TEXAS > *
Posts: 192
Likes: 0
Received 0 Likes
on
0 Posts
A basic fuel injector that can work for a single injector (sequential injection), an MPFI injector bank (batch injection), or TBI. Just drop as many (or as few) as you need on the system VI and there you go.
Edit: I know it has bugs but the basic sequence should work pretty easily.
Edit: I know it has bugs but the basic sequence should work pretty easily.
08-13-2006, 04:26 PM
#10
TECH Senior Member
Why aren't FPGA's used more often for ECU's?
Originally Posted by 280Z28
A basic fuel injector that can work for a single injector (sequential injection), an MPFI injector bank (batch injection), or TBI. Just drop as many (or as few) as you need on the system VI and there you go.
Edit: I know it has bugs but the basic sequence should work pretty easily.
Edit: I know it has bugs but the basic sequence should work pretty easily.
The Xilinx FPGA's at $20-$30 in quantity cost too much for an OEM to put them on a PCM; the typical GM PCM has about $50 (or less) worth of parts on it.
An individual may be willing to spend the money on several, but GM (or any other OEM) is not willing to increase the cost by millions.
$0.02
08-13-2006, 04:28 PM
#11
TECH Enthusiast
iTrader: (14)
Join Date: Apr 2005
Location: NE Ohio
Posts: 591
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by 280Z28
A basic fuel injector that can work for a single injector (sequential injection), an MPFI injector bank (batch injection), or TBI. Just drop as many (or as few) as you need on the system VI and there you go.
Edit: I know it has bugs but the basic sequence should work pretty easily.
Edit: I know it has bugs but the basic sequence should work pretty easily.
08-13-2006, 05:00 PM
#12
On The Tree
Thread Starter
iTrader: (1)
Join Date: Jul 2002
Location: Austin, TEXAS > *
Posts: 192
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by joecar
Sounds like fun, but doesn't your PCM already do that...?
The Xilinx FPGA's at $20-$30 in quantity cost too much for an OEM to put them on a PCM; the typical GM PCM has about $50 (or less) worth of parts on it.
An individual may be willing to spend the money on several, but GM (or any other OEM) is not willing to increase the cost by millions.
$0.02
The Xilinx FPGA's at $20-$30 in quantity cost too much for an OEM to put them on a PCM; the typical GM PCM has about $50 (or less) worth of parts on it.
An individual may be willing to spend the money on several, but GM (or any other OEM) is not willing to increase the cost by millions.
$0.02
The Commander 950 couldn't run an LS1 anyway which is what's going in the car.OEM applications are not at all my target market with this project.
Actually... I'd guess I'm still a couple years out on having a target market at all. 
08-13-2006, 07:54 PM
#14
TECH Regular
Join Date: Jan 2002
Location: Orlando, FL
Posts: 414
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by 280Z28
A basic fuel injector that can work for a single injector (sequential injection), an MPFI injector bank (batch injection), or TBI. Just drop as many (or as few) as you need on the system VI and there you go.
Edit: I know it has bugs but the basic sequence should work pretty easily.
Edit: I know it has bugs but the basic sequence should work pretty easily.
I'm a FAE (at the distributor level) for Intel, Freescale, and Lattice (FPGA), among others. Before I became a FAE I did FPGA/ASIC/PowerPC/TI DSP designs at Lockheed. FPGAs can do many many things extremely well but you also need to look at a problem from a business level as well. Do I need a Ferrari when a Lumina will do? The Ferrari will needed highly skilled mechanics (hardware engineers) to work on it where as the Lumina can be worked on by your run of the mill garage (software engineers).
Tim
Last edited by TimZ28; 08-13-2006 at 08:01 PM.
08-13-2006, 08:11 PM
#15
On The Tree
Thread Starter
iTrader: (1)
Join Date: Jul 2002
Location: Austin, TEXAS > *
Posts: 192
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by TimZ28
I've been doing FPGA designs and embedded processor designs (PowerPC, DSP) for 12 years now. Creating an injector coil driver and creating a complete engine management system at the functionality level of today's OEM PCMs are two very different things. For a low volume aftermarket implementation I could envision using a FPGA with an embedded processor core but for OEM volumes/functionality it would not be the most efficent or cost effective approach at any level (development time, development cost, unit cost).
I'm a FAE (at the distributor level) for Intel, Freescale, and Lattice (FPGA), among others. Before I became a FAE I did FPGA/ASIC/PowerPC/TI DSP designs at Lockheed. FPGAs can do many many things extremely well but you also need to look at a problem from a business level as well. Do I need a Ferrari when a Lumina will do? The Ferrari will needed highly skilled mechanics (hardware engineers) to work on it where as the Lumina can be worked on by your run of the mill garage (software engineers).
Tim
I'm a FAE (at the distributor level) for Intel, Freescale, and Lattice (FPGA), among others. Before I became a FAE I did FPGA/ASIC/PowerPC/TI DSP designs at Lockheed. FPGAs can do many many things extremely well but you also need to look at a problem from a business level as well. Do I need a Ferrari when a Lumina will do? The Ferrari will needed highly skilled mechanics (hardware engineers) to work on it where as the Lumina can be worked on by your run of the mill garage (software engineers).
Tim
I'm working on something that would really be suited for low production aftermarket use. Some of the more interesting aspects I'm working on I can't really talk about until I figure out IP issues. :grumble: I can say I'm not going into a Ph.D. program for nothing though. At least some of my research has been/will be focused on sections of this. I just finished my BSEE and start as a grad student in what, 2 weeks now? :hmm: Man homework FTL :o
What I really need right now is a running dev system. I'd be happy I could just start it and get it to idle. Once I get the mundane "have to do" tasks out of the way I can focus on the controller.
Someone's always going to want a Ferrari though.
08-13-2006, 08:21 PM
#16
On The Tree
Thread Starter
iTrader: (1)
Join Date: Jul 2002
Location: Austin, TEXAS > *
Posts: 192
Likes: 0
Received 0 Likes
on
0 Posts
I don't have any VHDL experience from school. Thankfully the NI hardware uses LabVIEW which I already know and interfaces with my C# programs so I don't have to worry about that (for now).
My undergrad focuses were on DSP (general and realtime) and communications.
My undergrad focuses were on DSP (general and realtime) and communications.
08-13-2006, 08:31 PM
#17
TECH Regular
Join Date: Jan 2002
Location: Orlando, FL
Posts: 414
Likes: 0
Received 0 Likes
on
0 Posts
PLEASE PLEASE PLEASE take the time to educate yourself with VHDL or Verilog. I can appreciate the high level tools that exist today to aid in the development and implementation of algorithms but if you do not understand the design at the RTL level you are going to be at a severe disadvantage if you need to try and optimize the design at the gate level (timing, FPGA architecture, etc.)
I have a customer right now that has an engineer capable of writing the higher level firmware functions in their design but is unable to understand the low level world of the hardware he is working on. Because of his lack of understanding he is unable to properly debug a DDR2 memory interface. If he were able to debug the problem and allow the use of VLP modules he would save his company $ and eliminate a significant design challenge on the upcoming new design.
You will be much more marketable and effective if you can speak both software and hardware.
Tim
I have a customer right now that has an engineer capable of writing the higher level firmware functions in their design but is unable to understand the low level world of the hardware he is working on. Because of his lack of understanding he is unable to properly debug a DDR2 memory interface. If he were able to debug the problem and allow the use of VLP modules he would save his company $ and eliminate a significant design challenge on the upcoming new design.
You will be much more marketable and effective if you can speak both software and hardware.
Tim
08-13-2006, 08:51 PM
#18
On The Tree
Thread Starter
iTrader: (1)
Join Date: Jul 2002
Location: Austin, TEXAS > *
Posts: 192
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by TimZ28
PLEASE PLEASE PLEASE take the time to educate yourself with VHDL or Verilog. I can appreciate the high level tools that exist today to aid in the development and implementation of algorithms but if you do not understand the design at the RTL level you are going to be at a severe disadvantage if you need to try and optimize the design at the gate level (timing, FPGA architecture, etc.)
I have a customer right now that has an engineer capable of writing the higher level firmware functions in their design but is unable to understand the low level world of the hardware he is working on. Because of his lack of understanding he is unable to properly debug a DDR2 memory interface. If he were able to debug the problem and allow the use of VLP modules he would save his company $ and eliminate a significant design challenge on the upcoming new design.
You will be much more marketable and effective if you can speak both software and hardware.
Tim
I have a customer right now that has an engineer capable of writing the higher level firmware functions in their design but is unable to understand the low level world of the hardware he is working on. Because of his lack of understanding he is unable to properly debug a DDR2 memory interface. If he were able to debug the problem and allow the use of VLP modules he would save his company $ and eliminate a significant design challenge on the upcoming new design.
You will be much more marketable and effective if you can speak both software and hardware.
Tim
Plus directed learning is always good. 