Sign in

Search adsp

Subscribe to adsp

adsp by Keywords

Discussion Groups

Discussion Groups | Analog Devices DSPs | Re: use 16BIT with ADSP21065L

Technical discussions related to Analog Devices DSPs (including Blackfin, TigerSHARC, SHARC and ADSP-21xx DSPs).

Post a new Thread

use 16BIT with ADSP21065L - Jens Michaelsen - Jul 23 10:14:00 2004

Hello Members, having to train a 65L some more tricks I need to go for some fome more memory. (Things haven't changed ever...) There is one DMA output transfer table that I may place in 16Bit memory if possible. Things I thing of 1) Place in 16bit Memory will only save half the size 2) Place in this one little hole, where only code was supposed to life. End of Block0. 3) Move around code blocks, so that one lower 16Bit Segment of Block0 gets freed. I currently use Block0 like this: 0x8000 - 0x8fff WIDTH(48) for programm code 0x9800 - 0x9fff WIDTH(48) for fft table data If there is a proper way to split the code: 0x8000 - 0x87ff WIDTH(48) for programm code I 0x9000 - 0x87ff WIDTH(48) for programm code II 0x9000 - 0x97ff WIDTH(48) for fft table data a unused 16bit hole shows up 0x11000 - 0x11ffe ????(??) LSB usable only Will this 16bit segment be uasble for DMA output?? Did someone allready try something like this?? Is there a AppNote I did not find?? Any suggestions?? ThanX for your time (found no shorter desription) Jens Michaelsen

(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )

Re: use 16BIT with ADSP21065L - Mike Rosing - Jul 23 16:48:00 2004

On Fri, 23 Jul 2004, Jens Michaelsen wrote: > Hello Members, > > having to train a 65L some more tricks I > need to go for some fome more memory. > (Things haven't changed ever...) > There is one DMA output transfer table that > I may place in 16Bit memory if possible. > > Things I thing of > 1) Place in 16bit Memory will only save half the size > 2) Place in this one little hole, where only code > was supposed to life. End of Block0. > 3) Move around code blocks, so that one > lower 16Bit Segment of Block0 gets freed. > > I currently use Block0 like this: > 0x8000 - 0x8fff WIDTH(48) for programm code > 0x9800 - 0x9fff WIDTH(48) for fft table data > > If there is a proper way to split the code: > 0x8000 - 0x87ff WIDTH(48) for programm code I > 0x9000 - 0x87ff WIDTH(48) for programm code II > 0x9000 - 0x97ff WIDTH(48) for fft table data > a unused 16bit hole shows up > 0x11000 - 0x11ffe ????(??) LSB usable only > > Will this 16bit segment be uasble for DMA output?? > Did someone allready try something like this?? > Is there a AppNote I did not find?? > Any suggestions?? I'm a bit confused by your addresses. If you look on page 5-16 of the 21065 user's manual it shows that block 0 has 9 banks and block 1 has 8 banks. You need 3 banks for each 48 bit wide set and 2 banks for the 32 bit wide stuff. Each set gives you 2k or 0x800. With 3 banks you have 0x8000-0x87ff, 0x8000-0x8fff, 0x9000-0x97ff in block 0 for 48 bit code or data. From the manual (page 18) it says block 1 starts at 0xC000. You can use either 32 bit or 48 bit data there, if you use 48 bit data then you only have 0xC000-0xCfff. If you use 32 bit data then you have 0xC000-0xDfff. There is no 16 bit wide hole if you use 48 bit data. There can be if your last bank is 32 bit data instead of 48 bit data. Those addresses would have to be 0x137ff-0x13fff. The 32 bit data would also be in the 0x9000-0x97ff adress range. You'd get it off the DM bus instead of the PM bus It's not too confusing is it :-) Just look at the pictures and write down the numbers for each bank, it will make sense after a little while (and a few beers I bet!) Patience, persistence, truth, Dr. mike

(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )

Re: use 16BIT with ADSP21065L - Jens Michaelsen - Jul 23 17:01:00 2004

Hello Mike, my information is partly from the user manual rev2.0 page 5-32. There it shows that if I use 2x3 segments for programm and 1x2 for data I loose one segment. The one is "L" at pm(0x9000). For FFT I need tables in PM, so I look for a way not to loose this segment. I'm not shure if one of us mixed some information up with the 21161 where there are even more ways to go for memory. ThanX Jens Michaelsen Mike Rosing schrieb: >On Fri, 23 Jul 2004, Jens Michaelsen wrote: > >>Hello Members, >> >>having to train a 65L some more tricks I >>need to go for some fome more memory. >>(Things haven't changed ever...) >>There is one DMA output transfer table that >>I may place in 16Bit memory if possible. >> >>Things I thing of >>1) Place in 16bit Memory will only save half the size >>2) Place in this one little hole, where only code >>was supposed to life. End of Block0. >>3) Move around code blocks, so that one >>lower 16Bit Segment of Block0 gets freed. >> >>I currently use Block0 like this: >>0x8000 - 0x8fff WIDTH(48) for programm code >>0x9800 - 0x9fff WIDTH(48) for fft table data >> >>If there is a proper way to split the code: >>0x8000 - 0x87ff WIDTH(48) for programm code I ***OK >>0x9000 - 0x87ff WIDTH(48) for programm code II !!!!!!WRONG!!!!!!! >> >> That upper line was a copy-paste bug. it should go from 0x8800 to 0x8fff >>0x9000 - 0x97ff WIDTH(48) for fft table data *****OK >>a unused 16bit hole shows up >>0x11000 - 0x11ffe ????(??) LSB usable only >> >> >> >I'm a bit confused by your addresses. If you look on page 5-16 of the >21065 user's manual it shows that block 0 has 9 banks and block 1 has >8 banks. You need 3 banks for each 48 bit wide set and 2 banks for >the 32 bit wide stuff. Each set gives you 2k or 0x800. With 3 banks >you have 0x8000-0x87ff, 0x8000-0x8fff, 0x9000-0x97ff in block 0 for >48 bit code or data. From the manual (page 18) it says block 1 starts >at 0xC000. You can use either 32 bit or 48 bit data there, if you >use 48 bit data then you only have 0xC000-0xCfff. If you use 32 bit >data then you have 0xC000-0xDfff. > >There is no 16 bit wide hole if you use 48 bit data. There can be if >your last bank is 32 bit data instead of 48 bit data. Those addresses >would have to be 0x137ff-0x13fff. The 32 bit data would also be in >the 0x9000-0x97ff adress range. You'd get it off the DM bus instead of >the PM bus > >It's not too confusing is it :-) Just look at the pictures and write >down the numbers for each bank, it will make sense after a little while >(and a few beers I bet!) > >Patience, persistence, truth, >Dr. mike

(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )

Re: use 16BIT with ADSP21065L - Mike Rosing - Jul 23 18:19:00 2004

On Fri, 23 Jul 2004, Jens Michaelsen wrote: > Hello Mike, > > my information is partly from the user manual rev2.0 page 5-32. > There it shows that if I use 2x3 segments for programm and > 1x2 for data I loose one segment. The one is "L" at pm(0x9000). > For FFT I need tables in PM, so I look for a way not to loose > this segment. > > I'm not shure if one of us mixed some information up with the > 21161 where there are even more ways to go for memory. Howdy Jens, That picture is what I tried to describe. The next page (5-33) shows what you are describing exactly, 2 sets of 3 column instruction followed by one set of 2 column instruction which gives you a 16 bit wide hole (Picture B). You don't lose anything, you just have an extra column you can store 16 bit wide data in. the important thing is to use the correct address - in this case it's 0x13800-0x13fff for that last column. You can store the data as 40 bit wide and use all 3 columns too. You get more accuracy and no loss of ram. I think you are ok either way - if you need extra space and can live with 16 bit wide storage that's a bonus. Patience, persistence, truth, Dr. mike

(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )

Re: use 16BIT with ADSP21065L - Jens Michaelsen - Jul 23 20:37:00 2004

Hi Mike, for the 9th segment I guess the calculation would be: 0x00010000 for 16bit access, PLUS 0x00004000 for ((8*0x800)<<1) Range for segment 9 would look something like this: 0x00014000 up to 0x000147ff Any clue if this is usable?? Official saying is NoooP.! If, how to tell the LDF file about it??? Thanx Jens Mike Rosing schrieb: >On Fri, 23 Jul 2004, Jens Michaelsen wrote: > >>Hello Mike, >> >>my information is partly from the user manual rev2.0 page 5-32. >>There it shows that if I use 2x3 segments for programm and >>1x2 for data I loose one segment. The one is "L" at pm(0x9000). >>For FFT I need tables in PM, so I look for a way not to loose >>this segment. >> >>I'm not shure if one of us mixed some information up with the >>21161 where there are even more ways to go for memory. >> >> > >Howdy Jens, > >That picture is what I tried to describe. The next page >(5-33) shows what you are describing exactly, 2 sets of 3 >column instruction followed by one set of 2 column instruction >which gives you a 16 bit wide hole (Picture B). You don't lose >anything, you just have an extra column you can store 16 bit wide >data in. the important thing is to use the correct address - in >this case it's 0x13800-0x13fff for that last column. > >You can store the data as 40 bit wide and use all 3 columns too. >You get more accuracy and no loss of ram. I think you are ok either >way - if you need extra space and can live with 16 bit wide storage >that's a bonus. > >Patience, persistence, truth, >Dr. mike

(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )

Re: use 16BIT with ADSP21065L - Mike Rosing - Jul 23 22:15:00 2004

On Fri, 23 Jul 2004, Jens Michaelsen wrote: > Hi Mike, > > for the 9th segment I guess the calculation would be: > 0x00010000 for 16bit access, PLUS > 0x00004000 for ((8*0x800)<<1) > > Range for segment 9 would look something like this: > 0x00014000 up to 0x000147ff > > Any clue if this is usable?? > Official saying is NoooP.! > > If, how to tell the LDF file about it??? The manuals says 0x13fff is the max address, but I think you are correct. Not sure how to access it via the LDF, I would think you specify it as width=16, address=0x14000, length=0x800. Read the manual again carefully, but it ought to work! One way to check is to force reading and writing: i8 = 0x14000; r1 = 0xa5a5; pm(i8,0) = r1; r0 = pm(0,i8); and see what r0 reads back. try a whole bunch of addresses. Even if ldf can't load it, you can still use it (but I'd think ldf should be able to load it). If the manual is correct and 0x13fff is the last address, then the last bank is not accessable for 16 bit data. That would be a bummer. I don't know why they'd do that, but it could be because of block 1 similar structure and they didn't want to copy non readable memory over. Patience, persistence, truth, Dr. mike

(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )