DDR2 chip how slow can you go? - Page 1
Forum section: electronics / projects

author: JohanHoltby
author_rank: Contributor
timestamp: August 28, 2019, 09:53:57 pm
content: HiI'm investigating how to store a lot of data. and need an as cheap as possible data storage solution. Flash is not an option since I will write it over multiple times every minute.I'm lookng att an DDR2 chip but since I'm using a low voltage STM32 device which only has a clock speed of about 72mhz. How slow can I go without any problem?The chip has auto refresh so that will be handled by the ship itself. Cost is a factor so going to SRAM is not an too intresting option if I can get away with using DDR2 chips.The chip is: W971GG6SB-25-NDhttps://www.digikey.se/product-detail/sv/winbond-electronics/W971GG6SB-25/W971GG6SB-25-ND/5125232

author: amyk
author_rank: Super Contributor
timestamp: August 29, 2019, 01:21:13 am
content: The datasheet shows a maximum clock period of 8ns, or 125MHz as the minimum speed at which they guarantee it to work. In practice I believe this is limited by the leakage of the dynamic logic used within, which is related to operating temperature. This means that it may be possible to go lower if you don't let the temperature go up too high, but I suspect you'll encounter a lot of part-to-part variance.

author: wraper
author_rank: Unknown
timestamp: August 29, 2019, 01:25:04 am
content: Wait, are you going to bit bang DDR2?.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 29, 2019, 02:31:13 am
content: What overall lifetime do you want?Flash at that rate isn't bad if you have tens of gigs to spare. Shove in an uSD and be done?You may also consider buffering incremental changes in SRAM or FeRAM, then dumping larger payloads into Flash much less frequently (minutes, hours even?).Tim

author: jbb
author_rank: Super Contributor
timestamp: August 29, 2019, 02:44:29 am
content: It costs more per bit than commodity, but Cypress and Winbond (and some others) have SDR SRAM still very much in production. This should be compatible with the STM32 external memory interface.

author: pigrew
author_rank: Frequent Contributor
timestamp: August 29, 2019, 03:36:11 am
content: While you may be able to bit-bang DDR2, it'd be tough, and your throughput would be awful. You may end up needing external logic ICs, too.I founda PDF describing which STM32 models are compatible with which RAM types. It looks like most of the F7 and some of the F4 have SDRAM interfaces, which support up to 512 Mb in a package. It appears that, for example, the F469 can control two separate SDRAMs, so that'll get you a gigabyte of storage. (but I've never used SDRAM on the STM32 before, so I don't know much more than I've written).ADDENDUM: In STM32CubeMX, you can filter by which MCUs have a "FMC" to see which are available. Some L4, G4, and F3 are listed, so you can get lower power/slower than the F4 would be. The main constraint in timing is the refresh interval, which is every 64 ms, so you should be able to clock things fairly slow.

author: james_s
author_rank: Super Contributor
timestamp: August 29, 2019, 04:31:36 am
content: If you really want to use DDR RAM then you should look at using a small FPGA to implement the memory controller. There is code already written that will let you use it somewhat like SRAM.

author: Berni
author_rank: Super Contributor
timestamp: August 29, 2019, 05:01:26 am
content: Just use some SDRAM instead, its available in pretty large sizes for cheep and a lot of STM32 MCUs have a memory controller that supports it.This not only makes it faster as its not bitbanged, but it also properly memory maps the RAM so that to the CPU it looks exactly the same as internal RAM. This lets you use the RAM for anything, including executing code from it and easily DMA data in and out of it.

author: krho
author_rank: Regular Contributor
timestamp: August 29, 2019, 03:12:16 pm
content: Or he can use STM32MP151 with LPDDR2/3 DDR3, DDR3L, with FreeRTOS on A7, the CPU itself costs less than M7

author: Yansi
author_rank: Super Contributor
timestamp: August 29, 2019, 05:27:40 pm
content: Somebody clearly just got the evil bluepill board and a soldering iron and has as we say "too big eyes".I am missing any application specs for data troughput, storage capacity, etc and a sensible description of what has to be achieved. You know, SDcards can hold tens of GBytes.There is a crapton of STM32 chips with integrated SDR memory controllers, that can tackle I think up to 512MByte SDRAM.(Forget MP1, you won't make that one work, it is a pain even for those who know what they are doing)

author: jbb
author_rank: Super Contributor
timestamp: August 29, 2019, 07:12:53 pm
content: Some words of warning when using external SDRAM:Thorough testing is suggested with low / high supply voltage and low / high temperature to make sure everything is configured correctlyIt's likely slower than internal RAM, so you'll need to do some reading about linker behaviour make sure your most critical storage - e.g. stack and critical RTOS tables - are in on-chip RAMIf you don't want people copying your code, don't run code from external RAMIf you're doing any cryptographic security, make sure the keys stay in internal RAMSDRAM will increase your standby power consumption

author: nctnico
author_rank: Super Contributor
timestamp: August 29, 2019, 07:53:49 pm
content: Quote from: JohanHoltby on August 28, 2019, 09:53:57 pmIIRC DDR2 has two modes: with PLL enabled and PLL disabled. In the latter mode it can work at very slow speeds. The slow speeds are used to load test patterns into the memory which are then used to compensate the delays at the normal operating speed. Needless to say the memory will work just fine for as long as you adhere to the refresh intervals (and auto refresh is an easy way to do this). However a big nand-flash connected to SPI might be another option. You'll need to have BCH error correction and be able to detect bad blocks but even at many overwrites it will take long to wear the flash out. If you don't need any long term data retention then flash wear may not even be an issue.

author: ejeffrey
author_rank: Super Contributor
timestamp: August 29, 2019, 08:56:13 pm
content: Quote from: jbb on August 29, 2019, 07:12:53 pmInternal keys are only slightly more secure than external keys. If you need physical tamper-proof cypto you should be using a special purpose crypto processor.

author: daqq
author_rank: Super Contributor
timestamp: August 29, 2019, 09:26:02 pm
content: 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. Look around, lattice has fairly cheap FPGAs (https://www.digikey.sk/products/en/integrated-circuits-ics/embedded-fpgas-field-programmable-gate-array/696?FV=ffe002b8&quantity=0&ColumnSort=1000011&page=1&pageSize=25).

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 29, 2019, 10:47:06 pm
content: Quote from: JohanHoltby on August 28, 2019, 09:53:57 pmYou may want to consider whether you really need to do that to begin with, or at least explain to us why. DO you really need to store that much data multiple times every minute? What are you going to do with this data? Can you not store smaller chunks and process them accordingly instead?Once you're sure you have no choice, you could still consider using Flash for that. Using an SD card or something would get you for relatively cheap so much more memory than a single RAM chip (the one you showed is 128MBytes if I'm not mistaken), that you could just use a very simple wear-leveling scheme (writing your blocks of data to a different area every time, and then cycle when you've reached the end of the SD card) that would get you a pretty decent lifetime.Otherwise, if you're sure this is really not an option, SDRAM would be more adequate here than DDR2 as already said (but you'll have a hard time finding single SDRAM chips with that much memory, so maybe that's why you targetted DDR2?)PSRAM would otherwise be an option too, but they usually come in more limited memory size. How much memory do you REALLY need?

author: JohanHoltby
author_rank: Contributor
timestamp: August 30, 2019, 03:09:42 pm
content: 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 pmGreat 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.

author: DaJMasta
author_rank: Super Contributor
timestamp: August 30, 2019, 03:33:49 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 30, 2019, 03:54:39 pm
content: Quote from: JohanHoltby on August 30, 2019, 03:09:42 pmOK. 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.

author: Berni
author_rank: Super Contributor
timestamp: August 30, 2019, 04:26:14 pm
content: Quote from: JohanHoltby on August 30, 2019, 03:09:42 pmWhat 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 16bitThe 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.

author: Yansi
author_rank: Super Contributor
timestamp: August 30, 2019, 04:45:51 pm
content: What I would want to hear instead is what is Johan trying to achieve? So far he looks confused even himself about his goal.

author: bson
author_rank: Unknown
timestamp: August 30, 2019, 06:07:42 pm
content: Quote from: JohanHoltby on August 30, 2019, 03:09:42 pmJust be aware that many STM32 packages have an abbreviated FMC interface. Especially the smaller packages either omit it altogether or have only a small subset of signals to drive things like 8080-bus interface LCD controllers (where data matters and only a few address lines are provided in case you need them for arbitration and addressing logic). On chips like the F103 I've found you will need the full density BGA packages to get the full FMC, and even then it's often pin sharing with other precious functions, and you might find yourself unable to use it at all with any amount of pin or port swapping.

author: Yansi
author_rank: Super Contributor
timestamp: August 30, 2019, 06:14:30 pm
content: FMC is not FSMC peripheral and secondly he may be more concerned he probably can't do the layout for the multiple chip high capacity SDRAM bank alltogether. (Even though such layout may not be difficult at all, but judging from the style of questions and lack of basic understanding, there may be quite steep learning curve to be aware of)Note: interfacing a huge SDRAM bank is never considered doable with any small package. Likely 176pin one required.

author: daqq
author_rank: Super Contributor
timestamp: August 30, 2019, 06:32:02 pm
content: QuoteUnless you need isolation, then at 80 channels per board you're likely better off with one hefty FPGA and 10x simultaneously sampling 8 channel ADCs ( such as this:http://www.ti.com/product/ADS8598H#orhttps://www.analog.com/en/ltc2320-12). The price per chip is fairly large (though cheaper ones exist), but at a quick guess it might be cheaper than an MCU + Hacked RAM.Essentially per channel, let's say you manage to hack a cheap (3USD) DDR2 memory to play along with a cheapish STM32 (say, 2-3 USD), then you get 6 USD per channel.With a single 10 USD ADC such as thehttps://www.analog.com/en/products/ltc2320-12.html#product-overviewyou get 0.95 USD per channel. The processing stuff (FPGA) will be more expensive, but will be single and the costs for this will be divided between all of the channels.

author: Yansi
author_rank: Super Contributor
timestamp: August 30, 2019, 06:41:20 pm
content: Why do you even consider hacking the ram? Considering this is basicaly likely not doable at all, otherwise don't you have anyhing better to do than hacking what is way easier done the proper way?I am even lacking any explanation what he will do with all hose data in the memory or any further explanation of the project.

author: nctnico
author_rank: Super Contributor
timestamp: August 30, 2019, 07:14:54 pm
content: Quote from: JohanHoltby on August 30, 2019, 03:09:42 pmI have the feeling that by the time you have designed this you spend more money compared to just buying a data acquisition system. Unless ofcourse this has to become a product. But even then this is likely for a niche market. I'd optimise the design for the least amount of R&D effort and risks. Starting with low cost parts is not the good direction because it will lead to a large amount of effort to make it work. IOW: use a cheap FPGA (Xilinx Spartan series for example) to read a bunch of ADCs and stream the data into a PC using PCIexpress. Inside the PC you'll have easy access to (fast) data storage and analysis.

author: Yansi
author_rank: Super Contributor
timestamp: August 30, 2019, 07:17:01 pm
content: Yeah and then spend the next two years developing a kernel driver for the pciex card.

author: nctnico
author_rank: Super Contributor
timestamp: August 30, 2019, 07:20:57 pm
content: Quote from: Yansi on August 30, 2019, 07:17:01 pmJust hire someone who can.

author: bson
author_rank: Unknown
timestamp: August 30, 2019, 07:39:23 pm
content: I would second the idea of an SD card slot and an SDIO bus interface. 16MB/s should be straightforward. Use FAT32 and have a PC program pre-format the cards to have a single big continuously allocated data file that you use as a buffer.

author: Yansi
author_rank: Super Contributor
timestamp: August 30, 2019, 07:49:45 pm
content: 16MB/s yes, but definitely not with fatfs.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 30, 2019, 08:21:14 pm
content: I would not use a FS for that. It would add overhead, possible bugs and make the wear-leveling much harder to do without largely modifying the FS code.Just write your raw data in consecutive blocks, and cycle when you've reached the end of the available memory.If you need to read that back on a computer, write a small utility - could be done with just a few lines of C or whatever language you feel comfortable with as long as you can get access to the raw data of the card. On Linux, you wouldn't even need to write anything: use dd. On Windows, could be done in under 100 lines of C, comments included.

author: Yansi
author_rank: Super Contributor
timestamp: August 30, 2019, 08:27:33 pm
content: SDcard is already a managed NAND flash memory, isn't it? No wear leveling and bad block management required (the latter probably even not possible with an SDcard, as I think the ECC spare area sectors are not accessible? and the SDcard controller does all that required).Bare metal NAND FLASH chip may be a completely different story.//On windows, you use for example HXD.

author: nctnico
author_rank: Super Contributor
timestamp: August 30, 2019, 08:34:49 pm
content: Quote from: SiliconWizard on August 30, 2019, 08:21:14 pmMost SD-cards from sensible brands will do wear levelling. Otherwise the flash would wear out very fast for the area where the FAT is written to.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 30, 2019, 08:41:37 pm
content: Quote from: Yansi on August 30, 2019, 08:27:33 pmMaybe you're right. Don't know how effective it is or if all SD cards are born equal (I would suspect not...)Even if it's not for wear leveling, one benefit of writing data explicitely to consecutive sectors instead of writing it always starting at the same sector would be the ability to read back several past data blocks instead of just one. If you keep writing from the first sector, the SD card controller may write the data in different parts of the Flash for wear leveling, but you will never be able to access anything else but the last block.

author: Kilrah
author_rank: Unknown
timestamp: August 30, 2019, 08:45:10 pm
content: Quote from: nctnico on August 30, 2019, 08:34:49 pmI don't know of any commercial card that does this, and yes the FAT area is what usually fails first for obvious reasons.SOME industrial spec ones do it, but they're a niche and specifically marketed as such.

author: JohanHoltby
author_rank: Contributor
timestamp: August 30, 2019, 10:20:36 pm
content: I'm a test energier and this memory will be in a switch module which will be one of my products I will sell to my clients. It's a modular system of startkabel modules. Each sub module will ha ve 40 channels 32 in from TPs and 8 out (to the 8 rows). Each connection will have monitoring for safety and debugging for current and voltage. I want to have the data for all channels for the last 8 seconds. So when the test is stoped then I can go around and check what happens leading up to the break in the system to know what's happening and why. No more reruns to try to find the problems so streaming is not needed. No more broken equipment du to malfunctioning DUTs since the system can set the safty levels for each value. The STM32 chip has 4ADC with 5Msps each.Regarding my lack of knowledge I have to agree on this topic since I have not worked with any other memory modules than EEPROMs and SD cards. The layout and exact schematics will be done by a small design house which have good knowledge of high speed communication but as some pointed out I need to know what I want.When I did look in to the Flash modules I noticed that I will need to replace the SD cards two times every year for a 128Gb SD card. And since this system will be deployed by an EMS overseas often I don't have the luxury of replacing SD cards. SO about 10 years of operation would be great.So right now I hink of going with SDRAM or SRAM.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 30, 2019, 10:48:07 pm
content: OK now that's clearer. I agree in your case RAM would make a lot more sense.SDRAM would be the way to go IMO. Take a look there:http://www.issi.com/US/product-dram-SDR.shtmlFor the same memory size with SRAM, you'll need quite a few ICs and that will cost you an arm and a leg.

author: JohanHoltby
author_rank: Contributor
timestamp: August 30, 2019, 10:52:26 pm
content: Quote from: nctnico on August 30, 2019, 07:14:54 pmThis is an interesting point and I will probably go this rout to extract the data from the system but not by live streaming since the system might have up to 8 boards in each stacks and up to 16 stacks and each board will have 80 1Msps data streams (1Msps per adc channel).That would be about 10 gigabytes (not bit) per second.The BOM cost per board my not be above 400 dollars or it will be hard to sell to the end customer. Is that inside an arm and an leg? If not I will need to limit the amount of memory.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 30, 2019, 10:56:59 pm
content: Quote from: JohanHoltby on August 30, 2019, 10:52:26 pmOh, for this amount you could definitely go for an external ADC+FPGA+DDR2 or DDR3 RAM... would cost you a lot less than an MCU+several big SRAM chips.

author: JohanHoltby
author_rank: Contributor
timestamp: August 30, 2019, 11:13:22 pm
content: I will take a look in to that advice and investigate that stack. using a single FPGA would be nice since that would same som real estate which is not a luxury I have since I need to fit it all inside a standard test fixture.The problem I did find before was that the ADC was very costly when they where not dedicated. An alternative would be using the STM32 with 4ADC ringing att 5Msps and use the 4 SPI channels at 18MBps to stream the data to the FPGA. Sure I would not get all the data there but I could limit the stored data frequency.

author: nctnico
author_rank: Super Contributor
timestamp: August 31, 2019, 12:23:42 am
content: The ADCs inside a microcontroller may not be very good compared to a dedicated ADC chip. Especially in lower cost microcontrollers.

author: Yansi
author_rank: Super Contributor
timestamp: August 31, 2019, 08:02:48 am
content: Quote from: SiliconWizard on August 30, 2019, 10:56:59 pmNOBODY did suggest SRAM, but there is a metric shit ton of microcontrollers with integrated SDRAM controllers, that can manage more than enough size of memory for his purpose and can deal with such data IO speeds without an issue.FPGA of course is almost always more suitable option for large data ackq systems.

author: daqq
author_rank: Super Contributor
timestamp: August 31, 2019, 06:16:52 pm
content: QuoteDefine costly.Assuming that you need simultaneous sampling (a reasonable assumption) then you have 10 USD (price of an STM32 with 3 channels) per 3 channels, giving you 3 USD per channel.The cheapest 12 bit ADC I found on farnell was ~1 EUR in bulk quantities. Assuming you use several multichannel simultaneous sampling ADC as I have advised (or a fast ADC and a fast MUX), then you can cut down the price and improve performance.Just because you are used to using STM32s doesn't mean that they are the best tool for everything. Just because you have a hammer does not mean everything is a nail.

author: OwO
author_rank: Super Contributor
timestamp: August 31, 2019, 07:16:06 pm
content: I would personally go with a Zynq based solution. Each FPGA board will cost ~$100 (if you use digikey prices) but has >2GB/s of memory bandwidth and up to 1GB of memory. The number of streams you can handle per board will only be limited by the available IOs.The hard part is finding high channel count ADCs. I did a quick search on the analog devices website and couldn't find a suitable ADC (>=8 channels and >=1Msps per channel). Using an external MUX is very ugly in terms of timing (you'd need an analog switch that can switch on the order of 10MHz, and settle in a fraction of a cycle, which from what I'm aware does not exist at reasonable cost), so if I were tasked with this project I'd use my go-to technique which is delta sigma modulation using schmitt triggers.The 74LVC14 contains 6 inverting schmitt triggers, each of which can implement a delta sigma modulator with only 2 resistors and a capacitor. I did spice simulations a while ago that showed this can work well well above 10MHz toggle frequency, so it should be adequate for your 1Msps signal. The output of each modulator is a single bit signal, which you would feed into the FPGA and use a CIC filter to decimate to 1Msps. The IO utilization would be one FPGA IO per stream, so it should be possible to do over 80 streams on a Zynq 7010. The CIC filters are very small and it's easy to implement a multi-channel filter that can handle 200 1Msps streams running at 200MHz.

author: NiHaoMike
author_rank: Super Contributor
timestamp: September 01, 2019, 05:11:34 am
content: There's even a trick to use the LVDS inputs on a FPGA as ADCs, of course you'll have to characterize it yourself.https://hackaday.com/2015/09/09/video-fpga-with-no-external-ad/

author: JohanHoltby
author_rank: Contributor
timestamp: September 01, 2019, 09:10:22 am
content: I'm no fanboy of STM32 so I'm open to every thing. The reason I'm looking in to STM32 is that they have the F3 series which some of them have 4 ADCs running att 5Msps and can do scanning of multiple channels so in theory giving me about 20Msps but in reality some number less. As someone mentioned before they also have FSMC.So after some more design thinking maybe going with a simple STM32F303CBT6 (2.7$ @ 1000 units) and do only two channels scanning which would give me 8ch. Using the SPI would be a working solution but I think the better solution would be to just push out new data using I/O pins. 16 pin wide bit banged parallell port to an FPGA. If I run in to problems I could also do differential signaling on the parallel port since they also come in higher pin count. Sure I might need to lower some specification if I run out of CPU cycles. Since I will have 20Mb/us and only 72 cycles to do it on. But in reality it will be just read data and push it to the FPGA. The FPGA could then be responsible for turning on and off the and storing the data to an DDR memory.Regarding Zynq 7010 it looks interesting. I have not done any FPGA work before but dome some in school and liked it back then. How hard can it be....haha. Will post some new question on what FPGA to choose.Quote from: nctnico on August 30, 2019, 07:14:54 pmWhat interface do you use for the PCIexpress? Standard parallel port or just and I/O board? To be able to dump all the data from every node for the last 8 seconds for every time a DUT fails is a hope I have but that is a lot of data in worst case and even with only 100-300 nodes (average simple sized test) that is about 2.5Gbyte of data and I can not bloc the test for more than maybe 5 seconds. So high speed to the PC would be nice.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: September 01, 2019, 09:21:45 am
content: Quote from: JohanHoltby on August 30, 2019, 10:20:36 pm16 MB/s are 16*3600*24*365/1024 ~= 500 TB/year IIANM. That's almost 250000/128 ~= 2000 full card rewrites/erases in six months. An SD card can really handle that much?There are now 256 and 512GB cards. If you've got spare pins or SD card interfaces in the STMs perhaps you could devise a RAID-ish setup with more than one card.

author: Yansi
author_rank: Super Contributor
timestamp: September 01, 2019, 10:05:03 am
content: Spare SDIO interfaces should not be required, SDIO I think supports multiple device interfacing. Never tried it though.I still think this project is poorly thought out and the goal is not clear.

author: JohanHoltby
author_rank: Contributor
timestamp: September 01, 2019, 10:40:11 am
content: Quote from: Yansi on September 01, 2019, 10:05:03 amInterested (with a true open mind, not aiming for protecting my darling) in what you think is the poor parts and do you have any suggestions? In the end I want this to be as a good product as it possible could be.To give some more background:Normally I get a limited test specification which are updated many times so there for I enjoy wokring with matrix based interface systems (TPs, instruments and PS on columns and they can be switched in by software to a number of shared rows e.g. PXI-2533) which enable only software updates as the product specification updates as long as the TPs stay in place.However DUTs break and people make mistakes so debugging and safety is important. This leads to multiple reruns to find bugs and broken equipment in worst case. To avoid reruns I want an all seeing scope which can log all current and voltage going through the matrix. Whenever any thing breaks I want the matrix to trigger if e.g. a current is above set value and disconnect the switch.Since the specifications is not set ahead of time I want to have it modular so that it will be able to connect and disconnect modules depending on specification changes. And since test systems is almost always one offs making custom PCBs are very costly in regards to labor cost.Yansi with that background what would you suggest?

author: Yansi
author_rank: Super Contributor
timestamp: September 01, 2019, 01:16:26 pm
content: I am still quite confused, as what the design goal of your instrument should be. Have you posted a full definition of it? I do not follow the thread carefully, I may have missed. It even seems the design goal is changing throughout.What I would like to see is something like this:State the intention of the device, the typical end use (for us, who are not familiar for example with those PXI systems mentioned which)State the desired electrical interfaces, bot inputs and outputs and its characteristics:ie.: I need to record 32 analog voltage channels at 1Msps rate @12bit resolution and sample them simultaneously for whatever the reason. I need to record all channels for as long as 1 minute, and then read out the sampled values from the device through XYZ interface.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 01, 2019, 01:35:02 pm
content: Why would you even consider an STM over, say, a multicore SOM, using USB or PCIe (and bridges, interfaces, FPGAs, etc. as needed) to concentrate data from the various peripherals?Such a device also trivially(?) runs Linux, communicates over Ethernet, connects to the Internet, connects ordinary HID devices, HDMI or DVI or whatever monitors, etc. In short, a small PC with custom hardware attached.Timing constraints for test equipment usually isn't terribly tight (i.e., on a similar scale as toggling relays), so the relatively poor timing of a multitasking OS is fine; real-time functionality is still available, with some difficulty (run as root? timing still subject to device drivers and hardware timing?), but preferably all hard real-time activity should be constrained to the peripherals themselves, and merely buffered data flows to the PC.Tim

author: Berni
author_rank: Super Contributor
timestamp: September 02, 2019, 05:38:29 am
content: Quote from: JohanHoltby on September 01, 2019, 10:40:11 amAh now i get it what you are trying to do.In terms of that i have two suggestions depending on the response time needed.1) Near instantanious response time:Just connect a bunch of ADCs to a FPGA and build a standard data analysis block inside it. Each ADC channel feeds its own data analysis block that on the fly measures a bunch of parameters about the input waveform. Then have another block constantly do a comparison of those values against some configured min/max ranges, if it goes out of range the FPGA can signal it in a matter of nanoseconds to the outside so that you switch whatever you needed to switch.2) Milisecond range response time:Grab something like a FTDIs USB3.0 FIFO chip ( FT600/FT601 ) and use a little bit of CPLD glue logic to connect it to a bunch of ADCs. As soon as you give it power it simply starts streaming the ADC data out to the USB host and that's all it does, no configuration or anything. Then you plug this into a small PC running windows or a single board computer running linux where you write your software to take in the data, analyze it and then send a command to switch whatever you need via any means you like: Serial, USB, Ethernet, SCPI etc... The advantage here is that you have gigabytes of RAM available to buffer it or at these speeds the data can easily be directly written to the hard drive giving you terabytes of recording memory. There is as much processing power as you would ever need (Heck you can use Cuda for GPU acceleration even) but the response times are going to be much slower due to all the extra stuff in the loop and the OS scheduler getting in the way.As for cheap high speed ADCs you can find 16bit ADCs that run from a megasample to >100 MSPS for a reasonable price in the form of CCD imaging digitizers (Used to turn signals from a CCD chip into digital pixels). The only problem is that these ADCs often have weird interfaces buses or LVDS and things like that to talk to them, so running them using a MCU is very annoying, but easy with a FPGA.

author: JohanHoltby
author_rank: Contributor
timestamp: September 02, 2019, 12:53:40 pm
content: The FPGA rout will be best since storing the data locally is important. USB is not an option since It's not a stable protocol for production environment. I will make a new thread with more structured specifications. I have got what I was asking for (and a lot more) and now feel more comfortable with the decision FPGA -> DDR [2 or3] for storing the data. Hacking is not an good option.Thank you all for your help!

author: Yansi
author_rank: Super Contributor
timestamp: September 02, 2019, 01:21:28 pm
content: So why did you begin yourself, with bold statements of hacking a DDR memory? (... ... see those shifting goals?)