• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 433 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.

Original question:

LP-MSPM0G3507: MATHACL data format, arctan(ATAN2) operating

LP-MSPM0G3507: Clock cycles/BUSY period for MATHACL ATAN2 operation

Alan
Prodigy 155 points
Part Number: LP-MSPM0G3507

Tool/software:

Setup for the MATHACL ATAN2 includes a NUMITER value to say how many iterations are required.  However, in the reference manual section 5.4.2 it simply describes needing to write to CTL, OP1 and OP2, then read the results from RES1.  This is the process that is implemented in the MathIQ source file.  Is there no need to wait for the iterations to complete before reading RES1?  The reference manual describes a higher value for NUMITER taking longer to compute, but gives no indication of how to implement this in the example and says that there are no status bits (which would presumably include the BUSY bit).

  • 0
    TI__Genius 16000 points

    Hi Alan,

    I am looking at our documentation now, specifically the MSPM0 G-Series TRM, at section 5.4.2, and I see the description of the function includes the CTL.NUMITER field is used for the number of iterations to calculate the arctangent.

    In table 5-5 of the same document I also see that CTL.NUMITER is used to indicate the number of iterations for the operation. Are we looking at the same document here or am I missing something?

    Looking at our MATHACL examples inside of the SDK, I see we do not demonstrate the ATAN2 function, but we do demonstrate other trig functions, and include a function to wait for the STATUS.BUSY bit to clear. The ATAN2 operation should be performed similarly. 

  • 0 in reply to Dylan OBrien
    Prodigy 155 points

    Dylan

    Apologies, I explained myself poorly.

    The text at the end of 5.4.2 in the TRM is as follows:

    There is no mention of a wait as I might have expected between steps 3 and 4.

    When I referred to an example, I should have been clearer - I was looking at the source for the mathIQ library, specifically function __IQNatan2() where the following lines are executed:

    Again, I would have assumed a wait would have been required between configuring the operands and reading the results.

    (Now I look at it again, I see that the trigger operand is listed as OP2 in the TRM but as OP1 in the comment on line 286 above.  Can you clarify?)

    Given that there is no mention of a wait in the TRM configuration section or the mathIQ code, what impact does the NUMITER have on timings and how should I ensure that I am waiting long enough for it?

  • 0 in reply to Alan
    TI__Genius 16000 points

    Ah I see what you mean.

    I'm going to hunt down some internal documents to see if this is just a gap in the TRM and the mathIQ library. Logically, if the function requires more iterations, it should take longer. 

    I should be able to find more information on this by the end of the day tomorrow so please expect a response then.

  • 0 in reply to Dylan OBrien
    Prodigy 155 points

    Dylan

    Thanks for looking into this.  The only mention of the use of BUSY to wait is in this text of the TRM:

    However, this isn't consistent with the mathIQ library, and doesn't really give an indication of how RES1/RES2 should be used to check for a result (unless you're just supposed to check for a change in the register, which seems a bit vague).

    That snippet also contradicts the triggering order in the mathIQ library, so if you're able to comment on that too that would be really helpful.

  • +1 in reply to Alan
    TI__Genius 16000 points

    Hi Alan,

    Sorry for the delayed response here. I've been able to find more clear information in our internal documentation.

    So the exact behavior from the MATHACL peripheral is that when you attempt to read the results register before the result is ready, the data bus will stall until it is ready. So what should happen is that you are stuck in function to read the register until the operation is complete. In effect, this would cause the device to wait until the result is ready, without the code explicitly saying to do so. That also means that the source code is waiting for the correct data to be available even though it does not appear to do so.

    To me this is a documentation issue and I'll be filing a ticket to explain this better in our TRM, as this behavior is not explained anywhere that I can find publicly and of course many more of our customers will want to know how to get correct results from the math accelerator. 

    Please let me know if you have more unresolved questions or if I can help with anything else.

  • 0 in reply to Dylan OBrien
    Prodigy 155 points

    Dylan

    I've just realised that there is still the question of which order to write the operands in.  The TRM states that OP2 is the trigger to start the calculation, but mathIQ library code (and comments) refer to OP1 being the trigger.  Can you clarify?

  • +1 in reply to Alan
    TI__Genius 16000 points

    Sorry I missed that one the first time around.

    Checking our device specification, it looks like OP1 is listed as the trigger, like as shown in the MathIQ library code. 

    So thats another TRM error that I'll list to be updated. Thanks for pointing that out, and please let me know if you have more questions.