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

Martin E. schrieb:

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

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

Antti wrote:
> Martin E. schrieb:
> 
>> 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
> 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
> 

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


"Austin Lesea" <austin@xilinx.com> wrote in message 
news:44EF5DD5.5040502@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
>
> Antti wrote:
>> Martin E. schrieb:
>>
>>> 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
>> 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
>> 

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.

Austin

Martin E. wrote:
> 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
> 
> 
> "Austin Lesea" <austin@xilinx.com> wrote in message 
> news:44EF5DD5.5040502@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
>>
>> Antti wrote:
>>> Martin E. schrieb:
>>>
>>>> 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
>>> 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
>>>
> 
> 

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

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.

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!)
>
> 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.

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

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

"PeteS" <PeterSmith1954@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@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl