The 21065L Ez-kit does have external SDRAM. If it was possible to move
the
monitor code to external memory, that would be great. But I don't know how
to
do that. As I mentioned earlier, the way the monitor gets linked and loaded
in
with my application is a mystery to me--you don't do anything explicit that
I
can find. The documentation just tells you "don't use these memory
addresses"
(internal memory) and somehow the monitor code ends up there.
--- Steve Holle <sholle@shol...> wrote:
> Do you have external memory space? We've
moved
> quite a bit of our low speed code out to external memory.
>
> At 04:44 PM 7/6/2005, Jon Harris wrote:
> >Is the source code included for the Ez-kit monitor kernel code? I
couldn't
> >seem to find it. I am using the 21065L Ez-kit Lite.
> >
> >Also, is there an easy way to tell how much code
> >space is actually required for
> >the kernel? The documentation tells you to reserve 0x9000 - 0x97FF for
the
> >kernel, but my application is _very_ tight on PM space and it would be
nice
> to
> >be able to use some of that block for some variables. Looking at the
> >dissasembly, it doesn't look like the whole thing is being used,
but it is a
> >little tough to tell.
> >
> >The way the whole monitor/kernel is a bit of mystery to me, since you
don't
> >explicitly allocate any space for it, and you
> >don't link it with your application.
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
June update for VDSP++4.0
Started by ●July 1, 2005
Reply by ●July 7, 20052005-07-07
Reply by ●July 8, 20052005-07-08
As far as I know -- it's a long time since I last used this stuff -- the
monitor code is NOT compiled and/or linked in, as well as it is NOT
loaded (from the PC, at last).
When the EZK starts up, the monitor code is booted to the internal
memory locations mentioned in the manual and the LDF file (they reserved
a bit more then was actually needed for later extensions). When loading
your own program sending it over the serial line, the monitor code is
responsible for interpreting the tags and placing the code into memory.
Using adresses that are reserved for monitor's usage would simply
overwrite them and kill the monitor.
Moving the monitor out of internal memory should be fairly simple if you
could get hold of the source code... doing this to the binary boot image
inside the EPROM is not so easy, but sure not impossible: you would
essentially have to patch the adress marks of the code tags and adapt
the call adresses inside the monitor code.
Friedrich
> -----Original Message-----
> From: adsp@adsp... [mailto:adsp@adsp...] On
> Behalf Of Jon Harris
> Sent: Thursday, July 07, 2005 7:44 PM
> To: Steve Holle; adsp@adsp...
> Subject: Re: [adsp] 21065L Ez-kit kernel source? > The 21065L Ez-kit does have external SDRAM. If it was
> possible to move the monitor code to external memory, that
> would be great. But I don't know how to do that. As I
> mentioned earlier, the way the monitor gets linked and loaded
> in with my application is a mystery to me--you don't do
> anything explicit that I can find. The documentation just
> tells you "don't use these memory addresses" (internal
> memory) and somehow the monitor code ends up there.
>
> --- Steve Holle <sholle@shol...> wrote:
>
> > Do you have external memory space? We've moved
> > quite a bit of our low speed code out to external memory.
> >
> > At 04:44 PM 7/6/2005, Jon Harris wrote:
> > >Is the source code included for the Ez-kit monitor kernel code? I
> > >couldn't seem to find it. I am using the 21065L Ez-kit Lite.
> > >
> > >Also, is there an easy way to tell how much code
> > >space is actually required for
> > >the kernel? The documentation tells you to reserve 0x9000
> - 0x97FF for the
> > >kernel, but my application is _very_ tight on PM space and
> it would be nice
> > to
> > >be able to use some of that block for some variables.
> Looking at the
> > >dissasembly, it doesn't look like the whole thing is being
> used, but
> > >it is a little tough to tell.
> > >
> > >The way the whole monitor/kernel is a bit of mystery to
> me, since you
> > >don't explicitly allocate any space for it, and you don't link it
> > >with your application. >
>
> ____________________________________________________
> Sell on Yahoo! Auctions - no fees. Bid on great items.
> http://auctions.yahoo.com/ >
>
Reply by ●July 8, 20052005-07-08
Thanks--your description makes sense and explains why you can't control
the
monitor position easily. As mentioned earlier in the thread, ADI does not
supply source code for the monitor.
I have found experimentally that it reserves more space than it needs, and I a
have "stolen" a bit of that space for my own purposes. I know this isn't good
practice long term (future monitor versions may require more code space) but
for now it gets me going.
--- Burgwedel Friedrich <burgwedelF@burg...> wrote:
>
> As far as I know -- it's a long time since I last used this stuff -- the
> monitor code is NOT compiled and/or linked in, as well as it is NOT
> loaded (from the PC, at last).
>
> When the EZK starts up, the monitor code is booted to the internal
> memory locations mentioned in the manual and the LDF file (they reserved
> a bit more then was actually needed for later extensions). When loading
> your own program sending it over the serial line, the monitor code is
> responsible for interpreting the tags and placing the code into memory.
> Using adresses that are reserved for monitor's usage would simply
> overwrite them and kill the monitor.
>
> Moving the monitor out of internal memory should be fairly simple if you
> could get hold of the source code... doing this to the binary boot image
> inside the EPROM is not so easy, but sure not impossible: you would
> essentially have to patch the adress marks of the code tags and adapt
> the call adresses inside the monitor code.
>
> Friedrich >
> > -----Original Message-----
> > From: adsp@adsp... [mailto:adsp@adsp...] On
> > Behalf Of Jon Harris
> > Sent: Thursday, July 07, 2005 7:44 PM
> > To: Steve Holle; adsp@adsp...
> > Subject: Re: [adsp] 21065L Ez-kit kernel source?
> >
> >
> > The 21065L Ez-kit does have external SDRAM. If it was
> > possible to move the monitor code to external memory, that
> > would be great. But I don't know how to do that. As I
> > mentioned earlier, the way the monitor gets linked and loaded
> > in with my application is a mystery to me--you don't do
> > anything explicit that I can find. The documentation just
> > tells you "don't use these memory addresses" (internal
> > memory) and somehow the monitor code ends up there.
> >
> > --- Steve Holle <sholle@shol...> wrote:
> >
> > > Do you have external memory space? We've moved
> > > quite a bit of our low speed code out to external memory.
> > >
> > > At 04:44 PM 7/6/2005, Jon Harris wrote:
> > > >Is the source code included for the Ez-kit monitor kernel code? I
> > > >couldn't seem to find it. I am using the 21065L Ez-kit Lite.
> > > >
> > > >Also, is there an easy way to tell how much code
> > > >space is actually required for
> > > >the kernel? The documentation tells you to reserve 0x9000
> > - 0x97FF for the
> > > >kernel, but my application is _very_ tight on PM space and
> > it would be nice
> > > to
> > > >be able to use some of that block for some variables.
> > Looking at the
> > > >dissasembly, it doesn't look like the whole thing is being
> > used, but
> > > >it is a little tough to tell.
> > > >
> > > >The way the whole monitor/kernel is a bit of mystery to
> > me, since you
> > > >don't explicitly allocate any space for it, and you don't link it
> > > >with your application.
__________________________________
monitor position easily. As mentioned earlier in the thread, ADI does not
supply source code for the monitor.
I have found experimentally that it reserves more space than it needs, and I a
have "stolen" a bit of that space for my own purposes. I know this isn't good
practice long term (future monitor versions may require more code space) but
for now it gets me going.
--- Burgwedel Friedrich <burgwedelF@burg...> wrote:
>
> As far as I know -- it's a long time since I last used this stuff -- the
> monitor code is NOT compiled and/or linked in, as well as it is NOT
> loaded (from the PC, at last).
>
> When the EZK starts up, the monitor code is booted to the internal
> memory locations mentioned in the manual and the LDF file (they reserved
> a bit more then was actually needed for later extensions). When loading
> your own program sending it over the serial line, the monitor code is
> responsible for interpreting the tags and placing the code into memory.
> Using adresses that are reserved for monitor's usage would simply
> overwrite them and kill the monitor.
>
> Moving the monitor out of internal memory should be fairly simple if you
> could get hold of the source code... doing this to the binary boot image
> inside the EPROM is not so easy, but sure not impossible: you would
> essentially have to patch the adress marks of the code tags and adapt
> the call adresses inside the monitor code.
>
> Friedrich >
> > -----Original Message-----
> > From: adsp@adsp... [mailto:adsp@adsp...] On
> > Behalf Of Jon Harris
> > Sent: Thursday, July 07, 2005 7:44 PM
> > To: Steve Holle; adsp@adsp...
> > Subject: Re: [adsp] 21065L Ez-kit kernel source?
> >
> >
> > The 21065L Ez-kit does have external SDRAM. If it was
> > possible to move the monitor code to external memory, that
> > would be great. But I don't know how to do that. As I
> > mentioned earlier, the way the monitor gets linked and loaded
> > in with my application is a mystery to me--you don't do
> > anything explicit that I can find. The documentation just
> > tells you "don't use these memory addresses" (internal
> > memory) and somehow the monitor code ends up there.
> >
> > --- Steve Holle <sholle@shol...> wrote:
> >
> > > Do you have external memory space? We've moved
> > > quite a bit of our low speed code out to external memory.
> > >
> > > At 04:44 PM 7/6/2005, Jon Harris wrote:
> > > >Is the source code included for the Ez-kit monitor kernel code? I
> > > >couldn't seem to find it. I am using the 21065L Ez-kit Lite.
> > > >
> > > >Also, is there an easy way to tell how much code
> > > >space is actually required for
> > > >the kernel? The documentation tells you to reserve 0x9000
> > - 0x97FF for the
> > > >kernel, but my application is _very_ tight on PM space and
> > it would be nice
> > > to
> > > >be able to use some of that block for some variables.
> > Looking at the
> > > >dissasembly, it doesn't look like the whole thing is being
> > used, but
> > > >it is a little tough to tell.
> > > >
> > > >The way the whole monitor/kernel is a bit of mystery to
> > me, since you
> > > >don't explicitly allocate any space for it, and you don't link it
> > > >with your application.
__________________________________
Reply by ●August 10, 20052005-08-10
On the SHARC 21161, a very useful feature is the ability to use "long
word"
memory access to move 2 "neighbor" registers to memory (and vice versa) in a
single operation. For example:
dm(test) = R0 (LW); //equivalent to dm(test)=R0; dm(test+1)=R1;
The documentation clearly defines the neighbor register pairs for the normal
registers (R0-R15). However, it says nothing about neighbor registers for the
DAG registers (I0-I15, L0-L15, B0-B15, M0-M15). So, I am wondering if you can
use this same technique to move from DAG registers to memory in one operation,
for example:
dm(test) = I0 (LW); //equivalent to dm(test)=I0; dm(test+1)=I1; ???
It seems to work in the simulator, but I am a little hesitant to try it since
it is not documented at all (unless I've missed it). Does anyone have any
experience in this area?
I also have another related question on DAGs and memory access. What if SIMD
mode is on and you try to access a DAG register? I know that for normal
registers, it works like this:
dm(test) = R0; //when PEYN=1, equivalent to dm(test)=R0; dm(test+1)=S0;
But what happens for the second move if you specify a DAG register?
dm(test) = I0; //when PEYN=1, equivalent to dm(test)=I0; dm(test+1)=???
Perhaps it "broadcasts" I0 to both memory locations?
Again, if this is documented by ADI, please point out where it is discussed.
Thanks!
-Jon
__________________________________________________
memory access to move 2 "neighbor" registers to memory (and vice versa) in a
single operation. For example:
dm(test) = R0 (LW); //equivalent to dm(test)=R0; dm(test+1)=R1;
The documentation clearly defines the neighbor register pairs for the normal
registers (R0-R15). However, it says nothing about neighbor registers for the
DAG registers (I0-I15, L0-L15, B0-B15, M0-M15). So, I am wondering if you can
use this same technique to move from DAG registers to memory in one operation,
for example:
dm(test) = I0 (LW); //equivalent to dm(test)=I0; dm(test+1)=I1; ???
It seems to work in the simulator, but I am a little hesitant to try it since
it is not documented at all (unless I've missed it). Does anyone have any
experience in this area?
I also have another related question on DAGs and memory access. What if SIMD
mode is on and you try to access a DAG register? I know that for normal
registers, it works like this:
dm(test) = R0; //when PEYN=1, equivalent to dm(test)=R0; dm(test+1)=S0;
But what happens for the second move if you specify a DAG register?
dm(test) = I0; //when PEYN=1, equivalent to dm(test)=I0; dm(test+1)=???
Perhaps it "broadcasts" I0 to both memory locations?
Again, if this is documented by ADI, please point out where it is discussed.
Thanks!
-Jon
__________________________________________________
Reply by ●August 10, 20052005-08-10
For your second question, see page 5-3 of the instruction manual. The
DAG registers don't have complements (see page 2-31), just like the
MODE1 register (given in the example), so they operate the same in
SISD and SIMD modes.
On the first question, I don't think it would work reliably. First,
the I registers aren't listed as having neighbor registers on page
5.30 of the core manual. Second, the DAGS generally don't like being
accessed twice in a cycle, and can cause incorrect execution (page
4-24 of the core manual, gives some examples, but none with an LW)
--- In adsp@adsp..., Jon Harris <jon_harris7@y...> wrote:
> On the SHARC 21161, a very useful feature is the ability to use
"long word"
> memory access to move 2 "neighbor" registers to memory (and vice
versa) in a
> single operation. For example:
> dm(test) = R0 (LW); //equivalent to dm(test)=R0; dm(test+1)=R1;
>
> The documentation clearly defines the neighbor register pairs for
the normal
> registers (R0-R15). However, it says nothing about neighbor
registers for the
> DAG registers (I0-I15, L0-L15, B0-B15, M0-M15). So, I am wondering
if you can
> use this same technique to move from DAG registers to memory in one
operation,
> for example:
> dm(test) = I0 (LW); //equivalent to dm(test)=I0; dm(test+1)=I1; ???
>
> It seems to work in the simulator, but I am a little hesitant to try
it since
> it is not documented at all (unless I've missed it). Does anyone
have any
> experience in this area?
>
> I also have another related question on DAGs and memory access.
What if SIMD
> mode is on and you try to access a DAG register? I know that for normal
> registers, it works like this:
> dm(test) = R0; //when PEYN=1, equivalent to dm(test)=R0;
dm(test+1)=S0;
>
> But what happens for the second move if you specify a DAG register?
> dm(test) = I0; //when PEYN=1, equivalent to dm(test)=I0;
dm(test+1)=???
> Perhaps it "broadcasts" I0 to both memory locations?
> Again, if this is documented by ADI, please point out where it is
discussed.
>
> Thanks!
> -Jon
>
> __________________________________________________
>
DAG registers don't have complements (see page 2-31), just like the
MODE1 register (given in the example), so they operate the same in
SISD and SIMD modes.
On the first question, I don't think it would work reliably. First,
the I registers aren't listed as having neighbor registers on page
5.30 of the core manual. Second, the DAGS generally don't like being
accessed twice in a cycle, and can cause incorrect execution (page
4-24 of the core manual, gives some examples, but none with an LW)
--- In adsp@adsp..., Jon Harris <jon_harris7@y...> wrote:
> On the SHARC 21161, a very useful feature is the ability to use
"long word"
> memory access to move 2 "neighbor" registers to memory (and vice
versa) in a
> single operation. For example:
> dm(test) = R0 (LW); //equivalent to dm(test)=R0; dm(test+1)=R1;
>
> The documentation clearly defines the neighbor register pairs for
the normal
> registers (R0-R15). However, it says nothing about neighbor
registers for the
> DAG registers (I0-I15, L0-L15, B0-B15, M0-M15). So, I am wondering
if you can
> use this same technique to move from DAG registers to memory in one
operation,
> for example:
> dm(test) = I0 (LW); //equivalent to dm(test)=I0; dm(test+1)=I1; ???
>
> It seems to work in the simulator, but I am a little hesitant to try
it since
> it is not documented at all (unless I've missed it). Does anyone
have any
> experience in this area?
>
> I also have another related question on DAGs and memory access.
What if SIMD
> mode is on and you try to access a DAG register? I know that for normal
> registers, it works like this:
> dm(test) = R0; //when PEYN=1, equivalent to dm(test)=R0;
dm(test+1)=S0;
>
> But what happens for the second move if you specify a DAG register?
> dm(test) = I0; //when PEYN=1, equivalent to dm(test)=I0;
dm(test+1)=???
> Perhaps it "broadcasts" I0 to both memory locations?
> Again, if this is documented by ADI, please point out where it is
discussed.
>
> Thanks!
> -Jon
>
> __________________________________________________
>
Reply by ●August 10, 20052005-08-10
--- djthurin <dthuringer@dthu...> wrote:
> For your second question, see page 5-3 of the instruction manual. The
> DAG registers don't have complements (see page 2-31), just like the
> MODE1 register (given in the example), so they operate the same in
> SISD and SIMD modes.
Thanks for pointing out the relevant sections in the documentation. I agree
with your interpretation that there shouldn't be an extra implicit operation
for MODE1 or DAGs. However, the simulator shows the opposite--broadcasting the
MODE1 or DAG value to adjacent memory locations. I have contacted ADI about
this.
> On the first question, I don't think it would work reliably. First,
> the I registers aren't listed as having neighbor registers on page
> 5.30 of the core manual. Second, the DAGS generally don't like being
> accessed twice in a cycle, and can cause incorrect execution (page
> 4-24 of the core manual, gives some examples, but none with an LW)
What manual are you referring to here? The page numbers you list don't line up
with my documentation. I have the 21161 Hardware Reference and the 21160
Instruction Set Reference.
Thanks again for your help! I'll post back if I hear anything from ADI.
> --- In adsp@adsp..., Jon Harris <jon_harris7@y...> wrote:
> > On the SHARC 21161, a very useful feature is the ability to use
> "long word"
> > memory access to move 2 "neighbor" registers to memory (and vice
> versa) in a
> > single operation. For example:
> > dm(test) = R0 (LW); //equivalent to dm(test)=R0; dm(test+1)=R1;
> >
> > The documentation clearly defines the neighbor register pairs for
> the normal
> > registers (R0-R15). However, it says nothing about neighbor
> registers for the
> > DAG registers (I0-I15, L0-L15, B0-B15, M0-M15). So, I am wondering
> if you can
> > use this same technique to move from DAG registers to memory in one
> operation,
> > for example:
> > dm(test) = I0 (LW); //equivalent to dm(test)=I0; dm(test+1)=I1; ???
> >
> > It seems to work in the simulator, but I am a little hesitant to try
> it since
> > it is not documented at all (unless I've missed it). Does anyone
> have any
> > experience in this area?
> >
> > I also have another related question on DAGs and memory access.
> What if SIMD
> > mode is on and you try to access a DAG register? I know that for normal
> > registers, it works like this:
> > dm(test) = R0; //when PEYN=1, equivalent to dm(test)=R0;
> dm(test+1)=S0;
> >
> > But what happens for the second move if you specify a DAG register?
> > dm(test) = I0; //when PEYN=1, equivalent to dm(test)=I0;
> dm(test+1)=???
> > Perhaps it "broadcasts" I0 to both memory locations?
> > Again, if this is documented by ADI, please point out where it is
> discussed.
> >
> > Thanks!
> > -Jon
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
> For your second question, see page 5-3 of the instruction manual. The
> DAG registers don't have complements (see page 2-31), just like the
> MODE1 register (given in the example), so they operate the same in
> SISD and SIMD modes.
Thanks for pointing out the relevant sections in the documentation. I agree
with your interpretation that there shouldn't be an extra implicit operation
for MODE1 or DAGs. However, the simulator shows the opposite--broadcasting the
MODE1 or DAG value to adjacent memory locations. I have contacted ADI about
this.
> On the first question, I don't think it would work reliably. First,
> the I registers aren't listed as having neighbor registers on page
> 5.30 of the core manual. Second, the DAGS generally don't like being
> accessed twice in a cycle, and can cause incorrect execution (page
> 4-24 of the core manual, gives some examples, but none with an LW)
What manual are you referring to here? The page numbers you list don't line up
with my documentation. I have the 21161 Hardware Reference and the 21160
Instruction Set Reference.
Thanks again for your help! I'll post back if I hear anything from ADI.
> --- In adsp@adsp..., Jon Harris <jon_harris7@y...> wrote:
> > On the SHARC 21161, a very useful feature is the ability to use
> "long word"
> > memory access to move 2 "neighbor" registers to memory (and vice
> versa) in a
> > single operation. For example:
> > dm(test) = R0 (LW); //equivalent to dm(test)=R0; dm(test+1)=R1;
> >
> > The documentation clearly defines the neighbor register pairs for
> the normal
> > registers (R0-R15). However, it says nothing about neighbor
> registers for the
> > DAG registers (I0-I15, L0-L15, B0-B15, M0-M15). So, I am wondering
> if you can
> > use this same technique to move from DAG registers to memory in one
> operation,
> > for example:
> > dm(test) = I0 (LW); //equivalent to dm(test)=I0; dm(test+1)=I1; ???
> >
> > It seems to work in the simulator, but I am a little hesitant to try
> it since
> > it is not documented at all (unless I've missed it). Does anyone
> have any
> > experience in this area?
> >
> > I also have another related question on DAGs and memory access.
> What if SIMD
> > mode is on and you try to access a DAG register? I know that for normal
> > registers, it works like this:
> > dm(test) = R0; //when PEYN=1, equivalent to dm(test)=R0;
> dm(test+1)=S0;
> >
> > But what happens for the second move if you specify a DAG register?
> > dm(test) = I0; //when PEYN=1, equivalent to dm(test)=I0;
> dm(test+1)=???
> > Perhaps it "broadcasts" I0 to both memory locations?
> > Again, if this is documented by ADI, please point out where it is
> discussed.
> >
> > Thanks!
> > -Jon
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
Reply by ●August 17, 20052005-08-17
Djthurin do not rights! DAG registers are complementary too. Therefore
dm(test) = I0 (LW);
will be equivalents to
dm(test)=I0;
dm(test+1)=I1;
but if test is even adress, else
dm(test)=I1;
dm(test+1)=I0;
dm(test) = I0 (LW);
will be equivalents to
dm(test)=I0;
dm(test+1)=I1;
but if test is even adress, else
dm(test)=I1;
dm(test+1)=I0;
Reply by ●August 17, 20052005-08-17
You are correct. The 21161 hardware manual doesn't discuss this, and
even ADI
processor support told me initially it wouldn't work. But when I asked them to
look into it further, they confirmed that DAG registers are indeed
complementary. I have requested that they update their documentation to
mention this explicitly, so hopefully this will be cleared up in the future.
Good point about the even address as well--that is important to note!
--- chornobm@chor... wrote:
> Djthurin do not rights! DAG registers are complementary too. Therefore
>
> dm(test) = I0 (LW);
>
> will be equivalents to
>
> dm(test)=I0;
> dm(test+1)=I1;
>
> but if test is even adress, else
>
> dm(test)=I1;
> dm(test+1)=I0;
__________________________________________________
processor support told me initially it wouldn't work. But when I asked them to
look into it further, they confirmed that DAG registers are indeed
complementary. I have requested that they update their documentation to
mention this explicitly, so hopefully this will be cleared up in the future.
Good point about the even address as well--that is important to note!
--- chornobm@chor... wrote:
> Djthurin do not rights! DAG registers are complementary too. Therefore
>
> dm(test) = I0 (LW);
>
> will be equivalents to
>
> dm(test)=I0;
> dm(test+1)=I1;
>
> but if test is even adress, else
>
> dm(test)=I1;
> dm(test+1)=I0;
__________________________________________________
