FPGA -> SATA?
in [FPGA]
|
From: Jim Granville on 25 Aug 2006 18:47 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
From: fpga_toys on 25 Aug 2006 19:14 Austin Lesea wrote: > 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!) And like Xilinx isn't equally protective and prolific with FPGA patents? > 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. Maybe Xilinx just needs to join the ASSP group, license some technology, and quit bitching.
From: PeteS on 26 Aug 2006 07:14 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? Cheers PeteS
From: Nico Coesel on 26 Aug 2006 08:49 "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
From: Antti on 26 Aug 2006 10:16
Nico Coesel schrieb: > "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 well in the case of SATA it is not so much an option. FPGA has no issues when external SATA PHY is used, but then we are not much talking about using MGT ofr SATA anymore. if we use external CDR circuitry that locks to SATA and spits out serial stream suitable for MGTs, then I think its still possible that MGTs dont lock anyway. and I dont think such an CDR IC is easier to find (or cheaper) then SATA PHY (what is almost impossible to obtain) BTW in my comment about V2Pro MGT issues I did mean the CDR clock region being too narrow +-100ppm (SATA +-300), those making V2Pro not to lock in some cases where initial clock is too far away - also when spread spectrum is not used. This issue has been fixed in V4FX ASFAIK - the CDR lock range is extended. Antti |