DSPRelated.com
Forums

c5416 memory interface

Started by vser...@aselsan.com.tr April 2, 2008
Hi,
I am trying to connect 2 memories each having a size of 2M x 16bits to 5416 using its memory interface. In the datasheet of 5416, it says data memory is upto 64K. So, should I use program memory space to access 2 memories? Or what can be the possible solution? Is program memory space writable?Thanks for help
V Serter-

> I am trying to connect 2 memories each having a size of 2M x 16bits to
> 5416 using its memory interface. In the datasheet of 5416, it says data
> memory is upto 64K. So, should I use program memory space to access 2
> memories? Or what can be the possible solution? Is program memory space
> writable?Thanks for help

C54xx data memory is limited to 64k because the ARn registers are 16-bit. That means
any instruction that makes a data memory access can't "see" more than 64k.

If you're going to have 4M x 16 of external mem, then almost all of this memory has
to be program memory. If I recall correctly, you can have up to 124 pages of
external program memory, each page 32k. I remember that it wasn't easy to get a full
64k of data memory unless you set OVLY = 0, which was usually a bad idea because it
disabled a 32k chunk of fast onchip program mem. Typically onchip program memory is
a valuable resource for achieving better performance, as data memory is not accessed
as often. If you do set OVLY = 0, then you can combine /DS strobe and appropriate
address lines in some external circuitry that would make the first 32k of your
external memory accessible as data mem.

I don't recall any reason to set DROM = 0. You can always have 32k of onchip data
mem without any tradeoffs.

If this is the MELPe project with Murat der, I thought you guys were using 55x?
Why switch back to 54xx? Well if you have switched back to 54xx for some reason,
then my suggestion would be to declare codebook tables as .const arrays, which will
cause them to be located in program memory.

-Jeff
Siva-
> i am having one doubt, if i store my code book details in program memory..how can i
> distinguish program memory and data memory....if it is in pure assembly ok..some
> specific instructions r there.... when it comes 2 algebraic (assume i am using
> pointers) how 2 distinguish..can any ody pls clarify??? its basic doubt only but no
> body is there 2 clear....

Algebraic instructions for accessing program memory:

prog(A) = Smem
Smem = prog(A)

-Jeff
> On 4/4/08, Jeff Brower wrote:
>
> V Serter-
>
> > I am trying to connect 2 memories each having a size of 2M x 16bits to
> > 5416 using its memory interface. In the datasheet of 5416, it says data
>
> > memory is upto 64K. So, should I use program memory space to access 2
> > memories? Or what can be the possible solution? Is program memory space
>
> > writable?Thanks for help
>
> C54xx data memory is limited to 64k because the ARn registers are 16-bit.
> That means
> any instruction that makes a data memory access can't "see" more than
> 64k.
>
> If you're going to have 4M x 16 of external mem, then almost all of this
> memory has
> to be program memory. If I recall correctly, you can have up to 124 pages
> of
> external program memory, each page 32k. I remember that it wasn't easy to
> get a full
> 64k of data memory unless you set OVLY = 0, which was usually a bad idea
> because it
> disabled a 32k chunk of fast onchip program mem. Typically onchip program
> memory is
> a valuable resource for achieving better performance, as data memory is
> not accessed
> as often. If you do set OVLY = 0, then you can combine /DS strobe and
> appropriate
> address lines in some external circuitry that would make the first 32k of
> your
> external memory accessible as data mem.
>
> I don't recall any reason to set DROM = 0. You can always have 32k of
> onchip data
> mem without any tradeoffs.
>
> If this is the MELPe project with Murat ?nder, I thought you guys were
> using 55x?
> Why switch back to 54xx? Well if you have switched back to 54xx for some
> reason,
> then my suggestion would be to declare codebook tables as .const arrays,
> which will
> cause them to be located in program memory.
>
> -Jeff
>
Siva Anne-
> actually i am working in some verification department...
> generally i verify the code written...code is written as follows
>
> ar4 = #a_coeff ;//here (a_coeff) is stored in prog memory with specifying tables
> sections in ;//command file
> ar1 = #inp_buffer
>
> a = (*ar4) * (*ar1)
> ;//for the above instruction inp_buffer is in data memory as these r the input
> samples...
> ;//ar4 is in prog memory...
>
> actually my work is to simulate the code in CCS... when i was simulating ar4 loaded
> with a_coeff address but ... when i executing it takes only data memory
> contents.....is it the correct way of implemntation r i am interpreting wrongly...

*ARn access to program mem only works in address space 0 to 32767 and if OVLY = 1.
Otherwise you have to use the specific program memory instructions (TBLR, TBLW,
prog(A), etc).

-Jeff
> On Mon, Apr 7, 2008 at 8:34 PM, Jeff Brower wrote:
>
> Siva-
> > i am having one doubt, if i store my code book details in program
> > memory..how can i distinguish program memory and data memory....if it
> > is in pure assembly ok..some specific instructions r there.... when it
> > comes 2 algebraic (assume i am using pointers) how 2 distinguish..can
> > any ody pls clarify??? its basic doubt only but no body is there 2
> > clear....
> Algebraic instructions for accessing program memory:
>
> prog(A) = Smem
> Smem = prog(A)
>
> -Jeff
> > On 4/4/08, Jeff Brower wrote:
> >
> > V Serter-
> >
> > > I am trying to connect 2 memories each having a size of 2M
> > x 16bits to
> > > 5416 using its memory interface. In the datasheet of 5416,
> > it says data
> > > memory is upto 64K. So, should I use program memory space
> > to access 2
> > > memories? Or what can be the possible solution? Is program
> > memory space
> > > writable?Thanks for help
> >
> > C54xx data memory is limited to 64k because the ARn registers
> > are 16-bit. That means
> > any instruction that makes a data memory access can't "see"
> > more than 64k.
> >
> > If you're going to have 4M x 16 of external mem, then almost
> > all of this memory has
> > to be program memory. If I recall correctly, you can have up
> > to 124 pages of
> > external program memory, each page 32k. I remember that it
> > wasn't easy to get a full
> > 64k of data memory unless you set OVLY = 0, which was usually
> > a bad idea because it
> > disabled a 32k chunk of fast onchip program mem. Typically
> > onchip program memory is
> > a valuable resource for achieving better performance, as data
> > memory is not accessed
> > as often. If you do set OVLY = 0, then you can combine /DS
> > strobe and appropriate
> > address lines in some external circuitry that would make the
> > first 32k of your
> > external memory accessible as data mem.
> >
> > I don't recall any reason to set DROM = 0. You can always
> > have 32k of onchip data
> > mem without any tradeoffs.
> >
> > If this is the MELPe project with Murat ?nder, I thought you
> > guys were using 55x?
> > Why switch back to 54xx? Well if you have switched back to
> > 54xx for some reason,
> > then my suggestion would be to declare codebook tables as
> > .const arrays, which will
> > cause them to be located in program memory.
> >
> > -Jeff
> >
actually i am working in some verification department...
generally i verify the code written...code is written as follows

ar4 = #a_coeff ;//here (a_coeff) is stored in prog memory with specifying
tables sections in ;//command file
ar1 = #inp_buffer

a = (*ar4) * (*ar1)
;//for the above instruction inp_buffer is in data memory as these r the
input samples...
;//ar4 is in prog memory...

actually my work is to simulate the code in CCS... when i was simulating ar4
loaded with a_coeff address but ... when i executing it takes only data
memory contents.....is it the correct way of implemntation r i am
interpreting wrongly...

anne

On Mon, Apr 7, 2008 at 8:34 PM, Jeff Brower wrote:

> Siva-
> i am having one doubt, if i store my code book details in program
> memory..how can i distinguish program memory and data memory....if it is in
> pure assembly ok..some specific instructions r there.... when it comes 2
> algebraic (assume i am using pointers) how 2 distinguish..can any ody pls
> clarify??? its basic doubt only but no body is there 2 clear....
> Algebraic instructions for accessing program memory:
>
> prog(A) = Smem
> Smem = prog(A)
>
> -Jeff
> On 4/4/08, *Jeff Brower* wrote:
> >
> > V Serter-
> >
> > > I am trying to connect 2 memories each having a size of 2M x 16bits to
> > > 5416 using its memory interface. In the datasheet of 5416, it says
> > data
> > > memory is upto 64K. So, should I use program memory space to access 2
> > > memories? Or what can be the possible solution? Is program memory
> > space
> > > writable?Thanks for help
> >
> > C54xx data memory is limited to 64k because the ARn registers are
> > 16-bit. That means
> > any instruction that makes a data memory access can't "see" more than
> > 64k.
> >
> > If you're going to have 4M x 16 of external mem, then almost all of this
> > memory has
> > to be program memory. If I recall correctly, you can have up to 124
> > pages of
> > external program memory, each page 32k. I remember that it wasn't easy
> > to get a full
> > 64k of data memory unless you set OVLY = 0, which was usually a bad idea
> > because it
> > disabled a 32k chunk of fast onchip program mem. Typically onchip
> > program memory is
> > a valuable resource for achieving better performance, as data memory is
> > not accessed
> > as often. If you do set OVLY = 0, then you can combine /DS strobe and
> > appropriate
> > address lines in some external circuitry that would make the first 32k
> > of your
> > external memory accessible as data mem.
> >
> > I don't recall any reason to set DROM = 0. You can always have 32k of
> > onchip data
> > mem without any tradeoffs.
> >
> > If this is the MELPe project with Murat der, I thought you guys were
> > using 55x?
> > Why switch back to 54xx? Well if you have switched back to 54xx for some
> > reason,
> > then my suggestion would be to declare codebook tables as .const arrays,
> > which will
> > cause them to be located in program memory.
> >
> > -Jeff
>


Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467