3 posts / 0 new
Last post
Electronic Fuel injection control with FPGA

I am contemplating an EFI setup with the use of an FPGA rather then the more common place CPU solutions. My justification for doing so is the desire to operate the EFI contoler as a state machine with the external stimuli providing the change states.

I had asked FFD to post his

I had asked FFD to post his question here as a good topic for the kind of ideas and factors that go into small system design.
So first you probably could implement an EFI controller in FPGA; it sounds like a fit as there are state machines, a real time cycle in the form of a firing cycle as it relates to the turning over of the engine, and we don’t normally think of an FPGA “crashing” much in the way we think of microcontrollers.
There are three basic architectures that come to mind: a microcontroller only, an FPGA only and a combination of FPGA and microcontroller.
An FPGA has the attributes of being able to do things in parallel, for example you could have a 36bit buss of results available on a clock edge.  There is also some implied table driven dataflow under the parallel processing, essentially a calculated, pumping data-pusher like a systolic processors as an extreme example.
So two ways of creating data in an FPGA: Calculating mathematically or indexing table data:  Creating the table data is kind of the start of the problems of a processor-less design, in fact there usually is a processor hanging around for housekeeping purposes.
So while an EFI would seem to be comprised of lots of tables and maybe lots of things in parallel, thinking it through further starts to emphasis the serial aspects and the high number of computations needed to create the table data or manipulate it further or to just arrive at a couple of values: on/off times for injectors and spark.
So we start to see we can’t get away from the needs for some sheer computation: For example let’s say we have a fuel air map in a table.  This table then needs to be modified further based on a lot of inputs; looking at the setup software for Megasquirt there are at least 6-10 additional maps of modifying factors for things like temperature and other A/D driven inputs, so either you have lots of versions of tables representing the various influences of other inputs or you would need something to calculate new values for the tables.  Things start to get a little squirrely when talking about modifying the datatables for other inputs; do you modify the whole table including values you probably wont use? Or do you just modify the values that most likely will get referenced? If the latter how do you determine which table values are influenced by other inputs?  At this point you are returning back to serial processing or doing lots of parallel processing and throwing away 99.9% of the work. For example: Multiplying Table A 16x16, times Table B 16x16, Modify by Table C 16x16, etc etc just to use one value when done.
We also don’t really need a lot of parallel if we think about it; basically in a processor version of an EFI the processor is either controlling the open/close times of the injectors or setting up timers; most likely it is manipulating timers that have a free-running aspect to them; I.E. reloading timers.  Same thing for spark, basically the timer output is a signal with start –time, frequency and duty cycle under control.
So given that we probably need a processor for housekeeping and loading data tables, I would also state that if we set aside the conversation about the output timers/state machines, that the EFI in general is really working serially for the most part (as opposed to lots and lots of parallel.)
The processor would start a run/main loop of calculating the fuel/air proportion and modify the pulse width by lots of others measures, basically A/D driven values (MAP sensor, head temperature, throttle position etc) and table modifiers based on some additional input like wide open throttle switch. At the end it might have calculated two values of interest: the PWM characteristics of the injector and the PWM characteristic of the spark.  In reality there is a LOT of other math being done for gauges and datalogging as well as other calculations. 
So at the end of the exercise I would say that you would need to write enough FPGA code to simulate a processor, and its firmware.  Every new value you would need to have calculated would have to have a data source and a place to put the result as it relates to the dataflow, and truthfully time is a factor as things are probably pipelined so where you inject data and when becomes important.
I think a good rule of thumb is if you have to write something big to simulate a processor, then use a processor.
As far as the time based outputs, these would lend themselves to state machines. And while state machines could be used but I would bet that they look a lot like generic self-reloading timers as you would need to tell it the start and end values as a function of counted clock pulses.
Now my personal opinion would be that the magic juu-juu in a controller like MegaSquirt is in the sheer quantity of code written to do all off the math, and that it represents hundreds of man-hours of coding.  Whether than being written in C/Assy for a microcontroller or Verilog/VHDL for an FPGA, the effort would require similar times for development, given that you can simulate a controller or FPGA equally.
Given that timers are built in to microcontrollers, including A/D convertors  and things like CAN controllers, I don’t know that FPGA’s can replace any large part of the design too easily on low quantity designs and even on large quantity designs you would need a way to make changes.  You would also need the support not normally built into an FPGA to support it for example the A/D converters.
The final perceived weakness of the processor is crashing, however there are many good techniques for keeping a processor running correctly.
This isn’t meant to say there isn’t a lot of fun and educational value to be had from working FPGA’s, this is just my gut analysis on how I would personally look at some architectural choices when comparing processor to FPGA.

good point about the support

good point about the support from the MS, yet I think the PRU cores in the Beaglebone Black are worth a look.

Log in or register to post comments