FPGA in ECU
Re: FPGA in ECU
We are currently doing a bunch of clock cycles in the STM32 to decode the crank wheel and update the timer(s). Would we get less watts from the STM32 if that is not done by an STM32? Or are those clock cycles still consuming energy just not producing results? I think the watts are simply transferred from the STM32 to the FPGA. I guess build and test is the only real way to know if the total watts balance has gone up, down or stay the same. It sounds like we do not expect an increase that would warrant additional thermal management needs.
About SMPS, I was thinking we are currently commonly using a chip which includes CAN, VR interface, AEQ friendly power supply, and a bunch of features like that. The MicroSemi chip has many of those features, but I did not see the power supply. I wonder if it's practical to put in some logic to allow for a regulator. Could we some how put in some logic to allow the FPGA to function as the SMPS, or is that not practical? AKA can we create something that will actually boot, then increase the efficiency with a SMPS once the FPGA has been loaded.
About SMPS, I was thinking we are currently commonly using a chip which includes CAN, VR interface, AEQ friendly power supply, and a bunch of features like that. The MicroSemi chip has many of those features, but I did not see the power supply. I wonder if it's practical to put in some logic to allow for a regulator. Could we some how put in some logic to allow the FPGA to function as the SMPS, or is that not practical? AKA can we create something that will actually boot, then increase the efficiency with a SMPS once the FPGA has been loaded.
Welcome to the friendlier side of internet crazy
Re: FPGA in ECU
The STM will still consume the same power if the processing is done by the core unless you put it to sleep the programme counter will still be running and stepping through addresses. The power consumed by the FPGA will depend on how much logic is actually switching. For an engine timer you would usually have one high resolution timer and a bunch of input capture/output compare modules. The GTM is a good example of a configurable engine timer, but its complex and it would probabl;y be easier to port the RusEFI code to a processor with a GTM.
I think part of the issue here is the perceived lack of accuracy. I haven't looked at the rusEFI code for a long time but if I remember correctly it uses the input capture/output compare modules to trigger interrupts and the clock capture and pin toggling is performed manually in the interrupt. No OEM ECU runs that way, but maybe there is an issue in synchronising the timers that prevents a conventional IC/OC method.
I think part of the issue here is the perceived lack of accuracy. I haven't looked at the rusEFI code for a long time but if I remember correctly it uses the input capture/output compare modules to trigger interrupts and the clock capture and pin toggling is performed manually in the interrupt. No OEM ECU runs that way, but maybe there is an issue in synchronising the timers that prevents a conventional IC/OC method.
-
- running engine in first post
- Posts: 1494
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: FPGA in ECU
We actually do put the cpu to sleep when there are no threads to be scheduled. The lowest priority thread calls a function that parks the CPU, allowing wakeup from interrupts.
Also, power consumption is dependent upon what you're doing. For example, keeping the pipeline saturated will consume more power than lots of pipeline stalls, since more gates are actually switching and consuming power.
-
- contributor
- Posts: 435
- Joined: Mon Mar 04, 2019 10:19 pm
- Location: Slovakia
Re: FPGA in ECU
..I don't read all post listed above ...
but, I have FPGA ECU on my desk ...
it is IMF Master Ignition control unit - https://imfsoft.com/en/category-control-units
but, I have FPGA ECU on my desk ...
it is IMF Master Ignition control unit - https://imfsoft.com/en/category-control-units
- Attachments
-
- Inside IMF Master Ignition CDI
- DSCN3206.JPG (162.22 KiB) Viewed 16867 times
.. some Proteus and microRusEFI for sale in Europe ..
-
- Posts: 33
- Joined: Sat Jun 24, 2017 7:48 am
- Location: Neftekamsk
Re: FPGA in ECU
I didn’t read the whole conversation (this is difficult for me), but I understood the essence
http://www.ti.com/lit/pdf/spnu515
beginning on page 1115
end on page 1136
but most importantly at 1118 - this is exactly what I'm trying to repeat
But I read the main discussion thread and noticed that someone had already done the same thing on FPGA.
http://www.ti.com/lit/pdf/spnu515
beginning on page 1115
end on page 1136
but most importantly at 1118 - this is exactly what I'm trying to repeat
But I read the main discussion thread and noticed that someone had already done the same thing on FPGA.
- Attachments
-
- 10022020.png (40.17 KiB) Viewed 16813 times
Re: FPGA in ECU
yes. I've done this: https://github.com/essess/agen... But I read the main discussion thread and noticed that someone had already done the same thing on FPGA. ...
As with everyone else, I'll try to answer/help in anyway I can. It's been a while since I've worked on this.
-
- Posts: 33
- Joined: Sat Jun 24, 2017 7:48 am
- Location: Neftekamsk
Re: FPGA in ECU
Tested on real work?
Now I am faced with the task of connecting the microcontroller to the FPGA through an asynchronous interface.
I’m afraid that I won’t be able to connect via wires and will have to make a printed circuit board.
it is a pity that not many people are interested in fpga.
I will continue to work on hwag - won't leave it halfway.
alone
none of my friends want to do this
Now I am faced with the task of connecting the microcontroller to the FPGA through an asynchronous interface.
I’m afraid that I won’t be able to connect via wires and will have to make a printed circuit board.
it is a pity that not many people are interested in fpga.
I will continue to work on hwag - won't leave it halfway.
alone
none of my friends want to do this
Re: FPGA in ECU
I do think its the best approach to create a high performance, lowish cost open source ECU but sadly the only thing I can contribute is best wishes as I have no knowledge or skill that would actually help at this stage
The problem seems to always be convincing people that they need more accuracy or more speed and its worth paying extra to get it. I've never seen a post or article or claim from megasquirt about any of that....but they are pretty cheap and the engine will run pretty well so lots of people buy them. rusEFI as is runs engines well. Way back the F1 guys caused pretty good systems to be created and ever tightening emissions laws have caused similar systems to move to OEM street use....but unless you're measuring everything, and the vast majority of users din't measure anything, then running pretty well is plenty good enough.
....but i'm excited to see a system assemble that can be as good an an F1 setup at a price mortals can afford ad an ARM with an FPGA is probably the heart of that system
The problem seems to always be convincing people that they need more accuracy or more speed and its worth paying extra to get it. I've never seen a post or article or claim from megasquirt about any of that....but they are pretty cheap and the engine will run pretty well so lots of people buy them. rusEFI as is runs engines well. Way back the F1 guys caused pretty good systems to be created and ever tightening emissions laws have caused similar systems to move to OEM street use....but unless you're measuring everything, and the vast majority of users din't measure anything, then running pretty well is plenty good enough.
....but i'm excited to see a system assemble that can be as good an an F1 setup at a price mortals can afford ad an ARM with an FPGA is probably the heart of that system
-
- Posts: 33
- Joined: Sat Jun 24, 2017 7:48 am
- Location: Neftekamsk
Re: FPGA in ECU
From page 653 Technical Reference Manual:
Then I opened the datasheet and there were even more questions.
VCLK3 can be 100MHz and HCLK run at 160MHz.
What 2.5MHz and 10MHz did they mean?
Technical Reference Manual , page 653
Datasheet , page 43 and 64.
And then FPGA? FPGA will be connected via EMIF.
upd: EMIF avalable in ZWT Package - Not PGE. I have PGE.
At first I did not understand and decided to translate into russian, but still did not understand.The EMIF clock is output on the EMIF_CLK pin and should be used when interfacing to external SDRAM devices. The EMIF module gets the VCLK3 clock domain as the input. This clock domain is running at half the frequency of the main oscillator by default, that is, between 2.5MHz to 10MHz. The VCLK3 frequency is divided down from the HCLK domain frequency by a programmable divider (/1 to /16). Refer the Architecture chapter of the device technical reference manual for more information on configuring the VCLK3 domain frequency.
Then I opened the datasheet and there were even more questions.
VCLK3 can be 100MHz and HCLK run at 160MHz.
What 2.5MHz and 10MHz did they mean?
Technical Reference Manual , page 653
Datasheet , page 43 and 64.
And then FPGA? FPGA will be connected via EMIF.
upd: EMIF avalable in ZWT Package - Not PGE. I have PGE.
Re: FPGA in ECU
We can be friends!peredelkin wrote: ↑Wed Feb 12, 2020 12:01 pmTested on real work?
Now I am faced with the task of connecting the microcontroller to the FPGA through an asynchronous interface.
I’m afraid that I won’t be able to connect via wires and will have to make a printed circuit board.
it is a pity that not many people are interested in fpga.
I will continue to work on hwag - won't leave it halfway.
alone
none of my friends want to do this
Unfortunately, I really don't have the time to dig back into this. I'll have to leave it as an example for others to ridicule instead.
I'm really wiped at the end of the day by my other paying work.
As you and mck1117 rightly point out, a synchronous interface (such as SPI) is the way to go. I'll do some thinking on this.
Re: FPGA in ECU
Hello, I am new to the forum but have been watching rusefi evolve for some time(years).essess wrote: ↑Wed Feb 12, 2020 11:10 amyes. I've done this: https://github.com/essess/agen
As with everyone else, I'll try to answer/help in anyway I can. It's been a while since I've worked on this.
I have been interested in doing an angle clock since college, but have never found an open source design until now. Unfortunately, I only know Verilog and your design is in VHDL:-( First, thank you for sharing your design.
It looks like the agen project is an implementation of the Ti HWAG. I seemed to have missed this on my first read. As stated earlier pages 1110-1127 of the Ti doc SPNU515C.pdf are very helpful.
Last edited by samwise on Mon Feb 24, 2020 4:53 pm, edited 1 time in total.
Re: FPGA in ECU
Are any of the VHDL to Verilog converters any good or of any use?
Welcome to the friendlier side of internet crazy
Re: FPGA in ECU
A conversion of angcnt.vhd to Verilog.
Code: Select all
// File angcnt.vhd translated with vhd2vl v3.0 VHDL to Verilog RTL translator
//
// // Copyright (c) 2018 Sean Stasiak. All rights reserved.
// Developed by: Sean Stasiak <sstasiak@protonmail.com>
// Refer to license terms in license.txt; In the absence of such a file,
// contact me at the above email address and I can provide you with one.
//
// Converted to Verilog by samwise ;-) This version compiles but is NOT tested!!!
//-
// SB ieee.numeric_std.all,
// SB work.agen_pkg.all;
//-
// (ANG)le (C)ou(NT) management
//-
// no timescale needed
// these are from the angcnt_pkg.vhd file
//[ defaults ]-----------------------------------------------------
parameter CNTRWIDTH = 24; //< counter width
parameter ACNTWIDTH = CNTRWIDTH; //< ACNT
parameter PCNTWIDTH = CNTRWIDTH; //< PCNT
parameter SCNTWIDTH = CNTRWIDTH; //< SCNT
parameter PCNTDEPTH = 4; //< buffer the last PCNTDEPTH period measurements
parameter TWCNTWIDTH = 9; //< count up to 2^TWCNTWIDTH teeth per tw rev
parameter PCNTRSTVAL = 0; //< reset value for PCNT registers
//[ types ]-----------------------------------------------------
parameter [1:0]
LOADACNT = 0,
HOLD = 1,
COUNT = 2;
module angcnt_top(
input wire clk_in, // Clock
input wire twtck_in, // Toothed wheel active edge
input wire runflg_in, // Enable angle clock
input wire loadflg_in, // acnt <= acnt_in
input wire rstflg_in, // Reset - Angle count to zero on next twtck
input wire [2:0] stwd_in, // step width selector
input wire [PCNTWIDTH - 1:0] prevpcnt_in, // Previous tooth period
input wire [ACNTWIDTH - 1:0] acnt_in, // acnt Load value
input wire gapnxtflg_in, // Next flag
input wire gaptcnt_in, // Num of teeth in gap
output wire ovfflg_out, // Angle count overflow flag
output reg [ACNTWIDTH - 1:0] acnt_out, // Angle counter
// Debugging
output reg [1:0] state,
output reg [23:0] scnt,
output reg [23:0] acnt,
output reg [10:0] tckc,
output wire [10:0] tckc_in
);
// SB subtype sel_t is std_logic_vector(1 downto 0);
wire [1:0] sel_t;
assign sel_t = { gapnxtflg_in, gaptcnt_in };
reg [10:0] K; //< easiest to match tckc
// wire [10:0] tckc_in; //< see note
// NOTE:
// make sure tckc can handle 4x the step width in order to
// handle gaps of at least size 3 (I have ideas for the future)
// 512x4-> 2048 ->log_2(2048) is 11 bits
//---------------------------------------------------------------------------
// SB - Changed to posedge from *
always @(posedge clk_in) begin
case(stwd_in) // < determine step width, aka K
3'b000 : K <= 4;
3'b001 : K <= 8;
3'b010 : K <= 16;
3'b011 : K <= 32;
3'b100 : K <= 64;
3'b101 : K <= 128;
3'b110 : K <= 256;
default : K <= 512;
endcase
case(sel_t)
2'b11 : tckc_in <= (K << 1) + K;
2'b10 : tckc_in <= (K << 1);
default : tckc_in <= K;
endcase
end
//---------------------------------------------------------------------------
// basic idea here,
// ignore the world until runflg_in asserted, then wait for a toothed wheel
// edge to roll in as a gating function for sub tick generation
//
// when no more subticks to generate in this tooth period, put self on
// hold until the next toothed wheel input edge arrives
//
always @(posedge clk_in) begin : P1
// reg [1:0] state = LOADACNT;
// reg [SCNTWIDTH - 1:0] scnt = 0;
// reg [ACNTWIDTH - 1:0] acnt = 0;
// reg [10:0] tckc;
if(runflg_in == 1'b0) begin
state = LOADACNT;
end
else begin
case(state)
COUNT : begin
if((twtck_in == 1'b1) && (tckc != (0))) begin
//< accel ?
acnt = acnt + tckc;
//< beware: acnt is not monotonic!
scnt = 0;
tckc = tckc_in;
if(rstflg_in == 1'b1) begin
//< ugly, but MUST be handled here
acnt = 0;
end
else if(loadflg_in == 1'b1) begin
acnt = acnt_in;
end
end
else begin
//< counting off subticks until finished
scnt = scnt + K;
if(scnt >= prevpcnt_in) begin
//< scnt overflow? (or = for last subtick)
scnt = scnt - prevpcnt_in;
//< compensate for non integer PCNT(1)/K values
acnt = acnt + 1;
tckc = tckc - 1;
if(tckc == (1)) begin
state = HOLD; //< HOLD on last subtick
end
end
end
end
HOLD : begin
//< eval for resets and loads sync to twtck
scnt = 0;
tckc = tckc_in;
if(twtck_in == 1'b1) begin
if(rstflg_in == 1'b1) begin
acnt = 0;
end
else if(loadflg_in == 1'b1) begin
acnt = acnt_in;
end
else begin
//< neither load or reset desired, ++ on twtck
acnt = acnt + 1;
end
state = COUNT;
end
end
default : begin
//< forced load on twtck upon transition to run
scnt = 0;
tckc = tckc_in;
if(twtck_in == 1'b1) begin
acnt = acnt_in;
state = COUNT;
end
end
endcase
end
acnt_out <= acnt;
end
// < it's impossible to ovf acnt with current K and
// thnb limits (512*512 = 262144 (18 bits))
assign ovfflg_out = 1'b0;
// YO!: Would be nice to figure out some kind of VHDL compile time assert for this.
endmodule
Last edited by samwise on Sun Feb 23, 2020 2:27 am, edited 2 times in total.
Re: FPGA in ECU
You can use the "code" thing, see the </> icon in the editor. It allows the below.
Code: Select all
blah
blah with tab
more blah with tab
No tab blah
Welcome to the friendlier side of internet crazy