TMS320F28035: CLA Data Read Bus & Shared peripherals

There are two peripheral bus bridges. You can find how they are mapped in the Data Sheet.

http://www.ti.com/lit/ds/sprsp14/sprsp14.pdf

Figure 1-1

sal

Hello Sal,

Sal Pezzino said:

There are two peripheral bus bridges. You can find how they are mapped in the Data Sheet.

http://www.ti.com/lit/ds/sprsp14/sprsp14.pdf

Figure 1-1

The figure you mentioned is not very clear as it has 7 blocks labeled "Bridge", could you give more detail?

Regarding the initial stalls can you confirm whether they add 2 SYSCLK cycles every time they occur?

In any case I found the time to conduct the test you described in the previous topic but I don't know what to think of the results described below.

Sal Pezzino said:

 If the C28x accessed the registers (memory region) last, and then the CLA accesses it next, you may experience additional stalls to arbitrate the CLA as the master for its access.

Can you try reading the PWM registers from the CLA prior to your test? See if you get a difference in access times with a CLA read prior, and without a CLA read prior.

In my test code the CPU does not write to any registers after the initial configuration is done, so there should be only accesses by the CLA. Despite this fact the results are the same:

1. When replacing a single MNOP by a single read the task becomes 2 TBCLK longer
2. When replacing a single MNOP by a single write the task has the same duration
3. When replacing 2 MNOPs by 2 consecutive writes the task becomes 1 TBCLK longer
4. When replacing 3 MNOPs by 3 consecutive writes the task becomes 2 TBCLK longer
5. When replacing 4 MNOPs by 4 consecutive writes the task becomes 3 TBCLK longer
6. When replacing 8 MNOPs by 8 consecutive writes the task becomes 7 TBCLK longer
7. etc.

Therefore it doesn't look like an "initial" stall but the opposite, as only the initial access does not add a delay. However if I replace the MNOPs by non-consecutive writes the tasks remains at the expected duration.

What could the explanation be?

Regards,

Pierre

Hi Pierre,

If multiple peripherals come out to the same bridge, that means they are connected on the same bridge. So, there appears to be multiple bridges connecting to the same buses on f2838x. For example, I2C and SCI are on the same bridge, and there may be arbitration issues if CLA and C28x are both accessing them, since they are peripherals on the same bridge.

However, this is not your problem since only CLA is accessing the PWM.

Do you know what frequency your EPWMCLK is running compared to the PLL or SYSCLK? Is your EPWMCLK divided from the SYSCLK? If so, then this will create delays when accessing the PWM registers.

For example, if the EPWMCLK is slower than SYSCLK, then data reads will be stalled because the data will take 2 cycles (or more) to get put on the data read bus. If multiple writes occur, then those may be stalled since it takes 2 cycles for the write to occur. If the writes occur to the same location, this may create a pipeline stall.

For your above scenarios it appears the EPWMCLK may be slower than the clock the CLA is running at:

1. adding a read will create a stall if the EPWMCLK is slower.

2. replacing an MNOP with a single write will not create a stall since there are no two consecutive writes to the same location.

3. the second write will be stalled waiting for the first write to complete. 1 cycle delay.

4-6. there are these additional 1 cycle stalls for every write you add consecutively because the previous write must complete before continuing. THis is likely a pipeline stall created by the memory conrtoller.

This is what I believe is happening.

Hope this help,

sal

Sal Pezzino said:

Do you know what frequency your EPWMCLK is running compared to the PLL or SYSCLK? Is your EPWMCLK divided from the SYSCLK? If so, then this will create delays when accessing the PWM registers.

For example, if the EPWMCLK is slower than SYSCLK, then data reads will be stalled because the data will take 2 cycles (or more) to get put on the data read bus. If multiple writes occur, then those may be stalled since it takes 2 cycles for the write to occur. If the writes occur to the same location, this may create a pipeline stall.

Hello Sal,

I believe EPWMCLK is the same as SYSCLK since PERCLKDIVSEL[EPWMCLKDIV] is set to zero. Both clocks are set to 200MHz (testing this on the F2838x ControlCard). I confirmed this configuration by observing pulses at 1MHz with ePWM1 in up-count mode and TBCTL[CLKDIV]=0 and TBCTL[HSPCLKDIV]=0  and TBPRD=199.

Furthermore if I set EPWMCLKDIV to 1 the frequency of the pulses changes to 500kHz, indicating that EPWMCLK is indeed slower than SYSCLK afterwards. 

However the behaviour of the GPIO toggled by the CLA task is the same in both cases, as if the stalls you described were always occurring regardless of the ratio between SYSCLK and EPWMCLK. 

Should I make a test project and send it to you so you can study this phenomenon?

Pierre

Hi Pierre,

Before you do that, let me ask for some additional help from some architecture and design engineers. I will request their help now.

sal

Hi Sal,

Thank you for your answer. After comparing the datasheets of the F28035 and F28388 I noticed that :

• this information is actually mentioned in the F28035 datasheet (SPRS584) in Table 3-5. Wait-States
• however it is not present in the F28388 datasheet (SPRSP14)

Thank you,

Pierre