• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 80 subscribers
  • Views 982 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LEA energy consumption for Matrix Multiply

Rosh Mendis
Intellectual 730 points

Part Number: MSP430FR5994
Other Parts Discussed in Thread: ENERGYTRACE

Hi,

in http://www.ti.com/lit/an/slaa698b/slaa698b.pdf the latency of a LEA matrix multiply operation (msp_matrix_mpy_q15) is stated as (16+3)*(N/2). Here, N = block size, but what is meant by 'block size' in this operation ?


Also, I have tried to analyze the energy consumption of the msp_matrix_mpy_q15 LEA operation, but it seems like the energy cost is not linear with respect to the number of MACs or even with respect to the matrix size.


can someone shed some light on why this is ?

I am using EnergyTrace to measure the energy cost.


What is the energy cost of the LEA Matrix Multiply related to ?


thanks

  • 0
    TI__Guru 71216 points

    Hi Rosh,

    Let me see if I can reach out to our LEA expert to get some help with your questions.

  • 0 in reply to Dennis Lehman
    Intellectual 730 points

      - Thank you

    Also, it seems like the msp_matrix_mpy_q15 command, iteratively computes [A(each row)  x B (whole matrix)], where A and B are the input matrices. Instead of a full hardware matrix-matrix multiply, it seems like an iterative vector-matrix multiply. Alternatively, is there a matrix mult operation entirely done in LEA ?

    thanks

    Rosh

  • 0 in reply to Rosh Mendis
    TI__Guru 71216 points

    Hi Rosh,

    I appreciate your patience.  Our LEA expert is no longer with us so I'm having to work with a few folks that might be able to help resolve your questions.

  • 0 in reply to Dennis Lehman
    Intellectual 730 points

    - Thank you, any advice is appreciated.

  • 0 in reply to Rosh Mendis
    TI__Genius 16840 points

    Hi Rosh,

    Thank you for your patience, I had to double-check the implementation of DSPLib and run a few tests.

    From what I can see, slaa698 is incorrect. It says that the matrix MPY should take 16+ (3 x N/2); however, this is the same number of cycles as a vector multiplication, and as you mention above, the library uses a loop to multiply row-by-row. That, for starters, doesn't make much sense.

    Based on some information I found, and after running some tests, it seems like the actual number of cycles for each row is:

    27 + (colSize/2) x (15 + 5 x (rowSize/2) ), where colSize is ColB, and rowSize is RowB = ColA.

    Where, the size of the matrices is defined as:

    [RowA  x ColA] x [RowB x ColB] = [RowA x ColB], and ColA=RowB

    In addition to that, each loop will add more cycles but using the CPU. The number of loops is defined by RowA and it's difficult to define them since they will depend on the compiler and its optimization.

    My assumption about the power consumption is that it will vary depending on the dimensions of the matrices.

    Increasing ColA=RowB and ColB should increase the duration of each row multiplication done by LEA. In this case, the CPU is in LPM0 with LEA running.

    Increasing RowA would increase the number of loops with the device in active mode.

    Unfortunately, I couldn't find any LEA functions doing the complete matrix implementation.

    Regards,

    Luis R

  • 0 in reply to Luis RC
    Intellectual 730 points

    Hi  

    Thank you for taking time to run those tests.

    I tried to get some measurements using EnergyTrace for different [ColA, ColB, RowA]. What I observed was:

    - With ColB = RowA = 1, Energy increased linearly as ColA size increased, say with a fixed rate of increase (M) - this is i guess similar to vector-vector multiply

    - However, the rate of increase M scales up as ColB increases. (i.e.,  M is not the same different ColB>1)

    - Similarly there is a different rate of increase in energy as RowA increases, so it's not simple as estimating the energy of (ColA x ColB) and multiply by RowA.

    Does LEA not consume a fixed amount of energy per cycle ? (assuming CPU is sleeping). then we can easily get the total energy cost of a Matrix Multiply using the formula you provided.

    Last question :

    - Can you please illustrate some code to put CPU into LPM0 when LEA is executing using DSPLib ? as I understood, DSPLib (msp_matrix_mpy_q15 or any other func), does not support interrupts ?

    thank you

    Rosh

  • 0 in reply to Rosh Mendis
    Intellectual 730 points

    sorry - after a closer look, the dsplib LEA functions actually do put the CPU into LPM0 and the ISR is specified in "msp_lea_isr", which wakes up CPU when LEA finishes.

  • 0 in reply to Rosh Mendis
    TI__Genius 16840 points

    Hi Rosh,

    There are a few things that might explain this behavior:

    • According to the function above, the number of cycles per row depends on the dimensions of the matrix and the rate of increase is not the same for rows (RowB = ColA) and columns (colB)
      • Having col=row=2 would give 47 cycles
      • keeping columns =2, but rows =4 increases to 52 cycles; however, increasing to 50 will result in 167 cycles. Or a rate of 2.5 cycles.
        • Calculating the rate of f(row) - f(row-1) gives me a rate of (5*col/4). (I.e. with col=2, 5x2/4 = 2.5 cycles per increase of row)
      • Keeping rows=2, but cols=4 increases to 67 cycles; and increasing to 50 results in 527 cycles which is a rate of 10 cycles.
        • Calculating the rate of f(col) - f(col-2) gives me (15/2 + (5*row)/4). (i.e. with row=2, 15/2 + 5x2/4 = 10 cycles per increase of col).
    • Regarding your comment about the current being proportional to the number of rowA, are you seeing different average current once LEA starts running? There is a portion of the function that is going to be "static" - initialization, parameter checks, etc- and another portion which should be variable and proportional to the number of cycles. In theory, once the loop starts running, the current should stay relatively stable in average, except for the next comment.
    • The current for LEA depends on the types of instructions executed and even the data. That's why the datasheet doesn't include just a spec for power consumption, but it shows different use cases (Table 5-14 of SLASE54C) .Table 5.10 also shows how the typical current for an FFT is 66uA/MHz when the data is zero, but 86uA/Mhz when the data is nonzero.

    Overall, LEA was designed to improve performance and further reduce power consumption of MSP430. SLAA698 was created to show some use cases, but the savings will depend on the usage.

    Regards,

    Luis R

  • 0 in reply to Luis RC
    Intellectual 730 points

    Hi Luis,

    Yes I think I understand the rate of increase now.

    As for the proportionality w.r.t to rowA, yes there is a fixed energy portion related to the overhead of initialization. I haven't checked this though.

    w.r.t to Matrix Multiply - if the data is zero (e.g., rowA is all Zero), then would the current be lower ? (i.e. LEA would not execute the respective multiply-accumulate operations and simply arrive at a zero result) ? If this is the case, I would assume the current reduction would be much less than a non-zero case, and would only include the fixed parameter initialization overhead.

    thanks

    Rosh

  • 0 in reply to Rosh Mendis
    TI__Guru 71216 points

    Hi Rosh,

    Has Luis answered all of your questions?

  • 0 in reply to Rosh Mendis
    TI__Genius 16840 points

    Hi Rosh,

    Just to follow-up on your question:

    Rosh Mendis said:
    w.r.t to Matrix Multiply - if the data is zero (e.g., rowA is all Zero), then would the current be lower ? (i.e. LEA would not execute the respective multiply-accumulate operations and simply arrive at a zero result) ? If this is the case, I would assume the current reduction would be much less than a non-zero case, and would only include the fixed parameter initialization overhead.

    The implementation doesn't really do that, it will do the multiplication nonetheless and it will take the same amount of time. The power will differ due to the actual data itself as explained in SLAA698:

    Regards,

    Luis R

  • 0 in reply to Luis RC
    Intellectual 730 points

    Okay, I think I understand, different inputs should consume different energy, but the variance should be not more than 20uA/MHz. The zero input case should consume the lowest current, because of the gate-level behavior. Thank you

**Attention** This is a public forum