|
Martin- I don't know if this got through or not, because our mail system was down over the weekend, so I'm resending just in case. -Jeff -------- Original Message -------- Subject: [Fwd: Re: [c6x] EDMA - EMIF maximum speed.] Date: Mon, 29 Sep 2003 07:58:58 -0500 (CDT) From: To: Martin Thompson <> CC: Martin- > I'd use the SDRAM and FPGA in parallel, as I don;t want to do anything > more to the data once it's in SDRAM - passing the data through the FPGA > will put even more latency on the access :-( > > If you need to do error correction or encryption, then I think you > probably have to pass it through unforunately... Thanks very much for your suggestions. 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. -Jeff |
|
|
[Fwd: [Fwd: Re: EDMA - EMIF maximum speed.]]
Started by ●October 2, 2003
Reply by ●October 2, 20032003-10-02
|
Hi Jeff, >Martin- > >I don't know if this got through or not, because our mail system was >down over the weekend, so I'm resending just in case. > It has now :-) >-Jeff > >-------- Original Message -------- >Subject: [Fwd: Re: [c6x] EDMA - EMIF maximum speed.] >Date: Mon, 29 Sep 2003 07:58:58 -0500 (CDT) >From: >To: Martin Thompson <> >CC: > >Martin- > >> I'd use the SDRAM and FPGA in parallel, as I don;t want to do anything >> more to the data once it's in SDRAM - passing the data through the FPGA >> will put even more latency on the access :-( >> >> If you need to do error correction or encryption, then I think you >> probably have to pass it through unforunately... > >Thanks very much for your suggestions. > No probs! >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. Cheers, Martin -- Martin Thompson CEng MIEE TRW Conekt Stratford Road, Solihull, B90 4AX. UK Tel: +44 (0)121-627-3569 - |
Reply by ●October 2, 20032003-10-02
|
Martin- > >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. -Jeff |
Reply by ●October 3, 20032003-10-03
|
>> >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 - |
