Gearslutz.com - View Single Post

dale116dot7 · 13th March 2010

I've been working on a revised hardware platform, I had too many blue jumper wires on the previous version, and after too much handling, it's starting to get a bit flakey. Also, a double-sided PC board isn't the best for a 100 MHz data bus - so a 4-layer it is. Along with fixing things that were obvious errors on the previous PC board, I've changed the DSP from a 100 MHz DSP56366 to a 200 MHz dual-core DSP56720. I'm thinking about using SDRAM, however, I'm a bit confused as to the best way to arrange data and move it to/from the SDRAM. It seems to me that SDRAM timing is pretty slow for hopping around in memory. For long delays, it's pretty obvious what to do (put the head and tail in internal SRAM and burst the middle into and out of the SDRAM) but for a high density multitap algorithm, the answer isn't quite so simple. Is this a case where certain algorithms just don't run as efficiently on different hardware? Is it best to try to keep large tap sizes in internal RAM if I can? Would I be better off with an untapped algorithm like an FDN? A single random SDRAM access takes about the same amount of time as almost 20 instructions (per core) - if in internal SRAM, I could do four allpasses (two per core) in the time it takes to just fetch a single sample from the SDRAM.

13th March 2010	#499
dale116dot7 Lives for gear Joined: Dec 2003 Location: Calgary, Alberta Posts: 816 Thread Starter	I've been working on a revised hardware platform, I had too many blue jumper wires on the previous version, and after too much handling, it's starting to get a bit flakey. Also, a double-sided PC board isn't the best for a 100 MHz data bus - so a 4-layer it is. Along with fixing things that were obvious errors on the previous PC board, I've changed the DSP from a 100 MHz DSP56366 to a 200 MHz dual-core DSP56720. I'm thinking about using SDRAM, however, I'm a bit confused as to the best way to arrange data and move it to/from the SDRAM. It seems to me that SDRAM timing is pretty slow for hopping around in memory. For long delays, it's pretty obvious what to do (put the head and tail in internal SRAM and burst the middle into and out of the SDRAM) but for a high density multitap algorithm, the answer isn't quite so simple. Is this a case where certain algorithms just don't run as efficiently on different hardware? Is it best to try to keep large tap sizes in internal RAM if I can? Would I be better off with an untapped algorithm like an FDN? A single random SDRAM access takes about the same amount of time as almost 20 instructions (per core) - if in internal SRAM, I could do four allpasses (two per core) in the time it takes to just fetch a single sample from the SDRAM.