FPGA in ECU

klyttle
Posts: 19
Joined: Fri Jan 02, 2015 9:47 pm

FPGA in ECU

Post by klyttle »

I thought I'd share this article I found online while researching FPGA utilization in an ECU:

http://m.autosport.com/news/report.php/id/35334

Now, I know such a feature outlined in this article is currently not in the cards for this project, but as I had stated in my introduction to this forum, it could (keyword here is could) be a consideration later, especially now that rusEFI is in the works to become an LLC; this project may do well to differentiate itself from the rest of the open source ECU pack.

User avatar
kb1gtt
contributor
contributor
Posts: 3669
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: FPGA in ECU

Post by kb1gtt »

I agree that FPGA's are the cat's meow and should be something to consider on the longer term plan. They offer nS timing events, unlimited timers and signal processing that requires no CPU cycles. Mostly once you have developed 1 cyl, you can very easily scale to 48 cyl's. They are not only faster and more accurate, they scale very well.

In another thread I noted the http://papilio.cc/ which is attempting to make FPGA easy to program similar to how Aruduino's made it easy to program micro processors. Papilio has made some great progress in making FPGA programming far easier than it has been over the last several years. They are doing this with one of the largest FPGA MFG's chips known as the spartan. As luck has it, that MFG has also identified that automotive is a market worth some effort, and they make automotive grade FPGA's.

http://www.xilinx.com/applications/automotive.html
http://www.xilinx.com/training/automotive-fpga-training.htm

So I would suggest the path to FPGA would probably be to start with papilio pro, which will set up ISE PC development environment and an underlying wishbone structure. It will allow AVR style programming for soft processors, which I believe is an reasonably easy port for chibios and the current rusEFI platform. Then once it's working with these low cost off the shelf items, it would be a reasonably easy port to one of xilinx automotive grade FPGA's.

Oh, did I also mention that the papilio has the ability to connect a logic analyzer to internal registers and to internal timer bits. That's a crazy mind blowing option for FPGA approaches.
Welcome to the friendlier side of internet crazy :)

User avatar
kb1gtt
contributor
contributor
Posts: 3669
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: FPGA in ECU

Post by kb1gtt »

Logic sniffer with papilio video found here titles "How-to debug internal FPGA Logic with the $50 Openbench Logic Sniffer."
Welcome to the friendlier side of internet crazy :)

User avatar
AndreyB
Site Admin
Posts: 10747
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City

Re: FPGA in ECU

Post by AndreyB »

To be honest I simply do not know much about FPGA. I am a software developer and in the end of the day I do not really care what kind of programmable logic device is executing my code.

What problems would FPGA solve? Are there any 5v FPGA? What about ADC - do any of FPGA have analog inputs?
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

User avatar
kb1gtt
contributor
contributor
Posts: 3669
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: FPGA in ECU

Post by kb1gtt »

FPGA's don't have analog inputs, you have to have an external SPI or what ever digital interface. Closest to an Analog input FPGA that I know of is a PSoC, which isn't really an FPGA, it's more like an CPLD which is a really small FPGA. Analog outputs can be done with a low pass filter and a PWM.

Features they provide include fast timing which is handy for multiple injection pulses during combustion / direct inject events at higher RPM, lower level diagnostics / lower level bit information, and they are very scale-able. For example, they would allow multi-injections of direct injection, multi-spark of CDI events, transmission control, and very complicated math all with very low latency. Traditional MCU's have issues with processing all that information fast enough and with a low enough latency. That's why we see ETPU's, low latency IRQ's and other such mechanisms in traditional MCU's.
Welcome to the friendlier side of internet crazy :)

User avatar
AndreyB
Site Admin
Posts: 10747
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City

Re: FPGA in ECU

Post by AndreyB »

kb1gtt wrote:FPGA's don't have analog inputs, you have to have an external SPI or what ever digital interface.
external ADC topic: http://rusefi.com/forum/viewtopic.php?f=4&t=805
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

klyttle
Posts: 19
Joined: Fri Jan 02, 2015 9:47 pm

Re: FPGA in ECU

Post by klyttle »

It's important to note that your current development path is absolutely essential, so there's no need to be overly concerned at the moment with undertaking some radical FPGA ECU development.

On the issue regarding analog I/O interface with FPGAs, may I direct your attention to the following article I also came across:

http://www.eeherald.com/section/news/onws20141629001.html

It seems the FPGA manufacturers are thinking the very same thing!

Cheers!

User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: FPGA in ECU

Post by abecedarian »

IIRC, Xylinx has some FPGA with ADC capabilities, as do some of the others.
You can lead the horticulture but you can't make them think.

klyttle
Posts: 19
Joined: Fri Jan 02, 2015 9:47 pm

Re: FPGA in ECU

Post by klyttle »

abecedarian wrote:IIRC, Xylinx has some FPGA with ADC capabilities, as do some of the others.
You're probably thinking of the Xilinx Virtex line of FPGAs. not sure if any of them are automotive rated though.
kb1gtt wrote:In another thread I noted the http://papilio.cc/ which is attempting to make FPGA easy to program similar to how Aruduino's made it easy to program micro processors. Papilio has made some great progress in making FPGA programming far easier than it has been over the last several years. They are doing this with one of the largest FPGA MFG's chips known as the spartan. As luck has it, that MFG has also identified that automotive is a market worth some effort, and they make automotive grade FPGA's.

http://www.xilinx.com/applications/automotive.html
http://www.xilinx.com/training/automotive-fpga-training.htm

So I would suggest the path to FPGA would probably be to start with papilio pro, which will set up ISE PC development environment and an underlying wishbone structure. It will allow AVR style programming for soft processors, which I believe is an reasonably easy port for chibios and the current rusEFI platform. Then once it's working with these low cost off the shelf items, it would be a reasonably easy port to one of xilinx automotive grade FPGA's.

Oh, did I also mention that the papilio has the ability to connect a logic analyzer to internal registers and to internal timer bits. That's a crazy mind blowing option for FPGA approaches.
Yep, I remember you mentioned to me in my forum introduction thread that you had one of those boards; I like the idea of using the Papilio Pro to get things started
(at the appropriate time when things are more settled, of course), and then possibly step up to one of the Picozed SOMs (http://zedboard.org/product/picozed) from there.
Last edited by klyttle on Mon Jan 26, 2015 5:19 pm, edited 1 time in total.

User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: FPGA in ECU

Post by abecedarian »

klyttle wrote:
abecedarian wrote:IIRC, Xylinx has some FPGA with ADC capabilities, as do some of the others.
You're probably thinking of the Xilinx Virtex line of FPGAs. not sure if any of them are automotive rated though....
I think that was it; didn't check for automotive rating though.
You can lead the horticulture but you can't make them think.

User avatar
AndreyB
Site Admin
Posts: 10747
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City

Re: FPGA in ECU

Post by AndreyB »

https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: FPGA in ECU

Post by Rhinoman »

I have done quite a bit of FPGA work on defence contracts. Its very unlikely you will see one in a production ECU because they are far too expensive, fortunately FPGAs aren't needed for EFI, modern processors are more than fast enough.
I prefer VHDL to Verilog; neither VHDL nor Verilog should be confused with software - you are still designing hardware but simply describing it rather than drawing a schematic.

puff
contributor
contributor
Posts: 2815
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: FPGA in ECU

Post by puff »

just for educational purposes, could you name some examples of its use in defence applications? missile tracking? nuclear reaction analysis?

Flying
Posts: 13
Joined: Fri Apr 21, 2017 8:35 am

Re: FPGA in ECU

Post by Flying »

puff wrote:just for educational purposes, could you name some examples of its use in defence applications? missile tracking? nuclear reaction analysis?
I'm not privy to the world of military hardware, but the uses that first come to mind for me are control interfaces (missiles, fly by wire) and anything to do with signals processing (enhancing radio/radar capabilities and robustness).

essess
Posts: 13
Joined: Thu Aug 10, 2017 7:12 pm

Re: FPGA in ECU

Post by essess »

kb1gtt wrote:
Fri Jan 10, 2020 10:02 pm
Speaking of OT, should we break the FPGA talk into a different thread?
here we are.
kb1gtt wrote:
Fri Jan 10, 2020 10:02 pm
Angle clock? I'm not following this. Do you mean an angle register that ticks between 0 and 3599? Then the software sets a 5mS injector timer to go off when the clock angle is something like 1800. When you say clock angle do you mean it's just a register which has some representation of the crank angle?
yep, except it's scaled different .. if you used the full 512 teeth and 512 subteeth, then 360* would be 512x512=262144 counts (~.001* per tick). Even 60-2 is 360/(60x512) -> ~.01* per tick.
kb1gtt wrote:
Fri Jan 10, 2020 10:02 pm
Seems like you would need many digital lines to echo this clock angle thing digitally to the STM32.
yep, thats why I say SPI is not usable (nor intended for this design). I actually have the agen in a lattice xo3 talking to an F4 using the PSRAM bus. I've got a little 'shim' that wraps up the agen as a memory mapped device. What I learned is that I need to keep going and push some more stuff in hardware because the latency is a little too large for my tastes. So a softcore (think something like the GTM) was next on the list ... so then I thought I'd look right into the GTM itself which led to my Infineon frustration. It all got shelved and I have other interests now. I learned a lot.
kb1gtt wrote:
Fri Jan 10, 2020 10:02 pm
Do they make ARM softcores that you can use these days?
yes, but just use this.

mck1117
running engine in first post
running engine in first post
Posts: 565
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: FPGA in ECU

Post by mck1117 »

It's easiest to not try to think of the FPGA running the whole engine. Try to think of the FPGA instead as a box in which you can build any magical timer peripheral that you could theoretically have inside the MCU.

At the very least, you could move our scheduling priority queue to hardware. Over an SPI interface you could schedule pin X to be set/cleared at timestamp Y. At the most, I'd want to move trigger decode and output scheduling both in to an FPGA. Things like injection duration, injection start phase, and ignition phase would be given to the FPGA over SPI, which would then do all the math to compute engine RPM, decide which tooth should schedule things, then set a timer to run from that tooth.

As for how to measure angles on an FPGA, you actually don't really need to do anything special. You divide the circle in to units that may not necessarily be degrees, but they function the same. Trigger tooth occurs at position X, a full revolution takes time Y, so we can figure out how long after a trigger tooth (in time, not angle) something needs to occur.
essess wrote:
Fri Jan 10, 2020 11:00 pm
yep, thats why I say SPI is not usable (nor intended for this design).
What? An SPI slave is extremely easy to implement on an FPGA. It's a very common thing to do. We don't need huge bandwidth, so SPI is more than enough.
essess wrote:
Fri Jan 10, 2020 11:00 pm
So a softcore (think something like the GTM) was next on the list
I think you've confused some terms.

The GTM is a fancy multi-timer apparatus that allows chaining timers together based on capture/compare events from other timers. Nothing more.

A softcore is a CPU core built inside an FPGA. Soft isn't quite the right word, because it's very much hardware, but it's reconfigurable. We do NOT need a softcore. We're always going to require an external ARM core, since there are severe limitations of what an FPGA can do (only a few have ADCs, they're VERY slow to configure on initial boot, etc).

SVeilleux9
Posts: 14
Joined: Sun Jan 05, 2020 3:06 am

Re: FPGA in ECU

Post by SVeilleux9 »

I would think you could measure time between crank pulses on an fpga, send this to mcu to calculate rpm, fuel/spark timing and pulse widths and send this information back to the fpga to control the outputs. This should easily be achievable using spi since the data sent back and forth is minimal.

The benefit is you would be able to do your calculations whenever you can (given you still report back to the fpga in time) and output whatever you need with high precision. Additionally you can keep the fpga agnostic to what engine you have since these calculations would remain on the mcu.

mck1117
running engine in first post
running engine in first post
Posts: 565
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: FPGA in ECU

Post by mck1117 »

SVeilleux9 wrote:
Fri Jan 10, 2020 11:29 pm
I would think you could measure time between crank pulses on an fpga, send this to mcu to calculate rpm, fuel/spark timing and pulse widths and send this information back to the fpga to control the outputs. This should easily be achievable using spi since the data sent back and forth is minimal.

The benefit is you would be able to do your calculations whenever you can (given you still report back to the fpga in time) and output whatever you need with high precision. Additionally you can keep the fpga agnostic to what engine you have since these calculations would remain on the mcu.
That's what I mean, yes. Trying to have the FPGA run the whole show doesn't actually improve performance, and greatly increases complexity. Doing it as you and I mentioned is not very difficult at all.

mk e
Posts: 159
Joined: Tue Dec 06, 2016 7:32 pm

Re: FPGA in ECU

Post by mk e »

mck1117 wrote:
Fri Jan 10, 2020 11:32 pm
SVeilleux9 wrote:
Fri Jan 10, 2020 11:29 pm
I would think you could measure time between crank pulses on an fpga, send this to mcu to calculate rpm, fuel/spark timing and pulse widths and send this information back to the fpga to control the outputs. This should easily be achievable using spi since the data sent back and forth is minimal.

The benefit is you would be able to do your calculations whenever you can (given you still report back to the fpga in time) and output whatever you need with high precision. Additionally you can keep the fpga agnostic to what engine you have since these calculations would remain on the mcu.
That's what I mean, yes. Trying to have the FPGA run the whole show doesn't actually improve performance, and greatly increases complexity. Doing it as you and I mentioned is not very difficult at all.
What does that gain you?

I'm with you that having the fpga fire the spark and injectors using timing and pulse length info from the main processor. If that info is updated every 10msec that plenty fast and the fpga bangs away firing the outputs......but It also NEEDS an angle clock to be able to do that. So the fpga needs to be decoding the cranks and just sending rpm to the processor, which again could be read every 10msec so no issue with spi. But trying to send the tooth times seems a real stretch for spi and still requires the processor to do most of the timing ....at least that is how it appears but I may have it wrong????

it seems pointless to even think about doing ADC in the fpga....the processor has that capability and its the processor that need the info so I can't see why to even consider moving it.

Edit: what I described is an fpga version of the freescale eTPU in their ECU intended chips so its a know good path.
Last edited by mk e on Sat Jan 11, 2020 12:06 am, edited 1 time in total.

mck1117
running engine in first post
running engine in first post
Posts: 565
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: FPGA in ECU

Post by mck1117 »

mk e wrote:
Sat Jan 11, 2020 12:00 am
but It also NEEDS an angle clock to be able to do that. So the fpga needs to be decoding the cranks and just sending rpm to the processor, which again could be read every 10msec so no issue with spi. But trying to send the tooth times seems a real stretch for spi and still requires the processor to do most of the timing ....at least that is how it appears but I may have it wrong????
The FPGA should do trigger input timing measurement, but doesn't necessarily have to do RPM calculation. What makes you think it couldn't send every crank event to the MCU as required? Suppose you want to read 128 bits of stuff (rpm, timestamp, status, whatever) after every crank event at 8MHz spi speed. That's only 16 microseconds - only around 10% of the current time we spend on every trigger event (which includes scheduling outputs, which would go away!)

mk e
Posts: 159
Joined: Tue Dec 06, 2016 7:32 pm

Re: FPGA in ECU

Post by mk e »

mck1117 wrote:
Sat Jan 11, 2020 12:04 am

The FPGA should do trigger input timing measurement, but doesn't necessarily have to do RPM calculation. What makes you think it couldn't send every crank event to the MCU as required? Suppose you want to read 128 bits of stuff (rpm, timestamp, status, whatever) after every crank event at 8MHz spi speed. That's only 16 microseconds - only around 10% of the current time we spend on every trigger event (which includes scheduling outputs, which would go away!)
I know that COULD be done, I'm not sure why you'd want to? If you are sending the crank times then the MCU is effectively doing the angle calculations and then needs to send it back to the fpga.....so you are still doing the time critical work in the MCU and adding an extra steps sending it to and from the fpga....I' don't think you've gained anything.

If you have the fpga generate an angle clock all the the critical timing is in the fpga. The only info that needs to transfer is rpm, dwell, injector pulse, spark and fuel angles and that can be slow, 10msec is good, 20msec would work....nothing time critical on the spi buss, no need for interrupts at all in the MCU. Its pretty clean and is how the fancy MCU chips operate, I think.

User avatar
kb1gtt
contributor
contributor
Posts: 3669
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: FPGA in ECU

Post by kb1gtt »

The micro semi board looks interesting. Don't they make FPGA's that have real arm cores and eeproms inside? Also boot times need to be remembered. You need to load the FPGA then start decoding the crank. How long does that take to get sync from powered on?
Welcome to the friendlier side of internet crazy :)

User avatar
kb1gtt
contributor
contributor
Posts: 3669
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: FPGA in ECU

Post by kb1gtt »

Rusefi decodes some odd crank wheels which can be more difficult to implement in the fpga. Can rusefi some how relay the angle clock? That might be a way to fast track the less common crank wheels.
Welcome to the friendlier side of internet crazy :)

infinityedge
Posts: 17
Joined: Fri Dec 27, 2019 4:43 pm

Re: FPGA in ECU

Post by infinityedge »

As a theoretical fan of an FPGA coprocessor for an EFI board, here is an off the cuff assessment of what is needed at the bare minimum:

SPI connection to the main MCU with the MCU handling the slow sensors and closed loop or table selection and the FPGA handling the time critical parts.

There should be an FPGA input for every trigger wheel on the engine that should ideally include the crank and every camshaft. There could be a basic input block that just took a digital signal as well an input block that used an external (or faked internal) ADC for a VR signal. With those two blocks you could do any trigger wheel type or tooth configuration.

An ion sensor analog input signal would be fun to work with.

Outputs would be ignition and injection: time and duration for both with multiple triggers per revolutions as an option. The time and duration of each would be specified by the MCU.

User avatar
kb1gtt
contributor
contributor
Posts: 3669
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: FPGA in ECU

Post by kb1gtt »

Are these arm processors soft or hard?
https://www.arm.com/resources/designstart/designstart-fpga

Does the altera cyclone have a hard processors?
https://images.app.goo.gl/HvTfhRwKhaACf2Ng7
Welcome to the friendlier side of internet crazy :)

User avatar
kb1gtt
contributor
contributor
Posts: 3669
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: FPGA in ECU

Post by kb1gtt »

Looks like MicroSemi's SmartFusion2 has an hard ARM, FPGA, AEQ cert, and many desirable features. The below flying lead chip costs about $18 and has inventory at Digikey.
https://octopart.com/m2s005-tqg144-microsemi-52741915?r=sp&s=9fGERWwCS5SIkW1hndj5jw

Basic overview of how to program and use the SmartFusion2 found here.
Welcome to the friendlier side of internet crazy :)

essess
Posts: 13
Joined: Thu Aug 10, 2017 7:12 pm

Re: FPGA in ECU

Post by essess »

mck1117 wrote:
Fri Jan 10, 2020 11:12 pm
It's easiest to not try to think of the FPGA running the whole engine. Try to think of the FPGA instead as a box in which you can build any magical timer peripheral that you could theoretically have inside the MCU.

At the very least, you could move our scheduling priority queue to hardware. Over an SPI interface you could schedule pin X to be set/cleared at timestamp Y. At the most, I'd want to move trigger decode and output scheduling both in to an FPGA. Things like injection duration, injection start phase, and ignition phase would be given to the FPGA over SPI, which would then do all the math to compute engine RPM, decide which tooth should schedule things, then set a timer to run from that tooth.

As for how to measure angles on an FPGA, you actually don't really need to do anything special. You divide the circle in to units that may not necessarily be degrees, but they function the same. Trigger tooth occurs at position X, a full revolution takes time Y, so we can figure out how long after a trigger tooth (in time, not angle) something needs to occur.
essess wrote:
Fri Jan 10, 2020 11:00 pm
yep, thats why I say SPI is not usable (nor intended for this design).
What? An SPI slave is extremely easy to implement on an FPGA. It's a very common thing to do. We don't need huge bandwidth, so SPI is more than enough.
yep - an SPI slave is easy to implement.
what I said was this design is not intended for SPI. I know I don't have a lot of documentation on the nuances/intentions of this design that led to another rationale document ... but you're more than welcome to make your own in your own vision.

In my vision I was going to feed an angle clock to something like an EMIOS (google mpc5xxx stuff).

before that, I wanted to test the agen and make sure angle clock generation was solid ... this required a high bandwidth interface to do so.
after that, I wanted to drop in something like an EMIOS. With that done, we now have a more complete system that doesn't necessarily need high bandwidth nor low latency. At this point it could all be wrapped with an SPI interface.

I never got there. ¯\_(ツ)_/¯
sounds just like what you describe too. Great minds think alike? haha.
mck1117 wrote:
Fri Jan 10, 2020 11:12 pm
essess wrote:
Fri Jan 10, 2020 11:00 pm
So a softcore (think something like the GTM) was next on the list
I think you've confused some terms.

The GTM is a fancy multi-timer apparatus that allows chaining timers together based on capture/compare events from other timers. Nothing more.

A softcore is a CPU core built inside an FPGA. Soft isn't quite the right word, because it's very much hardware, but it's reconfigurable. We do NOT need a softcore. We're always going to require an external ARM core, since there are severe limitations of what an FPGA can do (only a few have ADCs, they're VERY slow to configure on initial boot, etc).
I've confused nothing. Maybe my wording is not as clear as it could be. Softcore was my next step because I wanted lower latency to my current interface to test the living hell out of it in realtime. Maybe it's a little fun too ... What might have been easier to swallow was using the words 'model a softcore in the spirit of the GTM'. To start this next step I need to get some touch time on a real GTM to make sure I wanted to go this route.

A detour? probably ... I could have just moved on to my other steps and have faith in sim. That's not what I do. I've taught myself to use sim as a helper, but the real proof is realtime use. I've also taught myself that I reap the greatest rewards via incremental implementation. When I'm done with something I'm done. I've got enough time under my belt to have learned ways to stop wasting even more of my time. Too meta!

Anyways,
Look man, I'm not new to this (and it looks like you're not either!) you're more than welcome to take this over. If you need any help, I'll do what I can for you depending on my time constraints. Let me help you morph this into your vision if this one doesn't fit. It simply is what it is and I thought I'd throw it out there for inspection, motivation and proof that it can be done by the common man and doesn't need a multi billion dollar design house behind it.

IP like this is usually tightly controlled and someone's cash cow. Because I don't need cash and I'm motivated by smiles, thankyous, neatos and providing a helping hand then it goes up on github. I really should update it with my more current stuff. But now you've got the gears in my head turning.... more to come?

essess
Posts: 13
Joined: Thu Aug 10, 2017 7:12 pm

Re: FPGA in ECU

Post by essess »

kb1gtt wrote:
Sat Jan 11, 2020 11:41 am
Looks like MicroSemi's SmartFusion2 has an hard ARM, FPGA, AEQ cert, and many desirable features. The below flying lead chip costs about $18 and has inventory at Digikey.
Don't get sidetracked with soft/hardcores unless you're considering ditching the F4. I think it would be a mistake to ditch the F4.

User avatar
kb1gtt
contributor
contributor
Posts: 3669
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: FPGA in ECU

Post by kb1gtt »

Would we expect the Watts to go up, down or stay the same with the use of an fpga? I ask because some of the designs that are out there are very small. The Watts are important to consider for thermal regulation purposes on those small layouts.

Could we some how include other features like a switching regulator into the fpga chip?
Welcome to the friendlier side of internet crazy :)

mck1117
running engine in first post
running engine in first post
Posts: 565
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: FPGA in ECU

Post by mck1117 »

kb1gtt wrote:
Sun Jan 12, 2020 10:06 am
Would we expect the Watts to go up, down or stay the same with the use of an fpga? I ask because some of the designs that are out there are very small. The Watts are important to consider for thermal regulation purposes on those small layouts.

Could we some how include other features like a switching regulator into the fpga chip?
It would almost certainly net increase the power consumption/dissipation. It's practically required to run the fpga off of a switching regulator so that the dissipation isn't too high. Part of the complication is that the power consumption is heavily dependent upon what design is programmed in to the FPGA. An FPGA without a configuration will pull almost no power, as it's just the statically defined support logic (programming interface, clock distribution, etc) that's alive. Your design will then actually start switching gates and using memory in the configurable logic, which will then consume the majority of the power. All FPGA vendors offer tools that estimate power consumption as part of the synthesis (like compilation, but for hardware) of your design.

Whatever the added power consumption, it would be wise for an FPGA'd ecu to use switching regulators all the way down to the FPGA supplies of 1.0/1.2/2.5/3.3v. However, the actual power consumption probably isn't huge. The Lattice ice40 series pulls something like 50-100mA, but only at 1.2v, so in reality it's perhaps only 10% more than our current ECUs (with switching regulators) consume.

Post Reply