Why aren't FPGA's used more often for ECU's?

[280Z28]

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?" I suppose only time whatever comes from my efforts will tell....

[kcelectronics]

It may be the harsh electrical environment? The wiring on any automobile is very "Noisy"! and the voltage can swing from less than 10v when starting to over 14v (this is not the main issue, and a stable supply voltage can easily be built), But superimposed on the DC voltage can be large voltage spikes, (Ignition voltages, relays switching High currents, Etc.) all of these can cause faulty signals.

 

Of course, all of these issues can be addressed with enough time and R+D.

 

I wish you well and keep us informed, with your progress, and as you may know several companies, who now produce after-market ECU's, started this way, and went on to become famous suppliers to the "Motor Racing" world.

[280Z28]

Man this is painfully expensive for something I don't even know will actually run

 

Relays are easy to drive with special darlington transistors that have built in diodes to handle inductive back-current. I have a nice stable voltage supply in my test mule as well. Thankfully most of those issues you mentioned are well-covered online, as even the Megasquirt has to deal with them. In most ways, I'm even going to hook this up similar to the MS system, just hoping to provide a bit more powerful control over the system in the end.

[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.

 

[280Z28]

And now I add spark to the engine....

 

Ignition coil driver.

 

[mobythevan]

The only reason I see that FPGA's aren't used more is handling analog to digital conversion. The processor works better for that. But if everything was digital or the processor is used for that function and then like you say everything is sent over to the FPGA in digital format then it could be used.

[Jolane]

Why not just use a mixed signal processor? Everything can be done with very few components in this manner. As to why they are aren't used more often...I guess they really aren't needed. You don't need 1/500th degree resolution on the crankshaft. Engines are systems that can tolerate less resolution. Reliability is much more important. I believe Ford (or was it GM, I can't remember now) uses the Motorola 6811 based systems with 2MHz processor speeds. With efficient code writing (say in Assembly, or even machine language), the greter speeds are not required. There are many tricks that can be played also during processing to reduce the latency times.

 

Hopefully you have a scope and signal generator to run this on before using a real engine. I found that my digital scope was a life saver in checking the timing sequences.

 

Good luck,

Joshua

[280Z28]

The only reason I see that FPGA's aren't used more is handling analog to digital conversion. The processor works better for that. But if everything was digital or the processor is used for that function and then like you say everything is sent over to the FPGA in digital format then it could be used.

 

The NI FPGA card I'm getting has 8 16bit analog inputs that can be accessed directly from code. For inputs that I don't need sitting on the 40MHz clock I have 32 more 16 bit inputs on my M series card.

 

I'm setting up the FPGA to run the "bare minimum" required to run the motor. I'm communicating with it from a host computer to handle things like short term and long term fuel trims and the AI networks.

 

Why not just use a mixed signal processor? Everything can be done with very few components in this manner. As to why they are aren't used more often...I guess they really aren't needed. You don't need 1/500th degree resolution on the crankshaft. Engines are systems that can tolerate less resolution. Reliability is much more important. I believe Ford (or was it GM' date=' I can't remember now) uses the Motorola 6811 based systems with 2MHz processor speeds. With efficient code writing (say in Assembly, or even machine language), the greter speeds are not required. There are many tricks that can be played also during processing to reduce the latency times.

 

Hopefully you have a scope and signal generator to run this on before using a real engine. I found that my digital scope was a life saver in checking the timing sequences.

 

Good luck,

Joshua[/quote']

 

It's hard to find items that can interface easily with my host computer. The NI stuff offers easy very high speed DMA transfers between my cards. If I wanted to do "basic" fuel injection, I would do a project focusing on adding sequential fuel injection and individual cylinder trims for spark and fuel to the Megasquirt system.

 

I'm actually targeting my research towards some other stuff which will have EXTREME processing requirements. I want to see what modern processors have to offer in a control system. By the time I'm ready to put this thing on the market, I expect this kind of power will be available in chips for embedded applications. They might not be priced attractive to OEMs, but they would be fine for a relatively low volume aftermarket application.

 

I'm not discounting the Megasquirt, as that would be quite an advanced and very beneficial project in itself. I just know that after I get that section done, I'll be stuck with nothing going into the section I really wanted to do.

 

I have a function generator, two NI DAQ cards (listed in the first post), and a Fluke 88V/A meter on my bench right now (actually the second NI card isn't here yet, so after that arrives then they'll all be on my bench).

 

On a side note, the Fluke was as good a purchase as I have ever made...that thing is amazing.

[280Z28]

Here's where I am right now on the core

 

[280Z28]

Alright I know I made this thread asking for criticism of the FPGAs, and I definitely got that

 

On a slightly different note, can you think of any reason why I'll be SOL trying to make a controller if I'm using an FPGA like I'm talking about in this thread?

[mobythevan]

I can't think of any big reasons, at worse case you can always instantiate a small processor core in the FPGA to handle overhead and coordination of events. I work with FPGAs at my job. I considered using an FPGA when I first started looking at megasquirt 3 years ago. The reason I considered it was because I had some old test boards here at work that were scrap, so I could use one for free. I still have one of the boards, it was designed in MArch 1999, it has an ORCA 2T26 part on it and 96 I/O that are routed to two pin headers. The problem is that it was never designed with analog to digital circuitry on the board so I gave up and just went with a more tried and true setup. But don't let that discourage you, it is a lot of fun to work with FPGAs and design your own controllers. Over the years I have been able to work with ORCA parts, Xilinx parts and Altera parts. You mentioned the spartan series, that would be a great choice for this project.

 

At one time or another I have tried everything for making my car computer, even etching my own double sided board. It was all fun and good learning, but in the end I went with the better quality boards and kits from Bowling and Grippo. It is just really time consuming and expensive to do one off PCBs that are quality units. But if you can start with a developement kit that gives you the FPGA on a board and fits your needs for I/O you are miles ahead.

[280Z28]

Sweet I really never would have guessed how many people work with these things.

 

I redesigned what I did above to fit all on one VI instead of calling all the sub-VIs. Now I can optimize the thing better and can use the sychronization and memory functions to control timing precisely.

 

My injectors and coils are now updated every time the crank position engine detects movement (interpolated, degrees * 100).

 

Fuel pump and cooling fans took up 747 out of 14336 SLICEs (logic blocks on the board). Adding an adjustable injector driver capable of bank, TBI, or sequential injection for any number 1-16 cylinders (easier than it sounds like) bumped that to 1125 used (not quite done here, need to do some boolean logic on the final output but that's minimal resources). I'm guessing there's some decent fixed overhead The injection block/loop is wayy more complicated.

[280Z28]

I don't have my R series yet so I can't test it, but this should work, at least in a form very similar to this. Note that the loop across the top of the first image is a single cycle timed loop. The loop runs a complete pass on the whole thing in 1 clock cycle at 40MHz. A complete fuel and spark update together will take around 10 clock cycles because each of the memory reads (sunglasses) takes a cycle, plus there are 2 parallel multiplies at 1 cycle for both (parallel), plus one clock cycle to run through the rest of the output, literally :faint: This thing is "only 40MHz" but the logic circuits run as fast or faster than a P4 3.0GHz in series and parallel paths run independently so it's like you have as many CPU cores as you want/can fit on the chip. At $17 for a Spartan core (for a release version; my dev kit is crazy expensive), I am REALLY digging this system

 

Angle detection:

 

http://www.280z28.org/images/z/ecu/engine_speed_angle_detect_1.png

 

Handling updates to angle changes:

 

http://www.280z28.org/images/z/ecu/fuel_spark_1.png

 

Side note: 30" Dell =

[z-ya]

I would think that if you need to some timing logic outside of what the processor can do, a small PAL would probably do the trick. FPGAs are way overkill for use as glue logic in a Megasquirt. The processor can do 99.9% of everything.

 

Now to use an FPGA to exclusively do all engine management fuctions would not be a good choice. Engine management system have many parameters, including multiple fuel and ignition maps. Memory is required to store all this information. When you instantiate memory in an FPGA, you suck up a lot of potential logic. Memory is never a good use of an FPGAs resources. You would also need to design a serial port to change the paramenters. Also, because an FPGA is volitile, each time the MS is turned off, it would loose it's program. You would need to burn the serial prom in circuit each time you made change to the map. A lot of work when the processor can do all but a few rare cases where timing beyond its precision is required.

 

Lastly, you need different, and sometimes costly tools to develop FPGAs. You need an HDL compiler, simulator, and synthesis tool. If you don't know how to write VHDL or Verilog, then you really have an up hill battle. With the procerssor all you need is a free compiler, and knowlege of C. Or do no programming as all of the work is already done for you by the MS developers.

 

My $0.02? Stick with the $10 processor.

[280Z28]

I would think that if you need to some timing logic outside of what the processor can do' date=' a small PAL would probably do the trick. FPGAs are way overkill for use as glue logic in a Megasquirt. The processor can do 99.9% of everything.

 

Now to use an FPGA to exclusively do all engine management fuctions would not be a good choice. Engine management system have many parameters, including multiple fuel and ignition maps. Memory is required to store all this information. When you instantiate memory in an FPGA, you suck up a lot of potential logic. Memory is never a good use of an FPGAs resources. You would also need to design a serial port to change the paramenters. Also, because an FPGA is volitile, each time the MS is turned off, it would loose it's program. You would need to burn the serial prom in circuit each time you made change to the map. A lot of work when the processor can do all but a few rare cases where timing beyond its precision is required.

 

Lastly, you need different, and sometimes costly tools to develop FPGAs. You need an HDL compiler, simulator, and synthesis tool. If you don't know how to write VHDL or Verilog, then you really have an up hill battle. With the procerssor all you need is a free compiler, and knowlege of C. Or do no programming as all of the work is already done for you by the MS developers.

 

My $0.02? Stick with the $10 processor.[/quote']

 

This isn't a MS at all I only have it in this forum because there's no "aftermarket ECU" forum. The FPGA will definitely be used in this app (not overkill).

 

The one I'm using has 196kb of ram attached.

[proxlamus©]

I wish i spoke spanish

[z-ya]

The FPGA has non-volitile RAM in it (inlcuding the CLBs?)? Are you going to plug these NI PCI cards into some sort of PCI backplane? Is it going to be a PC motherboard? I guess I haven't been following your project very closely, sorry.

 

I thought you wanted to add some glue logic to the proto area on the V3.0 PCB.

 

Keep us posted on your project.

[280Z28]

The FPGA has non-volitile RAM in it (inlcuding the CLBs?)? Are you going to plug these NI PCI cards into some sort of PCI backplane? Is it going to be a PC motherboard? I guess I haven't been following your project very closely' date=' sorry.

 

I thought you wanted to add some glue logic to the proto area on the V3.0 PCB.

 

Keep us posted on your project.[/quote']

 

Dude, I got a Dell!!

 

Seriously though, yes, my dev system is a full blown PC.

 

Edit: and it is a dell

[z-ya]

Hopefully it doesn't have a battery 8^)

[280Z28]

Here's one example of a more advanced feature I'm researching:

 

Current idle control systems often use a PD controller on the spark and a PID controller on the IAC valve. This provides rather mediocre control over big cams. I'm investigating a system that works somewhat like follows:

 

1. Monitor the value and first and second derivatives of the speed at 45* past TDC for each cylinder. That's 8 cylinders x 3 data points per cylinder, IE wayy too much to handle for an embedded system (an FPGA could do it but it'd take an unreasonable amount of gates).

2. Calculate the first principle component of the inputs affecting the desired speed with first and second derivatives 0 for each for of the 8 cylinders.

3. Optimize a single in, single out function for controlling spark on a cylinder-by-cylinder basis. The input is a linear combination of the measured inputs. The output would be trained in a special neural net (a simple one too...) and/or genetic algorithm. A lookup table can then be generated and put in the ram attached to the FPGA and applied rapidly by the output controller.

4. The function continuously trains with a low learning coefficient to keep it running optimally in various weather conditions, etc.

 

The IAC valve will end up as a boring old controller because they work fine. The spark has a more immediate effect on the "jitter" you feel from a big cam motor though.