>> >I think you could do some type of error correction using an
in-parallel >> >architecture. For instance, you could monitor address and data and store >> >parity info in a separate, x4 SDRAM device (parity info generated by the >> >FPGA, all other lines in parallel with the data SDRAM), monitor readbacks >> >for errors, and interrupt the DSP if needed. Not efficient and does not >> >auto-correct, but in a low error-rate environment might be Ok. >> > >> >> That would indeed be an option - as you say, it depends on how often you expect errors and how serious they are. > >Right. > >Another thing we are thinking about is a bus-switch that allows the "safe approach" >described above, or puts data through the FPGA for possible "auto-correct mode". At >least that way the design is usable until the parity detect/correct logic is worked >out and we have determined whether we can, in fact, deal with the latency problems. > Another potentially silly idea: If you can deal with an 3 cycles of latency *and* you can do the error correction in one cycle, you could set up the SDRAM with a CAS latency of 2, setup the DSP to expect a CL of 3, wire up all the control signals from the DSP to the SDRAM, but put the datalines through the FPGA. Then you can use the extra cycle to do your error correction.... Or just use SRAM, then you can pick the timings ;-) Cheers, Martin -- Martin Thompson CEng MIEE TRW Conekt Stratford Road, Solihull, B90 4AX. UK Tel: +44 (0)121-627-3569 - |