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