1. Home
  2. Field-Programmable Gate Arrays
  3. FPGA -> SATA?
  4. Page 3

FPGA -> 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.

Reply to
fpga_toys
Loading thread data ...

fpga snipped-for-privacy@yahoo.com schrieb:

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

Reply to
Antti

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.

Reply to
fpga_toys

Lets say Xilinx is a bit too optimistic about their devices every now and then.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

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:

Reply to
Austin Lesea

Then completely update the docs online to be specifically clear. Not hidden 67 pages in, a non-descript area, roughly fine print.

Reply to
fpga_toys

Beter yet, revise to docs to not call it SATA, but rather a Xilinx bit serial development prototype for testing protocols such as SATA.

Reply to
fpga_toys

fpga_toys,

The reason why SATA connectors are used in the XUP board is primarily to provide inexpensive high-speed connection between boards, either between

2 boards, or a number of boards in a ring. As the SATA leads are a commodity item, they are really inexpensive compared to other high-speed leads, and easy to get hold of around the world.

That said, its understandable that people see SATA and immediately think hard drives. We tried in the documentation to explain the difficulty of connecting to drives, for example, on page 67 of the user guide, we stated

The SATA specification requires an out-of band signalling state that is to be used when the channel is idle. This capability is not directly provided by the MGTs. Two resistors, an FET transistor, and two AC coupling capacitors along with special idle state control signals add the out-of-band IDLE state signaling capability to the MTGs. Additional off-board hardware can be required to properly interface to generic SATA disk drives.

I know this doesn't help your particular situation - you still have a very nice board, even if it doesn't work for your SATA project. Please drop me a line if you'd like to discuss this further - I'd be particularly interested in any thoughts you have on how we could have documented this better.

Phil

Reply to
Phil James-Roxby

Phil James-Roxby schrieb:

Phil,

the OOB workaround is on board. that fine, so basically it useable for SATA (if you are lucky and the drive is working in suitable for V2Pro manner)

but there is NO off-board hardware available that would connect to the SATA connector of XUP board and make the XUP to fully work with any generic SATA drive. Correct me if I am wrong about this.

there are many choices to make XUP board a SATA board

1) use add-on board with SATA PHY 2) use add-on board with SATA PATA bridge 3) use add-on board with PCI-SATA bridge 4) use add-on board with some other SATA bridge

but none of those solutions would use the SATA connectors that are on board.

sure SATA connectors are nice low cost connectors suitable for high speed transmittion, but if SATA connectors are added to any board for other intended use then SATA then this should be fully described and explained in the board documentation, what currently isnt the case.

latest manuals for at least, those boards ML300 XUP V2Pro ML405 ML410

all list that SATA is operational and useable, not stating that there are severe restrictions regarding the possible use, and that there are no workarounds available.

So all those documents should list something like:

SATA connectors can be used for custom protocols, and for SATA experiments with the SATA products that do not use spread spectrum.

additionally ML300 and XUP board documentation should read:

can only work with SATA drivers when the SATA drive bit clock initial error is less than +-150ppm (SATA spec is +-300ppm)

additionally ML300 documentation should read:

for SATA OOB signalling external add on circuitry is required.

without those additions to the manuals, some p***** off guy could get some lawer and sue Xilinx on false advertizing. I guess no one is so upset, and it would not pay off, but it would still nice to be clean as of not adertizing features that either can not be used, or can only be used with severe restrictions

Antti

Reply to
Antti

Hi Phil,

People have a right to get upset when you advertise/describe one thing, and deliver something completely different.

Consider selling 74LS02 chips and calling them PLD's or FPGA's.

Sure, you have a fine bit serial prototype bench, SATA shouldn't be anywhere in ANY document unless it's standard conforming product.

Reply to
fpga_toys

Just like Micro$oft is about its OS software.

--
 JosephKK
 Gegen dummheit kampfen die Gotter Selbst, vergebens.  
  --Schiller
Reply to
joseph2k

Hi Martin,

if you need some help please let me know. We are SATAIO member and very specialized in SATA.

I hope we can help.

--
Christian Kuehn

www.interelectronix.com

Professional SATA Solutions
Reply to
Sata Know How

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.