Part Number: TMS320F280049C
Tool/software:
I'm trying to exactly understand the CLA pipeline and related timing for an extremely timing-critical application.
From documentation and other forum threads I got the following understanding:
-> MSGRAM works the same way as LSRAM, every LSRAM and MSGRAM block has its own arbiter
-> MSGRAM is not Dual-Port but also round-robin between CPU/CLA
-> LS/MSGRAM blocks do not have separate Read/Write ports but a shared R/W interface, so write access stalls read access
-> Arbiter Prioritizes write before read (otherwise it could cause a deadlock) on every CPU/CLA, then round-robin between CPU/CPA
-> Access is always without waitstate (if free), 1 cycle
-> Peripheral read access always causes 2 waitstates; 3 cycles/instruction
Is this correct?
Open Questions:
-> How about peripheral write access?
Does it also cause waitstates or is it single cycle?
-> How about W vs. R1/2 phase read/write collision?
So the arbiting between CPU/CLA is clear, but not exactly between read and write:
The CLA has an 8-stage pipeline with F1-F2-D1-D2-R1-R2-E-W.
My question: Does W interfere with R1 or R2?
Example:
MMOV32 @LSRAM0_x, MR0 ; write to LSRAM0
MNOP
MMOV32 MR2, @LSRAM0_y ; this instruction is in R2 stage while write is in W stage -> Waitstate inserted?
MMOV32 MR0, @LSRAM0_z ; this instruction is in R1 stage while write is in W stage -> Waitstate inserted?
MMOV32 @MSGRAM_x, MR0 ; write to message RAM CLA->CPU
MNOP
MMOV32 MR2, @LSRAM0_y ; this instruction is in R2 stage while write is in W stage -> Different arbiter, no problem? (except CPU parallel access / round robin...)
MMOV32 MR0, @LSRAM0_z ; this instruction is in R1 stage while write is in W stage -> Different arbiter, no problem? (except CPU parallel access / round robin...)
MI16TOF32 MR0,@AdcaResultRegs ; -> always 3 cycles / 2 waitstates?
MMOV32 @EPwm2Regs+108,MR0 ; -> 1 or 3 cycles?
Would be nice if someone could confirm my assumptions and clarify the open questions.
Thanks,
Carl
