Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 107300

Article: 107300
Subject: Re: What is the truth about the Virtex5 ?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 26 Aug 2006 09:31:12 -0700
Links: << >>  << T >>  << A >>
V5LX50 have been available for several months.
I don't want to get into a fight with your distributor, but he is
feeding you nonsense data.
Unless you want a peculiar combination of package-speed-temp range
there should be no problem getting many samples now.
If you have trouble, send me an e-mail. But I will be gone through
labor day, Sept 4.
Peter Alfke,  peter@xilinx.com
==========================
jeffnewcomb@nci-usa.com wrote:
> I questioned the availability of the Virtex5 back in July on this group
> and got some responses from Xilinx people saying it was being sampled
> and to get a sample I needed to get an order in immediately. I did that
> even though the parts were not even in distributors systems and the
> local Xilinx reps initially were not sure what delivery would be.  I
> did get a response back from the rep saying there was a 13 week
> delivery for an engineering sample which would be in late Sept. and you
> could not get production parts until next year. I could live with that
> and proceeded with my design using a V5LX50. Yesterday we got a FAX
> from our distributor /rep saying delivery of the engineering sample
> would not be until May 2007!!!. This is a full year after the part was
> anounced. I have seen numerous advertisements for the Virtex 5
> "Shipping NOW". Does anyone know the truth behind this part ???? Are
> there major problems with the part?


Article: 107301
Subject: Re: What is the truth about the Virtex5 ?
From: Kolja Sulimma <news@sulimma.de>
Date: Sat, 26 Aug 2006 18:35:17 +0200
Links: << >>  << T >>  << A >>
Peter Alfke schrieb:
> V5LX50 have been available for several months.
> I don't want to get into a fight with your distributor, but he is
> feeding you nonsense data.

Distributors like to do that to small companies....
:-(

Kolja Sulimma

Article: 107302
Subject: Re: FPGA -> SATA?
From: Peter Wallace <pcw@karpy.com>
Date: Sat, 26 Aug 2006 09:39:36 -0700
Links: << >>  << T >>  << A >>
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 = x@y.com
> 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

Article: 107303
Subject: Re: fastest FPGA
From: "rickman" <gnuarm@gmail.com>
Date: 26 Aug 2006 09:40:42 -0700
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:
> Replacing LUT SRL's with LUT RAM's certainly helps by removing the SRL
> bit shifting power, but doesn't lower the design toggle rates below 50%

I don't understand this.  LUT SRL's are not shift registers if I
understand them correctly.  They don't move the data, they move the
pointer.  So the only power used is in the internal address counter and
the writing of the data to one cell in the LUT.  Is that really so much
power?  If you use the LUTs as RAM and make your own counter, I expect
the power per shift register is actually higher at that point.


Article: 107304
Subject: Re: Why isn't there a thermal diode on large FPGAs?
From: Peter Wallace <pcw@karpy.com>
Date: Sat, 26 Aug 2006 09:43:52 -0700
Links: << >>  << T >>  << A >>
On Thu, 24 Aug 2006 12:36:56 -0700, PeteS wrote:

> A recent thread went over the maximum permitted power on a device.
> 
> So why don't we have a sensing diode (well, a transistor with collector
> tied to base works better) on the die somewhere? It's fairly easy to do,
> according to my VLSI acquaintances, and with faster and faster IO
> [implying as it does faster and faster logic switching as well], it
> would make sense to see these on any largescale (more than 100 pins
> perhaps) FPGA package.
> 
> Comments?
> 
> Cheers
> 
> PeteS
 
A little awkward but what about forward biasing one of the input
protection diodes with a mA or so?

Peter Wallace

Article: 107305
Subject: Re: FPGA -> SATA?
From: fpga_toys@yahoo.com
Date: 26 Aug 2006 09:52:31 -0700
Links: << >>  << T >>  << A >>
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.


Article: 107306
Subject: Re: fastest FPGA
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 26 Aug 2006 10:03:14 -0700
Links: << >>  << T >>  << A >>
Rickman, the SRL16 (or SRL32 in Virtex-5) really is a "physical" shift
register that transfers all data bits to their respective neighbors. So
it will probably consume more power than a pointer-addressed RAM.
But you don't need the pointer, and it's also a neat way to load a LUT
with its 16 bits.
Peter Alfke
==================
rickman wrote:
> fpga_toys@yahoo.com wrote:
> > Replacing LUT SRL's with LUT RAM's certainly helps by removing the SRL
> > bit shifting power, but doesn't lower the design toggle rates below 50%
>
> I don't understand this.  LUT SRL's are not shift registers if I
> understand them correctly.  They don't move the data, they move the
> pointer.  So the only power used is in the internal address counter and
> the writing of the data to one cell in the LUT.  Is that really so much
> power?  If you use the LUTs as RAM and make your own counter, I expect
> the power per shift register is actually higher at that point.


Article: 107307
Subject: Re: FPGA -> SATA?
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 26 Aug 2006 10:06:34 -0700
Links: << >>  << T >>  << A >>
Nico Coesel wrote:
> "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

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


Article: 107308
Subject: Re: FPGA -> SATA?
From: "rickman" <gnuarm@gmail.com>
Date: 26 Aug 2006 10:08:07 -0700
Links: << >>  << T >>  << A >>
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?


Article: 107309
Subject: Re: fastest FPGA
From: "rickman" <gnuarm@gmail.com>
Date: 26 Aug 2006 10:09:53 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Rickman, the SRL16 (or SRL32 in Virtex-5) really is a "physical" shift
> register that transfers all data bits to their respective neighbors. So
> it will probably consume more power than a pointer-addressed RAM.
> But you don't need the pointer, and it's also a neat way to load a LUT
> with its 16 bits.

I wasn't aware of that.  Is this only true for the V5 parts, or has
this always been true for SRLs in Xilinx parts that have them?


Article: 107310
Subject: Re: Xilinx FPGA editor error ISE8.2
From: yttrium <yttrium@telenet.be>
Date: Sat, 26 Aug 2006 19:18:56 +0200
Links: << >>  << T >>  << A >>
Tim Verstraete wrote:
> Hey,
> 
> I just updated to ISE8.2SP2 but still the same issue ...
> 
> i started debugging the issue and found that for some reason it has a
> problem with the IFF1:\#FF\ statement and still Xilinx makes the same
> attribute when i use the records script option and do the  changement
> manually? i've mailed to my FAE just in case ...
> 
> thanks for the feedback,
> 
> kind regards,
> 
> Tim
> 
> John_H schreef:
> 
>> I don't have an answer, but a suggestion:  break the config into its parts.
>> If you set the Config IFF1 in one line and Config INIT_Q4 in another - just
>> one per line - you might find out what "really" fails.
>>
>> If I had to guess I'd think the line length in your command is a problem.
>> Breaking it up eliminates this issue and can let you debug the problem to
>> its core.
>>
>>
>> "yttrium" <yttrium@telenet.be> wrote in message
>> news:%RHGg.127097$YS7.119815@blueberry.telenet-ops.be...
>>> Hey, when i run a script through FPGA editor i get the following error:
>>>
>>> setattr comp
>>> c_DDR2_framebuffer_0/c_Ddr2Interface/i_DDR/i_DdrInputOutput_DataEvenFromSdr_d(2)
>>> Config CE1INV:CE1\ CLKDIVINV:CLKDIV\ CLKINV:CLK\ IDELAYMUX:1\ IFF1:\#FF\
>>> IFFDELMUX:0\ IFFMUX:1\ INIT_Q1:0\ INIT_Q2:0\ INIT_Q3:0\ INIT_Q4:0\
>>> IOBDELAY_TYPE:VARIABLE\ IOBDELAY_VALUE:0\ Q1MUX:IFF3\ Q2MUX:IFF4
>>> ERROR:FPGAEditor:25 - "CE1INV:CE1 CLKDIVINV:CLKDIV CLKINV:CLK IDELAYMUX:1
>>> IFF1:\#FF IFFDELMUX:0 IFFMUX:1 INIT_Q1:0 INIT_Q2:0 INIT_Q3:0 INIT_Q4:0
>>> IOBDELAY_TYPE:VARIABLE IOBDELAY_VALUE:0 Q1MUX:IFF3 Q2MUX:IFF4" is not a
>>> valid value for the Config attribute.  BRBCF ILOGIC Failure: INVALID_RB:
>>> "IFF1::\#FF" CFG: "CE1INV:CE1 CLKDIVINV:CLKDIV CLKINV:CLK IDELAYMUX:1
>>> IFF1:\#FF IFFDELMUX:0 IFFMUX:1 INIT_Q1:0 INIT_Q2:0 INIT_Q3:0 INIT_Q4:0
>>> IOBDELAY_TYPE:VARIABLE IOBDELAY_VALUE:0 Q1MUX:IFF3 Q2MUX:IFF4"
>>>
>>> even when i make this change manually and then save and record this a
>>> script and then run it, it gives me that error. So when FPGA editor
>>> generates the following statement:
>>>
>>> setattr comp
>>> c_DDR2_framebuffer_0/c_Ddr2Interface/i_DDR/i_DdrInputOutput_DataEvenFromSdr_d(2)
>>> Config CE1INV:CE1\ CLKDIVINV:CLKDIV\ CLKINV:CLK\ IDELAYMUX:1\ IFF1:\#FF\
>>> IFFDELMUX:0\ IFFMUX:1\ INIT_Q1:0\ INIT_Q2:0\ INIT_Q3:0\ INIT_Q4:0\
>>> IOBDELAY_TYPE:VARIABLE\ IOBDELAY_VALUE:0\ Q1MUX:IFF3\ Q2MUX:IFF4
>>>
>>> and that one is exactly the same as the one in my script then what am i
>>> doing wrong??? to get me that answer?
>>>
>>> Thanks in advance for your help,
>>>
>>> kind regards,
>>>
>>> Tim
> 


I have found that you should write IFF1:FF instead of IFF1:\#FF\ ... 
only the Xilinx tools also write the second version instead of the first 
one ... so if you just correct this one it works fine again ...

thanks for the feedback anyway...

Article: 107311
Subject: adiabatic and reversible computing with FPGAs?
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 26 Aug 2006 19:19:55 +0200
Links: << >>  << T >>  << A >>
Is it possible to use adiabatic computing with today FPGAs? It uses less
power by stretching the time for loading capacitors and uses LC tanks for
energy storage:

http://www.eecs.umich.edu/acal/energyrecovery/papers/soc03.pdf

The ultimate power reduction would be to use reversible computing:

http://en.wikipedia.org/wiki/Reversible_computing

because in theory the energy dissipation is zero. You can use the Fredkin
gate as the base gate for implementing all logics:

http://en.wikipedia.org/wiki/Fredkin_Gate

which can be implemented with collision-based computing, like the billiard
ball model:

http://tinyurl.com/gbarb

But how can this be implemented in ICs? Some ideas are presented in this
article and one implementation of the Fredkin gate with collision-based
computing elements:

http://www.zyvex.com/nanotech/helical/helical.html

Are there any plans from the major FPGA vendors to incorporate some of
these ideas in their devices?

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 107312
Subject: Re: FPGA -> SATA?
From: fpga_toys@yahoo.com
Date: 26 Aug 2006 10:22:29 -0700
Links: << >>  << T >>  << A >>

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.


Article: 107313
Subject: Re: DCM vs. PLL
From: yttrium <yttrium@telenet.be>
Date: Sat, 26 Aug 2006 19:38:14 +0200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Oops,
> 
> You still need to have the X7 clock, the the ISERDES does all the work.
> 
> Austin
> 
> Austin Lesea wrote:
>> Antti,
>>
>> Thank you.  Yes, it does look like this is a X7 deserializer.  In which
>> case the cheapest, fastest and easiest may be to just buy the ASSP that
>> was designed to do that job.
>>
>> I still think that V4 could also do this without any need for the ASSP
>> as the SSIO features include X7 sampling, without having to mutliply the
>> clock.
>>
>> http://direct.xilinx.com/bvdocs/userguides/ug070.pdf
>> page 355
>>
>> Austin
>>
>> Antti wrote:
>>> Austin Lesea schrieb:
>>>
>>>> Rob,
>>>>
>>>> Here goes,
>>>>
>>>> See below:
>>>>
>>>> Austin
>>>>
>>>> -snip-
>>>>> Serious question:  Does Altera's PLL's offer an advantage (veratility,
>>> [snip]
>>>> I am confused, however, the 45 MHz ports should be trivial, and won't
>>>> even require a DCM.  It is the 315 MHz ports that will make use of the
>>> Austin,
>>>
>>> the OP desing looks very much like CameraLink.
>>>
>>> so the incoming clock would be multiplied by x7 to get bit clock.
>>>
>>> it is doable with Virtex and DCM, but for what I would suggest
>>> (if it is CameraLink) is still to use the dedicated deserializer.
>>>
>>> if you look at Virtex boards with Cameralink support than most
>>> of them (but not all) have dedicated serializers.
>>>
>>> of course if it not Cameralink (or those deserializers can not
>>> be used) then it has to be checked if it makes sense to
>>> use only virtex LVDS + DCM or have external circutry too.
>>>
>>> Antti
>>> http://xilant.com
>>>

why not use the x3.5 clock and then use a DDR FF at the input => lower 
clock frequency, we use this all the time in video processing units ...

xilinx even has a core for it: 
<http://www.xilinx.com/bvdocs/appnotes/xapp265.pdf>


Article: 107314
Subject: Re: fastest FPGA
From: fpga_toys@yahoo.com
Date: 26 Aug 2006 10:51:01 -0700
Links: << >>  << T >>  << A >>

JustJohn wrote:
> Now I'm totally confused TC. What does "highly random" data mean? Data
> with a 75% toggle rate is halfway towards the ultimate pathological
> case of "0101010101...". To me, highly random data implies a fairly
> flat distribution with a 50% average toggle rate, period. If any given
> flop has a 50% chance of toggling on any given clock cycle, your
> summation seems to imply that some flops (or srl cells) are toggling
> twice per cycle. That's a neat trick, and I don't get it.

yep ... my error ... was tired and starting thinking in terms of run
probability which is clearly wrong.

I should have simply stood on my real concern, which is for bit serial
machines, they will have worst case data from time to time, or even
more likely near worst case data, and have to eat the power for that
state for a word length of clocks. Which means, the power system needs
to be able to deliever worst case power for a word latency, or get a
power rail "THUMP" and reset, or worse, corrupted data.

> The caustic expletives
> don't help your cause, and really puts folks off here.

you are right ... and at the same time, my tollerance for Austin and
Peter is near zero, when they assert things on reputation and their
employers name, that are direct personal attacks. I'll be nice and mind
my language better.

My respect level for Xilinx is at a near all time low.


Article: 107315
Subject: Re: FPGA -> SATA?
From: fpga_toys@yahoo.com
Date: 26 Aug 2006 11:12:19 -0700
Links: << >>  << T >>  << A >>

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.


Article: 107316
Subject: Re: FPGA -> SATA?
From: fpga_toys@yahoo.com
Date: 26 Aug 2006 11:21:41 -0700
Links: << >>  << T >>  << A >>

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.


Article: 107317
Subject: Re: Why isn't there a thermal diode on large FPGAs?
From: Austin Lesea <austin@xilinx.com>
Date: Sat, 26 Aug 2006 11:39:12 -0700
Links: << >>  << T >>  << A >>
Peter,

It is the substate to s,d pn junction, but it does not resemble the 
1N914 that is the "standard" for measuring temperature.

I have no idea if it would work, or not.

Before we had temp diode, people would calibrate the frequency shift on 
a ring oscillator, with nothing else in the part, forcing the temperature.

Then, with the design running, all you had to do was measure the 
frequency of the ring oscillator to get a reading.

Since the temp diode, the ring oscillator method has been abandoned.

Austin

Peter Wallace wrote:

> On Thu, 24 Aug 2006 12:36:56 -0700, PeteS wrote:
> 
> 
>>A recent thread went over the maximum permitted power on a device.
>>
>>So why don't we have a sensing diode (well, a transistor with collector
>>tied to base works better) on the die somewhere? It's fairly easy to do,
>>according to my VLSI acquaintances, and with faster and faster IO
>>[implying as it does faster and faster logic switching as well], it
>>would make sense to see these on any largescale (more than 100 pins
>>perhaps) FPGA package.
>>
>>Comments?
>>
>>Cheers
>>
>>PeteS
> 
>  
> A little awkward but what about forward biasing one of the input
> protection diodes with a mA or so?
> 
> Peter Wallace

Article: 107318
Subject: Re: FPGA -> SATA?
From: John_H <johnhandwork@mail.com>
Date: Sat, 26 Aug 2006 18:45:22 GMT
Links: << >>  << T >>  << A >>
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.

Article: 107319
Subject: Re: fastest FPGA
From: John_H <johnhandwork@mail.com>
Date: Sat, 26 Aug 2006 18:48:19 GMT
Links: << >>  << T >>  << A >>
rickman wrote:
> Peter Alfke wrote:
>> Rickman, the SRL16 (or SRL32 in Virtex-5) really is a "physical" shift
>> register that transfers all data bits to their respective neighbors. So
>> it will probably consume more power than a pointer-addressed RAM.
>> But you don't need the pointer, and it's also a neat way to load a LUT
>> with its 16 bits.
> 
> I wasn't aware of that.  Is this only true for the V5 parts, or has
> this always been true for SRLs in Xilinx parts that have them?

SRLs have been actual shift registers for quite some time.  A recent 
discussion pointed out that the Pre-V5 SRLs shifted charge from one 
memory cell to the next (I'm assuming like a CCD) but this "trick" 
didn't scale well beyond 90 nm so the V5 parts use master/slave latches 
to halve the number of available elements in the SRLs.

SRLs physically have a Din and a MUX out with a Dout optionally 
available to extend the SRL length.

Article: 107320
Subject: Re: Why isn't there a thermal diode on large FPGAs?
From: Gerhard Hoffmann <spamtrap@dk4xp.de>
Date: Sat, 26 Aug 2006 21:05:44 +0200
Links: << >>  << T >>  << A >>
On Thu, 24 Aug 2006 13:18:37 -0700, Austin Lesea <austin@xilinx.com> wrote:

>The heatsinking has to be able to remove the heat such that the 85C
>(commercial) or 100 C (industrial) junction temperature is not exceeded,

Junction or case?


regards, Gerhard

Article: 107321
Subject: Re: FPGA -> SATA?
From: "rickman" <gnuarm@gmail.com>
Date: 26 Aug 2006 12:17:27 -0700
Links: << >>  << T >>  << A >>
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.


Article: 107322
Subject: Re: FPGA -> SATA?
From: fpga_toys@yahoo.com
Date: 26 Aug 2006 12:34:04 -0700
Links: << >>  << T >>  << A >>

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?


Article: 107323
Subject: Re: fastest FPGA
From: "rickman" <gnuarm@gmail.com>
Date: 26 Aug 2006 12:45:19 -0700
Links: << >>  << T >>  << A >>
John_H wrote:
> rickman wrote:
> > Peter Alfke wrote:
> >> Rickman, the SRL16 (or SRL32 in Virtex-5) really is a "physical" shift
> >> register that transfers all data bits to their respective neighbors. So
> >> it will probably consume more power than a pointer-addressed RAM.
> >> But you don't need the pointer, and it's also a neat way to load a LUT
> >> with its 16 bits.
> >
> > I wasn't aware of that.  Is this only true for the V5 parts, or has
> > this always been true for SRLs in Xilinx parts that have them?
>
> SRLs have been actual shift registers for quite some time.  A recent
> discussion pointed out that the Pre-V5 SRLs shifted charge from one
> memory cell to the next (I'm assuming like a CCD) but this "trick"
> didn't scale well beyond 90 nm so the V5 parts use master/slave latches
> to halve the number of available elements in the SRLs.
>
> SRLs physically have a Din and a MUX out with a Dout optionally
> available to extend the SRL length.

I thought the reason that SRLs were added was that they took little
extra resources.  This sounds like it requires significantly more logic
in the LUT.  But I guess the utility of the feature has allowed it to
be practical in spite of the increased complexity.


Article: 107324
Subject: Re: fastest FPGA
From: fpga_toys@yahoo.com
Date: 26 Aug 2006 12:46:43 -0700
Links: << >>  << T >>  << A >>

Peter Alfke wrote:
> I almost threw up when I read John Bass explain how he uses a
> deliberately dumb-sounding name plus naive questions to light some fire
> and create controversial flames.
>
> Really destroys my enthusiasm for this newsgroup.
> It's like a rich guy pretending to be homeless, and then hitting you in
> the groin while you are reaching for your wallet. Scum is the word
> describing that kind of behavior...

A better analogy, is that you and Austin have been having great fun
kicking the homeless, and are pissed because you got busted for assault
by an undercover cop.

It's never fair to shoot down someones statements with a totally lost,
clueless assertion unless you also make the effort to defend that
statement with a sound reasoned argment.

Trashing someone, on your reputation alone, or Xilinx's reputation
alone is simply calling them clueless because you and Xilinx say they
are, to hide the failings in your product line.




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search