How to add some SDRAM to a FPGA board ?

In article <4977c2e8$0$28669$7a628cd7@news.club-internet.fr>, 
whygee@yg.yg says...
> CBFalconer wrote:
..
> > Also bear in mind that you have to provide the appropriate signals
> > and addresses to refresh the memory at some interval.
> that's what bothers me most.
> I'll check if there is an auto-refresh mode that cuts my efforts.
> 
> Also :
> If I scan the buffers sequentially at a known rate
> (this is for audio samples) then I could arrange the interleaving
> in such a way that no explicit refresh is needed.

Only if the buffering is continuous for every mS of being powered up.
 
> I suspect that this method is used in video adapters,
> since at least one old personal computer (a french 6809-based
> thing popular around 1984) uses this idea.

Nearly every video controller ususe either the norml scan to
refresh or creates refresh cycles in blanking time. Ensuring 
RAS addresses are only used for low order addresses is a good
way to do this until you have > 10MiB of data storage. At that 
point the scan does not guarantee to go through all RAS address
lines, just some of them.

> So I will try to combine both refresh and normal scan...

A complex refresh controller does that, a simple one does not.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

On Jan 21, 5:57 pm, whygee <why...@yg.yg> wrote:
> hi,
>
> linnix wrote:
> > On Jan 21, 4:04 pm, whygee <why...@yg.yg> wrote:
> >> linnix wrote:
> >>> There are 10 to 20ns sram in TSOP, and faster if you pay more.
> >> I know these, but in the end it's too expensive... even for a proto.
> > I read a little bit of your web pages.  You are using it for code
> > storage, right?  Why can't you use flash?
>
> The SDRAM thing just popped up on the surface of my brain since
> I realised that some DSP/sound applications (that I resurrected)
> need a lot of volatile storage. Like maybe one minute of sound
> samples or things like that.

What kind of filter requires all the samples to be available in
memory?  Most DSP filters need only a sliding window of thousand
samples, if at all.  For such DSP filters without hardware
multipliers, your 100MHz uC would not even match a 50MHz ARM.

On Jan 21, 6:34=A0pm, whygee <why...@yg.yg> wrote:
> Also :
> If I scan the buffers sequentially at a known rate
> (this is for audio samples) then I could arrange the interleaving
> in such a way that no explicit refresh is needed.
>
> I suspect that this method is used in video adapters,
> since at least one old personal computer (a french 6809-based
> thing popular around 1984) uses this idea.
> So I will try to combine both refresh and normal scan...


The Apple II (and several of its descendents) did that as well.  The
good old days - when you could have RAM that was twice as fast as your
processor!  Apple did processor access on half the cycles, video (and
implicit refresh) on the other half, and ended up running the CPU at a
slightly odd frequency; so the video ran at the right rate.
Approximately 1.023MHz, IIRC, a nice "even" divide by 14 off the
14.316558Mhz crystal that was also used to drive the video.

hi,

linnix wrote:
> On Jan 21, 5:57 pm, whygee <why...@yg.yg> wrote:
>> hi,
<snip>
>> The SDRAM thing just popped up on the surface of my brain since
>> I realised that some DSP/sound applications (that I resurrected)
>> need a lot of volatile storage. Like maybe one minute of sound
>> samples or things like that.
> 
> What kind of filter requires all the samples to be available in
> memory?  Most DSP filters need only a sliding window of thousand
> samples, if at all.
AFAIR I did not mention any filter. DSP is not only about filters.
It's about ... well, processing signals, digitally. This goes
well beyond the Laplace and Fourier transforms.
And some applications need to remember samples from 30s before,
not just the 1 or 2s of a digital reverberation chamber.

On top of that, I may end up teaming with musicians who are
less technician than me, hence who have much more weird desires...
since what matters is the final sounds, not how it's done.
One of them uses 16 audio channels on stage, so this would
leave only 2MB per channel if I had 32MB. That's not much
room for long-term delays with high-quality samples.

Maybe I should have avoided the term DSP, even if I thought
it was generic enough.

> For such DSP filters without hardware
> multipliers, your 100MHz uC would not even match a 50MHz ARM.
first, I am implementing a hardware multiplier in my uC.
Ok it's only 8x8 unsigned but it will help is a few situations.
But for "DSP work", I do my best to use adapted structures.
I even have many unused DSP chips in stock (I was an ADi fan).
And the "uC" has never been meant to be a workhorse,
but rather a "controller" to a dedicated processing unit.

Furthermore, I don't understand why a second person
raises the issue of "my 100MHz UC" (I presume it is a
reference to YASEP). This was completely independent from
the original question, and it might open a smelly can of worms...
I'd rather work on it than speak about it.

Regards,
yg

-- 
http://ygdes.com / http://yasep.org

On Jan 22, 5:21 pm, whygee <why...@yg.yg> wrote:
> hi,
>
> linnix wrote:
> > On Jan 21, 5:57 pm, whygee <why...@yg.yg> wrote:
> >> hi,
> <snip>
> >> The SDRAM thing just popped up on the surface of my brain since
> >> I realised that some DSP/sound applications (that I resurrected)
> >> need a lot of volatile storage. Like maybe one minute of sound
> >> samples or things like that.
>
> > What kind of filter requires all the samples to be available in
> > memory?  Most DSP filters need only a sliding window of thousand
> > samples, if at all.
>
> AFAIR I did not mention any filter. DSP is not only about filters.
> It's about ... well, processing signals, digitally. This goes
> well beyond the Laplace and Fourier transforms.
> And some applications need to remember samples from 30s before,

May be 60s, or 180s,...  How do you draw the line?  Why can't you
store them in flash memory, SD or CF.  Are they really so time
critical?

> not just the 1 or 2s of a digital reverberation chamber.
>
> On top of that, I may end up teaming with musicians who are
> less technician than me, hence who have much more weird desires...
> since what matters is the final sounds, not how it's done.
> One of them uses 16 audio channels on stage, so this would
> leave only 2MB per channel if I had 32MB. That's not much
> room for long-term delays with high-quality samples.

You can move tens of MB per second with CF.

>
> Maybe I should have avoided the term DSP, even if I thought
> it was generic enough.
>
> > For such DSP filters without hardware
> > multipliers, your 100MHz uC would not even match a 50MHz ARM.
>
> first, I am implementing a hardware multiplier in my uC.
> Ok it's only 8x8 unsigned but it will help is a few situations.
> But for "DSP work", I do my best to use adapted structures.
> I even have many unused DSP chips in stock (I was an ADi fan).
> And the "uC" has never been meant to be a workhorse,
> but rather a "controller" to a dedicated processing unit.
>
> Furthermore, I don't understand why a second person
> raises the issue of "my 100MHz UC" (I presume it is a
> reference to YASEP). This was completely independent from
> the original question, and it might open a smelly can of worms...
> I'd rather work on it than speak about it.

We are just echoing what you wrote on your site.  OK, it is irrelevant
in this case.

>
> Regards,
> yg
>
> --http://ygdes.com/http://yasep.org

Good evening,

linnix wrote:
> On Jan 22, 5:21 pm, whygee <why...@yg.yg> wrote:
>> hi,
<snip>
>> And some applications need to remember samples from 30s before,
> May be 60s, or 180s,...  How do you draw the line?
It depends on what is reasonably achievable
and the compromises I can find.
I have stocked many components for years and
my original post came after an attempt to sort them.
Now, I have tens of 32MB chips and they seem to fit,
but I'm not (yet) confident with dynamic RAM.

> Why can't you
> store them in flash memory, SD or CF.
 > Are they really so time critical?
Why would I imagine using Flash storage ?

First, it is not required to store the data when the system
(which is not even defined) is off. If this was needed,
I wouldn't limit the capacity to around 64MB, when 2BG is cheap.

Second, and that's what strikes me as really weird :
Flash memory has a given endurance (in write cycles).
It is well known that swap partitions should never
go to a flash disk, for example. So if I use Flash
memory to store a circular buffer of samples,
the Flash device will suffer and fail after "some time"
(depending on the controller, the Flahs, the access patterns,
the temperature etc.).

Finally, time is obviously critical for real
time sound processing, you don't want to hear "clicks".
There's probably going to be many unpredictable/random accesses,
and with roughtly 50KHz of sampling rate, 100ns
of access time is OK but 1ms is not.

>> One of them uses 16 audio channels on stage, so this would
>> leave only 2MB per channel if I had 32MB. That's not much
>> room for long-term delays with high-quality samples.
> You can move tens of MB per second with CF.

It's not so easy to make it work correctly.
The fastest I have seen was around 8MB/s on a PC, IIRC.
And a Flash device is not designed for constant writes.



regards,
-- 
http://ygdes.com / http://yasep.org