FPGA -> SATA?
in [FPGA]
|
From: fpga_toys on 28 Aug 2006 03:35 Antti wrote: > 1) XUP Board is *not* made by Xilinx, neither is Xilinx claiming it can > do SATA 1) title blocks on schematics ... Xilinx authorship/ownership 2) Reference manual ... Xilinx authorship/ownership 3) PCB artwork ... Xilinx authorship/ownership 4) Search RM for Digilent ... reference only compatability with Digilent boards. The unit does have Digilent compatable I/O ports, and may well have been designed under contract for Xilinx, but that does make it a Xilinx labeled Product that they claim ownership of, no matter who is building it for them. In fact, everything suggests it's actually a Xilinx Research Labs design instead ... specifically using Digilent I/O connectors for the University Program, to make it compatable with student board projects. And yes, I did finally find the statement on the bottom of page 67 in the reference manual which starts "the SATA specification requires an out of band signalling state that is to be used when the channel is idle. ... " Which means that since this is REQUIRED, and not provided the serial interfaces are NOT SATA, but simply have the same data rates and encoding ... not SATA which is a full system level specification. Using SATA everywhere to describe the interface, and not meeting the specification is simply bait and switch, substituting the Xilinx bit serial interconnect in it's place which just happens to be a non-compatable subset of the SATA standard. A parallel 16 bit data bus with control signals is not SCSI, unless it at least is capable of operating with the complete SCSI protocol ... anything short of that, and it's SASI, Pertec, or some other 16 bit bus, maybe even 16 bit ISA/EISA.
From: Antti on 28 Aug 2006 03:47 fpga_t...(a)yahoo.com schrieb: > Antti wrote: > > 1) XUP Board is *not* made by Xilinx, neither is Xilinx claiming it can > > do SATA > > 1) title blocks on schematics ... Xilinx authorship/ownership > 2) Reference manual ... Xilinx authorship/ownership > 3) PCB artwork ... Xilinx authorship/ownership > 4) Search RM for Digilent ... reference only compatability with > Digilent boards. > > The unit does have Digilent compatable I/O ports, and may well have > been designed under contract for Xilinx, but that does make it a Xilinx > labeled Product that they claim ownership of, no matter who is building > it for them. In fact, everything suggests it's actually a Xilinx > Research Labs design instead ... specifically using Digilent I/O > connectors for the University Program, to make it compatable with > student board projects. > > And yes, I did finally find the statement on the bottom of page 67 in > the reference manual which starts "the SATA specification requires an > out of band signalling state that is to be used when the channel is > idle. ... " > > Which means that since this is REQUIRED, and not provided the serial > interfaces are NOT SATA, but simply have the same data rates and > encoding ... not SATA which is a full system level specification. Using > SATA everywhere to describe the interface, and not meeting the > specification is simply bait and switch, substituting the Xilinx bit > serial interconnect in it's place which just happens to be a > non-compatable subset of the SATA standard. > > A parallel 16 bit data bus with control signals is not SCSI, unless it > at least is capable of operating with the complete SCSI protocol ... > anything short of that, and it's SASI, Pertec, or some other 16 bit > bus, maybe even 16 bit ISA/EISA. my mistake. somewhat I assumed the XUP board is designed by digilent (but digilent uses EAGLE cad tool and XUP board is made with professional CAD tool), or more precisly I assumed it is not designed by SEG. Well whatever it is, the copyright ownership is clearly owned fully by Xilinx so the responsibility is also at Xilinx. the OOB requirement - read my posts again and look again at page 29 of the schematic, the OOB requirement is OK, as the circuitry required for the OOB workaround for V2Pro is available. Means you can use XUP for SATA - the only constraint is that you can not claim full compliance as some drives will fail to be detected. Antti
From: fpga_toys on 28 Aug 2006 04:05 Antti wrote: > in any case - I can not and do not want to belive that Xilinx designed > boards with features knowing not to work (at the time of the board > design). I can, and do. I'm currently pissed about Austin's lost, totally insult, and the overt attempt to cover up the fact that they shipped FPGA's thru the XC2V and Pro series that trip over power problems for valid customer designs. That it's probably finally fixed in the XC4V and later parts is great ... ridiculing me as clueless when I bring up the point as a warning to someone getting ready to push a board to it's limits, is unethical to me. if they are willing to do this for FPGA chips, I have no trouble believing they would do it for board level products. Every time I have raised this issue for a year, Austin and Peter have let loose a scorched earth attack to suppress it, with full Xilinx managment support. Any customer design MUST be able to run with worst case data patterns without causing device upsets, or it WILL/MAY be unstable in the field under worst case voltage/temp/data patterns. I have spent far too many years constructing systems level diagnostics to debug this very problem in poor engineers designs that went into production. Either they leave the production floor stalled with failing product, or fail randomly in the field. To have a chip, which by DESIGN, has an unspecificed instability that is data/operation sensitive with power problems is HORRIBLE. Sure some designs, even a lot of designs, may work just fine. But what about the poor engineer that has chased these gremlins for months, without resolution ... or worse yet ... lost his job, or company because of it. Without clear, well defined Icc limits for a chip, and good software to accurately predict it with safe margins, it's impossible to design known stable large systems with Xilinx FPGA's. That has to include peak dynamic currents flowing a clock edge ... not rough averages over several clocks. Measuring "average systems" isn't enough, because it doesn't include worst case data patterns, which may not always be that easy to predict given that this software is free to combine and invert data internally to pack LUTs.
From: Nico Coesel on 28 Aug 2006 15:54 "Antti" <Antti.Lukats(a)xilant.com> wrote: > >in any case - I can not and do not want to belive that Xilinx designed >boards with features knowing not to work (at the time of the board >design). > Lets say Xilinx is a bit too optimistic about their devices every now and then. -- Reply to nico(a)nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nl
From: Austin Lesea on 28 Aug 2006 16:16
Nico, I think you said it pretty well. SATA was also a moving target. The standard had not yet been released when we were working on things. An attempt was made to be capable of testing things once the boards were available. As for the future, I have said that we are not SATA compatible now, and have no IP today, and that is true. I am saying nothing about the future, either immediate, or not so immediate. I am told that if you are serious about SATA, you should contact your Xilinx FAE. Austin Nico Coesel wrote: > "Antti" <Antti.Lukats(a)xilant.com> wrote: > >> in any case - I can not and do not want to belive that Xilinx designed >> boards with features knowing not to work (at the time of the board >> design). >> > > Lets say Xilinx is a bit too optimistic about their devices every now > and then. > |