> 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
Reply by linnix●January 22, 20092009-01-22
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.
> 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
Reply by robe...@yahoo.com●January 22, 20092009-01-22
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.
Reply by linnix●January 22, 20092009-01-22
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.
Reply by Paul Carpenter●January 22, 20092009-01-22
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...
On Jan 21, 7:34=A0pm, whygee <why...@yg.yg> wrote:
> CBFalconer wrote:
> > To evaluate the effects of wire length, consider that 1 foot (1/3
> > meter) of wire represents about 1 nS in a vacuum. =A0Probably closer
> > to 2 nS in your environment. =A0100 MHz chips are cycling in no more
> > than 10 nS.
>
> Yes but other issues arise.
> And I've read everywhere that SDRAMs are difficult to use...
> getting pas initialisation is often described as ... a lot of work.
>
> > 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.
Yes, they all have auto refresh, but it does require you to create the
refresh cycle, the SDRAM provides the address using an internal
counter. I don't remember the details, but the refresh cycle is just
like a RAS cycle, IIRC, it just has a different signal asserted.
Have you looked for IP anywhere? opencores.org may have an SDRAM
controller.
> 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...
If it is not easy, don't bother. It can make your design more complex
than needed. The refresh cycle is very simple and only takes one
clock cycle every 15 us I think.
> > =A0See the data sheets for this.
> > The circuitry is a complication, not present in static memory chips.
>
> Static RAMs also have their gotchas...
>
> > The variation in delays through this
> > circuitry also need to get absorbed in that 10 nS window.
>
> Certainly.
> Correct data latching is necessary.
>
> Damn, I'm almost afraid of what I've got myself into...
Reply by whygee●January 21, 20092009-01-21
Didi wrote:
> On Jan 21, 4:38 pm, whygee <why...@yg.yg> wrote:
>> Fortunately, the eval boards have rather short traces to the headers
>> so impedence will not be a big problem (I hope).
> You will not need to match lengths at 133 MHz that much, 10-20 mm
> won't make any difference (just do the math).
> However, not having a ground plane to reference the signals to may
> well become an issue.
A thick copper wire will do the trick...
I even have some copper sticky tape if needed.
> Since this is a one-off thing (I suppose you do not intend to hand-
> wire them DDRAMs in mass-production :-) ),
Who know if there is ever going to be a production ? :-)
> you may be better off if you explore and
> cut a piece (literally) from a DDRAM DIMM, some do use DDRAMs with 16
> bits of data (this means you can have 32 or 64M maximum depending on which
> parts you use).
I have a bunch of SDRAM DIMMs but they are a bit... complex.
also, tracing where each pin goes to which pad is going to be... tedious.
it's probably not less complex than soldering directly to the pins...
(except for the size but I have one or two ideas)
> Now how you connect this piece of board to the other
> still remains unclear, of course;
I won't risk the FPGA board, i'll use 2.54mm connectors.
If something goes wrong with the FPGA, or if modifications
are needed, i'll just unplug.
> using many evenly spread GND wires
> between the two might help, but you won't know if it will work until
> it works...
sure :-)
hmmmmm I slowly realise that it's obviously weird, but not impossible ...
I think that I've seen worse, maybe at http://www.fpga4fun.com and other places.
I just want to get the SDRAM pins, functions, timings and sequences right
before I spend time making a (proto) PCB...
regards,
> 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.
The program/code can fit is smaller, faster SRAM.
Hope this is clearer now,
yg
--
http://ygdes.com / http://yasep.org
Reply by whygee●January 21, 20092009-01-21
hi,
CBFalconer wrote:
> whygee wrote:
> ... snip ...
>> 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.
>
> If for audio why in the world do you need such high speed chips?
well,
* I just happen to have a small ribbon (90-ish) of 48LC16M16
that match the speed of my computation core (I stick to 100MHz pipelines)
* Whenever I downscale a project, I always end up bitten by the speed demons (ouch)
* sound processing, effects, synthesis and whatnot consume
so much computational power that, well, I'm not even sure
that the A3P1000 will be enough for some of my friends
like Satine (http://satinemusic.com/) who use severa laptop
on stage but are annoyed by the necessity of using Windows there.
* Any headroom or margin is eaten in some way in SW...
* In fact I have no idea of what I'll end up doing,
so "high speed chips" is questionable with this perspective,
if the workload is not yet characterised ;-)
* what's wrong with high speed ? :-)
* etc.
--
http://ygdes.com / http://yasep.org