FPGA -> SATA?

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 = snipped-for-privacy@y.com where: x = "martineu" y = "pacbell.net"

Reply to
Martin E.
Loading thread data ...

Martin E. schrieb:

Hi Martin,

good question :)

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)

ASFAIK those issues are no longer present with V4FX that should be fully SATA compliant without external workarounds. So you can just get the ML410 and start working :)

sure you would still need the IP core from some vendor though

Antti

Reply to
Antti

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.

Aust> Martin E. schrieb:

Reply to
Austin Lesea

We are designing with a V2P30 right now for migration to an equivalent V5 Q1'07. The SATA solution won't be needed until early next year. Would V5 work then?

Also, is SATA IP commercially available?

I guess an alternative might be to go PCI X/e and then use an off-the shelf SATA controller that talks to PCI. The problem is that I need lots of drives in parallel (I do mean LOTS) for this application. It'd be easier to hang them right off an FPGA with a PHY (which seem to be impossible to get).

Thanks,

-Martin

Reply to
Martin E.

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.

Aust> We are designing with a V2P30 right now for migration to an equivalent V5

Reply to
Austin Lesea

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

Reply to
Jim Granville

And like Xilinx isn't equally protective and prolific with FPGA patents?

Maybe Xilinx just needs to join the ASSP group, license some technology, and quit bitching.

Reply to
fpga_toys

Austin Lesea wrote:

Ok ... I took the time to see who the little guys are at SATA-IO that Austin claims are running completely scared of the 'big bad FPGA vendors'. Frankly, when I read down the list, it becomes pretty obvious many of the players could aquire Xilinx with a day or two's free profits and not even worry about the investment costs if they paid twice what Xilinx was worth.

The only two things obvious, is that Austin's/Xilinx's head is so full of shit if they think half these companies even care what Xilinx does with SATA, and that Xilinx is so full of NIH that they are failing to meet custmers needs by refusing to play nicely inside the industry wide SATA club.

Anybody spot those that Austin claims "are running completely scared of the 'big bad FPGA vendors'."????

ACARD Technology Corporation Accusys Adaptec, Inc. Addonics Technologies Adtron Corporation Aeluros, Inc. Agere Systems Agilent Technologies, Inc. Allion Computer Inc. Alta Engineering AMCC (3ware) AMD Aska Technologies Inc. ATI Avery Design Systems Bell Microproducts BiTMICRO Networks BizLink Broadcom Buffalo Inc. Catalyst Enterprises Inc. CEVA CI Design Circuit Assembly Corp. Comax Technology, Inc. CRU-DataPort CRUZ Systems Dallas Semiconductor, Inc. DataStor Technology Co., Ltd. Dell Denali Software, Inc. Der An Electric Wire & Cable Co., Ltd DoTop Technology, Inc. Ease Software, Inc. Electronics Testing Center, Taiwan Emulex Corporation Epson Research & Development, Inc. EqualLogic Exar Corporation Expert I/O Faraday Technology Corporation FCI Finisar FirmTek, LLC Foxconn Electronics Fujikura/DDK Fujitsu Computer Products of America Fujitsu-Siemens Computers Genesys Logic, Inc. Golden Bridge Electech Inc. Hewlett-Packard Highly Reliable Systems HighPoint Technologies, Inc. Hitachi Global Storage Technologies Hitachi-LG Data Storage Korea, Inc. Horng Tong (HOMETOM) Enterprise Co., Ltd. IBM Corporation IIX Consulting Infineon Technologies Infortrend Technology, Inc. Initio Corporation Intel Corp. Intella Sys Corp. IntelliProp Inc. Interelectronix Iomega JAE Electronics Jalink Technology Inc. Jei Wei Electronic Co., Ltd. JMicron Technology Corp. Joinsoon Electronics Mfg. Co. Ltd. J.S.T. Mfg. Co., Ltd. Kano Technologies Kawasaki Microelectronics, Inc. KnowledgeTek, Inc. Knowlent Corporation LeCroy Corp. LaCie Landwin Electronic Corp. Link-A-Media Devices LITE-ON Technology Corp. Longwell LSI Logic LyCOM Technology, Inc. Marvell Semiconductor, Inc. Maxtor MediaTek Inc. Mentor Graphics Microsoft Mitac International Corporation Molex, Inc. M-Systems NEC Electronics Corporation Netcell Corp. Niketech Northstar Systems Corp. Nvidia Corporation Omneon Video Networks Oxford Semiconductor Ltd. Quantum Corp. Panasonic Semiconductor PDE Technology Corporation PHILIPS & BenQ Digital Storage Corporation Philips Semiconductors Pioneer Corporation Plextor Corp. PMTC NV Prolific Technology, Inc. Promise Technology, Inc. ProStor Systems, Inc. P-TWO Industries Inc. Rapid Conn RATOC Systems, Inc. Realtek Renesas Technology RITEUP Co., Ltd. ROHM Co., Ltd. Samsung Electronics Sanko Electronics Co., Ltd. Seagate Technology Scientific Atlanta Sierra Logic, Inc. SIIG, Inc. Silicon Image Inc. Silicon Integrated Systems Corp SiliconStor, Inc. SimpleTech SMK Corporation Soft Mixed Signal Corporation Sonnet Technologies, Inc. Space Shuttle Hi-Tech Co., Ltd. STMicroelectronics Sunext Technology Sun Microsystems, Inc. Sunplus Technology Co. Ltd. Synthesys Research, Inc. Synopsys Taiwan Electronics Co., Ltd. Tektronix Top Yang Technology Enterprise Co., Ltd. Toshiba Total Technologies, Ltd. Trimax Electronics Co., Ltd. Tyco Electronics ULi Electronics Inc. ULINK Technology University of New Hampshire InterOperablitity Lab Via Technologies Inc. Vitesse Semiconductor Corp. VMC Consulting VSO Electric Co, Ltd. Wavecrest Western Digital Corp. Wieson Technologies Co., Ltd. Win Win Precision, Co., Ltd. Wipro Limited Y.C. Cable USA, Inc. Zarlink

Reply to
fpga_toys

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

Reply to
PeteS

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@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

Nico Coesel schrieb:

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

Reply to
Antti

[snip] Dear Mr Brass!

What has the World done to You? Did you lost your grannys savings in Xilinx stock or your own balls in the supermarket !?

Some free advice to you:

1) go fly a kite 2) rent a movie titled "Joe vs Volcano", watch it, to the very end 3) think twice before claiming to know the contents of the heads of the others

-------------

The ASSP vendors are very likely not directly scared, but for some reason almost every document regarding SATA IC's is only available under NDA and SATA PHY silicon is virtually impossible to obtain. The most reasonable use of SATA PHY would be an FPGA based product. As for the ASIC designs it makes more sense to integrate the PHY on chip. So for me its pretty much clear why SATA PHYs are not available, the same Silicon/IP vendors are also selling SATA IP, and selling bare SATA PHY as IC (to be possible be used with an FPGA) would make their possible earnings from ASSP and ASIC IP sales smaller. So some small guys are defenetly looking at FPGA vendors.

Antti, who just returned from "flying the kite"

Reply to
Antti Lukats

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

Reply to
Peter Wallace

Antti .... what you say would be true IF and ONLY IF the SATA-IO was a closed organization to FPGA vendors, such that the NDA was part of a deliberate means to exclude ALL FPGA vendors.

However, the opposite is true ... Every FPGA vendor is certainly free to join SATA, and to licence the SATA technology, just as the ASSP vendors are .... making access to the NDA material equal access between both FPGA vendors and ASSP vendors.

So the exclusive rights conspiracy theory presented by both you and Austin is a piece of crap. And as far as I can tell both of you have your heads in the clouds flying kits, and need to get your head back on the ground and learn how to COOPERATE with people rather than complain that others can band together as the SATA-IO organization and actually produce a usable industry wide standard that is available for license to all cooperating members participating in that standards process.

Reply to
fpga_toys

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

Reply to
PeteS

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?

Reply to
rickman

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.

Reply to
fpga_toys

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.

Reply to
fpga_toys

Both YOU and Austin are crazy to assert the ASSP's are blocking access to SATA-IO membership. By joining Austin's conspiracy theory, you violate this very rule of yours.

Frankly, when I read down the SATA-IO membership list, I see a large number of companies that should actually prefer the FPGA vendors were part of the standards process and shipping SATA enabled FPGA's. Even some of the ASSPs, since that would provide a prototype path to their volume production.

Reply to
fpga_toys

You are correct that the energy transmitted is the same. The test equipment isn't fooled: it still reads the same energy. The trick is that the energy is spread over a larger bandwidth. The higher the harmonic, the wider the bandwidth and the lower the maximum power since the energy is constant in that harmonic. While 30 kHz might not seem like a "wide" bandwidth for interference purposes, when is interference noticed above noise? Typically when it's rather narrow-band. 30 kHz isn't broad, but it isn't narrow-band. The interference should appear as a degraded noise floor but with no narrow band troubles.

The application will tell you if the increased noise floor is a problem. For the case of self interference in a radio, a degraded noise floor will degrade the performance when highest sensitivity is needed but the annoying tones won't be there.

Reply to
John_H

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.