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 42675

Article: 42675
Subject: Re: Xilinx Easypath- Selling parts with known defects
From: mrand@my-deja.com (Marc Randolph)
Date: 30 Apr 2002 13:27:38 -0700
Links: << >>  << T >>  << A >>
Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3CCEAECB.C40196E9@xilinx.com>...


Let me preface my message by saying that I use, and have used, and
will continue to use, Xilinx for many applications.  I've been very
happy with the abilities of their hardware both from a standpoint of
being moderately intutive and being able to absorb changes later that
weren't anticipated (although I have to admit pretty strong annoyance
with their SLOW and buggy software release after software release).

That being said... let me respond to Austin's email.  I was going to
leave this thread alone, but Austin keeps pressing the issue...

> I think everyone is missing the beauty of the EasyPath program.

Perhaps *everyone* is not missing it - rather you've bought into your
own marketing BS a little too much?  You wouldn't be the first, nor
the last.  Hell, I bought into the market BS of my previous company
all the way to it cancelling the project.

> We run lots of silicon to a specific customer test program, and the yield for
> just that functionality is good so that we can offer the parts at a price
> competitive with the price of an ASIC.

This is plain absurd.  Easypath is not the end-all be-all that Xilinx
makes it out to be.  There is *almost* no way you can compete with a
custom designed ASIC.  There are a number of reasons for this, and
I'll outline a few:

1. A custom ASIC die will always be smaller because it doesn't have to
have all that unused logic and memory
2. A custom ASIC package will sometimes be smaller (lower I/O count)
because you aren't forced to pick from Xilinx's choices
3. Because of the above two items, the piece price on the ASIC will
usually be cheaper
4. A custom ASIC will typically burn less power, because of #1 above -
and this is even when it is running 1.8V rather than 1.5V...
-or-
4. A custom ASIC can be designed to whatever voltage(s) you have
available so that you don't have to buy a 1.5V supply because the
Virtex2 parts are the only thing running 1.5 volts.
5. Put items #2 and #4 together, and you can have a higher density
product than you could have with EasyPath parts
6. Put #3 and #5 together and you now have some profit margin for your
company, rather than giving your profit margin to Xilinx for the
EasyPath parts.
7. Despite Xilinx showing that they can run incredibly high
frequencies through their parts, when you have everyday designs out in
the lab, our experience has been that 78 MHz is plenty hard to achieve
with the devices that use > 65% of their LUTS.

I suspect that Ray would say #7 is because of poor logic placement,
and I'll bet money he is correct.  So when is Xilinx going to start
taking floorplanning seriously?!  It doesn't have to mean admitting
anything is wrong with your parts - just ask your marketing people. 
They've done such a good job on the EasyPath marketing that I'm sure
they can come up with something showing that good floorplanning is
good for the economy or environment or SOMETHING!  Either that, or
improve the placer, cause it does some really silly things with real
world designs.


So when would you use EasyPath? (remember after all of the above, at
heart I *am* a fan of Xilinx)

1. Don't have resources for an ASIC group
2. Can't afford the risk and must get cost out of the product ASAP (no
time for an ASIC)
3. Can't afford the resources to respin a PCB to make a pinout change
for an ASIC.
4. Don't trust the ASIC group to have first pass success
5. When certain things converge, it may make sense.  Say the amount of
RAM you need matches up pretty good with a Virtex2 part, and it is
available in a reasonable priced package.  Or perhaps you are using
most of the I/O on your packageand you don't have an application where
power isn't one of the top issues.



> Thus, no reason to redesign your IP into an ASIC for cost reduction, just
> make the exact same decisions you would make anyway:  freeze the program,
> stop making changes, and sign up for a big order, with some NRE for the test
> program.

The phrase "some NRE" is misleading.  The NRE that was discussed with
us was on par with medium sized ASIC NRE's.  And then if that weren't
enough, don't forget the statement that you made in passing "sign up
for a big order".

I'm not kidding when I say that my manager laughed the EasyPath
marketing people out of his office (ie, I'm not the only one with this
opinion).

[...] 
> This is a revolutionary concept, one that will change the face of the use of
> programmable logic.

Wow.  Now that is truely a bold claim.  I suspect you're wrong - but I
try to approach things with an open mind, so I'm willing to wait a
while and see.

Since you're making a bold claim that we have to wait on, I'll make
one too:  As Xilinx increases logic density (say 500k logic cells),
the routing required on the die is going to start to dwarf the amount
of logic you have.  IE, an exponentially increasing amount of routing
is going to be required to guarantee moderate connectivity of logic. 
This is because even marginally good placement won't be good enough
when you have that much logic.  You're gonna need a top notch placer,
and so far, we haven't seen that out of Xilinx's software group.

I like the PROM idea that somebody else on this thread had.  Burn the
defect locations into the on-die PROM on each device that fails your
100% test.  Then put them into bin's.  No need to screw the customer
for NRE plus a big order.

Oh my, this has turned out to be longer than I intended - and I hope
it doesn't project that bad an image of Xilinx.  It's just the
EasyPath program that I'm commenting on.  If it is any relief, I own
some Xilinx stock - that's how much I believe in the company.

Best regards,

   Marc

Article: 42676
Subject: Xilinx fpgas for sale
From: "Wayne" <whalcomb@lucent.com>
Date: Tue, 30 Apr 2002 16:11:42 -0500
Links: << >>  << T >>  << A >>
4   -  xc4010 -6 pq208i
2   - xc2028xl bg352c
1   - xc95144xl cs144
2   - xc4013xl bg256c

Unused.
These are for sale.  Make offer if interested.


--
"If you're not a part of the solution,
 there's good money to be made in
 prolonging the problem."




Article: 42677
Subject: Re: SpartanIIE hold timing
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 30 Apr 2002 17:12:17 -0400
Links: << >>  << T >>  << A >>
Nicholas Weaver wrote:
> 
> In article <3CCEEE48.1B6EA5BA@yahoo.com>,
> rickman  <spamgoeshere4@yahoo.com> wrote:
> 
> >
> >> •You can deliberately delay the internal clock that drives the output in
> >> question.
> >
> >Can you give details on this?  Does it require the use of a DLL?  Can
> >the DLL be used independantly of the clock routing, that is, if I
> >already am using all four clock buffers, can I use the DLL as a fifth,
> >or do I need to delete one of the other clocks?
> 
> Ick, if you are using all the clock buffers, this would be
> problematic.  Otherwise, you drive the I/O output flip-flops with a 90
> degree phase offset from the bus clock, asuming you would still meet
> other timing constraints.
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Then I have a couple of problems.  

1) I am using all four of the global clock buffers (in fact I would like
to use five or six).  

2) Using a clock 90 degrees out of phase would give me an added 2.5nS of
delay which would delay the data output by 2.5 nS.  This may be
workable, but if the input clock is also delayed (advanced) by 2.5 nS,
then it won't work unless the clock is slowed to 12.5 nS.  There is
already very little margin on the read path.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 42678
Subject: Re: simultaneous switching of LVPECL outputs
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 30 Apr 2002 14:23:09 -0700
Links: << >>  << T >>  << A >>
Bob,

These are still plain old single ended IOs, and as measured in the lab, there is
virtually no difference in ground bounce from a regular single ended IO.

LVDS in Virtex II and Virtex II Pro are current sink and source differential
drivers, and there is actually a large benefit from such drivers.

Austin

Bob Perlman wrote:

> Austin -
>
> On Tue, 30 Apr 2002 10:01:09 -0700, Austin Lesea
> <austin.lesea@xilinx.com> wrote:
>
> >Bob,
> >
> >Spartan 2 uses external resistor networks to get the LVPECL levels, so there
> >is no benefit from differential switching as regards to ground bounce.  Each
> >single ended IO is already switching rail to rail, and driving hard.  Thus
> >even though some of the current flows out comes back in on the other pin, a
> >lot of current is flowing through power and ground.
> >
> >Austin
>
> The original poster wanted to use Spartan IIE which, if I'm reading
> the data sheet correctly, supports LVPECL differential outputs
> terminated with 100 ohms across the two signals.
>
> The VOH range is 1.92-2.28V, or ~2.1V typical; the VOL range is
> 1.06-1.43V, or~ 1.25V typical.  This means that the current through
> the terminating resistor is approximately (2.1V-1.25V)/100 = 8.5mA.
>
> When the differential signal switches, one driver switches from source
> to sink, while the other switches from sink to source.  On the ground
> side, one driver slews from sinking 8.5 mA to sinking nothing, while
> the other slews from sinking nothing to sinking 8.5mA.  Similar things
> happen on the VCC side, except that current is being sourced rather
> than sunk.
>
> Beyond a certain point, the strength of the drivers is moot; the
> current into or out of the I/O pin will be limited by the transmission
> line impedance.  If we think of the differential lines as two 50-ohm
> single-ended lines, the current needed to send a 0.85V delta V down
> each line is 17mA, which is exactly the delta you get when you stop
> sourcing 8.5mA and start sinking it, or vice versa.
>
> The balance isn't perfect, but the net di/dt on either the VCC or
> ground paths should be considerably less than for single-ended
> signals.
>
> Bob Perlman
> -----
> Cambrian Design Works
> http://www.cambriandesign.com
>
> >
> >Bob Perlman wrote:
> >
> >> Hi -
> >>
> >> On Tue, 30 Apr 2002 11:34:47 -0400, Theron Hicks
> >> <hicksthe@egr.msu.edu> wrote:
> >>
> >> >Hi,
> >> >    I am seriously considering using a spartan2e to serve as a clock
> >> >distribution generator for a lvpecl clock system.  This clock system
> >> >will be driving a total of 17 differential clocks.  When I price the
> >> >LVPECL chips the spartan2e looks very competetive.  Also, it would give
> >> >me the clock DLL to clean up my system clock.  The question is that I
> >> >have a total of 34 output lines that should be switching at the same
> >> >time.  The spec says 12 power and ground pairs in the chip and 3
> >> >simulatneous outputs per pair.  Thus a total of 36 outputs. (one spare
> >> >pair for me.)  How do I split these up over the 12 power/ground pairs?
> >> >I count 16 grounds and 8 VCC0 on the tq144 package (XC2S50E).  Where do
> >> >I get 12 power/ground pairs from these 24 pins?
> >>
> >> If you're using differential outputs, the power and ground di/dt
> >> should be significantly less than what you'd see for single-ended
> >> signals.  Assuming that the true and complementary transitions occur
> >> in unison, one driver should be increasing its ground or VCC current
> >> as the other driver's current is decreasing.  The match isn't perfect,
> >> but it should be pretty good.
> >>
> >> Ask Xilinx for diff pair power/ground guidelines; they should be less
> >> stringent than the  guidelines for single-ended signals.
> >>
> >> Bob Perlman
> >> -----
> >> Cambrian Design Works
> >> http://www.cambriandesign.com
> >>


Article: 42679
Subject: Re: power supply sequencer for Virtex II
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 30 Apr 2002 14:24:21 -0700
Links: << >>  << T >>  << A >>
Jim,

Sounds like something I would not want to use:  just a simple linear current
limiting response, please.

Austin

Jim Granville wrote:

> Austin Lesea wrote:
> >
> > YD,
> >
> > Texas Instruments has a web page devoted to powering Virtex and Virtex
> > E.
> >
> > National Semi, Linear Tech, Elantec, and many others all make either low
> > dropout linear regulators, and/or switchers that can be used (and we use
> > ourselves).
> >
> > Read app note 158, 450, and 451.
> >
> >  http://www.support.xilinx.com/apps/appsweb.htm
> >
> > Look up 158 under Virtex, and 450 and 451 under Spartan II.
> >
> > Avoid parts that trip, foldback, or shut off.  It is OK to trip,
> > foldback, or shutoff only after a time delay (say 20 ms) in order to
> > meet UL or VDE safety requirements.
> >
> > Many regulator parts today will start turning on, sense the current, and
> > if the current exceeds some threshold, they will turn off, and then
> > start up again.  This is exactly the kind of behavior you must avoid.
> > It will terminally confuse the startup logic of the Virtex, Virtex E,
> > Spartan II, Spartan IIE, and they will not power ON.
> >
> > The regulator parts which have thermal shutdowns, and are linear current
> > limiting all work fine.
> >
> > Avoid parts that say things like "high speed" as the FPGA is not an
> > Intel chip, and doesn't require 20 amperes in 100 ns.
> >
> > Read the data sheet and be sure you can supply at least the minimum
> > required current for power ON (ie 500 mA for most Virtex C grade parts).
> >
> > Austin
>
>  What about the so called snap-action regulators ?
>
> -jg


Article: 42680
Subject: Re: Xilinx Easypath- Selling parts with known defects
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 30 Apr 2002 14:34:17 -0700
Links: << >>  << T >>  << A >>



Jim,

There is no issue with reliability:  gate arrays ship with unknown defects
present, and they work just fine forever.

What are planning is actually much, much better.

We have the complete reliabilty report ready for those who wish to review it
(and believe me, the question was asked from day one by all customers we
approached, and everyone so far is completely satisfied with the study).

Austin


Jim Granville wrote:

> Austin Lesea wrote:
> >
> > All,
> <snip>
> > Do we care where the non-functional parts and pieces are?  No.  Do we
> > want to spend anytime trying to identify what is broken?  No.  Do we
> > want to fill experimenter bags with bogus parts that could be
> > remarked, and sold on the grey market and cause untold grief for our
> > real paying customers?  Absolutely not.  (anyone remember the grief on
> > bad EPROMs that were re-marked as good, and resold about twenty years
> > ago?).
>
>  I had seen this as a risk exposure, and since you have now mentioned
> it,
> what actually stops these devices comming back to bite users ?
>
> > This is a revolutionary concept, one that will change the face of the
> > use of programmable logic.
>
>  Sorry, but not at the MOQ and NRE's....
>
>  As to revolutionary ? - I've heard stories about russian programmers
> being given chips with an errata tagged to each device.
> They had to work around the errata on a batch basis !
>
> -jg




Article: 42681
Subject: Re: power supply sequencer for Virtex II
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 01 May 2002 10:09:57 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Jim,
> 
> Sounds like something I would not want to use:  just a simple linear current
> limiting response, please.

 My understanding of 'snap action' regulators, is they deliver a fast
Vcc ramp, on
slower inputs, by waiting until the Vin is high enough to delivery Vout.
- ie unlike simple linear regulators, they hold OUT off, until Vin is
reasonably
high, then enable it.

 Given the Vcc issues of many Logic devices, it sounded like a good idea
to me.
 
- jg

Article: 42682
Subject: Re: Xilinx Easypath- Selling parts with known defects
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 01 May 2002 10:12:45 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Jim,
> 
> There is no issue with reliability:  gate arrays ship with unknown
> defects present, and they work just fine forever.
> 
> What are planning is actually much, much better.
> 
> We have the complete reliabilty report ready for those who wish to
> review it (and believe me, the question was asked from day one by all
> customers we approached, and everyone so far is completely satisfied
> with the study).

You missed the point. You mentioned :
" parts that could be remarked, and sold on the grey market 
 and cause untold grief for our real paying customers? "

My question, was what stops that happening ? ( customer honesty ? ;)

-jg

Article: 42683
Subject: Placement, Retiming and Performance
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Tue, 30 Apr 2002 22:13:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <15881dde.0204301227.16749c14@posting.google.com>,
Marc Randolph <mrand@my-deja.com> wrote:
>7. Despite Xilinx showing that they can run incredibly high
>frequencies through their parts, when you have everyday designs out in
>the lab, our experience has been that 78 MHz is plenty hard to achieve
>with the devices that use > 65% of their LUTS.
>
>I suspect that Ray would say #7 is because of poor logic placement,
>and I'll bet money he is correct.  So when is Xilinx going to start
>taking floorplanning seriously?!  It doesn't have to mean admitting
>anything is wrong with your parts - just ask your marketing people. 
>They've done such a good job on the EasyPath marketing that I'm sure
>they can come up with something showing that good floorplanning is
>good for the economy or environment or SOMETHING!  Either that, or
>improve the placer, cause it does some really silly things with real
>world designs.

There are TWO big changes which need to be made to the toolflows:
either at the Xilinx backend level or one up (during synthesis).

The first is datapath placement.  Simulated anneiling is SOOO F)@#*$@
borken for datapaths that tweaking it is not really going to help.
I've argued that it is the synthesis tool's job, but barring that, the
placer should do a much better job.


The second is C-slow retiming.  Many synthesis tools (eg, Symplify
Pro, FPGA Compiler) already support retiming (moving registers to
balance delay paths).  

Allowing C-slowing within a module is a very small extension (replace
each logical register with C registers before applying retiming, and
two different memory options: shared or split), but a huge win in
performance and best done in the tools.

If there are no feedback loops, this is a time-C repipelining.
Otherwise, it is creating a block which interleaves C separate
streams.  There are huge numbers of "free" registers in many of these
75 MHz designs.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 42684
Subject: Re: Xilinx Easypath- Selling parts with known defects
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Tue, 30 Apr 2002 22:17:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3CCF16DD.77EF@designtools.co.nz>,
Jim Granville  <jim.granville@designtools.co.nz> wrote:
>You missed the point. You mentioned :
>" parts that could be remarked, and sold on the grey market 
> and cause untold grief for our real paying customers? "

a)  How big is the gray market for the top size xilinx chips?

b)  Plain, evident packaging.  If you laser enscribe the package, AND
drill a small, known hole or small, known cut in the side of the
package, such packages are instantly verifiable as being from the
easypath side of things.  OR even just use a slightly different alloy
(enough to make a color difference) for the metal on the BGA.


>My question, was what stops that happening ? ( customer honesty ? ;)
>
>-jg


-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 42685
Subject: Re: simultaneous switching of LVPECL outputs
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Tue, 30 Apr 2002 22:18:50 GMT
Links: << >>  << T >>  << A >>
Austin - 

I know they're conventional single-ended I/Os; I thought I made that
clear in my analysis (I assumed that the drivers both source and sink
current; real PECL drivers only source current).   I'm not sure why
you mentioned LVDS drivers, but they also source and sink.

If you're not seeing lower ground bounce for Spartan IIE
differerential LVPECL in the lab, it would be useful to figure out
why.  If you're not seeing lower ground bounce, I have to wonder if
the true and complementary transitions are simultaneous or
near-simultaneous.  If they're not, that could spell big trouble for
the receiver.

When lab results are counter-intuitive, it pays to find out why.

Bob Perlman
-----
Cambrian Design Works
http://www.cambriandesign.com


On Tue, 30 Apr 2002 14:23:09 -0700, Austin Lesea
<austin.lesea@xilinx.com> wrote:

>Bob,
>
>These are still plain old single ended IOs, and as measured in the lab, there is
>virtually no difference in ground bounce from a regular single ended IO.
>
>LVDS in Virtex II and Virtex II Pro are current sink and source differential
>drivers, and there is actually a large benefit from such drivers.
>
>Austin
>
>Bob Perlman wrote:
>
>> Austin -
>>
>> On Tue, 30 Apr 2002 10:01:09 -0700, Austin Lesea
>> <austin.lesea@xilinx.com> wrote:
>>
>> >Bob,
>> >
>> >Spartan 2 uses external resistor networks to get the LVPECL levels, so there
>> >is no benefit from differential switching as regards to ground bounce.  Each
>> >single ended IO is already switching rail to rail, and driving hard.  Thus
>> >even though some of the current flows out comes back in on the other pin, a
>> >lot of current is flowing through power and ground.
>> >
>> >Austin
>>
>> The original poster wanted to use Spartan IIE which, if I'm reading
>> the data sheet correctly, supports LVPECL differential outputs
>> terminated with 100 ohms across the two signals.
>>
>> The VOH range is 1.92-2.28V, or ~2.1V typical; the VOL range is
>> 1.06-1.43V, or~ 1.25V typical.  This means that the current through
>> the terminating resistor is approximately (2.1V-1.25V)/100 = 8.5mA.
>>
>> When the differential signal switches, one driver switches from source
>> to sink, while the other switches from sink to source.  On the ground
>> side, one driver slews from sinking 8.5 mA to sinking nothing, while
>> the other slews from sinking nothing to sinking 8.5mA.  Similar things
>> happen on the VCC side, except that current is being sourced rather
>> than sunk.
>>
>> Beyond a certain point, the strength of the drivers is moot; the
>> current into or out of the I/O pin will be limited by the transmission
>> line impedance.  If we think of the differential lines as two 50-ohm
>> single-ended lines, the current needed to send a 0.85V delta V down
>> each line is 17mA, which is exactly the delta you get when you stop
>> sourcing 8.5mA and start sinking it, or vice versa.
>>
>> The balance isn't perfect, but the net di/dt on either the VCC or
>> ground paths should be considerably less than for single-ended
>> signals.
>>
>> Bob Perlman
>> -----
>> Cambrian Design Works
>> http://www.cambriandesign.com
>>
>> >
>> >Bob Perlman wrote:
>> >
>> >> Hi -
>> >>
>> >> On Tue, 30 Apr 2002 11:34:47 -0400, Theron Hicks
>> >> <hicksthe@egr.msu.edu> wrote:
>> >>
>> >> >Hi,
>> >> >    I am seriously considering using a spartan2e to serve as a clock
>> >> >distribution generator for a lvpecl clock system.  This clock system
>> >> >will be driving a total of 17 differential clocks.  When I price the
>> >> >LVPECL chips the spartan2e looks very competetive.  Also, it would give
>> >> >me the clock DLL to clean up my system clock.  The question is that I
>> >> >have a total of 34 output lines that should be switching at the same
>> >> >time.  The spec says 12 power and ground pairs in the chip and 3
>> >> >simulatneous outputs per pair.  Thus a total of 36 outputs. (one spare
>> >> >pair for me.)  How do I split these up over the 12 power/ground pairs?
>> >> >I count 16 grounds and 8 VCC0 on the tq144 package (XC2S50E).  Where do
>> >> >I get 12 power/ground pairs from these 24 pins?
>> >>
>> >> If you're using differential outputs, the power and ground di/dt
>> >> should be significantly less than what you'd see for single-ended
>> >> signals.  Assuming that the true and complementary transitions occur
>> >> in unison, one driver should be increasing its ground or VCC current
>> >> as the other driver's current is decreasing.  The match isn't perfect,
>> >> but it should be pretty good.
>> >>
>> >> Ask Xilinx for diff pair power/ground guidelines; they should be less
>> >> stringent than the  guidelines for single-ended signals.
>> >>
>> >> Bob Perlman
>> >> -----
>> >> Cambrian Design Works
>> >> http://www.cambriandesign.com
>> >>


Article: 42686
Subject: Re: power supply sequencer for Virtex II
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 30 Apr 2002 15:20:04 -0700
Links: << >>  << T >>  << A >>
Jim,

I saw something like this just recently that was a problem.

The power supply (this was a switcher) waiting for the input to get to say about 2
volts, and then it turned ON.

The output ramped from 0 to 1.8 Volts in about 40 microseconds (!!! Wow !!!).  Now
as you may know we specify our minimum start up current from 2 ms to 50 ms, and
anything below 2 ms is considered unknown territory and isn't tested, or
characterized.  Now we know that the current needed to reliably start up a V1000E
for example, in 40 us may be anywhere from 2 amperes to ten amperes.  This is
partly from the bypass capacitors on the board (I = C dV/dt), and partly from the
turn on behavour of the V1000E (more current with faster ramps).

Now if the power supply had just continued to supply a steady linearly increasing,
or at least not a decreasing current, everything would have been OK.

But no, the 'evil' supply folded back to 1/4 of the peak current it was
delivering, and then the poor V1000E was stuck at 0.6 Vdc on Vccint forever.

The solution was to remove the foldback to 1/4 Imax, and to slow down the rate at
which the power supply woke up after the input voltage got to the 2 V input level.

If you have a data sheet URL, just send it to me directly, and I would be happy to
look at it and comment.

I do not want to talk about specific products here, as the power supply vendors
have all done a wonderful job supporting Xilinx, and it isn't that they have bad
products (they have wonderful parts), they have some products that are not well
matched to the FPGA powering application, and others which can be used, but
require some modifications from the applications drawings in their data sheets.

Austin



Jim Granville wrote:

> Austin Lesea wrote:
> >
> > Jim,
> >
> > Sounds like something I would not want to use:  just a simple linear current
> > limiting response, please.
>
>  My understanding of 'snap action' regulators, is they deliver a fast
> Vcc ramp, on
> slower inputs, by waiting until the Vin is high enough to delivery Vout.
> - ie unlike simple linear regulators, they hold OUT off, until Vin is
> reasonably
> high, then enable it.
>
>  Given the Vcc issues of many Logic devices, it sounded like a good idea
> to me.
>
> - jg


Article: 42687
Subject: Re: Altera Nios - ptf documentation
From: gcalac@altera.com (Alan Calac)
Date: 30 Apr 2002 15:23:42 -0700
Links: << >>  << T >>  << A >>
Mr. Finc, 

A complete PTF user guide is currently being created.  If it's okay, I
can email you a preliminary copy early next week.

Per your questions, the PTF format has changed and expanded from Nios
v1.1.  The new document mentioned above will contain a description of
-every- legal PTF setting known to mankind.

Alan Calac
Altera Corp.

"Matjaz Finc" <matjaz.finc@fe.uni-lj.si> wrote in message news:<aajeh1$a3c$1@planja.arnes.si>...
> Hello!
> 
> Can anyone advise where can I find the documentation about a complete list
> of ptf sections and assignments? According to Altera's manual it should be
> at http://www.altera.com/nios but no sign of it. I'd like the ptf specs for
> Nios 2.0 because I already have it for 1.1 (is there any difference or new
> feature?).
> 
> Regards,
> Matjaz Finc

Article: 42688
Subject: Re: Xilinx Easypath- is it a fake?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 30 Apr 2002 15:38:42 -0700
Links: << >>  << T >>  << A >>



Jim,

I suppose if one got a hold of a lot of EasyPath parts, they could somehow
figure out what they really are (they are not marked with their Xilinx
standard part number, but with an 'ASIC like' code part number--- you know,
like ABH0735494735-012, and a date code).

Then they would have to erase or mask the old markings, and try to copy the
new marking.  Since the marking is a laser etch now, that is kind of
tough.  In fact I hate it because I can't read it easily....although I
suppose my eyesight isn't as good as it used to be either.

They would have to fake the markings pretty well, so they at least looked
credible.

Now one phone call to us, and a customer would know instantly the parts
were bogus, as we track what gets shipped where, and to whom.

Austin


Jim Granville wrote:

> Austin Lesea wrote:
> >
> > Jim,
> >
> > There is no issue with reliability:  gate arrays ship with unknown
> > defects present, and they work just fine forever.
> >
> > What are planning is actually much, much better.
> >
> > We have the complete reliabilty report ready for those who wish to
> > review it (and believe me, the question was asked from day one by all
> > customers we approached, and everyone so far is completely satisfied
> > with the study).
>
> You missed the point. You mentioned :
> " parts that could be remarked, and sold on the grey market
>  and cause untold grief for our real paying customers? "
>
> My question, was what stops that happening ? ( customer honesty ? ;)
>
> -jg



Article: 42689
Subject: XC4000 readback woes
From: John Williams <j2.williams@qut.edu.au>
Date: Wed, 01 May 2002 08:43:58 +1000
Links: << >>  << T >>  << A >>
Hi,

I'm using an XC4010E on an XS40 board, and am trying to implement a
simple parallel cable readback interface.  I've scoured the Xilinx web
pages, newsgroups, and the web in general, and am having great
difficulty doing what appears on the surface to be fairly
straight-forward.  The problem is not the parallel interface, but simply
trying to instantiate a readback block and get the readback going.  

I'm using FPGA Express under ISE4.2i targetting the XC4010E.

I've tried using both schematic capture and VHDL, and whatever I do, it
seems like the readback block is being "optimised out".  I've even tried
attaching dummy logic to the inputs and outputs to force the signals to
remain, but it still happens.  There's a Xilinx Answer which proposes
the following VHDL code to implement readback:

-- begin rb_vhdl.vhd

entity rb_vhdl is 
  port(trig: in bit; 
       data, rip: out bit); 
end rb_vhdl; 

architecture inst of rb_vhdl is 

component RDBK 
  port(trig: in bit; 
       data, rip: out bit); 
end component; 

begin 

  U1: RDBK port map(trig, data, rip); 

end inst; 

-- end rb_vhdsl.vhd

I've synthesised this, and received the warning:
"Warning: The net '/rb_vhdl/trig' has no load.  (FPGA-CHECK-7)"

I continued, and constrained the inputs and outputs to external ports so
I can excite the clock and trig signals (and watch for RIP going high),
however P&R fails saying there are no connections to route.  I checked
the map report and found this:

Loadless block "U1" (RDBK) removed.
 The signal "N_trig" is loadless and has been removed.
  Loadless block "C2" (IBUF) removed.
   The signal "trig" is loadless and has been removed.
    Loadless block "trig" (X_IPAD) removed.

Which seems to support the idea that the synth tools () are throwing
away my request for a readback block.  I've even surrounded the readback
block with explicit IBUFs and OBUFs, but get similar messages to the
effect that the readback block basically isn't there.

I've seen references to the mode pins M0 and M1, but nothing explicit. 
The Xilinx doco states pretty plainly that for the 4000 series trig,
clk, rip and data are just normal nets and can be routed to any user
IOB, so I don't see what the problem is.

Can anyone please give a clear description of what is required to get
the readback connected?  After that I'll start worrying about actually
decyphering the stream - for now i'd be overjoyed to see the RIP line go
high!

Thanks in advance,

John

PS A contradiction:  In the 4000.pdf product specification document, the
readback section has a timing table giving contraints on the readback
clock and associated signals.  For the readback clock signal, the worst
case min and max high/low times are 250ns and 500ns respectively.  This
corresponds to a worst case readback clock requirement between 1 and 2
MHz.  However, in the xilinx app note "Using the XS4000 Readback
Capability" it says the readback clock must be between 10KHz and 1MHz. 
On the final page, there's the usual diagram and timing table, but the
timing figures are blanked out, with the words "Preliminary" stamped
across it.  Any clues what's going on here?

Article: 42690
Subject: Re: Hack an bitstream file for AT40Kxx
From: John Williams <j2.williams@qut.edu.au>
Date: Wed, 01 May 2002 08:53:04 +1000
Links: << >>  << T >>  << A >>

Ulf Samuelsson wrote:

> If you take one year subscribtion to a magazine, and do not renew, is
> it unfair that they do not continue send you magazines?

I don't think this is an appropriate analogy - if you've paid for the
software once, you shouldn't have to keep paying for it.   Of course, if
you don't pay, you don't expect dedicated tech support, or continued
updates, but in my opinion that should be be the choice of the user.  

A better analogy I think is whether, once you buy a book, you should
have to keep paying to read it year after year.  You wouldn't expect to
be sent the latest edition for free, nor would you expect to be sent
corrections to paste in, but you can keep and read the original copy
which you bought.

However, this is probably not the best place to get into a debate on
whether software is a product or a service :)

Regards,

John

Article: 42691
Subject: Virtex Evolution ( Deltas )
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 30 Apr 2002 16:18:21 -0700
Links: << >>  << T >>  << A >>



> Ray Andraka wrote:
>
> > A summary sheet listing the deltas (in detail) from the previous family would
> > probably make a lot of people happy.

As promised last weekend, here it is:


Changes from Virtex-II to Virtex-II Pro

Virtex-II Pro adds dedicated logic, 4 to 16 Multi-Gigabit Transceivers and 0 to 4
PowerPC microprocessors per chip. Each MGT takes the place of one BlockRAM at the
top or bottom of the chip. Each PPC, (with caches, MMU and wide interfaces) takes
the space of 128 CLBs plus 8 BlockRAMs

The rest of the architecture is unchanged; same CLBs, IOBs, BlockRAMs,
multipliers, DCMs, and the same routing structure.
Same I/O interface capabilities, including on-chip termination.

All circuits are re-laid out for the new 130 nm technology with nine layers of
metal.  (Virtex-II uses eight layers.)

Same Vccint of 1.5 V, but Vccaux changed from 3.3 V to 2.5 V
Each MGT has its own supply and ground pins.

No bitstream or package-pin-out compatibility with other families.

Nomenclature is different. Here are the approximate logic equivalents, ignoring
MGT and microprocessor capabilities.

XC2VP2  ~ XC2V250
XC2VP4 ~ XC2V500
XC2VP7 ~ XC2V1000
XC2VP20 ~ XC2V2000
XC2VP50 ~ XC2V4000



Changes from Virtex-E to Virtex-II

Virtex-II is a major redesign of the Virtex architecture.

The CLB has now 8 LUTs ( 4 slices) from 4 LUTs and 2 slices in Virtex and
Virtex-E.
The BlockRAM is >4 times bigger, and has  x9, x18, and x36 option
The BlockRAM has 3 options for read during write ( read first, write first, don't
read)
There is a dedicated 18 x 18 (max) 2-s complement multiplier close to each
BlockRAM
The DLL has grown to be a Digital Clock Manager with options for more multiply and
devide ratios, simultaneous multipliy and divide ( frequency synthesis) and
programmable phase delay.
Support for many I/O standards is added, and there is an option for on-chip
termination ( serial or parallel)

Virtex-II uses 180 nm micron technology with 8 layers of metal..

The internal logic uses Vccint = 1.5 V, Vccaux is 3.3 V, Vccio is 1.5...3.3 V
Virtex-II is not directly 5-V compatible ( needs external current-limiting
resistor)
Virtex-II (and Virtex-II Pro) have eliminated the large power-on inrush current.

Viretx-II is not bitstream or package-pin-out compatibe with other families.


Changes from Virtex to Virtex-E

Virtex-E is a minor change, mainly a shrink for higher speed and cost reduction.
The basic architecture is identical to Virtex, but the family now extends to
larger sizes.
Additional I/O standards are supported, notably LVDS ( with 2 pins per signal).
There are eight DLLs, vs four in Virtex.

I/O pins are 3-V tolerant, but need a 100 Ohm external resistor for 5-V tolerance.

Not 5-V PCI compatible ( use Virtex or Spartan-II instead).
Change in the banking rules.  LVTTL, LVCMOS2, and PCI inputs are powered from
Vccio.

Vccint is 1.8 V, instead of 2.5 V for Virtex. This is due to 180 nm processing
technology.

Virtex-E is not bitstream compatibel with other families.
Virtex-E is almost package-pin-out compatible with Virtex, see pin-out
documentation for details.
=============================================
This is not a substitute for studying the data sheets.
Please e-mail me if you find any errors or omissions
peter@xilinx.com






Article: 42692
Subject: Re: Altera Nios - master/slave peripheral
From: gcalac@altera.com (Alan Calac)
Date: 30 Apr 2002 16:25:22 -0700
Links: << >>  << T >>  << A >>
Hello Mr. Finc, 

Using the multi-master capabilities of the Avalon bus, you can easily
add a DMA peripheral to your Nios system.  The DMA allows most other
peripherals to act as a master on the bus.  The Nios CPU sets up the
DMA transaction by specifying the source and destination peripherals
(in your case, peripheral source and memory destination), and the DMA
peripheral carries out the transaction.

For more information, check out: Altera application note #184:
Simultaneous Multi-Mastering with the Avalon Bus
(http://www.altera.com/literature/an/an184.pdf).  Another excellent
resource for this type of application is the Nios tutorials that came
on the Nios 2.0 CD-ROM.  In particular, the SMM tutorial might be of
interest.

Alan Calac
Altera Corp.


"Matjaz Finc" <matjaz.finc@fe.uni-lj.si> wrote in message news:<aajfgi$aku$1@planja.arnes.si>...
> Hello again!
> 
> I would like to make a Nios peripheral that receives some data (as slave
> peripheral) from Nios cpu and after some processing pass it directly (as
> master) to shared RAM and let Avalon do the arbitration. How do I implement
> the master fuctionality and how can I address RAM directly through Avalon in
> the ptf file or SOPC builder?
> 
> Please advise.
> 
> Regards,
> Matjaz Finc

Article: 42693
Subject: Re: Xilinx Easypath- Selling parts with known defects
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Wed, 1 May 2002 00:51:12 +0100
Links: << >>  << T >>  << A >>
Jan Gray wrote
> > Another cut at this can be formed by browsing fpgacpu.org, where Jan
> > is proposing hundreds of processors per FPGA.  The record I have seen
> > (not on fpgacpu.org) is over 800 processors in one of the big Virtex-EM
> > parts.  Three processors per block RAM - giving some pretty severe
> > limitations on control flow changes.  The design was fractionally
> > application-specific :)
>
> Can you please provide a reference, or is it a proprietary design?

Proprietary - it was in a proposal document.

The application was simulation, which is probably one of the few
reasonable apps given the limitations of this sort of dense
architecture.  Each processor a maximum instruction memory of 256
10-bit instructions, though looping was allowed.  The idea was that
a master processor gave the 'go' signal to the array, then each CPU
ran until it hit a 'stop' instruction.  When all the CPUs had asserted
'stop', and side effects had stopped, the master processor could start
off another cycle.  As you can see, the 256-instruction limit would not
be a problem for this domain, though it turned out to be expensive
to encode immediates.

FWIW, I am not that impressed by this sort of architecture - it amounts
to implementing a slab of 'mini-transputers' in an FPGA fabric, with
a pretty low quotient of new thinking from an FPGA angle.

Another point - the architecture was optimized for big implementations,
typically 100+ FPGAs, with maybe 100,000 CPUs.  As Mike Flynn, the
architecture god, said "How many problems can be stamped to death by a
army of bunny rabbits?"






Article: 42694
Subject: Xilinx MicroBlaze, Opinion?
From: stant@attglobal.net (Vernon L. Stant)
Date: Wed, 01 May 2002 00:11:06 GMT
Links: << >>  << T >>  << A >>
Has anyone used the MicroBlaze? How did it work out?

Thanks!

Vern

Article: 42695
Subject: Re: EDIF parser (perl)
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Wed, 1 May 2002 01:21:03 +0100
Links: << >>  << T >>  << A >>

Laurent Gauch wrote
> I am searching an EDIF parser for automatic documentation generation.
>
> where can I get some scripts?

I don't want to discourage your search, but somewhere in the PERL
FAQ it discusses the problems PERL has with grammars like EDIF...





Article: 42696
Subject: Re: Altera Nios - ptf documentation
From: w.moyer2@verizon.net (Bill Moyer)
Date: 30 Apr 2002 17:45:01 -0700
Links: << >>  << T >>  << A >>
"Matjaz Finc" <matjaz.finc@fe.uni-lj.si> wrote in message news:<aajeh1$a3c$1@planja.arnes.si>...
> Hello!
> 
> Can anyone advise where can I find the documentation about a complete list
> of ptf sections and assignments? According to Altera's manual it should be
> at http://www.altera.com/nios but no sign of it. I'd like the ptf specs for
> Nios 2.0 because I already have it for 1.1 (is there any difference or new
> feature?).
> 
> Regards,
> Matjaz Finc

Look on http://www.altera.com/literature/lit-nio.html  The SOPCBuilder
data sheet will have all of the information you need.

-------------------------------------------------
I am an Altera FAE.  I am participating in this 
forum on my own time, please direct all techincal 
questions to http://mysupport.altera.com
-------------------------------------------------

Article: 42697
Subject: Re: Altera Nios - master/slave peripheral
From: w.moyer2@verizon.net (Bill Moyer)
Date: 30 Apr 2002 17:46:27 -0700
Links: << >>  << T >>  << A >>
"Matjaz Finc" <matjaz.finc@fe.uni-lj.si> wrote in message news:<aajfgi$aku$1@planja.arnes.si>...
> Hello again!
> 
> I would like to make a Nios peripheral that receives some data (as slave
> peripheral) from Nios cpu and after some processing pass it directly (as
> master) to shared RAM and let Avalon do the arbitration. How do I implement
> the master fuctionality and how can I address RAM directly through Avalon in
> the ptf file or SOPC builder?
> 
> Please advise.
> 
> Regards,
> Matjaz Finc

Again, all the information you need is available on-line at:
http://www.altera.com/literature/lit-nio.html


-------------------------------------------------
I am an Altera FAE.  I am participating in this 
forum on my own time, please direct all techincal 
questions to http://mysupport.altera.com
-------------------------------------------------

Article: 42698
Subject: Spartan outputs to 3.3V DRAMs...
From: "Austin Franklin" <austin@dark87room.com>
Date: Wed, 1 May 2002 00:56:09 -0400
Links: << >>  << T >>  << A >>
I have to update a board that has a Spartan on it that interfaces to memory.
The memory I have to use is 3.3V LVTT, changed from 5V TTL.  From what the
specs for the Spartan and memory say, the DRAM inputs to the Spartan aren't
a problem, but I am concerned about the outputs from the Spartan to the
DRAM.  The DRAM says it can tolerate VCC (3.3V) + .3V, or 3.6V (and 15ns of
VCC + 1.6V).  The TTL output from the Spartan is min 2.4V, with no max.

Anyone have any experience interfacing a Spartan to a 3.3Vmemory?  Switching
to an XL isn't a really good option, as I do not believe they are pin
compatible with their non-XL counterpart (or are they, except for VCC
obviously, which is an easy change?) and the PCB routing etc. from the old
design can be used, except for the DRAM to Spartan interface, and 3.3V
regulator, which are reasonably easy to re-do...

Any experience/input (sic) would be greatly appreciated.

Austin




Article: 42699
Subject: Re: Spartan outputs to 3.3V DRAMs...
From: "Austin Franklin" <austin@dark87room.com>
Date: Wed, 1 May 2002 01:53:37 -0400
Links: << >>  << T >>  << A >>
I did check the Spartan vs Spartan XL pinouts...and they are the same
(except for a few configuration pins), and obviously VCC has to change.  I
measured the output of a Spartan to the DRAMs, and it was 4V+, so that's not
going to work...default is TTL, so I believe this is TTL output.  Looks like
I have to change to an XL...  My outputs have to be registered in the IOBs
too, so that probably precludes my using any I/O open collector type trick.

Anyone know if the 5V PROMs will work fine with the SpartanXL part?

"Austin Franklin" <austin@dark87room.com> wrote in message
news:ucutbb7if6khe3@corp.supernews.com...
> I have to update a board that has a Spartan on it that interfaces to
memory.
> The memory I have to use is 3.3V LVTT, changed from 5V TTL.  From what the
> specs for the Spartan and memory say, the DRAM inputs to the Spartan
aren't
> a problem, but I am concerned about the outputs from the Spartan to the
> DRAM.  The DRAM says it can tolerate VCC (3.3V) + .3V, or 3.6V (and 15ns
of
> VCC + 1.6V).  The TTL output from the Spartan is min 2.4V, with no max.
>
> Anyone have any experience interfacing a Spartan to a 3.3Vmemory?
Switching
> to an XL isn't a really good option, as I do not believe they are pin
> compatible with their non-XL counterpart (or are they, except for VCC
> obviously, which is an easy change?) and the PCB routing etc. from the old
> design can be used, except for the DRAM to Spartan interface, and 3.3V
> regulator, which are reasonably easy to re-do...
>
> Any experience/input (sic) would be greatly appreciated.
>
> Austin
>
>
>





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