Forums

dsp56807 and external XRAM wait-state problem

Started by Stephen Foster August 7, 2003
We have developed a new board using a DSP56807 to run a Kalman filter
for a real-time application. The Kalman filter uses relatively large
matrices, hence RAM requirements exceed the amount available on-chip.
External XRAM has been used as a result (64Kx16 10ns static RAM).
This is where it becomes interesting... I started running into random
glitches in my code when the application was ported to this new board,
and it was eventually traced to the wait-state setting. At a setting
of 4, all was fine. At a setting of 0 w.s, next level (fastest) ,
random glitches / crashes would start. Running the 807EVM from onchip
flash program memory produced glitches too, but with a much reduced
frequency / severity (e.g. I had to wait many minutes before noticing
an anomaly in the processed output vs. seconds for our board). One
such glitch was repeatable enough for me to trace back to a bad memory
read. The EVM uses 10ns RAM.

Motorola DSP help advised that 7ns RAM is required to run successfully
at 0 w.s. The problem is we can't find a good source of supply of 7ns
64Kx16 asynchronous SRAM (we don't want to buy a 1000-unit lot at this
point, or wait 2 months, for example). Has anyone else run into this
one? Does anybody use 7ns SRAM who can share their supplier!?

Steve



We ran into the same thing on an external SRAM on our board. Our H/W guys had thought that we'd be fine with ~10ns since the processor is only running at 80MHz. Unfortunately, it failed intermittently.
 
At first, we suspected that one or more of our ADDR/CS/WR lines was being delayed going through an FPGA, but this turned out not to be the case. Our initial check of the H/W specs after noticing the sporadic failures implied that it should work, but I think that it was either a preliminary spec, or we misread it. Eventually we realized that we were in fact violating the 807 specs. 
 
Fortunately for us, we were able to live with 4 wait states, and swap stuff in and out of internal memory. In our case, we just needed buffer space for storing a few large chunks of data. Copying them is slow, but this can be done in the background and in less than a ms.
 
Living with 1WS would not be too bad, but between the granularity of 4WS increments and the difficult SRAM speed reqs makes this a serious deficiency. It would be very nice if in a future version of the processors more WS choices will be available. Same with loosening of the SRAM speed specs. It would also be nice if Motorola would more clearly documented the SRAM speed requirements.
 
Howard
-----Original Message-----
From: Stephen Foster [mailto:f...@aventech.com]
Sent: Thursday, August 07, 2003 4:53 PM
To: m...@yahoogroups.com
Subject: [motoroladsp] dsp56807 and external XRAM wait-state problem

We have developed a new board using a DSP56807 to run a Kalman filter
for a real-time application.  The Kalman filter uses relatively large
matrices, hence RAM requirements exceed the amount available on-chip.
External XRAM has been used as a result (64Kx16 10ns static RAM).
This is where it becomes interesting... I started running into random
glitches in my code when the application was ported to this new board,
and it was eventually traced to the wait-state setting.  At a setting
of 4, all was fine.  At a setting of 0 w.s, next level (fastest) ,
random glitches / crashes would start.  Running the 807EVM from onchip
flash program memory produced glitches too, but with a much reduced
frequency / severity (e.g. I had to wait many minutes before noticing
an anomaly in the processed output vs. seconds for our board).  One
such glitch was repeatable enough for me to trace back to a bad memory
read.  The EVM uses 10ns RAM.

Motorola DSP help advised that 7ns RAM is required to run successfully
at 0 w.s.  The problem is we can't find a good source of supply of 7ns
64Kx16 asynchronous SRAM (we don't want to buy a 1000-unit lot at this
point, or wait 2 months, for example).  Has anyone else run into this
one?  Does anybody use 7ns SRAM who can share their supplier!?

Steve


_____________________________________
Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer.  You need to do a "reply all" if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:  m...@yahoogroups.com

To Post:  m...@yahoogroups.com

To Leave: m...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3


">Yahoo! Terms of Service.


We've never used it because we don't need to have 0 wait states, but have a look
at the following:
http://www.gsitechnology.com/72116A.pdf
http://www.gsitechnology.com

It's twice the size (128Kx16) that you're looking for, but it does have the 7ns
access time that you need.

GSI Technology does have 64Kx16 SRAM devices, but they're listed as "not
recommended for new designs".

Hope this helps,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com
-----Original Message-----
From: Stephen Foster [mailto:]
Sent: Thursday, August 07, 2003 1:53 PM
To:
Subject: [motoroladsp] dsp56807 and external XRAM wait-state problem We have developed a new board using a DSP56807 to run a Kalman filter
for a real-time application. The Kalman filter uses relatively large
matrices, hence RAM requirements exceed the amount available on-chip.
External XRAM has been used as a result (64Kx16 10ns static RAM).
This is where it becomes interesting... I started running into random
glitches in my code when the application was ported to this new board,
and it was eventually traced to the wait-state setting. At a setting
of 4, all was fine. At a setting of 0 w.s, next level (fastest) ,
random glitches / crashes would start. Running the 807EVM from onchip
flash program memory produced glitches too, but with a much reduced
frequency / severity (e.g. I had to wait many minutes before noticing
an anomaly in the processed output vs. seconds for our board). One
such glitch was repeatable enough for me to trace back to a bad memory
read. The EVM uses 10ns RAM.

Motorola DSP help advised that 7ns RAM is required to run successfully
at 0 w.s. The problem is we can't find a good source of supply of 7ns
64Kx16 asynchronous SRAM (we don't want to buy a 1000-unit lot at this
point, or wait 2 months, for example). Has anyone else run into this
one? Does anybody use 7ns SRAM who can share their supplier!?

Steve

_____________________________________
Note: If you do a simple "reply" with your email client, only the author of this
message will receive your answer. You need to do a "reply all" if you want your
answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/