linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* MPC8308 bursting question
@ 2011-05-27  6:11 Bruce_Leonard
  2011-05-27 14:26 ` David Hawkins
  0 siblings, 1 reply; 4+ messages in thread
From: Bruce_Leonard @ 2011-05-27  6:11 UTC (permalink / raw)
  To: linuxppc-dev

All,

This isn't really a Linux PPC question, but this is the smartest mailing 
list I know for asking PPC hardware questions, so here goes.

We're using an MPC8308 and want to use the DMA engine to move data in and 
out of an FPGA hanging on the local bus.  Our bandwidth/local bus burden 
calculations were done assuming that we could use bursting.  So I've setup 
a UPM to do single beat and burst reads/writes.  I've also configured my 
DMA TCD to use a data transfer size of 32-bytes when accessing the FPGA. 
The problem I'm having is I can't seem to get the UPM to ever trigger the 
burst write sequence using the DMA.  Single beat reads and writes work 
okay, but no bursting.  In fact, the only thing I've been able to find in 
the manual that causes a burst transaction is a cache line miss, which is 
wholly in the purview of the core and really does me no good.

Does anyone know of any way (short of issuing a run command to the UPM via 
MxMR) to force a burst transaction on the 8308?  Am I just being dumb and 
missing something totally fundamental?

Thanks.

Bruce

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: MPC8308 bursting question
  2011-05-27  6:11 MPC8308 bursting question Bruce_Leonard
@ 2011-05-27 14:26 ` David Hawkins
  2011-05-27 20:29   ` Bruce_Leonard
  0 siblings, 1 reply; 4+ messages in thread
From: David Hawkins @ 2011-05-27 14:26 UTC (permalink / raw)
  To: Bruce_Leonard; +Cc: linuxppc-dev

Hi Bruce,

> This isn't really a Linux PPC question, but this is the smartest mailing
> list I know for asking PPC hardware questions, so here goes.
>
> We're using an MPC8308 and want to use the DMA engine to move data in and
> out of an FPGA hanging on the local bus.  Our bandwidth/local bus burden
> calculations were done assuming that we could use bursting.  So I've setup
> a UPM to do single beat and burst reads/writes.  I've also configured my
> DMA TCD to use a data transfer size of 32-bytes when accessing the FPGA.
> The problem I'm having is I can't seem to get the UPM to ever trigger the
> burst write sequence using the DMA.  Single beat reads and writes work
> okay, but no bursting.  In fact, the only thing I've been able to find in
> the manual that causes a burst transaction is a cache line miss, which is
> wholly in the purview of the core and really does me no good.
>
> Does anyone know of any way (short of issuing a run command to the UPM via
> MxMR) to force a burst transaction on the 8308?  Am I just being dumb and
> missing something totally fundamental?

Read my MPC8349EA UPM setup notes and see if you have used
similar settings (I assume the local bus UPMs are similar):

http://www.ovro.caltech.edu/~dwh/carma_board/carma_sys.pdf

Do you have a Modelsim simulation of your interface?
I have a VHDL bus-functional-model I wrote that I can
send you.

Cheers,
Dave

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: MPC8308 bursting question
  2011-05-27 14:26 ` David Hawkins
@ 2011-05-27 20:29   ` Bruce_Leonard
  2011-05-27 20:33     ` David Hawkins
  0 siblings, 1 reply; 4+ messages in thread
From: Bruce_Leonard @ 2011-05-27 20:29 UTC (permalink / raw)
  To: David Hawkins; +Cc: linuxppc-dev

Hi David,

> 
> Read my MPC8349EA UPM setup notes and see if you have used
> similar settings (I assume the local bus UPMs are similar):
> 

I found you paper interesting.  I didn't have a problem with my UPM 
settings, single beat reads and writes worked just fine, however it did 
tickle my memory and helped me find what was wrong.  Turns out that the 
person who was responsible for the BAx/ORx registers for this chip select 
had set the BI bit a long time ago, before we were contemplating doing 
what we're currently doing.  The code had been reviewed and signed off, so 
in my back brain I was thinking everything there was good.

When I read your paper, it mentioned the BI bit which got me to thinking. 
Sure enough, when I looked it was set.  Soon as I  cleared that bit, my 
burst transactions started working just fine.

Thanks for the help.

Bruce

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: MPC8308 bursting question
  2011-05-27 20:29   ` Bruce_Leonard
@ 2011-05-27 20:33     ` David Hawkins
  0 siblings, 0 replies; 4+ messages in thread
From: David Hawkins @ 2011-05-27 20:33 UTC (permalink / raw)
  To: Bruce_Leonard; +Cc: linuxppc-dev

Hi Bruce,

>> Read my MPC8349EA UPM setup notes and see if you have used
>> similar settings (I assume the local bus UPMs are similar):
>
> I found you paper interesting.  I didn't have a problem with my UPM
> settings, single beat reads and writes worked just fine, however it did
> tickle my memory and helped me find what was wrong.  Turns out that the
> person who was responsible for the BAx/ORx registers for this chip select
> had set the BI bit a long time ago, before we were contemplating doing
> what we're currently doing.  The code had been reviewed and signed off, so
> in my back brain I was thinking everything there was good.
>
> When I read your paper, it mentioned the BI bit which got me to thinking.
> Sure enough, when I looked it was set.  Soon as I  cleared that bit, my
> burst transactions started working just fine.
>
> Thanks for the help.

You're welcome. I'm glad it helped.

Cheers,
Dave

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-05-27 20:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-27  6:11 MPC8308 bursting question Bruce_Leonard
2011-05-27 14:26 ` David Hawkins
2011-05-27 20:29   ` Bruce_Leonard
2011-05-27 20:33     ` David Hawkins

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).