|
OK, I'll throw some light:) We have a board with shared distributed memory. There are (among others) two clusters of two 21065L, each cluster has 4Mx32bit SDRAM mapped to each processor's external memory bank 1. SDRAM is accessed using Memory Select Line 1. Both processors have the exact same SDRAM initialization routines setting SRDIV and IOCTL registers. Now we have a problem on some boards, while on others this problem does not occur (we also had mixed Rev.0.2 and 0.3 silicon, but cannot say if the boards that worked had Rev.0.3 because they have been released already, but the boards that don't work are all Rev.0.2). The problem is that one DSP is not accessible via the system bus by the host if the other accesses SDRAM (if it doesn't, everything is fine). Does this spark something? Regards, Andor Bariska > -----Ursprgliche Nachricht----- > Von: Jkumar [mailto:] > Gesendet am: Donnerstag, 27. Juli 2000 16:07 > An: Andor Bariska > Cc: 'ADSP eGroup' > Betreff: Re: [adsp] 21065L and SDRAM > > Hi, > there was a problem, when we run Ext DMA to get things from SDRAM. > that bug had fixed, now my friends Dolby AC-3 application is > working on > 21065L. > > I think BAriska can thorugh some light when exatly the problem occurs. > > regards > jk > > Singaram.Jayakumar > phone: 080-5283788 > On Thu, 27 Jul 2000, Andor Bariska wrote: > > > Hi group, > > > > does anybody have experience using a two processor cluster of 21065L > > Rev. 0.2 with shared SDRAM? > > > > I have a feeling that because of its host of SDRAM bugs in > the Anomaly > > List, a shared SDRAM setup using Rev. 0.2 doesn't work. > > > > Can anybody confirm or contradict? > > > > Regards, > > Andor Bariska > > > > WEISS ENGINEERING LTD. - Professional Digital Audio Products > > Florastrasse 42 8610 Uster Switzerland > > phone: +41 1 940 20 06, fax: +41 1 940 22 14 > > mailto: web: http://www.weiss.ch > > You *can* afford the best > > > > > > > -------------------------- > ------<e|- > > Download iPlanet Web Server, FastTrack Edition 4.1 for FREE, > > and start publishing dynamic web pages today! > > http://click.egroups.com/1/7628/7/_/8508/_/964692023/ > > > -------------------------- > ------|e>- > > > > To Join: Send an email to > > > > To Post: Send an email to > > > > To Leave: Send an email to > > > > Archives: http://www.egroups.com/group/adsp > > > > Other Groups: http://www.dsprelated.com > > > > > > > |
|
|
AW: 21065L and SDRAM
Started by ●July 27, 2000
Reply by ●July 28, 20002000-07-28
|
We just got a board with Rev.0.3 processors, and it works. So I agree with Kenneth's conclusion. Regards, Andor Bariska WEISS ENGINEERING LTD. - Professional Digital Audio Products Florastrasse 42 8610 Uster Switzerland phone: +41 1 940 20 06, fax: +41 1 940 22 14 mailto: web: http://www.weiss.ch You *can* afford the best > -----Ursprgliche Nachricht----- > Von: Kenneth Porter [mailto:] > Gesendet am: Donnerstag, 27. Juli 2000 19:55 > An: ADSP eGroup > Betreff: Re: [adsp] 21065L and SDRAM > > On Thu, 27 Jul 2000 11:24:49 +0200, Andor Bariska wrote: > > > I have a feeling that because of its host of SDRAM bugs in > the Anomaly > > List, a shared SDRAM setup using Rev. 0.2 doesn't work. > > It's not a complete failure, but I wouldn't use 0.2 in an MP design. I > had some mysterious problems when I tried to run code from SDRAM with > 0.2, that were very intermittent and impossible to characterize, so I > couldn't come up with a workaround. We finally banned 0.2 from our > product and the problems disappeared. > > Do note that 0.3 still has a bug involving BMAX, so if you > have latency > issues be sure to look at the errata sheet for potential workarounds. > > Kenneth Porter > Kensington Laboratories, Inc. > mailto: > http://www.kensingtonlabs.com |
Reply by ●July 28, 20002000-07-28
|
Hello, I can only share the following experience regarding 21065 chip revs: On rev 0.1, code executed from external SDRAM worked only reliably when setting the WAIT register to a value of 4 or higher (as suggested in issue 4 of the anomalies list). On rev 0.3 this workaround doesn't seem to be necessary any more. I also think it was highly dependend on the exact location of the code (SDRAM page boundaries or so), because it didn't occur on all external modules. But if you inserted a new line of code all could change. Setting the WAITs so high disables all burst access to the SDRAM and inserts a "hold cycle" in every read/write, which slows down the machine quite a bit. Though you can change the WAITs during runtime (e.g. before a block write). I also have to admit that the hardware was not custom-built, the rev 0.1 board was the 21065L EZLAB (SDRAM mapped to bank0) and the rev 0.3 board is from Bittware (Spinner). Regards, Michael Andor Bariska wrote: > We just got a board with Rev.0.3 processors, and it works. So I agree > with Kenneth's conclusion. > > Regards, > Andor Bariska > > WEISS ENGINEERING LTD. - Professional Digital Audio Products > Florastrasse 42 8610 Uster Switzerland > phone: +41 1 940 20 06, fax: +41 1 940 22 14 > mailto: web: http://www.weiss.ch > You *can* afford the best > > > -----Ursprgliche Nachricht----- > > Von: Kenneth Porter [mailto:] > > Gesendet am: Donnerstag, 27. Juli 2000 19:55 > > An: ADSP eGroup > > Betreff: Re: [adsp] 21065L and SDRAM > > > > On Thu, 27 Jul 2000 11:24:49 +0200, Andor Bariska wrote: > > > > > I have a feeling that because of its host of SDRAM bugs in > > the Anomaly > > > List, a shared SDRAM setup using Rev. 0.2 doesn't work. > > > > It's not a complete failure, but I wouldn't use 0.2 in an MP design. I > > had some mysterious problems when I tried to run code from SDRAM with > > 0.2, that were very intermittent and impossible to characterize, so I > > couldn't come up with a workaround. We finally banned 0.2 from our > > product and the problems disappeared. > > > > Do note that 0.3 still has a bug involving BMAX, so if you > > have latency > > issues be sure to look at the errata sheet for potential workarounds. > > > > Kenneth Porter > > Kensington Laboratories, Inc. > > mailto: > > http://www.kensingtonlabs.com -- /* michael.haertl DSP Programmer */ |
