Handling of 40bit values in Sharc

Hi Sharc fellows,

I'm stuck with a problem which is trivial for those who've done it.
However, I don't find documentation which helps me.

Given, I want to multiply two stored variables with two constants 
from a table (all are floating point 40bit) ,
then sum the results and store the new result for further use.

Retrieved from the working 32bit version, I'd guess something like,
but neither the initialization nor the calculation or storage works 
like expected. What am I missing?

Bernhard


.precision=40;

.section/pm seg_pmda;
.var constant[2]=1.23,2.34;

.section/dm seg_dmda;
.var storage[3] = 1.11,2.22,0;

.section/pm seg_pmco;
routine: 
    push sts;
    bit clr mode1 RND32;

    i8 = constant;
    i0 = storage;
                f0 = dm(i0,1);     f8 = pm(i8,1);
    f1 = f8 * f0;        f0 = dm(i0,1);     f8 = pm(i8,1);
    f2 = f8 * f0;

    f3 = f1 + f2;

    dm(i0,0) = f3;
    pop sts;
routine.end:
    
        

Bernhard Holzmayer wrote:
> Hi Sharc fellows,
> 
> I'm stuck with a problem which is trivial for those who've done it.
> However, I don't find documentation which helps me.
> 
> Given, I want to multiply two stored variables with two constants 
> from a table (all are floating point 40bit) ,
> then sum the results and store the new result for further use.
> 
> Retrieved from the working 32bit version, I'd guess something like,
> but neither the initialization nor the calculation or storage works 
> like expected. What am I missing?

Have you declared the segments as 40bit data memory in the LDF? And
are you using 40bit data access on PM and DM (by setting the IMDWx bit
in the SYSCON)?

Last, did you clear the RND32 bit in the MODE1 register?

Regards,
Andor

Andor wrote:


Sorry, I'm out of work for the week-end now.
Nevertheless, thanks for your answer. 

> Have you declared the segments as 40bit data memory in the LDF?

I'm not sure if I did it right. I'll show you my entries on Monday 
(no access in the moment!)

> And are you using 40bit data access on PM and DM (by setting the
> IMDWx bit in the SYSCON)?
No, I wasn't aware of this register. maybe it's the key. I'll check 
this!
> 
> Last, did you clear the RND32 bit in the MODE1 register?
Yes, as you see in my example.

Bernhard

Hi Andor,

meanwhile I started from scratch, trying to set 40bit processing up.
I succeeded to read data from 40bit internal ram, get it into 
registers and out again into 40bit IRAM.
Still, working with external SDRAM fails.

Below is a short portion of sample code which should contain 
everything necessary. Would you please have a look on it,
if anything obvious is wrong??

My LDF file contains appropriate segments like this:
In the MEMORY section, I marked it as 48bit 
in the SECTIONS section, I marked it as 40bit and linked correctly.
The Expressions-window of the VisualDSP-IDDE shows the correct 
initial values with 40bit precision, thus it seems as if the mapping 
were ok.

//------------------------------------------------------
#include    "def21161.h"

.precision=40;

.section/pm seg_pm40;
.var _ivektor  = 0.1;
.var _isummand = 0.1;

.section/pm seg_xpm40;
.var _xvektor  = 0.1;
.var _xsummand = 0.1;

.section/pm seg_pmco;
        
.global _main;

_main: 
        r0 = IPACK0|IMDW0X|IMDW1X; r1 = dm(SYSCON);
        r0 = r1 or r0;
        dm(SYSCON) = r0;
        
    bit clr MODE1 RND32;
        i8 = _xvektor;  i9=_xsummand;   m8=0;
        
tag:
        lcntr=5, do next1 until lce;
                px = pm(i8,m8);
                r0 = px;
                px = pm(i9,m8);
                r2 = px;
                f0 = f0 + f2;
                px = r0;
next1:  pm(i8,m8) = px;
        i8 = _ivektor; i9 = _isummand;
        jump  tag;
        jump _main;
_main.end:

//------------------------------------------------------

The program does essential initialization of SYSCON, MODE1 
registers, then tries to increment an external RAM cell (_xvektor).
This fails.
Then it does the same with a cell in internal RAM, and succeeds.

Bernhard

-- 
before sending to the above email-address:
replace deadspam by foerstergroup and de instead of com

Bernhard Holzmayer wrote:
> Hi Andor,
> 
> meanwhile I started from scratch, trying to set 40bit processing up.
> I succeeded to read data from 40bit internal ram, get it into 
> registers and out again into 40bit IRAM.
> Still, working with external SDRAM fails.

Bernhard,

before we proceed: are you working on the 21161N EZ-Kit?

Regards,
Andor

Andor wrote:

> Bernhard Holzmayer wrote:
>> Hi Andor,
>> 
>> meanwhile I started from scratch, trying to set 40bit processing
>> up. I succeeded to read data from 40bit internal ram, get it into
>> registers and out again into 40bit IRAM.
>> Still, working with external SDRAM fails.
> 
> Bernhard,
> 
> before we proceed: are you working on the 21161N EZ-Kit?
> 

Yes.


> Regards,
> Andor

Bernhard wrote:
> Hi Andor,
> 
> meanwhile I started from scratch, trying to set 40bit processing up.
> I succeeded to read data from 40bit internal ram, get it into 
> registers and out again into 40bit IRAM.
> Still, working with external SDRAM fails.
> 
> Below is a short portion of sample code which should contain 
> everything necessary. Would you please have a look on it,
> if anything obvious is wrong??

I don't see anything wrong at first glance. Make sure you have set up
the SDRAM for 48bit access and not for 32bit access (check out the
21161N and the EZ-Kit manuals for the relevant registers).


Regards,
Andor

Andor wrote:

> Bernhard wrote:
>> Hi Andor,
>> 
>> meanwhile I started from scratch, trying to set 40bit processing
>> up. I succeeded to read data from 40bit internal ram, get it into
>> registers and out again into 40bit IRAM.
>> Still, working with external SDRAM fails.
>> 
>> Below is a short portion of sample code which should contain
>> everything necessary. Would you please have a look on it,
>> if anything obvious is wrong??
> 
> I don't see anything wrong at first glance. Make sure you have set
> up the SDRAM for 48bit access and not for 32bit access (check out
> the 21161N and the EZ-Kit manuals for the relevant registers).
> 
> 
> Regards,
> Andor

Thanks Andor, for checking.
Yes, that's it, a wrong initialization of the SDRAM while loading 
the coefficients.
I didn't see it at first glance, because the emulator hides the 
effect:
after resetting and before reloading code and initialization values, 
it switches back to 32/48bit mode, thus initialized values are in  
wrong locations. However, when loading from Flash, it works bc. I'd 
inserted the SYSCON modification into the prom loader.

Removing the flag (Target options...) which resets the processor,
made the emulator behave as it should. 

I should have known, bc. I dealt with the issue one year ago, ...

Bernhard

I should have added,
that my confusion started when I watched wrong values while checking 
an algorithm's implementation.

I guessed that these wrong values must have their origin in the area 
of 40bit processing. Then I got trapped in this initialization 
stuff.

However, although these issues are solved, I still end up with 
errors during the algorithm.

While single stepping through my code, yesterday, I could see (in 
the emulator windows) that different registers change their values 
without obvious reason.
Concerned registers were i0, i8, m0 (and maybe others which I wasn't 
aware of).

The registers weren't actively used, I mean, they didn't participate 
in the current or previous/next commands to process.
So, it's certainly not an issue of contents of Lx or Bx registers.

This might be an explanation why my algorithm did fail:
when I fetched data from memory with a wrong index or modifier 
register, I'd have certainly ended up with messy data.

My question:
Is there anybody out there who suffered/suffers from the same 
problems with Sharc DSPs / EZ-Lite boards ?

Are there any experiences and/or maybe solutions?

I wonder if it's a hardware issue, maybe my USB cable is too long,
or the ground potentials of the different connections raise 
instabilities.

Any ideas welcome.

Bernhard  



 

Bernhard Holzmayer wrote:
...
> While single stepping through my code, yesterday, I could see (in 
> the emulator windows) that different registers change their values 
> without obvious reason.
> Concerned registers were i0, i8, m0 (and maybe others which I wasn't 
> aware of).

I have an 21161N EZ-Kit and never had any such problems. Single
stepping a real-time system is not trivial. Perhaps some interrupt
routine modified those registers?

Regards,
Andor