FPGA -> SATA?
in [FPGA]
|
From: Antti Lukats on 27 Aug 2006 06:13 <fpga_toys(a)yahoo.com> schrieb im Newsbeitrag news:1156638163.927585.251260(a)h48g2000cwc.googlegroups.com... > > Antti wrote: >> ML300 and digilent XUP V2Pro both have SATA connectors on >> them but can not actually be used for SATA as of compliance issues. >> (OOB and CDR lock range mainly) > > As a new owner of XUP V2Pro board, my comment is that Xilinx screwed up > royally by not joining the standards process BEFORE shipping a SATA > based product or design. I purchased the board simply BECAUSE it had > these interfaces. > > There are certain expectations that systems vendors actively take part > in industry standards if they are going to ship and support products > based on those standards. I've spent years of my life supporting > standards processes ... they are the most valuable customer asset a > systems company can invest in to protect both their products, their > customers products, and a safe product migration path over time. > Hi John, well I was in about the same situation as you, namly I recommended the purchase of ML300 (4695 USD !!) for an project, and I assumed that the SATA can be use don that board. Well Xilinx response was "Sure we thest the SATA on ML300! We use the BERT test application and loopback cable!" - you can imagine I wasnt very happy with such a response. At that time when that purchasing decison was made (base on my recommendatio) Xilinx MGT documentation listed SATA as on of the supported protocols. The updated MGT docs do not include SATA anymore. good god, I just checked the ML300 latest documentation and it still lists: "The ML300 provides for operation as a Serial ATA host or device." This is of course not true. Ok it must be that the ML300 docs have not been updated. Now to the XUP V2Pro board, first of all this board is designed made by digilent, so whatever is screwed up as you say with this board then its done by digilent, and not Xilinx. With the XUP board the SATA is a little better than with ML300 as the OOB fixup is added to the XUP (its missing on ML300) see page 29 of the XUP board schematic. The OOB can be done without the FET solution too when rx and tx are used from different MGT (not possible on ML300) I have tested that on Memec VP20 board where I did succesfull got past the OOB handshaking and was seeing the inband signalling from the Silicon Image SATA chip. So you should be also able to get SATA working on XUP. There isnt much ready IP for that, thats another question. And if you are considering an commercial product that has to pass __full__ compliance then I see no alternatives as using a external SATA-PATA bridge, it save you both development time and actual self cost of the product as well (relative cost of the SATA IP in terms of % of the FPGA is hihger than the SATA-PATA IC). And again, you can not blaime Xilinx in everything, sure it would be nice to use MGTs for SATA, and a free SATA IP core would be nice too, but - if you really read Xilinx documentation - they are no longer claiming MGTs to handle SATA, so if you missed that, you cant legally say anyhing. Just bad luck for you. Antti
From: Antti on 27 Aug 2006 07:52 PeteS schrieb: > 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 Pete, 1) DCMs are not used for SATA clock at all, the MGT should be feed with 75MHz reference clock and the SATA data rate clock is recovered in the CDR inside the MGT. So any issues DCM may have are ir-relevant in the regards of SATA 2) the serdes PLL from an wellknown competitor doesn make that serdes more SATA compliant ASFAIK, Stratix-IIGX is not listing SATA as supported standard. LatticeSC is no listing SATA either. Info about Stratix-III and LatticeXP2 is not available yet. So there just isnt any FPGA silicon devices currently available at all fully confirming to SATA. If you use extenal SATA PHY, then the choice of FPGA is ir-relevant, any decent FPGA should be handle the SATA (after PHY layer) Antti
From: Antti Lukats on 27 Aug 2006 11:41 "Austin Lesea" <austin(a)xilinx.com> schrieb im Newsbeitrag news:44EF5DD5.5040502(a)xilinx.com... > Martin, > > SATA worked, but not when it used the spread spectrum clocking. There > was also some out of band signaling issues, where you needed a > transistor and a couple of resistors. > > So, it could be a point solution for a known drive that did not have > spread spectrum, but it was not able to deal with the the broad spectrum > of SATA product. > > Austin > Hi Austin, there is still a possibility to get V4FX or V5xxT MGTs to work with SATA gen 1 - the RX and TX MGTs are configured with 4 to 1 datawidht ratio and same ref clock, the RX is configured as full bypass with clock permanently disabled (V4 MGT new feature) . Those the RX would be running at at 6GBit/s, the RX CDR and PCS functions would have to be implemented in FPGA fabric. Not an easy task but doable. Antti
From: Falk Brunner on 27 Aug 2006 11:48 Antti Lukats schrieb: > there is still a possibility to get V4FX or V5xxT MGTs to work with SATA gen > 1 - the RX and TX MGTs are configured with 4 to 1 datawidht ratio and same > ref clock, the RX is configured as full bypass with clock permanently > disabled (V4 MGT new feature) . Those the RX would be running at at 6GBit/s, > the RX CDR and PCS functions would have to be implemented in FPGA fabric. > Not an easy task but doable. Hmm, maybe. But probably with a hell of logic ressources. If it would be easy, Xilinx would have implemented it into the hard macro, right? But I guess the world (of SATA) is not that bad. AFAIK the spread sprectrum clocking in OPTIONAL and is activated by a register in the drive. So the FPGA application can run fine without spread spectrum option (ok, a metal case will help to fight EMC problems) No big deal at all for me. Comming generations of FPGAs will support spread spectrum stuff. Regards Falk
From: fpga_toys on 27 Aug 2006 14:18
I'd first like to commend Antti for his professionalism this morning in making civil and respectful replies in this forum. It's very difficult to be forced to respond in kind, and dress down such a wonderful resource in this forum, simply because he got sucked into a pecking frenzy setup by Austin and Peter lack of civility in this forum. Antti Lukats wrote: > Now to the XUP V2Pro board, first of all this board is designed made by > digilent, so whatever is screwed up as you say with this board then its done > by digilent, and not Xilinx. With the XUP board the SATA is a little better > than with ML300 as the OOB fixup is added to the XUP (its missing on ML300) > see page 29 of the XUP board schematic. The XUP board AFAIK is a Xilinx board resold by Digilent, and probably other sources. The board does not have the Digilent name anywhere on it, and the documentation is all Xilinx documentation. I looked at all the available boards before making the choice to use this system to prototype this embedded controller contract. > So you should be also able to get SATA working on XUP. There isnt much ready > IP for that, thats another question. And if you are considering an > commercial product that has to pass __full__ compliance then I see no > alternatives as using a external SATA-PATA bridge, it save you both > development time and actual self cost of the product as well (relative cost > of the SATA IP in terms of % of the FPGA is hihger than the SATA-PATA IC). The terms for the RFQ require full SATA compatability and compliance, which Xilinx has clearly failed to provide at this point. Given Austin's whining, it's pretty clear Xilinx is offering a bait and switch, with no intent of joining SATA-IO and offering a fully certifiable solution for Xilinx designers. > And again, you can not blaime Xilinx in everything, sure it would be nice to > use MGTs for SATA, and a free SATA IP core would be nice too, but - if you > really read Xilinx documentation - they are no longer claiming MGTs to > handle SATA, so if you missed that, you cant legally say anyhing. Just bad > luck for you. Excuse me .... why not blame Xilinx for the gross missrepresentations in the XUP product? It's clearly their product ... their design (Xilinx Research Labs) and their missleading advertising and documentation. And it's clearly their failure to join SATA-IO if they are offering a SATA solution for Xilinx FPGA designers, and to make sure the documentation for these boards is complete, including the compliance failures. |