Hi,
I'm working with a 6713B. I have a situation where src and dst of memcpy
point to ext. SDRAM. When I simulate this and do assembly-single steps
through memcpy I see that every step a data transfer is made. What if a
EDMA wants to access ext. SDRAM at the same time? Which one is stalled:
EDMA or CPU?
TIA
Gustl
_____________________________________
memcpy vs. EDMA
Started by ●March 4, 2009
Reply by ●March 4, 20092009-03-04
Gustl,
The short answer is that CPU always has priority over EDMA on a C6713.
The longer answer is that I think the transfer process is more complicated than you describe below. Is cache enabled ? The CPU can stall if data has to be fetched from either L2 or external SDRAM and I don't think you will see the stall in the simulator ?
- Andrew E
----- Original Message ----
From: Bernhard 'Gustl' Bauer
To: C6x
Sent: Wednesday, March 4, 2009 6:59:12 AM
Subject: [c6x] memcpy vs. EDMA
Hi,
I'm working with a 6713B. I have a situation where src and dst of memcpy
point to ext. SDRAM. When I simulate this and do assembly-single steps
through memcpy I see that every step a data transfer is made. What if a
EDMA wants to access ext. SDRAM at the same time? Which one is stalled:
EDMA or CPU?
TIA
Gustl
_____________________________________
_____________________________________
The short answer is that CPU always has priority over EDMA on a C6713.
The longer answer is that I think the transfer process is more complicated than you describe below. Is cache enabled ? The CPU can stall if data has to be fetched from either L2 or external SDRAM and I don't think you will see the stall in the simulator ?
- Andrew E
----- Original Message ----
From: Bernhard 'Gustl' Bauer
To: C6x
Sent: Wednesday, March 4, 2009 6:59:12 AM
Subject: [c6x] memcpy vs. EDMA
Hi,
I'm working with a 6713B. I have a situation where src and dst of memcpy
point to ext. SDRAM. When I simulate this and do assembly-single steps
through memcpy I see that every step a data transfer is made. What if a
EDMA wants to access ext. SDRAM at the same time? Which one is stalled:
EDMA or CPU?
TIA
Gustl
_____________________________________
_____________________________________
Reply by ●March 5, 20092009-03-05
Andrew,
L2 cache is disabled. I triggered a EDMA transfer during the simulation
of memcpy. It was delay, but not until the end of memcpy. How reliable
is the simulator? I'm using CCS 2.2.
Gustl
Andrew Elder schrieb:
>
> Gustl,
>
> The short answer is that CPU always has priority over EDMA on a C6713.
>
> The longer answer is that I think the transfer process is more
> complicated than you describe below. Is cache enabled ? The CPU can
> stall if data has to be fetched from either L2 or external SDRAM and I
> don't think you will see the stall in the simulator ?
>
> - Andrew E
>
> ----- Original Message ----
> From: Bernhard 'Gustl' Bauer >
> To: C6x >
> Sent: Wednesday, March 4, 2009 6:59:12 AM
> Subject: [c6x] memcpy vs. EDMA
>
> Hi,
>
> I'm working with a 6713B. I have a situation where src and dst of memcpy
> point to ext. SDRAM. When I simulate this and do assembly-single steps
> through memcpy I see that every step a data transfer is made. What if a
> EDMA wants to access ext. SDRAM at the same time? Which one is stalled:
> EDMA or CPU?
>
> TIA
>
> Gustl
>
_____________________________________
L2 cache is disabled. I triggered a EDMA transfer during the simulation
of memcpy. It was delay, but not until the end of memcpy. How reliable
is the simulator? I'm using CCS 2.2.
Gustl
Andrew Elder schrieb:
>
> Gustl,
>
> The short answer is that CPU always has priority over EDMA on a C6713.
>
> The longer answer is that I think the transfer process is more
> complicated than you describe below. Is cache enabled ? The CPU can
> stall if data has to be fetched from either L2 or external SDRAM and I
> don't think you will see the stall in the simulator ?
>
> - Andrew E
>
> ----- Original Message ----
> From: Bernhard 'Gustl' Bauer >
> To: C6x >
> Sent: Wednesday, March 4, 2009 6:59:12 AM
> Subject: [c6x] memcpy vs. EDMA
>
> Hi,
>
> I'm working with a 6713B. I have a situation where src and dst of memcpy
> point to ext. SDRAM. When I simulate this and do assembly-single steps
> through memcpy I see that every step a data transfer is made. What if a
> EDMA wants to access ext. SDRAM at the same time? Which one is stalled:
> EDMA or CPU?
>
> TIA
>
> Gustl
>
_____________________________________
Reply by ●March 5, 20092009-03-05
Gustl,
I wouldn't trust the simulator for this sort of test. Real hardware would be the way to run it. For us, since EDMA was feeding D/As, we would see channel rotation when an EDMA transfer was delayed for too long.
Are you EDMAing in and out of internal memory <-> McASPs ?
- Andrew
----- Original Message ----
From: Bernhard 'Gustl' Bauer
To: Andrew Elder
Cc: C6x
Sent: Thursday, March 5, 2009 1:30:12 AM
Subject: Re: [c6x] memcpy vs. EDMA
Andrew,
L2 cache is disabled. I triggered a EDMA transfer during the simulation of memcpy. It was delay, but not until the end of memcpy. How reliable is the simulator? I'm using CCS 2.2.
Gustl
Andrew Elder schrieb:
>
> Gustl,
>
> The short answer is that CPU always has priority over EDMA on a C6713.
>
> The longer answer is that I think the transfer process is more complicated than you describe below. Is cache enabled ? The CPU can stall if data has to be fetched from either L2 or external SDRAM and I don't think you will see the stall in the simulator ?
>
> - Andrew E
>
> ----- Original Message ----
> From: Bernhard 'Gustl' Bauer >
> To: C6x >
> Sent: Wednesday, March 4, 2009 6:59:12 AM
> Subject: [c6x] memcpy vs. EDMA
>
> Hi,
>
> I'm working with a 6713B. I have a situation where src and dst of memcpy
> point to ext. SDRAM. When I simulate this and do assembly-single steps
> through memcpy I see that every step a data transfer is made. What if a
> EDMA wants to access ext. SDRAM at the same time? Which one is stalled:
> EDMA or CPU?
>
> TIA
>
> Gustl
>
_____________________________________
I wouldn't trust the simulator for this sort of test. Real hardware would be the way to run it. For us, since EDMA was feeding D/As, we would see channel rotation when an EDMA transfer was delayed for too long.
Are you EDMAing in and out of internal memory <-> McASPs ?
- Andrew
----- Original Message ----
From: Bernhard 'Gustl' Bauer
To: Andrew Elder
Cc: C6x
Sent: Thursday, March 5, 2009 1:30:12 AM
Subject: Re: [c6x] memcpy vs. EDMA
Andrew,
L2 cache is disabled. I triggered a EDMA transfer during the simulation of memcpy. It was delay, but not until the end of memcpy. How reliable is the simulator? I'm using CCS 2.2.
Gustl
Andrew Elder schrieb:
>
> Gustl,
>
> The short answer is that CPU always has priority over EDMA on a C6713.
>
> The longer answer is that I think the transfer process is more complicated than you describe below. Is cache enabled ? The CPU can stall if data has to be fetched from either L2 or external SDRAM and I don't think you will see the stall in the simulator ?
>
> - Andrew E
>
> ----- Original Message ----
> From: Bernhard 'Gustl' Bauer >
> To: C6x >
> Sent: Wednesday, March 4, 2009 6:59:12 AM
> Subject: [c6x] memcpy vs. EDMA
>
> Hi,
>
> I'm working with a 6713B. I have a situation where src and dst of memcpy
> point to ext. SDRAM. When I simulate this and do assembly-single steps
> through memcpy I see that every step a data transfer is made. What if a
> EDMA wants to access ext. SDRAM at the same time? Which one is stalled:
> EDMA or CPU?
>
> TIA
>
> Gustl
>
_____________________________________
Reply by ●March 9, 20092009-03-09
Didn’t DMA operation need to be independent of CPU. Why will EDMA
operation stalls if CPU want to read data from same external device?
The SDRAM anyway will be have independent RAS /CAS timing based CPU interface to refresh/read/write/drive dynamic memory.
If CPU want to write on SDRAM while EDMA want access to read SDRAM. Both operation should happen at same time. All memory these days are dual port memories
--- On Wed, 3/4/09, Bernhard 'Gustl' Bauer wrote:
From: Bernhard 'Gustl' Bauer
Subject: [c6x] memcpy vs. EDMA
To: "C6x"
Date: Wednesday, March 4, 2009, 6:59 AM
Hi,
I'm working with a 6713B. I have a situation where src and dst of memcpy
point to ext. SDRAM. When I simulate this and do assembly-single steps
through memcpy I see that every step a data transfer is made. What if a
EDMA wants to access ext. SDRAM at the same time? Which one is stalled:
EDMA or CPU?
TIA
Gustl
_____________________________________
The SDRAM anyway will be have independent RAS /CAS timing based CPU interface to refresh/read/write/drive dynamic memory.
If CPU want to write on SDRAM while EDMA want access to read SDRAM. Both operation should happen at same time. All memory these days are dual port memories
--- On Wed, 3/4/09, Bernhard 'Gustl' Bauer wrote:
From: Bernhard 'Gustl' Bauer
Subject: [c6x] memcpy vs. EDMA
To: "C6x"
Date: Wednesday, March 4, 2009, 6:59 AM
Hi,
I'm working with a 6713B. I have a situation where src and dst of memcpy
point to ext. SDRAM. When I simulate this and do assembly-single steps
through memcpy I see that every step a data transfer is made. What if a
EDMA wants to access ext. SDRAM at the same time? Which one is stalled:
EDMA or CPU?
TIA
Gustl
_____________________________________
Reply by ●March 9, 20092009-03-09
gagan,
On Mon, Mar 9, 2009 at 9:00 AM, gagan singh wrote:
> Didnt DMA operation need to be independent of CPU. Why will EDMA operation
> stalls if CPU want to read data from same external device?
1 resource with 1 access path [SDRAM] can only be accessed by one
device [CPU or EDMA] at a time.
> The SDRAM anyway will be have independent RAS /CAS timing based CPU
> interface to refresh/read/write/drive dynamic memory.
> If CPU want to write on SDRAM while EDMA want access to read SDRAM. Both
> operation should happen at same time.
I believe that the SDRAM has a single set of address lines - this
would make it very difficult to select a write address and a read
address at the same time.
> All memory these days are dual port
> memories
Really?? I believe that this is incorrect information and that there
is a serious 'understanding' or 'communication' problem with the above
assertions.
mikedunn
>
> --- On Wed, 3/4/09, Bernhard 'Gustl' Bauer wrote:
>
> From: Bernhard 'Gustl' Bauer
> Subject: [c6x] memcpy vs. EDMA
> To: "C6x"
> Date: Wednesday, March 4, 2009, 6:59 AM
>
> Hi,
>
> I'm working with a 6713B. I have a situation where src and dst of memcpy
> point to ext. SDRAM. When I simulate this and do assembly-single steps
> through memcpy I see that every step a data transfer is made. What if a
> EDMA wants to access ext. SDRAM at the same time? Which one is stalled:
> EDMA or CPU?
>
> TIA
>
> Gustl
>
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
_____________________________________
On Mon, Mar 9, 2009 at 9:00 AM, gagan singh wrote:
> Didnt DMA operation need to be independent of CPU. Why will EDMA operation
> stalls if CPU want to read data from same external device?
1 resource with 1 access path [SDRAM] can only be accessed by one
device [CPU or EDMA] at a time.
> The SDRAM anyway will be have independent RAS /CAS timing based CPU
> interface to refresh/read/write/drive dynamic memory.
> If CPU want to write on SDRAM while EDMA want access to read SDRAM. Both
> operation should happen at same time.
I believe that the SDRAM has a single set of address lines - this
would make it very difficult to select a write address and a read
address at the same time.
> All memory these days are dual port
> memories
Really?? I believe that this is incorrect information and that there
is a serious 'understanding' or 'communication' problem with the above
assertions.
mikedunn
>
> --- On Wed, 3/4/09, Bernhard 'Gustl' Bauer wrote:
>
> From: Bernhard 'Gustl' Bauer
> Subject: [c6x] memcpy vs. EDMA
> To: "C6x"
> Date: Wednesday, March 4, 2009, 6:59 AM
>
> Hi,
>
> I'm working with a 6713B. I have a situation where src and dst of memcpy
> point to ext. SDRAM. When I simulate this and do assembly-single steps
> through memcpy I see that every step a data transfer is made. What if a
> EDMA wants to access ext. SDRAM at the same time? Which one is stalled:
> EDMA or CPU?
>
> TIA
>
> Gustl
>
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
_____________________________________
