FPGA -> SATA?
in [FPGA]
|
From: Peter Wallace on 26 Aug 2006 12:39 On Fri, 25 Aug 2006 12:41:38 -0700, Martin E. wrote: > I am looking for a way to read/write to a SATA drive from an FPGA. I've > looked around. Nothing seems to fit the bill. Any ideas worth > considering? > > Thanks, > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin > > To send private email: > email = x(a)y.com > where: > x = "martineu" > y = "pacbell.net" Not ideal pin count wise but how about a SATA-PATA bridge? We're using the JMicron chip, its inexpensive and goes both ways (host & device) Peter Wallace
From: PeteS on 26 Aug 2006 13:06 Nico Coesel wrote: > "PeteS" <PeterSmith1954(a)googlemail.com> wrote: > > >Jim Granville wrote: > >> Austin Lesea wrote: > >> > Martin, > >> > > >> > No, and No. Sorry, even V5 does not have the frequency tracking agility > >> > to track the SATA spread spectrum clock. And because of that, we have > >> > no IP for it, either. > >> > > >> > The ASSP vendors are very protective about their business: they > >> > continue to make their little applications as tough to do as possible, > >> > to keep out the 'big bad FPGA vendors' who seem to be eating up all > >> > their businesses. (Hey, we are just trying to make our customers happy!) > >> > > >> > Too bad: when an industry is spending time being defensive, they have > >> > already lost - any time spent not innovating means you are doomed to > >> > failure. > >> > >> That probably depends on where you are standing. > >> > >> Could be, that the FPGA sector needs to innovate, and include > >> sufficent agility to track a SATA spread spectrum clock ? > >> > >> Sounds more an issue of who decides the market is large enough to > >> bother with, than any perceived fpga-vs-assp battles ? > >> > >> -jg > > > >I'll second this with an added comment: Spread spectrum clocks are an > >absolute must in some areas, and very desirable in others; I would > >*love* to use a spread spectrum clock in my newest design because it > >does not have a metal enclosure and EMI/EMC is a major issue. > >When you make FPGAs (or ASICs or any other chip for that matter) for a > >living but not shipping board and enclosure level products it's easy to > >forget 'little details' like this (regulatory compliance) that systems > >and board designers live with day in and day out. > > > >Spread spectrum obviously alleviates the problem significantly (in some > >very subtle ways too). A lot of vendors offer the ability to track a > >spread spectrum clock; why not FPGA vendors too? > > You can as long as you don't use the DCM (or anything like it) and > route the fpga for the highest allowed clock frequency. If you use an > external device to create your clocks and feed them into the fpga, > there is no reason why an fpga won't work with spectrum spread clocks. > > -- > Reply to nico(a)nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U op www.adresboekje.nl My point is there is nothing I am using (or generating) in the design that would suffer from spread spectrum (indeed, my design would benefit higely) and I would love to generate all system clocks except a processor from a spread spectrum master. That implies using the DCM (or it's equivalent). A spread spectrum oscillator can be modelled as a device with (introduced) jitter, and are quite well documented [if they aren't, I don't use them]. I am astounded (in a way) that a DCM can't handle the (relatively minor) deviation of a master clock to generate new ones with the same percentage variances. If I have to use a PLL (which can be tuned to track such things), it would mean either changing the device to a 'well known competitor' or adding hardware (which adds power consumption I can not afford). Cheers PeteS
From: rickman on 26 Aug 2006 13:08 PeteS wrote: > I'll second this with an added comment: Spread spectrum clocks are an > absolute must in some areas, and very desirable in others; I would > *love* to use a spread spectrum clock in my newest design because it > does not have a metal enclosure and EMI/EMC is a major issue. I understand that spread spectrum helps pass EMI testing. But does a spread spectrum clock actually help reduce interference? It seems to me that by relatively changing the clock frequency, all you are doing is fooling the test equipment which operates slowly in comparison. In reality you have not reduced the energy transmitted and unless your interference is very narrow band in nature, it will not fix the problem. Many applications that care about EMI are not helped by a "trick" that gets through the testing without actually solving the problem. For example self interference in a radio. I don't think a spread spectrum clock on the digital circuits would actually reduce the amount of interference seen. Am I wrong about this?
From: fpga_toys on 26 Aug 2006 13:22 rickman wrote: > I understand that spread spectrum helps pass EMI testing. But does a > spread spectrum clock actually help reduce interference? It seems to > me that by relatively changing the clock frequency, all you are doing > is fooling the test equipment which operates slowly in comparison. In > reality you have not reduced the energy transmitted and unless your > interference is very narrow band in nature, it will not fix the > problem. I agree fully ... the peak energy is still there, just prevents the test equipment from integrating it. And all you are doing is poluting more of the band with energy. When the computer device is near the reciever which is also trying to listen to a transmitter that is relatively VERY far away, the small amount of near energy spread across more spectrum is still a major interference source, with a higher likelyhood for interference. I can't wait for someone to come out with a fast integrator that can truely measure peak energy ... at which point these idiots will be caught with their pants down trashing far more spectrum than needed.
From: fpga_toys on 26 Aug 2006 14:12
rickman wrote: > Many applications that care about EMI are not helped by a "trick" that > gets through the testing without actually solving the problem. For > example self interference in a radio. I don't think a spread spectrum > clock on the digital circuits would actually reduce the amount of > interference seen. I think the assumption was that the spread spectrum clock would get filtered by the decoder, and not affect signal decoding. That is certainly true in respect to voice/analog transmissions. However, for high rate data, the clock spread frequency isn't rejected at the symbol sampling rate, and certainly doesn't prevent symbol corruption or decode lock problems. |