Electronics > Projects, Designs, and Technical Stuff
DDR2 chip how slow can you go?
<< < (4/11) > >>
JohanHoltby:
Wow such much great thoughts Thank you all!

So what I can conclude is that I should not do the DDR2 since it has speed requirements due to ?????. The refresh time is required  to be 64ms.
The alternative would be to use SDRAM since that is not requiring a curtain speed.  And by using the FMC I will get a lot of less headache.  I will be generating about 1 mega sampels per second from up to 16 channels. So 16 mega byte per second of data in worst case scenario and about 5-10 seconds of data. When i did some calculations I noticed that FLASHs will not be an option since this will be running 24/7 365 days per year. The requirements is not a hard requirement and I have a lot of workarounds that might work, like only storing the value furthest away from the previous value during a 8 sample cycle or similar. The end product is a production test tool so strange spikes and such is of great interest.


--- Quote from: daqq on August 29, 2019, 09:26:02 pm ---How about using a small FPGA? If this is for your all-seeing-scope project ( Here ) then things might actually get simpler (and comparably priced) with the proper FPGA.

--- End quote ---

Great name on the project will stick to it :). Yes its that one. I have been looking in to FPGAs as an alternative but the great challenge is that I need 80 analog in at about 1Msps per board at low cost and the I would need external ADC or more costly FPGAs with ADC built in to it. Pleas if you got any suggestions for FPGAs I'm all open.
DaJMasta:
80 analog lines?  What  micro has that?

In any case, the usual way to deal with so many lines would be an analog multiplexer (well, several of them) - so long as it's not 1MS/s per line, it should be pretty manageable to do with a single (or small number) of ADC inputs and the switching controls.

If you actually have a micro in your design with 80+ ADC inputs, switching to a smaller size one could easily give you enough BoM budget headroom to afford a small FPGA, a bank of SRAMs, a discrete ADC, or almost anything you could be after.... those things ain't cheap.  It sounds to me like SRAM is the right part for the job, but swapping down the micro and FPGA+DDR2 would probably work fine too.
SiliconWizard:

--- Quote from: JohanHoltby on August 30, 2019, 03:09:42 pm ---The end product is a production test tool so strange spikes and such is of great interest.

--- End quote ---

OK. You're still not saying what you are doing with the stored data.
Since you will be writing it over on a regular basis, what are you going to do with the overwritten (past) data? Just discard it? Or send it somewhere through some link? That point may help finding an appropriate solution and figure out how much temporary memory you really need.

If you're interested in detecting specific events ("strange spikes") can you not implement some kind of internal triggering on such events, and only store a chunk of samples around them (as a scope would do)? That would also limit the memory size requirement.

As for Flash, as I suggested, using SD cards may be a workable solution (as long as write speeds are OK with your application). Cheap, if you use large ones, you can do decent wear leveling, and if they wear out, you can always replace them (even on a regular basis). Much easier than replacing a soldered chip. Added benefit is that the last samples will remain stored if your system crashes for any reason, whereas if you're using RAM only, they will just be lost.

Berni:

--- Quote from: JohanHoltby on August 30, 2019, 03:09:42 pm ---Wow such much great thoughts Thank you all!

So what I can conclude is that I should not do the DDR2 since it has speed requirements due to ?????. The refresh time is required  to be 64ms.
The alternative would be to use SDRAM since that is not requiring a curtain speed.  And by using the FMC I will get a lot of less headache.  I will be generating about 1 mega sampels per second from up to 16 channels. So 16 mega byte per second of data in worst case scenario and about 5-10 seconds of data. When i did some calculations I noticed that FLASHs will not be an option since this will be running 24/7 365 days per year. The requirements is not a hard requirement and I have a lot of workarounds that might work, like only storing the value furthest away from the previous value during a 8 sample cycle or similar. The end product is a production test tool so strange spikes and such is of great interest.

--- End quote ---

What i want to hear is what STM32 MCU has such a high performance ADC to get 16 channels at 1MSPS 16bit each. I think the most i have seen is 3 ADCs in one chip that can do about 2MSPS at 16bit

The problem with running DDR2 chips slowly is the DDR part. They run on both edges of the clock so there is extra interface timing crap with tuned delays to make this work reliably at high speeds. You can issue refresh commands as fast as you want, but overall its a pretty complex interface that has a ton more than just reading and writing to memory cells, just go look at a DDR2 chip datahseet.
Yansi:
What I would want to hear instead is what is Johan trying to achieve? So far he looks confused even himself about his goal.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod