Forums

C6713: data memory stalls

Started by Bernhard 'Gustl' Bauer March 31, 2010
Hi,

I'm looking for some documentation what causes data memory stalls on a
C6713. The only thing I found so far is spru733a. And it says only: 'A
memory stall occurs when memory is not ready to respond to an access
from the CPU.'

I'm using combinations of STW, LDW and LDDW. I want to know which
combinations are causing stalls. It would be help full to know how the
simulator indicate (event name) those stalls.

I use no L2 cache.

TIA

Gustl

_____________________________________
I suppose that such a description (besides that in spru 189/732/733) could
be found in a CPU hardware design text, in a section on CPU external memory
accessing.

There are 3 types of pipeline stalls in the C6000 architcture, all them
are described in spru733a, the first one shown in figure 4-28 (p.388) and
is due to multiple EPs in the same FP; the others are due to either
instruction or data memory access, shown in figure 4-32.

Stalls are something that software cannot control. If put in terms of software,
one would said that a stall is a polling wait for an event, specifically for
an external memory response. During stall cycles the CPU is doing nothing, its
pipeline is halted, while its memory subsystem hardware is waiting a response
signal from memory controller. I guess that simulators mostly would not
simulate memory controller stalls, but they do simulate pipeline stalls due to
multiple EPs in a single FP.

The reason for memory access stalls is in the fact that the dynamic memory is
usually clocked at a lower rate than the CPU, thus it takes additional CPU
clock cycles for a memory controller to deliver data on the CPU boundary.

Data fetch stalls can be induced only by the load type of instructions.
The store type instructions never induce data write stalls. In the Figure
4-15 of spru733a, a stall takes place after E3 until data are fetched to
the CPU boundary.

Pipeline also can be stalled by instruction flow. This time the stalls
do not affect performance at all, they allow for dispatching consequent
execute packets found in the same instruction fetch packet. See Figure 4-28
on page 338 (4-57), sect. 4.4.1.

Figure 4-32 also shows another type of pipeline stall, which is induced by
waiting (PW phase) for an instruction fetch packet to occur on the CPU
boundary. Pipeline is completely halted, none of its phases is advancing.

; move contents of B1 to B3 via external memory:
; stalls are possible due to instr mem access for every FP
(EP k+1) STW .D2T2 B1, *B2 ; data @B2 can be loaded in the next cycle
; stall is possible if EP1 and EP2 are in the same FP
(EP k+2) LDW .D2T2 *B2, B3 ; E1: data pointer modified
(EP k+3) NOP ; E2: data address sent
(EP k+4) NOP ; E3: stall until data @B2 is fetched
; stall is due to data memory access
(EP k+5) NOP ; E4: data is being stored to B3
(EP k+6) NOP ; E5: B3 has been modified with the data in B1

HTH,

Andrew

> Subject: C6713: data memory stalls
> Posted by: "Bernhard 'Gustl' Bauer"
> Date: Wed Mar 31, 2010 12:12 am ((PDT))
>
> Hi,
>
> I'm looking for some documentation what causes data memory stalls on a
> C6713. The only thing I found so far is spru733a. And it says only: 'A
> memory stall occurs when memory is not ready to respond to an access
> from the CPU.'
>
> I'm using combinations of STW, LDW and LDDW. I want to know which
> combinations are causing stalls. It would be help full to know how the
> simulator indicate (event name) those stalls.
>
> I use no L2 cache.
>
> TIA
>
> Gustl
>

_____________________________________
Hello Gustl,

On Wed, Mar 31, 2010 at 7:35 PM, Andrew Nesterov <
a...@techemail.com> wrote:

>
> I suppose that such a description (besides that in spru 189/732/733) could
> be found in a CPU hardware design text, in a section on CPU external memory
> accessing.
>
> There are 3 types of pipeline stalls in the C6000 architcture, all them
> are described in spru733a, the first one shown in figure 4-28 (p.388) and
> is due to multiple EPs in the same FP; the others are due to either
> instruction or data memory access, shown in figure 4-32.
>
> Stalls are something that software cannot control. If put in terms of
> software,
> one would said that a stall is a polling wait for an event, specifically
> for
> an external memory response. During stall cycles the CPU is doing nothing,
> its
> pipeline is halted, while its memory subsystem hardware is waiting a
> response
> signal from memory controller. I guess that simulators mostly would not
> simulate memory controller stalls, but they do simulate pipeline stalls due
> to
> multiple EPs in a single FP.
>
> The reason for memory access stalls is in the fact that the dynamic memory
> is
> usually clocked at a lower rate than the CPU, thus it takes additional CPU
> clock cycles for a memory controller to deliver data on the CPU boundary.
>
> Data fetch stalls can be induced only by the load type of instructions.
> The store type instructions never induce data write stalls. In the Figure
> 4-15 of spru733a, a stall takes place after E3 until data are fetched to
> the CPU boundary.
>
> Pipeline also can be stalled by instruction flow. This time the stalls
> do not affect performance at all, they allow for dispatching consequent
> execute packets found in the same instruction fetch packet. See Figure 4-28
> on page 338 (4-57), sect. 4.4.1.
>
> Figure 4-32 also shows another type of pipeline stall, which is induced by
> waiting (PW phase) for an instruction fetch packet to occur on the CPU
> boundary. Pipeline is completely halted, none of its phases is advancing.
>
> ; move contents of B1 to B3 via external memory:
> ; stalls are possible due to instr mem access for every FP
> (EP k+1) STW .D2T2 B1, *B2 ; data @B2 can be loaded in the next cycle
> ; stall is possible if EP1 and EP2 are in the same FP
> (EP k+2) LDW .D2T2 *B2, B3 ; E1: data pointer modified
> (EP k+3) NOP ; E2: data address sent
> (EP k+4) NOP ; E3: stall until data @B2 is fetched
> ; stall is due to data memory access
> (EP k+5) NOP ; E4: data is being stored to B3
> (EP k+6) NOP ; E5: B3 has been modified with the data in B1
>
> HTH,
>
> Andrew
>

I assume that you are using rev 2.0 devices. If you are using 1.1 and
internal RAM, make sure that you check the errata doc.

mikedunn

>
> > Subject: C6713: data memory stalls
> > Posted by: "Bernhard 'Gustl' Bauer"
> > Date: Wed Mar 31, 2010 12:12 am ((PDT))
>
> >
> > Hi,
> >
> > I'm looking for some documentation what causes data memory stalls on a
> > C6713. The only thing I found so far is spru733a. And it says only: 'A
> > memory stall occurs when memory is not ready to respond to an access
> > from the CPU.'
> >
> > I'm using combinations of STW, LDW and LDDW. I want to know which
> > combinations are causing stalls. It would be help full to know how the
> > simulator indicate (event name) those stalls.
> >
> > I use no L2 cache.
> >
> > TIA
> >
> > Gustl
> >
>
>

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php