FPGA Central

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 = [email protected]
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" <[email protected]> wrote in message
news:[email protected]..
> 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" <[email protected]> wrote in message
> news:[email protected]..
>> 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" <[email protected]> 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

Nico Coesel schrieb:

> "PeteS" <[email protected]> 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

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

<[email protected]> schrieb im Newsbeitrag
news:[email protected] oups.com...
> 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'."????
>
[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"

On Fri, 25 Aug 2006 12:41:38 -0700, Martin E. wrote:

> 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 = [email protected]
> where:
> x = "martineu"
> y = "pacbell.net"

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

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.

Nico Coesel wrote:
> "PeteS" <[email protected]> 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

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

PeteS wrote:
> 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.

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?

rickman wrote:
> 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.

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.

rickman wrote:
> 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.

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.

Antti Lukats wrote:
> 3) think twice before claiming to know the contents of the heads of the
> others

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.

rickman wrote:
> PeteS wrote:
>> 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.
>
> 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.

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.

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

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.

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

Ignoring all the paranoid nonsense that is being posted about this, I
was able to Google search and find at least one potential PHY from
Atmel, the AT78C5091. They have a summary data sheet although I don't
see a full sheet. They provide a contact which I assume means they
will only sell it if you are interested in high volumes.

It may well be that external PHY chips are not used because of the high
power or the high data rate. It would be a lot cheaper and lower power
to integrate the PHY into your controller chip.

John_H wrote:
> 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.

ummm ... yes and no. The test equipment has a specific bandwidth
(either from front end filters, or from FFT resolution) and a specific
integration time, both of which can be, and are likely to be, affected
by the spread spectrum effects.

The mV/m^2 remains the same, it's just time shifted across the 30KHz
bandwidth, with the assumption that is less evil. Which is the case for
signals that are integrated at 15KHz and below. At the reciever, the
MV/m^2 power from all sources is summed. Without spread spectrum, two
interference sources would have to have the same frequency to sum. With
spread spectrum they sum if within 30KHz of each other (or whatever the
spreading bandwidth is).

However, for data rate signals with symbol times greater than 30KHz,
the symbol decoder is integrating at a much faster rate, and the 30KHz
shift is a full power interference for one or more symbol times.

For recievers which are wide band, such as most data modems, the 30KHz
shift keeps the same mV/m^2 energy completely inside the channel that
is a MHz wide or two. The spread spectrum doesn't reduce the
interference at all, and may actually make it worse by additively being
integrated with non-spread spectrum narrow channel power sources,
taking the peak power at a specific frequency above what the reciever
can reject.

or, Did I miss something?

"rickman" <[email protected]> schrieb im Newsbeitrag
news:[email protected] oups.com...
> 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).
>
> Ignoring all the paranoid nonsense that is being posted about this, I
> was able to Google search and find at least one potential PHY from
> Atmel, the AT78C5091. They have a summary data sheet although I don't
> see a full sheet. They provide a contact which I assume means they
> will only sell it if you are interested in high volumes.
>
> It may well be that external PHY chips are not used because of the high
> power or the high data rate. It would be a lot cheaper and lower power
> to integrate the PHY into your controller chip.
>
oh there are "product briefs" for SATA PHY's available from many different
vendors.
but have you ever tried to purchase a SATA PHY IC? try! and let us know if
you succeed!

Antti

Antti Lukats wrote:
> "rickman" <[email protected]> schrieb im Newsbeitrag
> news:[email protected] oups.com...
> > 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).
> >
> > Ignoring all the paranoid nonsense that is being posted about this, I
> > was able to Google search and find at least one potential PHY from
> > Atmel, the AT78C5091. They have a summary data sheet although I don't
> > see a full sheet. They provide a contact which I assume means they
> > will only sell it if you are interested in high volumes.
> >
> > It may well be that external PHY chips are not used because of the high
> > power or the high data rate. It would be a lot cheaper and lower power
> > to integrate the PHY into your controller chip.
> >
> oh there are "product briefs" for SATA PHY's available from many different
> vendors.
> but have you ever tried to purchase a SATA PHY IC? try! and let us know if
> you succeed!

Atmel has three devices on their HDD page and I am confident that they
offer them for sale. I expect that if I wanted to buy a million they
would be readily available. The OP did not say how many he expects to
use so I am just providing a potential source. What they cost will
depend on how many he wants.

rickman wrote:
> Atmel has three devices on their HDD page and I am confident that they
> offer them for sale. I expect that if I wanted to buy a million they
> would be readily available. The OP did not say how many he expects to
> use so I am just providing a potential source. What they cost will
> depend on how many he wants.

Guess I'll have to go look into that as well. I was going to bid an
SATA controller design based on the mistaken assumption that since the
XUP Virtex-II Pro board had SATA interfaces, that it would be
relatively easy to include in the design. Even picked up one of these
expensive XUP development systems to prototype it with. Let's just say
that this insight was timely, and after the whining by Austin/Antti
about the SATA-IO NDA's it's about time to cut my losses with Xilinx
and pickup some Altera software and development boards. I'm getting
real tired of wasting money on Xilinx products which do not work.

Maybe Altera will listen to this, join SATA-IO and license the IP for
it's next product turn.