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.

C2000 FPU about RPTB instruction



In my project ,the RPTB block size is 9. The code can run normally,but result is not correct. If insert one 'NOP'instruction to the block,the result will be correct.What is the problem? The code is as follow:

RPTB   _END,#N-1
 MACF32 R3H, R2H, R2H, R4H, R5H
  || MOV32 R5H,  *XAR4++

  COSPUF32 R4H,R6H   

  ADDF32 R1H,R1H,R0H   
  || MOV32 R6H,  *XAR5++
  NOP
  ADDF32 R6H,R6H,R1H

_END:

look forward to your reply.

Thanks.

  • The parallel MOV32 instruction in your code requires a pipeline cycle to complete.

    ADDF32 R1H,R1H,R0H   
      || MOV32 R6H,  *XAR5++

    R6H will not be updated with the move until one instruction cycle after this parallel instruction.  You're using R6H in the last ADDF instruction at the end of the block, but without the NOP delay it takes the value before the parallel move.  See the pipeline section at the foot of the instruction description (p.45).

    http://www.ti.com/lit/ug/sprueo2b/sprueo2b.pdf

    Regards,

    Richard

  • I need to modify my answer.  The MOV32 is OK.  There are actually two pipeline issues in the code.

    The first is with the parallel ADDF32 instruction I mentioned in the last post.  R1H needs one cycle to update before you can use it as a source register in the last ADDF32.  The literature reference I mentioned before explains this. 

    The second issue is the number of delay slots after the COSPUF32 instruction.  You need three full delay slots after COSPUF32 for R4H to be updated, but with the zero overhead RPTB instruction you only have two without the NOP.  The literature reference for this is example 3-2 on p.383 of 

    http://www.ti.com/lit/ug/spruhs1a/spruhs1a.pdf

    Regards,

    Richard

  • Thank you for your answer.

    Maybe the problem is not described clearly.The code I mentioned above can run normally ,but the result is not correct. If want to get correct answer,another 'NOP'should be insert to the repeat block. Additionally,the 'NOP' to be inserted can be at anywhere of the RPTB block . 

    The code can be complied correctly,so I think the pipeline conflicts don't exist .Are there any other reasons for this problem?

    I need your help.Thank you.

  • I want to make another small point about the problem. If debug the code step by step the result is also right,but free run is not. It seems likely that there are pipeline conflicts in the code. Where are they and why do they happen? Write the code here for convenience,
    RPTB _END,#N-1 MACF32 R3H, R2H, R2H, R4H, R5H || MOV32 R5H, *XAR4++
    COSPUF32 R4H,R6H ADDF32 R1H,R1H,R0H || MOV32 R6H, *XAR5++ NOP
    ADDF32 R6H,R6H,R1H_END:
  • Without the NOP before the penultimate ADDF32 I am getting an assembler error, so that pipeline conflict is being picked up.  However I'm not seeing any warning of a conflict following the TMU instruction COSPUF32.  This applies event without the RPTB and may be an assembler bug.  I will report it to that team for further investigation.

    In the absence of the NOP you do have both conflicts in your code, so I think my previous reply is correct.

    When you single step through assembly code on the main CPU the pipeline is being flushed, so you may not see pipeline conflicts that way.  We just have to be circumspect about watching for possible pipeline effects and check you're results are correct, as you are doing.

    Regards,

    Richard