FPGA in ECU

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

Re: FPGA in ECU

Post by kb1gtt »

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.
Welcome to the friendlier side of internet crazy :)
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: FPGA in ECU

Post by Rhinoman »

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.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: FPGA in ECU

Post by mck1117 »

Rhinoman wrote:
Mon Jan 13, 2020 1:07 pm
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.
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.
JRD McLAREN
contributor
contributor
Posts: 434
Joined: Mon Mar 04, 2019 10:19 pm
Location: Slovakia

Re: FPGA in ECU

Post by JRD McLAREN »

..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
Attachments
Inside IMF Master Ignition CDI
Inside IMF Master Ignition CDI
DSCN3206.JPG (162.22 KiB) Viewed 16284 times
.. some Proteus and microRusEFI for sale in Europe ..
peredelkin
Posts: 33
Joined: Sat Jun 24, 2017 7:48 am
Location: Neftekamsk

Re: FPGA in ECU

Post by peredelkin »

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.
Attachments
10022020.png
10022020.png (40.17 KiB) Viewed 16230 times
essess
Posts: 13
Joined: Thu Aug 10, 2017 7:12 pm

Re: FPGA in ECU

Post by essess »

... But I read the main discussion thread and noticed that someone had already done the same thing on FPGA. ...
yes. 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.
peredelkin
Posts: 33
Joined: Sat Jun 24, 2017 7:48 am
Location: Neftekamsk

Re: FPGA in ECU

Post by peredelkin »

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 :( :D
none of my friends want to do this :D
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: FPGA in ECU

Post by mk e »

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 :)
peredelkin
Posts: 33
Joined: Sat Jun 24, 2017 7:48 am
Location: Neftekamsk

Re: FPGA in ECU

Post by peredelkin »

From page 653 Technical Reference Manual:
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.
At first I did not understand and decided to translate into russian, but still did not understand. :)
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. :mrgreen: I have PGE. :mrgreen:
essess
Posts: 13
Joined: Thu Aug 10, 2017 7:12 pm

Re: FPGA in ECU

Post by essess »

peredelkin wrote:
Wed Feb 12, 2020 12:01 pm
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 :( :D
none of my friends want to do this :D
We can be friends! :D
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. :lol:

I'm really wiped at the end of the day by my other paying work. :cry:

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.
samwise
Posts: 2
Joined: Fri Dec 11, 2015 4:54 pm
Location: NorCal

Re: FPGA in ECU

Post by samwise »

essess wrote:
Wed Feb 12, 2020 11:10 am
yes. 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.
Hello, I am new to the forum but have been watching rusefi evolve for some time(years).

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.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: FPGA in ECU

Post by kb1gtt »

Are any of the VHDL to Verilog converters any good or of any use?
Welcome to the friendlier side of internet crazy :)
samwise
Posts: 2
Joined: Fri Dec 11, 2015 4:54 pm
Location: NorCal

Re: FPGA in ECU

Post by samwise »

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.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: FPGA in ECU

Post by kb1gtt »

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 :)
Post Reply